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

Hi Moti,

Your proposed resolution to the comments looks satisfactory to me. 

Please proceed with creating a revised version of this document which
could be sent to IETF LC. 

Thanks and Regards,

Dan
 

> -----Original Message-----
> From: Moti Morgenstern [mailto:[email protected]] 
> Sent: Sunday, November 09, 2008 4:53 PM
> To: Romascanu, Dan (Dan); David B Harrington
> Cc: MIB Doctors (E-mail); [email protected]; Menachem Dodge; 
> [email protected]; [email protected]
> Subject: 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
>