[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ipcdn] Size of docsDevSwFilename in draft-ietf-ipcdn-device-mibv2-06.txt
(I thought I had sent this but it was stuck in my draft folder, and just saw Rich's note - sorry).
Azlina,
Good point, I forgot that the device mib is *not* a "new" mib and we can't increase the upper bound.
We have a couple of options:
- do nothing (operators should get their http server hostnames and URL down to 64 chars)
- keep docsDevSwFilename for TFTP and add a new object docsDevSwFilenameURL for http
(this has the advantage to leave the DOCSIS implementations intact on this object)
- deprecate docsDevSwFilename and a new object docsDevSwFilenameURL for tftp and http
Since this new object is moslty required for PAcketCable Standalone MTAs, I'm ok with option 2 above.
Jean-François
> -----Original Message-----
> From: Azlina Ahmad [mailto:azlina@cisco.com]
> Sent: Friday, October 31, 2003 11:01 AM
> To: Jean-Francois Mule
> Cc: Woundy, Richard; ipcdn@ietf.org
> Subject: Re: [ipcdn] Size of docsDevSwFilename in
> draft-ietf-ipcdn-device-mibv2-06.txt
>
>
> Jean-Francois,
> I believe we have extended the upper bound of a mib
> object in the past :) However, per RFC2578 Section 9 rule (3)
> defined that "the size in octets
> of the value may be refined by raising the lower-bounds, by
> reducing the
> upper-bounds, and/or by reducing the alternative size
> choices." So, extending this size may not be permitted.
>
> Thanks,
> Azlina
>
> Jean-Francois Mule wrote:
> > Rich,
> >
> > Reviewing the cable device v2 mib to create the compliance
> statement
> > for PacketCable Standalone MTAs, we noticed that the object size is
> > limited to 64 chars. While this may be plenty for tftp
> filenames, it
> > could be a bit restrictive in the case of HTTP download.
> >
> > Therefore, we'd like to recommend the following:
> > - the docsDevSwFilename object definition be extended to a size of
> > 128 at a minimum
> > - the compliance statement for v2 DOCSIS CM restrict the
> implementation to 64 for those devices so that there is no
> requirement change for DOCSIS
> >
> > docsDevSwFilename OBJECT-TYPE
> > SYNTAX SnmpAdminString (SIZE (0..64))
> > MAX-ACCESS read-write
> > STATUS current
> > DESCRIPTION
> > "The filename of the software image to be downloaded via
> > TFTP, or the abs_path (as defined in RFC2616) of the
> > software image to be downloaded via HTTP.
> >
> > Unless set via SNMP, this is the filename or abs_path
> > specified by the provisioning server during the boot
> > process, that corresponds to the software version that
> > is desired for this device.
> >
> > If unknown, the value of this object is the
> empty string."
> > ::= { docsDevSoftware 2 }
> >
> > Comments appreciated.
> > Jean-François
> >
> >>-----Original Message-----
> >>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> >>Sent: Monday, October 27, 2003 3:10 PM
> >>Cc: ipcdn@ietf.org
> >>Subject: I-D ACTION:draft-ietf-ipcdn-device-mibv2-06.txt
> >>
> >>
> >>A New Internet-Draft is available from the on-line Internet-Drafts
> >>directories. This draft is a work item of the IP over Cable Data
> >>Network Working Group of the IETF.
> >>
> >> Title : Cable Device Management Information
> >>Base for DOCSIS compliant Cable Modems and Cable Modem Termination
> >>Systems
> >> Author(s) : R. Woundy
> >> Filename : draft-ietf-ipcdn-device-mibv2-06.txt
> >> Pages : 79
> >> Date : 2003-10-27
> >>
> >>This memo is a draft revision of the standards track RFC-2669.
> >>Please see 'Revision Descriptions' below for a description of
> >>changes. This document will obsolete RFC-2669 when accepted. This
> >>memo defines a portion of the Management Information Base (MIB) for
> >>use with network management protocols in the Internet community. In
> >>particular, it defines a basic set of managed objects for SNMP-
> >>based management of DOCSIS compliant Cable Modems and Cable Modem
> >>Termination Systems. This memo is a product of the IPCDN
> >>working group within the Internet Engineering Task Force.
> >>Comments are solicited and should be addressed to the working
> >>group's mailing list at ipcdn@ietf.org and/or the author.
> >>
> >>A URL for this Internet-Draft is:
> >>http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mi
> >
> > bv2-06.txt
> >
> > To remove yourself from the IETF Announcement list, send a
> message to
> > ietf-announce-request with the word unsubscribe in the body
> of the message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login
> with the username "anonymous" and a password of your e-mail
> address. After logging in, type "cd internet-drafts" and then
> > "get draft-ietf-ipcdn-device-mibv2-06.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > mailserv@ietf.org.
> > In the body type:
> > "FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-06.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility. To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command. To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader. Different MIME-compliant
> mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> > _______________________________________________
> > IPCDN mailing list
> > IPCDN@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ipcdn
> >
>
>
>
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn