draft-ietf-hubmib-efm-oam-06
"Matt Squire" <[email protected]> Wed, 21 Feb 2007 11:16:50 -0500
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
A new (and hopefully final) revision to the EFM OAM MIB Internet Draft
has been submitted.=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
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. =20
* 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. =20
Excruciating details are included below, but those are the highlights. =20
- Matt
************************************************
************************************************
************************************************
************************************************
Many other (tens) of editorial items (misspellings, typos, minor wording
improvements, etc.) were also addressed. Details below. Responses
indicated with "MBS>>". =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
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>>=20
* 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. =20
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). =20
4. Section 3:=20
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. =20
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=20
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). =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 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. =20
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. =20
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.=20
MBS>> Good point - changed to EightOTwoOui. =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
>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=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)
MBS>> Added range.=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" ??
MBS>> Fixed 3 occurences of possiblity, 1 occurence of mulitplexer, 1
occurence of identifiying.=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 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.=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
>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.=20
- Sec 6 dot3OamAdminState OBJECT-TYPE: Description says disabled(1) it
should be disabled(2) to match the syntax.
MBS>>> Fixed. =20
- Sec 6 dot3OamPeerEntry OBJECT-TYPE: Description last line:"(4). or"
should be "(4), or"=20
MBS>> Fixed.=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
>From Eric Feb-11-2007
Summary:
=3D=3D=3D=3D=3D=3D=3D
Comments:
=3D=3D=3D=3D=3D=3D=3D=3D
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. =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).
MBS>> Mentioned content/purpose of 3.4. =20
___________________________________________________________________
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) -=20
"IEEE Std 802.3-2005:"=20
This looks like a cut-and-paste error.
MBS>> Fixed. =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).
MBS>> Fixed mulitple occurences of looopback. =20
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Questions:
=3D=3D=3D=3D=3D=3D=3D=3D=3D
>From section 3 (Overview - paraphrased):
Three functional objectives (of OAM):
Remote fault indication =20
Link monitoring=20
Remote loopback
Is this a general observation about OAM, or does it affect the=20
way that the MIB objects and tables are laid out?
MBS>> Intent is a general statement about OAM. Did not make any
changes. =20
___________________________________________________________________
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. =20
___________________________________________________________________
In section 7, Security Considerations, you include the following
statement:
"Unlike SNMP, IEEE P802.3ah OAM does not include encryption or=20
authorization mechanisms."
Should "authorization" be "authentication"?
MBS>> Yes it should, changed.=20
___________________________________________________________________
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.=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)?
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)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
idnits 2.01.1=20
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.=20