Subject: [Hubmib] Review of EFM-04 I-D

From: "David T. Perkins" <[email-masked]>
Date: Wed, 10 May 2006 16:03:26 -0700 (PDT)

HI,

I finished reviewing I-D draft-ietf-hubmib-efm-mib-04.txt.
My notes are below.

General comments:
 The updated document looks very clean. 
 It runs through both SMICng and smilint with no problems.
 I read through the document fairly quickly, and didn't
 try to verify all the references to other documents.
 (Even if there are a typo or two, a reader should be
 able to sort this out.)

Specific Comments:
1) The last paragraph of section 5 reads a little strange
   to me. It seems more complex than needed. (Given that it
   is an overview, it's Ok to leave as is. However, I suggest
   that it be simplified to the following:
   "There are two notifications defined to report Ethernet OAM
   events and are contained in one conformance group."

2) The TC Dot3Oui is defined in the module and has general
   applicability to all IEEE 802 areas. It seems like this
   should be defined elsewhere are imported into this module.
   (This is a duplicate of the comment made in the previous
    review, and I cannot remember the response.)
    
3) Also, the TC Dot3Oui where used is specified as having
   the value of zero. Either this should be changed to say
   the value of 3 octets of zero, or the syntax of the
   TC be modified to the following:
     SYNTAX  OCTET STRING(SIZE(0 | 3))
   I favor saying that the value is 3 octets of zero,
   since a zero length value may break existing mgmt apps.
   Note: objects dot3OamPeerVendorOui, and
         dot3OamEventLogOui
         
4) The syntax of object dot3OamMaxOamPduSize is specified
    as "SYNTAX (0..1518)", but the text says values
    1..63 are not allowed. So, why not
    "SYNTAX (0 | 64..1518)

In summary, great job Matt and others that worked on the
document.

Regards,
/david t. perkins

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

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 11 May 2006 13:38:08 +0300

Thank you David. 

Matt, please address the comments.

Could we consider the comments as initial comments for the IETF Last
Call without necessarily doing a new iteration?  If everybody agrees, I
believe that David Kessens could prepare the document for IETFLC. 

Dan

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Thursday, May 11, 2006 2:03 AM
> To: [email-masked]
> Cc: [email-masked]; Romascanu, Dan (Dan)
> Subject: Review of EFM-04 I-D
> 
> HI,
> 
>  I read through the document fairly quickly, and didn't  try 
> to verify all the references to other documents.
>  (Even if there are a typo or two, a reader should be  able 
> to sort this out.)
> 
> Specific Comments:
> In summary, great job Matt and others that worked on the document.
> 
> Regards,
> /david t. perkins
> 
> 
> 
>

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 11 May 2006 16:53:02 +0200

OK, then, for me it seems that the revision 4 of the document has
the proper SYNTYAX, namely
         SYNTAX      Unsigned32 (64..1518)

Bert
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, May 11, 2006 15:45
> To: Wijnen, Bert (Bert)
> Cc: David T. Perkins; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [Hubmib] Review of EFM-04 I-D
> 
> 
> Hi Bert,
> 
> The following is just my personal view of what IEEE Std 802.3 
> states, but 
> based on the text in Table 57-9 of IEEE Std 802.3-2005 that 
> states that 
> 'The minimum value is minFrameSize / 8.' and subclause 4.4.2 defining 
> minFrameSize as 512 bits the minimum value for Maximum OAMPDU 
> Size is 64.
> 
> I therefore believe 0-63 inclusive are not valid, I don't see 
> any special 
> case for 0.
> 
> Regards,
>   David
> 
> 
> "Wijnen, Bert (Bert)" <[email-masked]> wrote on 
> 11/05/2006 13:58:24:
> 
> > Ok, I did not link through to clause 4.4.1.
> > So then it seems that 0-63 are not valid values. Or is zero length
> > a special case?
> 
> > Bert
> 
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Thursday, May 11, 2006 13:46
> > > To: Wijnen, Bert (Bert)
> > > Cc: David T. Perkins; [email-masked]; [email-masked];
> > > [email-masked]
> > > Subject: RE: [Hubmib] Review of EFM-04 I-D
> > >
> > >
> > > Hi Bert,
> > >
> > > I don't know if the following is what you were looking for in
> > > IEEE Std
> > > 802.3ah-2004 (please note that IEEE 802.3ah-2004 has been
> > > superseded by
> > > IEEE 802.3-2005 which I will quote from):
> > >
> > > Subclause 30.3.6.1.8 'aOAMLocalPDUConfiguration' of IEEE Std
> > > 802.3-2005
> > > reads:
> > >
> > > ATTRIBUTE
> > > APPROPRIATE SYNTAX:
> > > INTEGER
> > > BEHAVIOUR DEFINED AS:
> > > An eleven bit value corresponding to the Maximum OAMPDU Size
> > > value within
> > > the OAMPDU Configuration field (see Table 57–9) in the 
> most recently
> > > transmitted OAMPDU.;
> > >
> > >
> > > In Table 57-9 of IEEE Std 802.3-2005 'Maximum OAMPDU Size' is
> > > described
> > > as:
> > >
> > > 11-bit field which represents the largest OAMPDU, in octets,
> > > supported by
> > > the DTE. This value is compared to the remote’s Maximum PDU
> > > Size and the
> > > smaller of the two is used. Prior to exchanging and 
> agreeing upon a
> > > Maximum OAMPDU Size, a DTE sends minFrameSize OAMPDUs. The
> > > minimum value
> > > is minFrameSize / 8. The maximum value is equal to
> > > maxUntaggedFrameSize,
> > > which is defined in 4.4.2. The OAMPDUs transmitted by a DTE
> > > are limited by
> > > both the local DTE’s Maximum OAMPDU size and the remote 
> DTE's Maximum
> > > OAMPDU size as indicated in received Information OAMPDUs. A
> > > DTE is not
> > > required to change the value transmitted in this field after
> > > negotiation
> > > to an agreed size as each end will dynamically.
> > >
> > > Subclause 4.4.2 of IEEE Std 802.3-2005 'Allowable
> > > implementations' defines
> > > minFrameSize as 512 bits.
> > >
> > > Hope this helps.
> > >
> > > Regards,
> > >   David
> > >
> > >
> > >
> > > "Wijnen, Bert (Bert)" <[email-masked]> wrote on
> > > 11/05/2006 12:26:16:
> > >
> > > > W.r.t.
> > >
> > > > >
> > > > Mmmm... which document are you looking at?
> > > > The   that I have says (on page 15)
> > > > dot3OamMaxOamPduSize OBJECT-TYPE
> > > > SYNTAX      Unsigned32 (64..1518)
> > > > UNITS       "octets"
> > > > MAX-ACCESS  read-only
> > > > STATUS      current
> > > > DESCRIPTION
> > > > "The largest OAMPDU that the OAM entity supports.  OAM
> > > > entities exchange maximum OAMPDU sizes and negotiate to use
> > > > the smaller of the two maximum OAMPDU sizes between the peers.
> > > > This value is determined by the local implementation.
> > > > "
> > > > REFERENCE   "[802.3ah], 30.3.6.1.8"
> > > > ::= { dot3OamEntry 4 }
> > > >
> > > > So it does not have (0..1518) and the DESCRIPTION clause
> > > also does not
> > > tell
> > > > me what a value of zero would mean ??
> > > > I tried to find it in the 802.3ah spec, but have not 
> found it (yet).
> > >
> > > > Bert
> > >
> > > >

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 11 May 2006 17:07:03 +0200

For that one I agree with your comment Dave.

Bert

> Sent: Thursday, May 11, 2006 16:44
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]; [email-masked]; [email-masked]
> oops. Cut and paste error on my part. Should be
> dot3OamPeerMaxOamPduSize.
> 
> Regards,
> /david t. perkins
> 
> On Thu, 11 May 2006, Wijnen, Bert (Bert) wrote:
> 
> > W.r.t.
> > 
> > >          
> also does not tell
> > I tried to find it in the 802.3ah spec, but have not found it (yet).
> > 
> > Bert
> > 
>

---

From: "Matt Squire" <[email-masked]>
Date: Thu, 11 May 2006 13:08:58 -0400

You are correct, the zero part of (0|64..1518) is a mistake. 

- Matt

> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Thursday, May 11, 2006 11:07 AM
> To: David T. Perkins; Wijnen, Bert (Bert)
> Cc: [email-masked]; [email-masked]; Matt Squire

---

From: "Matt Squire" <[email-masked]>
Date: Thu, 11 May 2006 13:41:47 -0400

Hi David - 

Thanks for the (re-)review.  Responses are in-line. 

>    events and are contained in one conformance group."

As a recap for those that don't have the document in front of them, the
last paragraph says:

"There are also a set of notifications (dot3OamNotifications) that
define alert conditions to management.  The [802.3ah] Event
Notifications can each be implemented independently of any other, and
therefore each has their own conformance group. " 

And I agree that it's confusing.  I'd offer a slight alteration to your
proposal.

"There are two notifications defined to report Ethernet OAM events (one
for threshold crossing events, one for non-threshold crossing events).
Both notifications are contained in the same conformance group. "

>     review, and I cannot remember the response.)

My response was that I theoretically agree, but I'm not sure how to
address it.  What MIB does it go in?  Who updates that MIB?  Do we wait
until it's updated?  

I'm just not sure what part falls on me, and what part falls on someone
else (and who that someone else would be).   

>    Note: objects dot3OamPeerVendorOui, and

Will do. 

>     1..63 are not allowed. So, why not

As has been discussed on the reflector and in private, there is a
difference in the syntax for dot3OamMaxOamPduSize and
dot3OamPeerMaxOamPduSize.  The former should be (64..1518) as the local
station knows its PDU size and it must be a value in the range 64-1518
octets.  The latter may have an unknown value (you may not have received
the value from the peer yet), and that is what the value of zero is for.
>From the Description of dot3OamPeerMaxOamPduSize:  

"A value of zero is returned if no Local Information TLV has been
received.  Otherwise, the value of the OAM peer's maximum OAMPDU size is
returned in this value.  Note that the values 1..63 are invalid sizes
for Ethernet frames and should never appear "

So (0 | 64..1518) is probably better then saying (0..1518) with 1..63 as
"should never appear".  So it's a good change to make.  

- Matt