RE: draft-ietf-hubmib-efm-oam-06

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.
=20
Bert Wijnen
HUBMIB WG chair

> -----Original Message-----
> From: Matt Squire [mailto:[email protected]]=20
> Sent: woensdag 21 februari 2007 17:17
> To: [email protected]
> Subject: [Hubmib] draft-ietf-hubmib-efm-oam-06
>=20
>=20
> A new (and hopefully final) revision to the EFM OAM MIB=20
> Internet Draft has been submitted.=20
>=20
> 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.=20
>=20
> The changes were pretty editorial, but some of main comments=20
> addressed were as follows:
>=20
> * Added a DEFVAL to dot3OamErrFrameWindow,=20
> dot3OamErrFrameThreshold, dot3OamErrFrameEvNotifEnable,=20
> dot3OamErrFrameSecsSummaryWindow, dot3OamErrFrameSecsSummaryThreshold,
> dot3OamErrFrameSecsEvNotifEnable, dot3OamDyingGaspEnable,=20
> dot3OamCriticalEventEnable
>=20
> * Changed OUI object name from Dot3Oui to EightOTwoOui in=20
> order to make it more correct hopefully useable by other MIBs=20
> in the future.  The OUI is really an 802 concept, not an=20
> 802.3 concept. =20
>=20
> * Updated boilerplate with newer IETF Trust wording.
>=20
> * Added and corrected some issues with references in that=20
> some normative references ones weren't appearing normative. =20
> References were added to the IMPORT section of the MIB so=20
> that all normative references were actually used in the document. =20
>=20
> Excruciating details are included below, but those are the=20
> highlights. =20
>=20
> - Matt
>=20
>=20
>=20
>=20
> ************************************************
> ************************************************
> ************************************************
> ************************************************
>=20
>=20
>=20
>=20
> Many other (tens) of editorial items (misspellings, typos,=20
> minor wording improvements, etc.) were also addressed. =20
> Details below. Responses
> indicated with "MBS>>".   =20
>=20
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Comments from Dan, Feb-07-2007
>=20
> 1. The header of the document should include: 'Intended=20
> Status - Proposed Standard'
>=20
> MBS>>>
> Replaced the header line:
>                     Ethernet OAM MIB              October 2006
> with:
> Intended Status - Proposed Standard               February 2007
>=20
>=20
>=20
>=20
> 2. References problems:
>=20
> - Unused Reference: 'RFC2586' is defined on line 2715, but=20
> not referenced
>     '[RFC2586]   Bierman, A., McCloghrie, K., Presuhn, R., "Textual
> Convent...'
> MBS>> CHANGED TO 2856
>=20
>   - Unused Reference: 'RFC3636' is defined on line 2738, but=20
> not referenced
>     '[RFC3636]   Flick, J., "Definitions of Managed Objects for IEEE
> 802.3...'
> MBS>>=20
>=20
>   * Downref: Informational Normative Reference: RFC 2586 -=20
> this is actually a typo (should be 2856) combined with=20
> another unused references
>=20
> Now, at least part of these unused references is caused by=20
> the fact that the MIB module does not list (commented) the=20
> RFC where the imported TCs originate. This should be=20
> Normative References
>=20
> Also, I would suggest to replace [RFC3636] with the update=20
> draft, which was already approved by the IESG and is in RFC=20
> Editor Queue
>=20
> 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. =20
>=20
>=20
>=20
> 3. It would be good to run again the latest version of=20
> idnits. There are more complaints about the boilerplate and=20
> about pages exceeding the maximal allowed number of lines per page.
>=20
> MBS>> Done. Nothing major found (though it still spits out concerns
> related to spacing and IP addresses which are not appropriate). =20
>=20
>=20
>=20
> 4. Section 3:=20
>=20
>    Although Ethernet access
>    deployments were the primary motivation for the task force=20
> activity,
>    the results of the task force are not strictly limited to that
>    application. =20
>=20
> Maybe we can be even more explicit here by adding:
>=20
> 'For example Ethernet OAM could be implemented on Ethernet=20
> links that are not necessarily EFM.'
>=20
> MBS>> Addressed
>=20
>=20
>=20
> 5. Something seems to be missing in the following phrase in=20
> Section 3.4:
>=20
> 'OAMPDUs are the mechanism two
>    directly connected Ethernet interfaces exchange OAM information. '
>=20
> MBS>> Changed to "OAMPDUs are the mechanism by which two directly
> connected Ethernet interfaces exchange OAM information."
>=20
>=20
>=20
> 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
>=20
> MBS>> Removed SNMP from title of 4.1
>=20
>=20
>=20
> 7. Update hubmib chair name and contact information
>=20
> MBS>> Done, put in Bert's email (no phone). =20
>=20
>=20
>=20
> 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=20
> we may want
> to mention this in the DESCRIPTION
>=20
> MBS>> After side conversations with commenters, changed the=20
> description
> field of this to reflect that the semantics are unknown and up to the
> vendor, and that this field simply reflects what was=20
> received.  Included
> an example that it could be used for a product or product family
> identifier.  =20
>=20
>=20
>=20
> 9. Why is not DEFVAL used to specify the default values of=20
> read-write or
> read-create objects wherever they are fixed - dot3OamErrFrameWindow,
> dot3OamErrFrameThreshold, dot3OamErrFrameEvNotifEnable,
> dot3OamErrFrameSecsSummaryWindow, dot3OamErrFrameSecsSummaryThreshold,
> dot3OamErrFrameSecsEvNotifEnable, dot3OamDyingGaspEnable,
> dot3OamCriticalEventEnable
>=20
> MBS>> Probably because nobody pointed it out before...  Added defval
> for all of the above consistent with the text in the description
> section.  =20
>=20
>=20
>=20
> 10. The Abstract section contains a reference - this should=20
> be avoideda
>=20
> MBS>> Removed
>=20
>=20
>=20
> 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.=20
>=20
> MBS>> Good point - changed to EightOTwoOui. =20
>=20
>=20
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> >From Bert Jan-18-2007
>=20
> Wow... this one dropped through the cracks.
> And nobody warned me. Oh well..
>=20
> I see (I means smicng tells me) an INDEX object:
>       dot3OamEventLogIndex       OBJECT-TYPE
>         SYNTAX      Unsigned32=20
> 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)
>=20
> MBS>> Added range.=20
>=20
> 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" ??
>=20
> MBS>> Fixed 3 occurences of possiblity, 1 occurence of mulitplexer, 1
> occurence of identifiying.=20
>=20
>=20
> 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=20
> Dan, or we
> can see it as a first IETF Last Call Comments.
>=20
> 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).
>=20
> MBS>> updated copyright with IETF Trust as per RFC4748.=20
>=20
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> >From Sean Turner Feb-14-2007
>=20
> - Sec 3.4: 1st sentence is missing a )
> MBS>> Fixed.
>=20
> - 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.=20
>=20
> - Sec 6 dot3OamAdminState OBJECT-TYPE: Description says disabled(1) it
> should be disabled(2) to match the syntax.
> MBS>>> Fixed. =20
>=20
> - Sec 6 dot3OamPeerEntry OBJECT-TYPE: Description last line:"(4). or"
> should be "(4), or"=20
> MBS>> Fixed.=20
>=20
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> >From Eric Feb-11-2007
>=20
>=20
> Summary:
> =3D=3D=3D=3D=3D=3D=3D
>=20
>=20
> Comments:
> =3D=3D=3D=3D=3D=3D=3D=3D
>=20
> 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).
>=20
> MBS>> Fixed reference section and section headers. =20
>=20
> ___________________________________________________________________
>=20
> As a purely structural comment, the text immediately preceding=20
> section 3.1 should either say something about section 3.4, or it=20
> 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).
>=20
> MBS>> Mentioned content/purpose of 3.4. =20
> ___________________________________________________________________
>=20
> In the description text on page 10 (second paragraph), you have
> the following text (without quotation marks):
>=20
>      "[802.3-2005] refers to:
>               IEEE Std 802.3-2002:"
>=20
> I belive the second line should read (without quotation marks) -=20
>=20
>              "IEEE Std 802.3-2005:"=20
>=20
> This looks like a cut-and-paste error.
>=20
> MBS>> Fixed. =20
> ___________________________________________________________________
>=20
> In the 1st line of the paragraph at the bottom of page 21,=20
> "looopback" should be "loopback" (there is an extra "o" in=20
> the current version).
>=20
> MBS>> Fixed mulitple occurences of looopback. =20
>=20
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>=20
> Questions:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> >From section 3 (Overview - paraphrased):
> Three functional objectives (of OAM):
>=20
>     Remote fault indication =20
>     Link monitoring=20
>     Remote loopback
>=20
> Is this a general observation about OAM, or does it affect the=20
> way that the MIB objects and tables are laid out?
>=20
> MBS>> Intent is a general statement about OAM.  Did not make any
> changes. =20
> ___________________________________________________________________
>=20
> At the top of page 13, should "At initialization and failure ..."
> be "At initialization and recovery ..."?
>=20
> MBS>> Didn't make any changes as it seemed ok either way. =20
> ___________________________________________________________________
>=20
> In section 7, Security Considerations, you include the following
> statement:
>=20
> "Unlike SNMP, IEEE P802.3ah OAM does not include encryption or=20
>  authorization mechanisms."
>=20
> Should "authorization" be "authentication"?
>=20
> MBS>> Yes it should, changed.=20
> ___________________________________________________________________
>=20
> On page 53, 3rd line, you say:
>=20
> "information available obtainable via OAM ..."
>=20
> Is the phrase "available obtainable" supposed to mean something,
> or should one, or the other, of the two words be omitted?
>=20
> MBS>>  Redundant wording, removed obtainable.=20
> __________________________________________________________________
>=20
> 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=20
> used for additional emphasis)?
>=20
> I had some difficulty in parsing this sentence, but it may be
> that I was trying to read something that isn't there...
>=20
> MBS>> No changes made (see Bert's response)
>=20
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>=20
> Results from running idnits (non verbose)
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> idnits 2.01.1=20
>=20
> tmp/draft-ietf-hubmib-efm-mib-05.txt:
>=20
>   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=20
> according to RFC
> 4748.
>=20
> MBS>> Added IETF trust stuff.=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Hubmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/hubmib
>=20