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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.