Re: AD review of draft-ietf-adslmib-vdsl2-06.txt

Hi Dan and David,

Thank you for the comments regarding to draft-ietf-adslmib-vdsl2-06.txt.
We, the editors, reviewed the comments and here is our response to each (Dan's comments and then David's):

Comment T1
-------------- 
Comment suggests writing specifically in the MIB module, in the DESCRIPTION clauses of the MIB tables, what is the persistence policy relative to the objects in the table.
Response: We have a section in the document called "2.5.  Persistence" which lists all persistent objects. If you search for each of these objects in the MIB, not all of the objects mention persistence in the DESCRIPTION clause. This is when the persistency is relevant to ALL objects and, when that happens, the DESCRIPTION clause of the containing table mentions: "Entries in this table MUST be maintained in a persistent manner." So we believe the current situation is satisfactory.

Comment T2 
--------------
Comment claims that indexation by name is very resource consuming.
Response: The observation is basically correct. Despite that, we chose name indexes on purpose for ease of use by the operator and consistency with all other xDSL MIBs. 

Comment T3 
--------------
Comment refers to rate-limiting notifications mentioned in the document.
Response: We will remove the rate limiting comment altogether because no other xDSL MIB mentions this.

Comment T4
--------------
Comment is a request to explain the Reserved bits in Xdsl2TransmissionModeType.
Response: We used reserved bits because we want the VDSL2 MIB to closely match the source document G.997.1.

Comment T5 
--------------
Comment about the Textual Conventions with enumerated INTEGER syntax in which the list of values starts from zero.
Response: Similar to T4 above this was done on purpose. We want the MIB to closely match the source document G.997.1 which already defines the range of enumerated values for many attributes. Since the syntax allows that we don't see it necessary to explain such considerations in the MIB. 

Comment T6 
--------------
Comment about the Boolean objects with new TCs instead of using TruthValue
Response: We use TruthValue for 10 objects in the MIB, so, it's not that we are not familiar with that TC. The real reason, again, is that G.997.1 specifically defines the range of values and meaning for many attributes and our MIB follows it as much as we could. 

Taking the Textual Conventions mentioned in this comment as examples:
Xdsl2LineLdsf- G.997.1 uses the value 0 to inhibit LDSF and 1 for forcing LDSF. We preferred explicitly using those values. 
Xdsl2LineCeFlag- CEFLAG is defined by G.997.1 as a bitmap with a single bit. So, the values range is 0 and 1.
Xdsl2LineSnrMode-TruthValue uses the value 1 for true and 2 for false, while G.997.1 uses 1 for disable and 2 for enable.

There is still one TC (Xdsl2LineForceInp) that could be replaced by the TruthValue. This will be performed.  

Comment T7
--------------
Comment regarding to using RowStatus only to delete rows
Response: We'll add text in the relevant DESCRIPTION clauses to explain that the agent rejects any SET operation which sets row status to a value other than delete(6)

Comment T8
--------------
Comment: why not replace inventory information in Xdsl2LineInventoryEntry with entPhysicalTable in RFC4133
Response: There are several arguments against the idea. However, the most important one is that we need to provide the inventory for both near-end and far-end units and that means two rows per each ifIndex. So, we cannot use RFC4133 for inventory because the indexing scheme is inappropriate.

Comment T9
--------------
Comment: what happens when row is validated, etc.
Response: We agree that there's a need to perform several changes in the DESCRIPTION clause of row-status objects. This will include removing the text about validating the row content (i.e., as we cannot explain how we expect the implementation to perform that) as well as giving more information regarding to deleting a "referenced" row. 

Comment T10
--------------
Comment requests explanation about how the thresholds in the xdsl2ChAlarmConfProfileTable are being applied
Response: First of all, RFC3705 includes TCs and we use one of them in the referred table. Second, we suggest to add a text in the top part of the document explaining that only one threshold trap per interval will be issued once the individual counter exceeds the threshold defined for it. Is that acceptable?

Comment T11
-------------- 
Comment suggests that the compliance should be function of the flavor(s) of xDSL an agent implements. 
Response: The MODULE-COMPLIANCE section applies to all technology types: VDSL2/ADSL/ADSL2 and ADSL2+. The assumption of G.997.1 is that a typical implementation supports a mixture of technologies and transmission modes, not a single selected one, and that's why the abstract attribute was originally defined as a bit map rather than an enumeration of modes. The idea is that a typical operator wishes to serve all transmission modes supported by the remote units so he prepares, for each service package, a setup that can satisfy multiple use cases. 
Theoretically, Most of the MIB attributes are relevant for all or at least multiple xDSL technologies. There are still several which are relevant for a specific technology. We didn't want to complicate the compliance section because otherwise we would also need to handle attributes that are sometimes mandatory and sometimes optional (and what happens when you have a mixed scenario..?). So, we believe an agent implementation should conform to the compliance clause but also consult with ITU-T G.997.1 to see exactly what is required depending on the mixture of the various transmission modes relevant for the specific operator.  

Comment E1
--------------
Comment: s/ a more comprehensive/a complementary/
Response: The ADSL2 MIB is recommended for implementations that do not implement VDSL2 and do not want to be affected by it at all. The NG-xDSL MIB (this draft) has a wider scope of technologies and is recommended for implementations of VDSL2 (only VDSL2 or together with older DSL technologies) and are ready to pay the "price". The "price" is expressed in various ways, e.g., the need to implement the "subcarrier group" related attributes for DELT also for ADSL/2/2+, although those attributes are meaningful only in VDSL2.
So the new MIB is not a complementary one but a solution for the same problem space, only with a wider set of DSL technologies.

Comment E2
--------------
Comment: list of abbreviations
Response: OK

Comment E3
--------------
Comment: Section 2.3.2 duplicates text from the TC-MIB module itself
Response: OK. We'll delete it.

Comment E4
--------------
Comment: page 28 - s/This MIB allows supporting/This MIB module allows supporting
Response: OK.

Comment E5
--------------
Comment: page 31 - s/ Network Elements may /Network Elements MAY/ and s/The xTU-C should / The xTU-C SHOULD/
Response: OK.

Comment E6
--------------
Comment: In SMIv2 we do not usually speak about attributes but about objects
Response: We'll correct the relevant text.

Comment E7
--------------
Comment: DESCRIPTION clause of the MIB module duplicates text in the Overview section
Response: We'll use a short summary in the overview section and a full description in the MIB module.

Comment E8
--------------
Comment: 'an ifType of vdsl(xxx)'. It is good to add at least at the first occurrence a note to the RFC Editor
Response: OK.

Comment E9
--------------
Comment: The DESCRIPTION clauses of Valid Intervals and Invalid Intervals are almost void
Response: We'll fill the DESCRIPTION clauses for these objects

Comment E10
--------------
Comment: Section 4 would benefit from one or two examples of configuration templates
Response: We prefer not to add any additional tutorial material into the VDSL2 draft MIB. 


Comments from David B Harrington
--------------------------------

Comment: "One suggestion would be to put the VDSL2-LINE-TC-MIB in a separate
document."
Response: This would require 2 RFC numbers for VDSL2 and we don't like it. We also have an experience from RFC4706 and the draft ANCP AN MIB (draft-ietf-ancp-mib-an-03) that have the same structure as this draft.

Comment:"I strongly support Dan's request to eliminate some of the redundancy in this document, and I recommend starting with the textual convention triplication. You can probably save 30% of the document length getting rid of unnecessary textual convention definitions."
Response: We have no real objection to removing the TCs that are referenced only once and placing the definition in the object definition. Is that also agreed by Dan? Any comment from the WG members?

Comment: "It might be good to have a manageability considerations section that discusses using short strings and internal choices to minimize the resource impact."
Response: We don't think this is necessary.

Dan and David, Thanks again for your time and your comments.

On behalf of the co-editors,
Moti Morgenstern