Subject: RE: [Hubmib] Last Call: draft-ietf-hubmib-efm-mib (Definitions and Managed Objects for OAM Functions on Ethernet Like Interfaces) to Proposed Standard

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 7 Feb 2007 17:06:03 +0200

1. The header of the document should include: 'Intended Status -
Proposed Standard'

2. References problems:

- Unused Reference: 'RFC2586' is defined on line 2715, but not
referenced
    '[RFC2586]   Bierman, A., McCloghrie, K., Presuhn, R., "Textual
Convent...'

  - Unused Reference: 'RFC3636' is defined on line 2738, but not
referenced
    '[RFC3636]   Flick, J., "Definitions of Managed Objects for IEEE
802.3...'

  * Downref: Informational Normative Reference: RFC 2586 - this is
actually a typo (should be 2856) combined with another unused references

Now, at least part of these unused references is caused by the fact that
the MIB module does not list (commented) the RFC where the imported TCs
originate. This should be Normative References

Also, I would suggest to replace [RFC3636] with the update draft, which
was already approved by the IESG and is in RFC Editor Queue

3. It would be good to run again the latest version of idnits. There are
more complaints about the boilerplate and about pages exceeding the
maximal allowed number of lines per page.

4. Section 3: 

   Although Ethernet access
   deployments were the primary motivation for the task force activity,
   the results of the task force are not strictly limited to that
   application.  

Maybe we can be even more explicit here by adding:

'For example Ethernet OAM could be implemented on Ethernet links that
are not necessarily EFM.'

5. Something seems to be missing in the following phrase in Section 3.4:

'OAMPDUs are the mechanism two
   directly connected Ethernet interfaces exchange OAM information. '

6. Section 4.1 - would be better to avoid saying 'SNMP MIB Modules' in
the title as MIB modules can be used with another protocol than SNMP

7. Update hubmib chair name and contact information

8. dot3OamPeerVendorInfo - I may be wrong, but the reference points to
table 57-11 in the IEEE specification and the 32-bit information there
is not other but the SMI Enterprise Number. If I am correct we may want
to mention this in the DESCRIPTION

9. Why is not DEFVAL used to specify the default values of read-write or
read-create objects wherever they are fixed - dot3OamErrFrameWindow,
dot3OamErrFrameThreshold, dot3OamErrFrameEvNotifEnable,
dot3OamErrFrameSecsSummaryWindow, dot3OamErrFrameSecsSummaryThreshold,
dot3OamErrFrameSecsEvNotifEnable, dot3OamDyingGaspEnable,
dot3OamCriticalEventEnable

10. The Abstract section contains a reference - this should be avoided

11. According to the naming convention in RFC 4181 the name of the
Dot3Oui TC should be Dot3oamOui. Now one may argue that this TC is not
Dot3-OAM specific, but then it is not Dot3 specific either. If we
already infringe the naming convention let us use a more generic name
(maybe just Oui or EightOTwoOui that would encourage the TC to be
imported by other MIB modules. 

Dan

> -----Original Message-----
> From: The IESG [mailto:[email-masked]] 
> Sent: Friday, January 26, 2007 5:43 PM
> To: IETF-Announce
> Cc: [email-masked]
> Subject: [Hubmib] Last Call: draft-ietf-hubmib-efm-mib 
> (Definitions and Managed Objects for OAM Functions on 
> Ethernet Like Interfaces) to Proposed Standard 
> 
> The IESG has received a request from the Ethernet Interfaces 
> and Hub MIB WG (hubmib) to consider the following document:
> 
> - 'Definitions and Managed Objects for OAM Functions on Ethernet Like 
>    Interfaces '
>    <draft-ietf-hubmib-efm-mib-05.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and 
> solicits final comments on this action.  Please send 
> substantive comments to the [email-masked] mailing lists by 
> 2007-02-09. Exceptionally, comments may be sent to 
> [email-masked] instead. In either case, please retain the 
> beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-mib-05.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_id&dTag=11360&rfc_flag=0
> 
> 
> _______________________________________________
> Hubmib mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hubmib
> 

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 8 Feb 2007 08:35:38 +0100

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 

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: woensdag 7 februari 2007 16:06
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Hubmib] Last Call: draft-ietf-hubmib-efm-mib 
> (Definitions andManaged Objects for OAM Functions on Ethernet 
> Like Interfaces)to Proposed Standard 
> 
> 1. The header of the document should include: 'Intended 
> Status - Proposed Standard'
> 
> 2. References problems:
> 
> - Unused Reference: 'RFC2586' is defined on line 2715, but 
> not referenced
>   - Unused Reference: 'RFC3636' is defined on line 2738, but 
> not referenced
>   * Downref: Informational Normative Reference: RFC 2586 - 
> this is actually a typo (should be 2856) combined with 
> another unused references
> 
> Now, at least part of these unused references is caused by 
> the fact that the MIB module does not list (commented) the 
> RFC where the imported TCs originate. This should be 
> Normative References
> 
> Also, I would suggest to replace [RFC3636] with the update 
> draft, which was already approved by the IESG and is in RFC 
> Editor Queue
> 
> 3. It would be good to run again the latest version of 
> idnits. There are more complaints about the boilerplate and 
> about pages exceeding the maximal allowed number of lines per page.
> 
> 4. Section 3: 
> 
>    Although Ethernet access
> 'For example Ethernet OAM could be implemented on Ethernet 
> links that are not necessarily EFM.'
> 
> 6. Section 4.1 - would be better to avoid saying 'SNMP MIB 
> Modules' in the title as MIB modules can be used with another 
> protocol than SNMP
> 
> 8. dot3OamPeerVendorInfo - I may be wrong, but the reference 
> points to table 57-11 in the IEEE specification and the 
> 32-bit information there is not other but the SMI Enterprise 
> Number. If I am correct we may want to mention this in the DESCRIPTION
> 
> 9. Why is not DEFVAL used to specify the default values of 
> read-write or read-create objects wherever they are fixed - 
> dot3OamErrFrameWindow, dot3OamErrFrameThreshold, 
> dot3OamErrFrameEvNotifEnable, 
> 11. According to the naming convention in RFC 4181 the name 
> of the Dot3Oui TC should be Dot3oamOui. Now one may argue 
> that this TC is not Dot3-OAM specific, but then it is not 
> Dot3 specific either. If we already infringe the naming 
> convention let us use a more generic name (maybe just Oui or 
> EightOTwoOui that would encourage the TC to be imported by 
> other MIB modules. 
> 
> Dan
> 
> 
> 
> 
> 
>  
>  
> 
> > Subject: [Hubmib] Last Call: draft-ietf-hubmib-efm-mib (Definitions 
> > and Managed Objects for OAM Functions on Ethernet Like 
> Interfaces) to 
> > Proposed Standard
> > 
> > The IESG has received a request from the Ethernet 
> Interfaces and Hub 
> > MIB WG (hubmib) to consider the following document:
> > 
> > The IESG plans to make a decision in the next few weeks, 
> and solicits 
> > final comments on this action.  Please send substantive comments to 
> > the [email-masked] mailing lists by 2007-02-09. 
> Exceptionally, comments 
> > may be sent to [email-masked] instead. In either case, please retain 
> > the beginning of the Subject line to allow automated sorting.
> >