Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
draft-ietf-hubmib-efm-cu-mib-08

IANA Last Call Comments:

[ Note: the IANA Considerations section is
unclear. The first paragraph only implies that
this draft has a dependency on another draft.
There are no actions in the first draft and the
phrasing is confusing. ]


Upon approval of this document, the IANA will
make the following assignments in the "NETWORK
MANAGEMENT PARAMETERS" registry located at

http://www.iana.org/assignments/smi-numbers

sub-registry "Prefix: iso.org.dod.internet.mgmt.mib-2
(1.3.6.1.2.1)"

Decimal Name Description References
------- ---- ----------- ----------
[tbd] efmCuMIB Ethernet in the First Mile
[RFC-hubmib-efm-cu-mib-07]
(EFM) Copper (EFMCu) MIB
[tbd] ifCapStackMIB cross-connect capabilities of [RFC-hubmib-efm-cu-mib-07]
stacked (layered) interfaces MIB

We understand the above to be the only IANA
Action for this document.

IANA Last Call Comments:

[ Note: the IANA Considerations section is
unclear. The first paragraph only implies that
this draft has a dependency on another draft.
There are no actions in the first draft and the
phrasing is confusing. ]


Upon approval of this document, the IANA will
make the following assignments in the "NETWORK
MANAGEMENT PARAMETERS" registry located at

http://www.iana.org/assignments/smi-numbers

sub-registry "Prefix: iso.org.dod.internet.mgmt.mib-2
(1.3.6.1.2.1)"

Decimal Name Description References
------- ---- ----------- ----------
[tbd] efmCuMIB Ethernet in the First Mile
[RFC-hubmib-efm-cu-mib-07]
(EFM) Copper (EFMCu) MIB
[tbd] ifCapStackMIB cross-connect capabilities of [RFC-hubmib-efm-cu-mib-07]
stacked (layered) interfaces MIB

We understand the above to be the only IANA
Action for this document.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Bert Wijnen.
Yes, I have reviewed the document and believe it is ready for
publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes. Reviews (some complete, some partial) have been done by several
people,
including Dan Romascanu (previous WG chair), Keith McCloghrie, Matt
Squire, Frank van der Putten, Menachem Dodge, Clay Sikes, Mike
Heard
and others.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No more detailed reviews needed.
Copies of WG last calls were sent to the ADSLMIB WG list and to the
IEEE 802.3 chairs.
When I see IETF Last Call, I will again forward those.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns. No known IPR disclosures.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The HUBMIB WG is not a large WG. But those who are active do have
consensus on this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

IDnits tells me:

idnits 2.04.07

Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:

------------------------------------------------------------------------
----

No issues found here.

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

------------------------------------------------------------------------
----

No issues found here.

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

------------------------------------------------------------------------
----

== There are 31 instances of lines with non-RFC3330-compliant IPv4
addresses in the document. If these are example addresses, they
should
be changed.

Bert Wijnen checked all these (using verbose option) and they are not
really IPv4 addresses, They just look like IPv4 addresses. Here is an
example:

An SNMP Agent for a EFMCu device builds ifCapStackTable and its
inverse ifInvCapStackTable according to the information contained
in
the Clause 45 PME_Available_register (see [802.3ah] 61.1.5.3 and
45.2.3.20).

IDnits tool seems to think that 61.1.5.3 and 45.2.3.20 are IPv4
addresses
which they clearly are not.

So nothing to worry about here.

Miscellaneous warnings:

------------------------------------------------------------------------
----

No issues found here.

Checking references for intended status: Proposed Standard

------------------------------------------------------------------------
----

== Outdated reference: A later version (-06) exists of
draft-ietf-hubmib-efm-mib-05

Bert Wijnen suggests that the RFC-Editor will catch this one, In fact,
the
document in section 10 (Notes to RFC Editor) suggests:

Please replace [I-D.ietf-hubmib-efm-mib] and
[I-D.ietf-hubmib-rfc3636bis] with actual RFC numbers if those are
available at time of publication.

So that will be taken care of.

Summary: 0 errors (**), 2 warnings (==), 0 comments (--).

-----------------------------------------------------------------------



(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References have been split.
No issues exists with any of them.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Document Shepherd believes IANA Considerations section is clear.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The MIB Module SYNTAX has been checked and is correct.
There is no other formal language.
There is a pseudo-code example that I think is correct, but it has not
been checked by a syntax checker.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document defines Management Information Base (MIB) modules for
use with network management protocols in TCP/IP based internets.
This document describes extensions to the Ethernet-like Interfaces
MIB and MAU MIB modules with a set of objects for managing Ethernet
in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL,
defined in IEEE Std 802.3ah-2004. In addition a set of objects is
defined, describing cross-connect capability of a managed device with
multi-layer (stacked) interfaces, extending the stack management
objects in the Interfaces Group MIB and the Inverted Stack Table MIB
modules.

Working Group Summary

The process was somewhat time consuming because many of the 802.3
domain experts do not attend the IETF f2f meetings on a regular basis
anymore. Nevertheless, the WG chair believes that we have had
sufficient
participation from IETF and IEEE 802.3 people to request publication
of this MIB document as a PS RFC.

Document Quality

Preliminary implementations have been claimed to exist.

Since various MIB doctors were active participants/reviewers, no
dedicated MIB doctor review was requested (yet). The WG chair
believes such is not needed anymore, but leaves this up to the AD.

Well known MIB doctors who have reviewed this document include
Bert Wijnen, Dan Romascanu, Keith McCloghrie, Mike Heard.

In addition, the WGLC was forwarded to IEEE 802.3 and ADSLMIB WG.

Because of comments during these reviews, a few new revisions were
created, which has now resulted in an agreed to revision 07.

Bert Wijnen
Chair of the IETF HUBMIB WG