Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-vdsl2-06.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 22 Jan 2009 15:37:55 +0100

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-masked]] 
> Sent: Sunday, November 09, 2008 4:53 PM
> To: Romascanu, Dan (Dan); David B Harrington
> Cc: MIB Doctors (E-mail); [email-masked]; Menachem Dodge; 
> [email-masked]; [email-masked]
> 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
> 
_______________________________________________
Adslmib mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/adslmib

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 22 Jan 2009 21:42:02 +0100

There are some more comments from David Harrington listed below. 

Please address them in the new version of the MIB module and of the
document. 

1) as per RFC4181 the TruthValue TC SHOULD be used in the SYNTAX clause
of object definitions
    that require a Boolean type.  MIB modules SHOULD NOT use enumerated
    INTEGER types or define TCs that duplicate its semantics.

2) the MIB organization does not follow the RECOMMENDED OID assignment
scheme for notifications as per section 4.7 and Appendix D of RFC 4181

3) Xdsl2LineEntry  ::=
   SEQUENCE {
      xdsl2LineCnfgTemplate            SnmpAdminString,
      xdsl2LineCnfgFallbackTemplate    SnmpAdminString,
      xdsl2LineAlarmCnfgTemplate       SnmpAdminString,
      xdsl2LineCmndConfPmsf            Xdsl2ConfPmsForce,
      xdsl2LineCmndConfLdsf            Xdsl2LineLdsf,
      xdsl2LineCmndConfLdsfFailReason  Xdsl2LdsfResult,
      xdsl2LineCmndConfBpsc            Xdsl2LineBpsc,
      xdsl2LineCmndConfBpscFailReason  Xdsl2BpscResult,
      xdsl2LineCmndConfBpscReqCount    Unsigned32,
      xdsl2LineCmndAutomodeColdStart   TruthValue,
      xdsl2LineCmndConfReset           Xdsl2LineReset,
      xdsl2LineStatusActTemplate       SnmpAdminString,
      xdsl2LineStatusXtuTransSys       Xdsl2TransmissionModeType,
      xdsl2LineStatusPwrMngState       Xdsl2PowerMngState,
      xdsl2LineStatusInitResult        Xdsl2InitResult,
      xdsl2LineStatusLastStateDs       Xdsl2LastTransmittedState,
      xdsl2LineStatusLastStateUs       Xdsl2LastTransmittedState,
      xdsl2LineStatusXtur              Xdsl2LineStatus,
      xdsl2LineStatusXtuc              Xdsl2LineStatus,
      xdsl2LineStatusAttainableRateDs  Unsigned32,
      xdsl2LineStatusAttainableRateUs  Unsigned32,
      xdsl2LineStatusActPsdDs          Integer32,
      xdsl2LineStatusActPsdUs          Integer32,
      xdsl2LineStatusActAtpDs          Integer32,
      xdsl2LineStatusActAtpUs          Integer32,
      xdsl2LineStatusActProfile        Xdsl2LineProfiles,
      xdsl2LineStatusActLimitMask      Xdsl2LineLimitMask,
      xdsl2LineStatusActUs0Mask        Xdsl2LineUs0Mask,
      xdsl2LineStatusActSnrModeDs      Xdsl2LineSnrMode,
      xdsl2LineStatusActSnrModeUs      Xdsl2LineSnrMode,
      xdsl2LineStatusElectricalLength  Unsigned32,
      xdsl2LineStatusTssiDs            Xdsl2Tssi,
      xdsl2LineStatusTssiUs            Xdsl2Tssi,
      xdsl2LineStatusMrefPsdDs         Xdsl2MrefPsdDs,
      xdsl2LineStatusMrefPsdUs         Xdsl2MrefPsdUs,
      xdsl2LineStatusTrellisDs         TruthValue,
      xdsl2LineStatusTrellisUs         TruthValue,
      xdsl2LineStatusActualCe          Unsigned32
   }

Check out inconsistent abbreviations, such as
xdsl2LineCnfgFallbackTemplate which points to the
xdsl2LineConfTemplateTable. (cnfg and conf both mean configuration) I
note that RFC2662 uses "conf" consistently.

4)The counter  xdsl2LineCmndConfBpscReqCount let's management station M1
know when another management station M2 requested a measurement, which
caused the relevant counter to reset, such that M1's measurement is no
longer valid. 
      "SNMP managers can use this attribute to check that the
       measurement results retrieved by the manager where not 
       interupted by another measurement request."

We discouraged resetting counters in IETF MIB modules. Can you explain
why this is necessary? 

5) The naming conventions for counters are not being followed -
xdsl2LineCmndConfBpscReqCount should probably be
xdsl2LineCmndConfBpscRequests.

6) xdsl2LineCmndConfBpscReqCount -  why is this an Unsigned32 and not a
Counter32?

7) I am a bit concerned about the table that actually contains the
measurement - the xdsl2LineSegmentTable  The actual measurement is in
xdsl2LineSegmentBitsAlloc. It appears the value is overloaded to provide
subcarrier allocation status, as well as the result of a line diagnostic
test. 

8) from security considerations "Unauthorized changes to
xdsl2LineCmndConfBpsc could cause an unscheduled bits per subcarrier
measurement to be carried out on the line.", and "Unauthorized changes
to xdsl2LineCmndConfLdsf could cause an unscheduled line test to be
carried out on the line." Since these two measurements report using the
same object, and since one measurement can interfere with the validity
of the measurement requested by a different manager, this seems to have
serious issues of information reliability.

9) On a larger scale, I am concerned that this appears to be a
**competing** standard to RFC2662. This does not complement, or update,
or obsolete RFC2662.

I have not yet gone into the two mib modules to determine how compatible
they are, but section 4 in this document makes me really uneasy as a
(previous) management app designer. Can a device support both mib
modules simultaneously? Can a management app use both MIB modules
simultaneously to manage the same ADSL functions on a device?

I note that rfc2662 does support using the entity mib, while this mib
module does not. Which makes me wonder about the compatibility between
the two mib modules.

Thanks and Regards,

Dan

> From: [email-masked]

---

From: Moti Morgenstern <[email-masked]>
Date: Fri, 30 Jan 2009 12:39:43 +0200

Hi Dan and David,

The editors reviewed the additional comments against revision -06 and our response is the following (numbered according to the comment numbers):

1) As explained in our previous reference to this issue, we prefer the special TCs we use instead of replacing them with the TruthValue TC, which we do use where appropriate. This is also because the use of TrutrhValue TC is not mandatory (That can easily understood from the [RFC2119] interpretation of "SHOULD NOT"). 

2) The comment is not so clear. 
Do you mean that, instead of xdsl2Notifications OBJECT IDENTIFIER ::= { vdsl2 0 } 
we should use xdsl2Notifications OBJECT IDENTIFIER ::= { vdsl2MIB 0 } 
so the notifications will reside directly under the MODULE-ENTITY?
We'll appreciate a quick answer for this, if possible.  

3) We'll fix the abbreviation inconsistency reported.

4-6) xdsl2LineCmndConfBpscReqCount will be renamed as suggested and we'll also change its syntax. However, we believe that there is a misunderstanding of the mechanism for which we use that object. Therefore we intend to change the DESCRIPTION clauses of this object and xdsl2LineCmndConfBpsc to clarify the dynamic behavior of the procedure. The main point to explain is that the SNMP agent does not allow interrupting a process which is in progress. The counter only allows the manager to identify the reported measurements are result of "his" process (i.e., they may belong to a process that was executed later on, after his process was already complete).   

7) The results of a line diagnostic tests have their own table (xdsl2SCStatusSegmentTable) and therefore xdsl2LineSegmentTable is not overloaded.

8) The xdsl2LineCmndConfBpsc and xdsl2LineCmndConfLdsf are associated with different results tables.

9) 
a) The document already describes the coexistence of RFC 2662, RFC 4706 and the current document. We can summarize that RFC2662 is relevant only for managing modems that do not support any DSL technology other than ADSL (e.g., G.992.1/2) especially if were produced prior to approval of ITU-T G.997.1 rev 3 . RFC 4706 is more appropriate for managing modems that support ADSL2 technology variants (with or without being able to support the legacy ADSL). The current document supports all ADSL, ASDSL2 and VDSL2 standards but it assumes a more sophisticated management model, which older modems (even ADSL2 ones) may not be able to support. 
b) It's important to notice that each modem can indicate, by the ifType, what (specific) MIB it supports. E.g., It's possible to upgrade from RFC 2662 to 4706 MIB, but it requires a software change on both sides of the management interface and also a database conversion.    
c) We do not agree that "rfc2662 does support using the entity mib". All it says is that implementing the entity MIB is optional and that, if implemented, it should include a row for the the ATU-C or ATU-R based on the agent lcation. This is so obvious that it's not a surprise no other xDSL line MIB (e.g., RFC 3728 (vdsl), RFC 4319 (shdsl), RFC 4706 (adsl2)) refers to that. 
By the way, note that even RFC 2662 understands that there can be a row in the entity MIB for either the ATU-C or ATU-R, not both. This strengthen our response to Dan's previous comment T8 that referred to the entity MIB.  

Thanks for your efforts,
Moti Morgenstern

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Thursday, January 22, 2009 10:42 PM
To: Romascanu, Dan (Dan); Moti Morgenstern; David B Harrington
Cc: MIB Doctors (E-mail); [email-masked]; Menachem Dodge; [email-masked]; [email-masked]
Subject: RE: [MIB-DOCTORS] AD review of draft-ietf-adslmib-vdsl2-06.txt

Hi Moti,

3) Xdsl2LineEntry  ::=
   SEQUENCE {

Thanks and Regards,

Dan