RE: [ipcdn] DOCSIS Cable Device MIB and downref normative referen ces

["Wijnen, Bert (Bert)" <bwijnen at lucent.com>]

I support moving these 5 references from the normative to the informative
section. 

Bert

> -----Original Message-----
> From: Woundy, Richard [mailto:Richard_Woundy at cable.comcast.com]
> Sent: Wednesday, November 22, 2006 00:52
> To: ipcdn at ietf.org
> Cc: jfm at cablelabs.com; Woundy, Richard
> Subject: [ipcdn] DOCSIS Cable Device MIB and downref normative
> references
> 
> 
> Folks,
> 
> In the process of trying to publish the updated DOCSIS Cable 
> Device MIB,
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mib
> v2-11.txt,
> we have identified five "downref" normative references that must be
> fixed prior to publication.
> 
> As RFC 3967 explains:
> 
>    IETF procedures generally require that a standards track 
> RFC may not
>    have a normative reference to another standards track document at a
>    lower maturity level or to a non standards track 
> specification (other
>    than specifications from other standards bodies).  For example, a
>    standards track document may not have a normative reference to an
>    informational RFC.
> 
> Per guidance from our Area Director, there are two ways to fix these
> downref normative references:
> 
> 1. Move the references to the informative references section, with WG
> consensus, or
> 
> 2. Explain each downref normative reference in the draft (per 
> RFC 3967),
> and perform another IETF Last Call.
> 
> My recommendation (both as co-author and as co-chair) is to move the
> five references to the informative references section, and complete
> publication of this draft as an RFC.
> 
> *** If you disagree with this recommendation, please reply to 
> me and the
> IPCDN mailing list by Friday December 1.
> 
> Here are the results of the new IETF draft/RFC dependency tool, as run
> against the latest draft:
> http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?doc=draft-ietf
-ipcdn-dev
ice-mibv2. The tool identifies normative references to five
Informational RFCs:

   [RFC1858]     Ziemba, G., Reed, D., and P. Traina, "Security
                 Considerations for IP Fragment Filtering", RFC 1858,
                 October 1995.

   [RFC1945]     Berners-Lee, T., Fielding, R., and H. Frystyk,
                 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
                 May 1996.

   [RFC3128]     Miller, I., "Protection Against a Variant of the Tiny
                 Fragment Attack (RFC 1858)", RFC 3128, June 2001.

   [RFC3164]     Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
                 August 2001.

   [RFC3617]     Lear, E., "Uniform Resource Identifier (URI) Scheme and
                 Applicability Statement for the Trivial File Transfer
                 Protocol (TFTP)", RFC 3617, October 2003.

The Security Considerations (section 6) recommends implementation of RFC
1858 (Informational) and RFC 3128 (Informational) to prevent the "tiny
fragment" and "overlapping fragment" attacks, but does not mandate them.

DOCSIS specifies the use of TFTP (RFC 1350 - Standard) for file
transfers, but this MIB module enables implementation of HTTP 1.0 (RFC
1945 - Informational) or HTTP 1.1 (RFC 2616 - Draft Standard) for file
transfers as well. See section 3.2.1 of the draft for a complete
explanation.

The TFTP URI (RFC 3617 - Informational) is referenced by
docsDevServerConfigTftpAddress, but the syntax of the the object is an
InetAddress, and is not dependent on RFC 3617.

SYSLOG (RFC 3164) is one of several possible event notification
mechanisms supported by this MIB module.

-- Rich

_______________________________________________
IPCDN mailing list
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn