RE: Last Call: draft-ietf-hubmib-efm-mib (Definitions andManaged Objects for OAM Functions on Ethernet Like Interfaces)to Proposed Standard

Thanks Dan,

Wow... as WG chair I missed quite a few it seems.
We will work on these.

Matt, can you take a crack at it?
Or do you want me to suggest resolution first?

Bert=20

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email protected]]=20
> Sent: woensdag 7 februari 2007 16:06
> To: [email protected]
> Cc: [email protected]
> Subject: RE: [Hubmib] Last Call: draft-ietf-hubmib-efm-mib=20
> (Definitions andManaged Objects for OAM Functions on Ethernet=20
> Like Interfaces)to Proposed Standard=20
>=20
> 1. The header of the document should include: 'Intended=20
> Status - Proposed Standard'
>=20
> 2. References problems:
>=20
> - Unused Reference: 'RFC2586' is defined on line 2715, but=20
> not referenced
>     '[RFC2586]   Bierman, A., McCloghrie, K., Presuhn, R., "Textual
> Convent...'
>=20
>   - Unused Reference: 'RFC3636' is defined on line 2738, but=20
> not referenced
>     '[RFC3636]   Flick, J., "Definitions of Managed Objects for IEEE
> 802.3...'
>=20
>   * Downref: Informational Normative Reference: RFC 2586 -=20
> this is actually a typo (should be 2856) combined with=20
> another unused references
>=20
> Now, at least part of these unused references is caused by=20
> the fact that the MIB module does not list (commented) the=20
> RFC where the imported TCs originate. This should be=20
> Normative References
>=20
> Also, I would suggest to replace [RFC3636] with the update=20
> draft, which was already approved by the IESG and is in RFC=20
> Editor Queue
>=20
> 3. It would be good to run again the latest version of=20
> idnits. There are more complaints about the boilerplate and=20
> about pages exceeding the maximal allowed number of lines per page.
>=20
> 4. Section 3:=20
>=20
>    Although Ethernet access
>    deployments were the primary motivation for the task force=20
> activity,
>    the results of the task force are not strictly limited to that
>    application. =20
>=20
> Maybe we can be even more explicit here by adding:
>=20
> 'For example Ethernet OAM could be implemented on Ethernet=20
> links that are not necessarily EFM.'
>=20
> 5. Something seems to be missing in the following phrase in=20
> Section 3.4:
>=20
> 'OAMPDUs are the mechanism two
>    directly connected Ethernet interfaces exchange OAM information. '
>=20
> 6. Section 4.1 - would be better to avoid saying 'SNMP MIB=20
> Modules' in the title as MIB modules can be used with another=20
> protocol than SNMP
>=20
> 7. Update hubmib chair name and contact information
>=20
> 8. dot3OamPeerVendorInfo - I may be wrong, but the reference=20
> points to table 57-11 in the IEEE specification and the=20
> 32-bit information there is not other but the SMI Enterprise=20
> Number. If I am correct we may want to mention this in the DESCRIPTION
>=20
> 9. Why is not DEFVAL used to specify the default values of=20
> read-write or read-create objects wherever they are fixed -=20
> dot3OamErrFrameWindow, dot3OamErrFrameThreshold,=20
> dot3OamErrFrameEvNotifEnable,=20
> dot3OamErrFrameSecsSummaryWindow, dot3OamErrFrameSecsSummaryThreshold,
> dot3OamErrFrameSecsEvNotifEnable, dot3OamDyingGaspEnable,=20
> dot3OamCriticalEventEnable
>=20
> 10. The Abstract section contains a reference - this should be avoided
>=20
> 11. According to the naming convention in RFC 4181 the name=20
> of the Dot3Oui TC should be Dot3oamOui. Now one may argue=20
> that this TC is not Dot3-OAM specific, but then it is not=20
> Dot3 specific either. If we already infringe the naming=20
> convention let us use a more generic name (maybe just Oui or=20
> EightOTwoOui that would encourage the TC to be imported by=20
> other MIB modules.=20
>=20
> Dan
>=20
>=20
>=20
>=20
>=20
> =20
> =20
>=20
> > -----Original Message-----
> > From: The IESG [mailto:[email protected]]
> > Sent: Friday, January 26, 2007 5:43 PM
> > To: IETF-Announce
> > Cc: [email protected]
> > Subject: [Hubmib] Last Call: draft-ietf-hubmib-efm-mib (Definitions=20
> > and Managed Objects for OAM Functions on Ethernet Like=20
> Interfaces) to=20
> > Proposed Standard
> >=20
> > The IESG has received a request from the Ethernet=20
> Interfaces and Hub=20
> > MIB WG (hubmib) to consider the following document:
> >=20
> > - 'Definitions and Managed Objects for OAM Functions on=20
> Ethernet Like=20
> >    Interfaces '
> >    <draft-ietf-hubmib-efm-mib-05.txt> as a Proposed Standard
> >=20
> > The IESG plans to make a decision in the next few weeks,=20
> and solicits=20
> > final comments on this action.  Please send substantive comments to=20
> > the [email protected] mailing lists by 2007-02-09.=20
> Exceptionally, comments=20
> > may be sent to [email protected] instead. In either case, please retain=20
> > the beginning of the Subject line to allow automated sorting.
> >=20
> > The file can be obtained via
> > http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-mib-05.txt
> >=20
> >=20
> > IESG discussion can be tracked via
> > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie
> > w_id&dTag=3D11360&rfc_flag=3D0
> >=20
> >=20
> > _______________________________________________
> > Hubmib mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/hubmib
> >=20
>=20
> _______________________________________________
> Hubmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/hubmib
>=20