FYI: Update references
"Jean-Francois Mule" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
Forwarding this to the list for all mib authors. Thank you Eduardo. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:[email protected]] Sent: Monday, October 20, 2003 8:14 PM To: Eduardo Cardona; Murwin William-LWM008; Wilson Sawyer; Jean-Francois Mule; Woundy, Richard Cc: Wijnen, Bert (Bert) Subject: RE: Update references Inline Thanks, Bert > -----Original Message----- > From: Eduardo Cardona [mailto:[email protected]] > Sent: dinsdag 21 oktober 2003 1:10 > To: Murwin William-LWM008; Wilson Sawyer; Jean-Francois Mule; Woundy, > Richard > Cc: Wijnen, Bert (Bert) > Subject: Update references > > > > Hi All > As current editors of MIB drafts, > > I noticed that from latest Bert's comments in BPI+ mib that in general > we missed the 3.5. References Sections requirement of > draft-ietf-ops-mib-review-guidelines-02.txt See the list below > > One Question For Bert, > > I am doing some updates of few closed issues in RFIv2 MIB for IPCDN > chairs, and I added in the normative references an entry because of > IMPORT IANAifType-MIB > > Would that be ok? or should I use an independent section IANA > Considerations as in RFC 2932? > If all you do is IMPORT from the IANAifTypeMIB, then all you need to do is add a normative reference to the web page that points to that IANA maintained MIB module. See for example RFC3292 [17] IANAifType - MIB DEFINITIONS, http://www.iana.org, January 2001. > I am a little bit confused with the OPS mib guidelines section 3.5 and > section 3.7. In the example of 3.7, RFC 2932 the IANA references are > updates of an existing IANA document so I have no clear what is > defining a IANA namespace and reference an IANA document ( like in > IMPORTS) > > This is the reference I added. > > > [IANA] "Protocol Numbers and Assignment Services",IANA, available > at http://www.iana.org/assignments/ianaiftype-mib. > > That is even better than what I showed above If you just do an IMPORT, you are not defining new IAN guidelines. So no specific IANA considerations are needed. > > > The list below shows my compilation of IMPORTS clauses from QOS, BPI, > CABLE, RFI and SUBMGT MIBs modules In overall, the first three > references are covered for the boilerplate template, the others must > be added in the Reference section > > - I see in few cases the -- comments of the RFC as a guide in the > imports; better avoid them since the Reference notes may overlook > those changes and will be a long term typo in RFCs > > DOCS-CABLE-DEVICE-MIB has almost references to all current drafts It > will need extensive notes > > IMPORTS > FROM SNMPv2-SMI --RFC2578 > FROM SNMPv2-TC --RFC2579 > FROM SNMPv2-CONF --RFC2580 > FROM SNMP-FRAMEWORK-MIB --RFC3411 > FROM IF-MIB --RFC2863 > FROM DOCS-IF-MIB --RFC2670 with note for new coming RFC > FROM INET-ADDRESS-MIB --RFC3291 with note for new bis draft > FROM DIFFSERV-DSCP-TC -- RFC3289 > FROM IANAifType-MIB -- IANA reference preferable with link to > the URL. > FROM RMON2-MIB --RFC 2021 > > looks good to me > > > Example of notes : for the normative section > RFC 3291 > ************************************************************ > * NOTES TO RFC Editor (to be removed prior to publication) * > * * > * 1.) The I-D <draft-ietf-ops-rfc3291bis-01.txt> (or a * > * successor) is expected to eventually replace RFC 3291. * > * If that draft (or a successor) is published as an RFC * > * prior to or concurrently with this document, then the * > * normative reference [RFC3291] should be updated to * > * point to the replacement RFC, and the reference tag * > * [RFC3291] should be updated to match. * > * * > ************************************************************ > > Most inminent, using the same template... ( have the most > dependencies) > RFC 2760 - draft 08 if published before your drafts. > > ************************************************************ > * NOTES TO RFC Editor (to be removed prior to publication) * > * * > * 1.) The I-D <draft-ietf-ipcdn-docs-rfmibv2-08.txt> (or a * > * successor) is expected to eventually replace RFC 2670. * > * If that draft (or a successor) is published as an RFC * > * prior to or concurrently with this document, then the * > * normative reference [RFC2670] should be updated to * > * point to the replacement RFC, and the reference tag * > * [RFC2670] should be updated to match. * > * * > ************************************************************ > > > Etc. > Looks good too. Bert