Subject: [Hubmib] Comments on draft-beili-hubmib-efm-cu-mib-00.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 22 Dec 2003 12:14:00 +0200

Here are my comments on draft-beili-hubmib-efm-cu-mib-00.txt. Please take them into consideration for the next version of the document.

Thanks and Regards,

Dan

A. TECHNICAL

A1. I would like to hear more discussions about the layering model described in 3.1. My personal opinions that the alternative of using ifStackTable is more consistent with the generic layering model used by other similar MIBs, but I would like to hear more opinions.
A2. Section 3.7 needs to be filled in. 
A3. The Security Considerations section needs to be filled in with specific information about the security threats related to setting values of read-write objects, as well as a list of read-only objects considered to carry sensitive information. 
A4. The previous released Ethernet MIB (Power Ethernet MIB) was placed under 'mib-2' rather than 'transmission' following a comment from Mike Heard. As Mike is also the author of the MIB Review Guidelines document I would ask his opinion about where this MIB needs to be placed. In any case, until the standard is released, please avoid picking a value to make the compilation pass. Leaving the value non-defined and inserting a note to the RFC editor is intentional practice
A5. What does the requirement to change objects like PAFAdminState value only 'when the link is Down' mean? I suppose that it implies ifAdminStatus disabled for the respective interface, and not a fault situation. This model also implies that there is at least one different interface to allow the management agent in the device to be accessed. I suggest that this is made clear in the text. 
A6. The threshold objects in EfmCuPmd2BTable are meant to trigger notifications, but the notifications are not defined in the MIB module. Are they supposed to be added here, or do they need a reference some place else?

B. EDITORIAL - MAJOR

B1. The document does not follow the requirements for use of the keywords as specified in RFC 2119. Please read and comply to this document - including the required text, as well as the use of capitalized keywords wherever needed.

C. EDITORIAL - MINOR

C1. Expand the MAU and IEEE abbreviations in the Abstract section.
C2. Expand PMI in the Introduction section
C3  Expand PCS at its first occurrence (I think it is in 3.1)
C4. Where is the SHDSL MIB defined? Needs to be added to the Informative references, as well as G.991.2
C5. Add VDSL MIB to Informative references
C6. Add RFC 3635 defining the ETHERIF-MIB to Normative References
C7. It is not clear why RFC 2460 is included in the references list.

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 22 Dec 2003 09:23:06 -0800 (PST)

On Mon, 22 Dec 2003, Romascanu, Dan (Dan) wrote:
> A. TECHNICAL
> 
> A1. I would like to hear more discussions about the layering
> model described in 3.1. My personal opinions that the
> alternative of using ifStackTable is more consistent with the
> generic layering model used by other similar MIBs, but I would
> like to hear more opinions.

I assume that what is being discussed here is the following note:

   Editor's Note: An alternative would be to use ifStackTable to
   describe cross-connect capability and efmCuAvailableStackTable
   to describe actual connections, so that the cross-connect action
   would be done in the EFM-CU-MIB by modifying the
   efmCuAvailableStackTable (and not in IF-MIB).

Since the ifStackTable is normally used to describe and manipulate
actual interlayer connections, the strategy of using it to
manipulate those connections and of using efmCuAvailableStackTable
to describe possible connections seems like the right way to go for
me.

> A3. The Security Considerations section needs to be filled in
> with specific information about the security threats related to
> setting values of read-write objects, as well as a list of
> read-only objects considered to carry sensitive information.

See draft-ietf-ops-mib-review-guidelines-02.txt Section 3.6

> A4. The previous released Ethernet MIB (Power Ethernet MIB) was
> placed under 'mib-2' rather than 'transmission' following a
> comment from Mike Heard. As Mike is also the author of the MIB
> Review Guidelines document I would ask his opinion about where
> this MIB needs to be placed. In any case, until the standard is
> released, please avoid picking a value to make the compilation
> pass. Leaving the value non-defined and inserting a note to the
> RFC editor is intentional practice

I agree with all of the above.  Traditionally, a MIB module is
rooted in the transmission branch when it defines a media-specific
extension to the ifTable relating to a specific ifType.  In most
other cases it's rooted under mib-2.  And in no case should an
Internet-Draft use a number that has not been obtained from IANA.
See draft-ietf-ops-mib-review-guidelines-02.txt Section 4.5.

I would like to comment more, but I have to go pack to go on
a vacation.  Enjoy your holidays.

//cmh

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

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 22 Dec 2003 09:23:06 -0800 (PST)

//cmh