Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt

From: "Matt Squire" <[email-masked]>
Date: Wed, 2 Mar 2005 01:23:25 -0500

Hi Dan - 
 
I don't think I responded to your note earlier.  Responding to the editorial comments below.  A separate email will address the more difficult technical issues.  Thanks.
 
- Matt

Here are my comments on draft-ietf-hubmib-efm-mib-02.txt. This document being in Last Call, all comments need to be taken into consideration, including the minor ones the comments editorial in nature. 

First running idnits we get the following:

tmp/draft-ietf-hubmib-efm-mib-02.txt:

tmp/draft-ietf-hubmib-efm-mib-02.txt(319): Line has weird spacing: '...ficInfo   dot3...'

tmp/draft-ietf-hubmib-efm-mib-02.txt(325): Line has weird spacing: '...ationTx  dot3O...'

tmp/draft-ietf-hubmib-efm-mib-02.txt(326): Line has weird spacing: '...ationRx  dot3O...'

tmp/draft-ietf-hubmib-efm-mib-02.txt(347): Line has weird spacing: '...dConfig    dot...'

tmp/draft-ietf-hubmib-efm-mib-02.txt(355): Line has weird spacing: '...dConfig  dot3O...'

tmp/draft-ietf-hubmib-efm-mib-02.txt(1691): Line has weird spacing: '...smitted  on th...' 

Except for the last one, the complaints are about columns in a table, which I intend to leave as is.   The spacing is weird, but its a table, and the columns are aligned.  

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

    Checking conformance with RFC 3667/3668 boilerplate...

  * The document claims conformance with section 10 of RFC 2026, but uses

    some RFC 3667/3668 boilerplate.  As RFC 3667/3668 replaces section 10 of RFC

    2026, you should not claim conformance with it if you have changed to using

    RFC 3667/3668 boilerplate. 

Changed to 3667 boilerplate (which is probably already outdated!).   Are we supposed to jump to the newest 3997/3998 stuff yet?  

  * The document seems to lack an RFC 3667 Section 5.1 IPR Disclosure

    Acknowledgement  -- however, there's a paragraph with a matching beginning.

    Boilerplate error?

  (Expected a match on the following text: 

    "By submitting this Internet-Draft, each author represents that any

    applicable patent or other IPR claims of which he or she is aware

    have been or will be disclosed, and any of which he or she becomes

    aware will be disclosed, in accordance with Section 6 of RFC 3668."

   ... but found this:

    "By submitting this Internet-Draft, I certify that any applicable

    patent or other IPR claims of which I am aware have been disclosed,

    or will be disclosed, and any of which I become aware will be

    disclosed, in accordance with   RFC 3668 [RFC3668].")

Changed (though 3667 has "I" instead of "he or she").   

  * The document seems to lack an RFC 3668 Section 5, para 3 IPR Disclosure

    Invitation -- however, there's a paragraph with a matching beginning.

    Boilerplate error?

  (Expected a match on the following text: 

    "The IETF invites any interested party to bring to its attention any

    copyrights, patents or patent applications, or other proprietary

    rights that may cover technology that may be required to implement

    this standard.  Please address the information to the IETF at

    [email-masked]."

   ... but found this:

    "The IETF invites any interested party to bring to its attention any

    copyrights, patents or patent applications, or other proprietary

    rights that may cover technology that may be required to implement

    EFM OAM MIB                 October 2004") 

This was just where the page happened to break, I'm sure the next version will break the page somewhere else.   

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

  * The document seems to lack a 1id_guidelines paragraph about

    Internet-Drafts being working documents -- however, there's a paragraph with

    a matching beginning. Boilerplate error?

  (Expected a match on the following text: 

    "Internet-Drafts are working documents of the Internet Engineering

    Task Force (IETF), its areas, and its working groups.  Note that

    other groups may also distribute working documents as Internet-Drafts."

   ... but found this:

    "Internet-Drafts are working documents of the Internet Engineering

    Task Force (IETF), its areas, and its working groups.  Note that

    other groups may also distribute working documents as Internet Drafts.") 

Fixed missing dash.   

More:

Technical

I'll address technical issues in a separate email.    

Editorial

E1. The expiration date on the footer of all pages excepting the first is longer than the accepted six months period. 

got it, all will be updated with latest dates.   

E2. Section 3.1 - last phrase '...notifications into within the SNMP ...' needs to be fixed 

fixed 

E3.  Section 3.2, second paragraph - no need to capitalize DOES NOT 

done 

E4. Section 4, second phrase - replace 'affects' by 'effects' 

done 

E5. Section 4.1 - 'Ethernet-like' is duplicated 

addressed 

E6. Section 4.2 - correct 'ThisThe' in the first phrase 

Corrected.   

E7. Titles of Section 4 - replace 'MIBs' with 'MIB modules' 

Fixed.   

E8. First phrase of 4.2 - replace 'MIBs' by 'MIB modules' and MIB document'' by 'MIB module' 

Replaced.   

E9. Numbering of subsections 4.24.3 and 4.34.4 is broken 

Not sure how that happened, but fixed now.   

E10. Last phrase in 4.34.4 - replace 'MIB' by 'MIB module', decide about 'waymanner' 

Done.   

E11. I would strongly recommend to add UNITS clauses for all objects where these apply, especially for counters 

I added units for all of the normal things (bytes, frames, etc.).   How do I handle when a 64-bit quantity is split between two Unsigned32s?  Are both Unsigned32s the same unit thats being counted by the 64-bit quantity, or am i supposed to refer to the Hi/Lo 32-bits as different UNITs?  

E12. No need for something like  REFERENCE   "N/A". If there is no reference, there is no reference clause. 

Removed a bunch of these.   

E13 Avoid using Traps, even in object names (dot3OamTraps, dot3OamTrapsPrefix, etc.)  

Replaced 'Trap' with 'Notif' (dot3OamNotifs, ...).   

E14 Some characters seem to have been corrupted when copied to the [802.3ah reference]   

For some reason, some "-" were corrupted.  This isn't in the source file, so its a result of the translation from Word to txt.  I'll have to watch out for this again.   

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

---

From: "Matt Squire" <[email-masked]>
Date: Wed, 2 Mar 2005 02:44:53 -0500

A stab at the technical issues below.  Thanks again.
- Matt

Technical

T1. I do not agree with the assertion made in the Security Consideration section that the read-write objects defined in this MIB module do not impact the users traffic, because they are only controls of the OAM protocol. For example the dot3OamLoopbackCommand object, puts the link on loopback mode. Even if there is another object that allows for the remote device to ignore the loopback commands, this does not help if the loopback command objects are activated in an improper manner. Also, an object like dot3OamAdminState if set to disabled(1) will cut-off the OAM functionality of the device, which does have a negative impact on the network behavior and can be considered as a possible source of attack. I would suggest that the editor makes another pass through the read-write objects and explicitly describes all the potential security hazard resulting from inadequate write operations on these objects.  

 We can break down the read-write objects pretty easily.  There are: 

1) AdminState & Mode.  I tried to address these variables (without calling them out explicitly) in the first 2 paragraphs of the security section by saying turning on OAM doesn't take up a lot of BW but it opens up the possibility of information access, and should be used in deployments where thats ok.  And that the mode can be used as a variable to control/limit that access.  

2) Loopback.  I have a paragraph on the dangers of loopback already.  

3) Event configuration.  I left out these r-w objects because I'm not sure how dangerous they are. Writes on these objects could result in more .3ah event notifications, but the frequency is controlled by the OAM protocol, so I didn't consider that a big threat.  They could also result in SNMP notifications, but again the frequency is controlled.  Since the frequency didn't seem a big deal, whats left seems to just be the threat of the information getting out from the notifications or OAM events.  But thats controlled by the adminState and mode, and didn't appear to be any more/less of then the information access generally available by enabling OAM in a mode that allows that access.  So I didn't mention it any more than the earlier things.  

So I should definitely mention that disabling OAM can interfere with certain management capabilities.  I can walk thru the logic on the event r-w objects if you think they deserve mentioning.  I'm not sure what to add beyond that.  

T2. What is the DEFAULT value of read-write objects like dot3OamAdminState and dot3OamMode? You need to describe the desired behavior of the agent at initialization before the first SetRequest command 

dot3OamAdminState already had some text on the default state being disabled.  But you're point is well taken. I made another scan for all read-write objects,and ensured each had at least a sentence reflecting the default state.  For most objects, it was fairly easy.  The only one I'm not sure about is the default dot3OamMode.  Its not clear that a default of passive or active is universally acceptable. For that object, I'm suggesting the following text on default value:  

"       The default value of dot3OamMode is dependent on the type of
       system on which this Ethernet like interface resides.  The
       default value should be 'active(1)' unless it is known that
       this system should take on a subservient role to the other
       device connected over this interface.  An example would be a
       modem or demarcation device on a customer premise, connected to
       carrier equipment at a central office. 

"

T3 In the Security section: 'By default, OAM is disabled on Ethernet-likeEthernet like interfaces and is therefore not a risk.' First there is an editorial problem (repeated words). Second, there may be a technical issue. As far as I remember from my participation in the EFM work, there is no interdiction in the standard to apply OAM to a non-EFM Ethernet interface. Did this change in the latest part of the work, when my attendance became rare?   

OAM can be applied to any Ethernet interface, EFM or otherwise. Is that what you're asking?

---

From: "Matt Squire" <[email-masked]>
Date: Wed, 2 Mar 2005 13:41:00 -0500

One other technical issue to close out on (from a completely different thread) was related to whether the log entries of OAM events should use DateAndTime or TimeStamp objects.  This thread was discussed in December (see archives) and the strong consensus of the list was that a TimeStamp based on sysUpTime was much more universal and therefore much better.  So I'm also making the change to that object to use sysUpTime as a time indicator rather than DateAndTime. 
 
- Matt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Matt Squire
Sent: Wednesday, March 02, 2005 2:45 AM
To: Romascanu, Dan (Dan); [email-masked]
Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt

Technical

"

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 3 Mar 2005 16:34:48 +0200

I did not receive yet any directives on this respect. Please continue to use 3667, unless you hear from me. 

Regards,

Dan

  .

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 3 Mar 2005 16:34:51 +0200

See in-line. 
 
Regards, 
 
Dan

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: 02 March, 2005 9:45 AM
To: Romascanu, Dan (Dan); [email-masked]
Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt

Technical

So I should definitely mention that disabling OAM can interfere with certain management capabilities.  I can walk thru the logic on the event r-w objects if you think they deserve mentioning.  I'm not sure what to add beyond that.  
[Romascanu, Dan (Dan)] It would be enough to mention the problems with disabling  dot3OamAdminState and to list the other read-write objects whose mis-manipulation would resulting inaccurate OAM information interfering with proper management decisions 

"
[Romascanu, Dan (Dan)] Sounds OK.  

OAM can be applied to any Ethernet interface, EFM or otherwise. Is that what you're asking?  
[Romascanu, Dan (Dan)] yes.

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 3 Mar 2005 16:34:52 +0200

I would suggest that we reach here a solution consistent with the EFM Cu MIB. There we decided to keep both a DateAndTime and a TimeStamp object. If DateAndTime cannot be filled in, then a all-zeros value will be used. 

Regards,

Dan

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: 02 March, 2005 8:41 PM
To: Romascanu, Dan (Dan); [email-masked]
Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt

 
- Matt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Matt Squire
Sent: Wednesday, March 02, 2005 2:45 AM
To: Romascanu, Dan (Dan); [email-masked]
Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt

Technical

"

---

From: "Matt Squire" <[email-masked]>
Date: Thu, 3 Mar 2005 09:51:09 -0500

Back in Dec, multiple people weighed in that a TimeStamp was preferred over a DateAndTime.  Additionally, multiple people weighed in that they preferred one object over two.  I don't think anyone weighed in with a preference for using both.  Even the person that brought it up as a possibility (I think you know him!) had reservations about using both.  
 
So unless I hear that multiple people have preference for using both objects as time indicators for when events happened, I'd suggest we use TimeStamp and settle with that.
 
- Matt

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Thursday, March 03, 2005 9:35 AM
To: Matt Squire; [email-masked]
Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt

Regards,

Dan

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: 02 March, 2005 8:41 PM
To: Romascanu, Dan (Dan); [email-masked]
Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt

 
- Matt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Matt Squire
Sent: Wednesday, March 02, 2005 2:45 AM
To: Romascanu, Dan (Dan); [email-masked]
Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt

Technical

"

---

From: "John Messenger" <[email-masked]>
Date: Thu, 3 Mar 2005 14:55:41 -0000

Hi,
 
I'm not happy with the specific example of a device which should operate in Passive mode:  "An example would be a modem or demarcation device on a customer premise, connected to carrier equipment at a central office.".  The 802.3ah standard makes no such stricture, and I wouldn't want it implied here either.  I don't think the example is necessary to support the point being made.
 
Regards,
    -- John
--
John Messenger ([email-masked]) 
R&D Manager, Software 
ADVA Optical Networking Ltd. 
+44-1904-699309 
www.advaoptical.com 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Romascanu, Dan (Dan)
Sent: 03 March 2005 14:35
To: Matt Squire; [email-masked]
Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt

See in-line. 
 
Regards, 
 
Dan

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: 02 March, 2005 9:45 AM
To: Romascanu, Dan (Dan); [email-masked]
Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt

Technical

"

---

From: "Matt Squire" <[email-masked]>
Date: Thu, 3 Mar 2005 11:31:42 -0500

Hi John - 
 
My main problem was that there is no one default that works for all devices, so the best I could do is say that its up to the system to figure out the default value.  With the example, I was just trying to provide some guidance.  I have no problem with removing it.  If there are better suggestions for text providing guidance I'm all ears.   Otherwise I'll just remove the "As an example..." sentence from the proposed text.  
 
- Matt

-----Original Message-----
From: John Messenger [mailto:[email-masked]]
Sent: Thursday, March 03, 2005 9:56 AM
To: Matt Squire
Cc: Romascanu, Dan (Dan); [email-masked]
Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt

Hi,

Regards,
    -- John

"

---

From: "Matt Squire" <[email-masked]>
Date: Thu, 3 Mar 2005 14:47:15 -0500

Thanks Mike.  I'll make the change below (using 2^32 since I'd probably mis-type the other quantity).  

- Matt

> I think that the low and high parts do count different quantities
> and so should have different units.  Taking as an example a "split"
> octet counter, how about something like
> 
>   UNITS "Octets"
> 
> for the low-order 32 bits and
> 
>   UNITS "4294967296 Octets"
> or
>   UNITS "2^32 Octets"
> 
> for the high order 32 bits?
> 
> Mike
> 
>