Subject: [Hubmib] draft-ietf-hubmib-efm-oam-06

From: "Matt Squire" <[email-masked]>
Date: Wed, 21 Feb 2007 11:16:50 -0500

A new (and hopefully final) revision to the EFM OAM MIB Internet Draft
has been submitted. 

The changes to the document reflect comments issued during last call.
Comments were received by the following individuals:
  Bert Wijnen
  Dan Romascanu
  Eric Gray
  Sean Turner
Thanks to these and all other reviewers in the process. 

The changes were pretty editorial, but some of main comments addressed
were as follows:

* Added a DEFVAL to dot3OamErrFrameWindow, dot3OamErrFrameThreshold,
dot3OamErrFrameEvNotifEnable, dot3OamErrFrameSecsSummaryWindow,
dot3OamErrFrameSecsSummaryThreshold,
dot3OamErrFrameSecsEvNotifEnable, dot3OamDyingGaspEnable,
dot3OamCriticalEventEnable

* Changed OUI object name from Dot3Oui to EightOTwoOui in order to make
it more correct hopefully useable by other MIBs in the future.  The OUI
is really an 802 concept, not an 802.3 concept.  

* Updated boilerplate with newer IETF Trust wording.

* Added and corrected some issues with references in that some normative
references ones weren't appearing normative.  References were added to
the IMPORT section of the MIB so that all normative references were
actually used in the document.  

Excruciating details are included below, but those are the highlights.  

- Matt

************************************************
************************************************
************************************************
************************************************

Many other (tens) of editorial items (misspellings, typos, minor wording
improvements, etc.) were also addressed.  Details below. Responses
indicated with "MBS>>".    

=============================================================
=============================================================

Comments from Dan, Feb-07-2007

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

MBS>>>
Replaced the header line:
                    Ethernet OAM MIB              October 2006
with:
Intended Status - Proposed Standard               February 2007

2. References problems:

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

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

  * 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

MBS>> I fixed the reference 2586.  Note that I don't actually
reference 3636 anywhere, so I removed that from the references.
Added references to MIB module when importing from other MIBs.  

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.

MBS>> Done. Nothing major found (though it still spits out concerns
related to spacing and IP addresses which are not appropriate).  

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.'

MBS>> Addressed

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. '

MBS>> Changed to "OAMPDUs are the mechanism by which 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

MBS>> Removed SNMP from title of 4.1

7. Update hubmib chair name and contact information

MBS>> Done, put in Bert's email (no phone).  

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

MBS>> After side conversations with commenters, changed the description
field of this to reflect that the semantics are unknown and up to the
vendor, and that this field simply reflects what was received.  Included
an example that it could be used for a product or product family
identifier.   

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

MBS>> Probably because nobody pointed it out before...  Added defval
for all of the above consistent with the text in the description
section.   

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

MBS>> Removed

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. 

MBS>> Good point - changed to EightOTwoOui.  

=============================================================
=============================================================

>From Bert Jan-18-2007

Wow... this one dropped through the cracks.
And nobody warned me. Oh well..

I see (I means smicng tells me) an INDEX object:
      dot3OamEventLogIndex       OBJECT-TYPE
        SYNTAX      Unsigned32 
that would need a range.
I assume that zero is not an intended value, so I would do:
      dot3OamEventLogIndex       OBJECT-TYPE
        SYNTAX      Unsigned32(1..4294967295)

MBS>> Added range. 

I also see that you have mad a few "editorial" changes
- a few occurences of "possibility" into "possiblity".
  The latter is nota real word, is it?
- "multiplexer" into "mulitplexor" ??
- "identifying" into "identifiying" ??

MBS>> Fixed 3 occurences of possiblity, 1 occurence of mulitplexer, 1
occurence of identifiying. 

Anyway, the latter can be fixed by RFC editor, and the INDEX fix (if
that is acceptable) can be done with a note-to-rfc-editor by Dan, or we
can see it as a first IETF Last Call Comments.

I don't think we need to respin a new version for this.
(However, if you do plan a new rev, then pls be aware you  need new
copy-right text, as I posted to the list last week).

MBS>> updated copyright with IETF Trust as per RFC4748. 

=============================================================
=============================================================

>From Sean Turner Feb-14-2007

- Sec 3.4: 1st sentence is missing a )
MBS>> Fixed.

- Sec 6: I'd probably add an RFC EDITOR note to update the copyright
notice to 2007.  It's right before the 1st RFC Editor note.
MBS>> Addressed the copy right notice issue re RFC 4748. 

- Sec 6 dot3OamAdminState OBJECT-TYPE: Description says disabled(1) it
should be disabled(2) to match the syntax.
MBS>>> Fixed.  

- Sec 6 dot3OamPeerEntry OBJECT-TYPE: Description last line:"(4). or"
should be "(4), or" 
MBS>> Fixed. 

=============================================================
=============================================================

>From Eric Feb-11-2007

Summary:
=======

Comments:
========

Weird formatting of section headers takes some getting used to.
Weird formatting of the reference section makes it difficult to
find specific references (especially if using a paper copy).

MBS>> Fixed reference section and section headers.  

___________________________________________________________________

As a purely structural comment, the text immediately preceding 
section 3.1 should either say something about section 3.4, or it 
should not say anything about sections 3.1 - 3.3.  Alternatively,
you might consider re-structuring section 3 (e.g. - 3.1.1, 3.1.2,
3.1.3 and 3.2).

MBS>> Mentioned content/purpose of 3.4.  
___________________________________________________________________

In the description text on page 10 (second paragraph), you have
the following text (without quotation marks):

     "[802.3-2005] refers to:
              IEEE Std 802.3-2002:"

I belive the second line should read (without quotation marks) - 

             "IEEE Std 802.3-2005:" 

This looks like a cut-and-paste error.

MBS>> Fixed.  
___________________________________________________________________

In the 1st line of the paragraph at the bottom of page 21, 
"looopback" should be "loopback" (there is an extra "o" in 
the current version).

MBS>> Fixed mulitple occurences of looopback.  

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Questions:
=========

>From section 3 (Overview - paraphrased):
Three functional objectives (of OAM):

    Remote fault indication  
    Link monitoring 
    Remote loopback

Is this a general observation about OAM, or does it affect the 
way that the MIB objects and tables are laid out?

MBS>> Intent is a general statement about OAM.  Did not make any
changes.  
___________________________________________________________________

At the top of page 13, should "At initialization and failure ..."
be "At initialization and recovery ..."?

MBS>> Didn't make any changes as it seemed ok either way.  
___________________________________________________________________

In section 7, Security Considerations, you include the following
statement:

"Unlike SNMP, IEEE P802.3ah OAM does not include encryption or 
 authorization mechanisms."

Should "authorization" be "authentication"?

MBS>> Yes it should, changed. 
___________________________________________________________________

On page 53, 3rd line, you say:

"information available obtainable via OAM ..."

Is the phrase "available obtainable" supposed to mean something,
or should one, or the other, of the two words be omitted?

MBS>>  Redundant wording, removed obtainable. 
__________________________________________________________________

In the 2nd paragraph of page 53, the 2nd sentence starts with
"Even if ..." and includes the phrase "..., even then, ..." -
what conditions does the 2nd use of "even" apply to (or is it 
used for additional emphasis)?

I had some difficulty in parsing this sentence, but it may be
that I was trying to read something that isn't there...

MBS>> No changes made (see Bert's response)

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Results from running idnits (non verbose)
==========================================

idnits 2.01.1 

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

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:
  * This document has an original RFC 3978 Section 5.4 Copyright Line,
    instead of the newer IETF Trust Copyright according to RFC 4748.
  * This document has an original RFC 3978 Section 5.5 Disclaimer,
instead of
    the newer disclaimer which includes the IETF Trust according to RFC
4748.

MBS>> Added IETF trust stuff. 

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

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Wed, 21 Feb 2007 17:22:51 +0100

Thanks Matt.
Indeed I think that this is the final revision so we can then
get Dan to put it on IESG Agenda.

Anyway, if anyone has comments on the below, pls let us know asap.
Also, when the new rev shows up (later today or tomorrow), pls do
check and speak up if you see any concerns.

I have carefully reviewed the latest changes that Matt made (before
he did send it to internet-drafts) and I am happy and confident that
all changes are OK.
 
Bert Wijnen
HUBMIB WG chair

> -----Original Message-----
> From: Matt Squire [mailto:[email-masked]] 
> Sent: woensdag 21 februari 2007 17:17
> To: [email-masked]
> Subject: [Hubmib] draft-ietf-hubmib-efm-oam-06
> 
> 
> A new (and hopefully final) revision to the EFM OAM MIB 
> Internet Draft has been submitted. 
> 
> The changes were pretty editorial, but some of main comments 
> addressed were as follows:
> 
> * Added a DEFVAL to dot3OamErrFrameWindow, 
> * Changed OUI object name from Dot3Oui to EightOTwoOui in 
> order to make it more correct hopefully useable by other MIBs 
> in the future.  The OUI is really an 802 concept, not an 
> 802.3 concept.  
> 
> * Added and corrected some issues with references in that 
> some normative references ones weren't appearing normative.  
> References were added to the IMPORT section of the MIB so 
> that all normative references were actually used in the document.  
> 
> Many other (tens) of editorial items (misspellings, typos, 
> minor wording improvements, etc.) were also addressed.  
> Details below. Responses
> indicated with "MBS>>".    
> 
> 
> 1. The header of the document should include: 'Intended 
> Status - Proposed Standard'
> 
> MBS>>>
> - 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.
> 
> 'For example Ethernet OAM could be implemented on Ethernet 
> links that are not necessarily EFM.'
> 
> MBS>> Addressed
> 
> 
>