Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)
draft-ietf-adslmib-vdsl2-07

[Ballot comment]
This document does a nice job of implementing the security considerations template for MIBs.  Richard Barnes secdir review suggested an additional issue for consideration - are there security
issues that are derived from the readable and writable objects in combination?  Given the
the number of security relevant objects in the MIB, that seems plausible.

The authors might want to take a few minutes and conider whether such problems exist.

[Ballot discuss]
This is a process discuss... I would like to be sure the authors have responded to
Richard Barnes review and suggested changes for the security considerations section.
The issues themselves are not blocking, although I think his suggestions have merit,
and I am not asking for changes to the SNMPv3 conformance language (I consider that
settled by the MIB template work).

[Ballot comment]
I don't understand the default value provided in the following object. Please check that it is appropriate majick.

xdsl2LineAlarmConfTemplate  OBJECT-TYPE
  SYNTAX      SnmpAdminString (SIZE(1..32))
  MAX-ACCESS  read-write
  STATUS      current
  DESCRIPTION
      "The value of this object identifies the row in the xDSL2
      Line Alarm Configuration Template Table,
      xdsl2LineAlarmConfTemplateTable, which applies to this line.

      This object MUST be maintained in a persistent manner."
  REFERENCE    "DSL Forum TR-129, paragraph #5.1"
  DEFVAL      { "DEFVAL" }
  ::= { xdsl2LineEntry 3 }

[Ballot discuss]
I would like to hear from the Ops ADs whether they think that TCs like Xdsl2TransmissionModeType should be moved to an IANA MIB module to allow the definition of new values without requiring to respin this MIB module as a new RFC.

It is odd (and possibly non-conformant) to place the IANA Considerations section at 2.2.

IANA Last Call Comments:

Action #1:
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 VDSL2 VDSL2-LINE-TC-MIB [RFC-adslmib-vdsl2-07]


ifType vdsl2(xxx) page 6

Action #2:
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 "mib-2.interface.ifTable.ifEntry.ifType (1.3.6.1.2.1.2.2.1.3)"
Decimal Name Description References
------- ---- ----------- ----------
TBD VDSL2 VDSL2-LINE-TC-MIB [RFC-adslmib-vdsl2-07]

Note: assign the same value in both registries

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

1.a)  Who is the Document Shepherd for this document?

  Menachem Dodge, co-Chair Adslmib WG.


  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?


  Yes.


  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?

          Yes. The document has been reviewed by the WG members. Clay Sikes
          reviewed version 04 in March. His comments were addressed in
          verion 05. The WG reviewed version 05 of the document during
          WG Last Call in June and the corrections following this review
          have been incorporated in version 06.

          The document has not been reviewed by non-WG members.


  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

          Only a small number of individuals in the WG participated in
          reviewing and commenting on the document.
 


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


  (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. There are no specific concerns and there is no IPR disclosure
          related to the document.


  (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?

 
         
          There has been some feedback by a few individuals as mentioned in
          the acknowledgedment section. On the whole, the WG has been silent.
         


  (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?

  Yes, this document satisfies ID nits.

  MIB doctor review has not yet taken place.


  (1.h)  Has the document split its references into normative and
          informative? 

  Yes.

  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?

          No.

  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]? 

  No.

  If so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?

          Yes.

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

          Yes. The identities of the MIB modules should be registered below
          transmission, so that the registration space can be controlled by IANA.



  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?

  Yes. MIB Doctor Review is required.

  (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?

  Yes.


  (1.k) Technical Summary


  This document defines a Management Information Base (MIB) module for
  use with network management protocols in the Internet community.  In
  particular, it describes objects used for managing parameters of the
  "Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type,
        which are also applicable for managing ADSL, ADSL2, and ADSL2+
        interfaces.


        Working Group Summary

        The WG process was smooth with no real controversies.


        Document Quality

        The initial draft of the document was based on the ADSL2 MIB, and thus it has benefited
        from all the comments, feedback and reviews that were done on that document. The model
        and objects follow the ITU-T G.997.1 document.

  The Working Group acknowledges and thanks Clay Sikes for his thorough review of the document.

        No information is available about implementations.