[ipcdn] FYI: Update references

["Jean-Francois Mule" <[e-mail]>]

Forwarding this to the list for all mib authors. Thank you Eduardo.

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[e-mail]] 
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:[e-mail]]
> 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

_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn