Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB
draft-ietf-adslmib-gbond-eth-mib-08

-------- Original Message --------
Subject: Re: [Adslmib] two questions on draft-ietf-adslmib-gbond-mib-10
Date: Wed, 20 Jun 2012 16:26:45 +0200
From: Benoit Claise
To: Edward Beili
CC: Moti Morgenstern , Menachem Dodge , "adslmib-chairs@ietf.org" , "Romascanu, Dan (Dan)" , Adrian Farrel , me


Hi Edward,

Thanks for your answer.
Please update the draft with your proposed changes below, and send it to this group.
From there, I will double-check if all points are addressed.
In the mean-time, I will put the draft in Revised-ID needed.

Regards, Benoit.

[Ballot comment]
I have cleared my Discuss. The liaison manager to the IEEE has tried a number of times to get a response on my question. we may safely assume that the absence of a robust and rapid objection means that there is no issue.

Sorry to have held this work up so long on my procedural Discuss.

[Ballot discuss]
This is a procedural Discuss that I am holding while I have a question
outstanding to the liaison to IEEE. I do not have any action for the
document authors, and expect to be able to clear the Discuss when I have
the answer.

updated write-up from Menachem Dodge:

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

  Menachem Dodge, Adslmib WG Chair.


  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 both key WG members, and
          non-WG members. Comments from these reviews have been taken into
          account.

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

          No.
 


  (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. The AD provided feedback during the development of the document.
          In addition the document has been reviewed by several MIB doctors
          and by the Security-DIR.


  (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.The Broadband Forum TR-159 document provides
          a basis for this MIB module, as for all the G.Bond MIB modules, and this
          work was solicited by the Broadband forum.This I-D has appeared in the RFP of an
          operator and at least one vendor is known to be including this module within its
          products.

          No, 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?

 
  This document is based on the Broadband Forum specification TR-159.
         
  There is WG agreement for 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?

  Yes, this document satisfies ID nits.

  This document has been reviewed by the MIB doctors.


  (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.     
          This document requests that an object identifier for gBondEthMIB be allocated
          by IANA [1] in the MIB-2 transmission sub-tree.

  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?

  The document has been reviewed by the MIB Doctors and for Security issues.

  (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 proposes an extension to the GBOND-MIB module with a set of
        objects for managing Ethernet-based multi-pair bonded xDSL interfaces, defined
        in ITU-T recommendation G.998.2.


        Working Group Summary

        The WG process was smooth with no real controversies. The document was reviewed
        by key members of the WG and by the MIB doctors and Security-DIR.Feedback from these
        reviews was taken into account and the I-D was updated accordingly.



        This work together with all of the other G.Bond documents is based on the guidelines set
        forward by the Broadband Forum TR-159. The Broadband Forum solicited this work and it is known
        that the G. Bond I-Ds have appeared in operator RFPs and this G.Bond MIB module is being
        implemented in at least one vendor's products.

IANA has the same question about documents
draft-ietf-adslmib-gbond-atm-mib-05.txt,
draft-ietf-adslmib-gbond-tdim-mib-07.txt,
draft-ietf-adslmib-gbond-eth-mib-05.txt, and
draft-ietf-adslmib-gbond-mib-09.txt.

This document appears to be requesting the following transmission number
from
http://www.iana.org/assignments/smi-numbers
under iso.org.dod.internet.mgmt.mib-2.transmission (1.3.6.1.2.1.10):

Decimal Name Description Reference
------- ------------ ------------------------------- ---------
?? gBondEthMIB ??? [RFC-to-be]

However, this does not correspond to an existing ifType registration,
and this document does not request a new one. There are three previously
assigned ifTypes that will have the related document
draft-ietf-adslmib-gbond-mib-09.txt as a reference, but their names are
"g9981," "g9982," and "g9983." Furthermore, that document (to which this
same question applies) appears to request a transmission number that
would refer to the whole group. Section 3.12 of RFC 1213 says of
transmission numbers,

"By convention, the name assigned is:

type OBJECT IDENTIFIER ::= { transmission number }

where 'type' is the symbolic value used for the media in the ifType
column of the ifTable object, and 'number' is the actual integer
value corresponding to the symbol."

Does the "by convention" language mean that this can be assigned without
a corresponding ifType? If so, we need the author to supply a description.

There would be an issue here, though, in that there are currently four
draft-ietf-adslmib-gbond documents that appear to be requesting unique
transmission numbers, and only three related ifTypes. To register a
fourth could potentially throw off the numbering for all future
ifType/transmission number registrations, if we understand the requests
correctly.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB) to Proposed Standard


The IESG has received a request from the ADSL MIB WG (adslmib) to
consider the following document:
- 'Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines Management Information Base (MIB) module for
  use with network management protocols in TCP/IP based internets.
  This document proposes an extension to the GBOND-MIB module with a
  set of objects for managing Ethernet-based multi-pair bonded xDSL
  interfaces, defined in ITU-T recommendation G.998.2.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-eth-mib/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-eth-mib/


No IPR declarations have been submitted directly on this I-D.

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

  Menachem Dodge, Adslmib WG Chair.


  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 the WG chair and the co-editors.
  Comments that were raised have been taken into account.

          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 very little feedback from WG members. 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.     
          This document requests that an object identifier for gBondEthMIB be allocated
          by IANA [1] in the MIB-2 transmission sub-tree.

  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?

  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 proposes an extension to the GBOND-MIB module with a set of
        objects for managing Ethernet-based multi-pair bonded xDSL interfaces, defined
        in ITU-T recommendation G.998.2.


        Working Group Summary

        The WG process was smooth with no real controversies.


        Document Quality


        No information is available about implementations.