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

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,

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

> -----Original Message-----
> From: [email-masked] 
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 16 Feb 2009 13:29:18 +0100

See my answers in-line. David, please jump in if you have objections.

Thanks and Regards,

Dan

> From: Moti Morgenstern [mailto:[email-masked]] 
> Sent: Friday, January 30, 2009 12:40 PM
> To: Romascanu, Dan (Dan); David B Harrington
> Cc: MIB Doctors (E-mail); [email-masked]; Menachem Dodge; 
> [email-masked]; [email-masked]
> 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"). 

OK - still not best IMO but I can live with this. 

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

I clarified this I think in the separate mail sent yesterday. 

> 3) We'll fix the abbreviation inconsistency reported.

Thanks. 

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

OK - pending on the exact edits you need to come with. 

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

OK

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

I am not sure that you understood our concern here. Exactly the fact
that there are two different tables is the reason of concern because the
tests can happen on the same line simultaneously, at the request of two
different managers, one writing  xdsl2LineCmndConfBpsc and another
xdsl2LineCmndConfLdsf. Can this happen? If not, please explain what we
are missing. 

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

The two issues above seem to be important enough to be explicitly
mentioned in the document. 
 
> 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. 

I guess that David's intent was that he expected this reference to the
entity MIB to show up here as well. Sometimes it is better to state the
obvious. 

> 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
> 
> Cc: MIB Doctors (E-mail); [email-masked]; Menachem Dodge; 
> [email-masked]; [email-masked]
> 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
> 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 {
> 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. 
> 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 
> 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. 
> 
> 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.
> 
> **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: "David B Harrington" <[email-masked]>
Date: Mon, 16 Feb 2009 09:55:57 -0500

Hi,

It is almost always important to remember the audience for a MIB. 
This MIB will be used by operators and NMS developers.

Operators and NMS developers are accustomed to Truthvalue TCs.
Many NMS applications already have been coded to present the values as
"true" and "false" for Truthvalue TCs. When those many NMS
applications parse this MIB module and get the special-case TCs, the
NM application writer will need to write new special-case code for
these special-case TCs.

People who helped develop the managed protocol are probably NOT the
same people who are going to work on the helpdesk or in the IT
department monitoring the values and behaviors of the network on a
daily basis, and are not the people who will write NM applications
(unless they will write special-case NM applications for this MIB
module).

So while it might be more "natural" for the protocol designers to
think in terms of 0-1, the end-users of the MIB are accustomed to
TruthValue TCs, and NMS applications already know how to deal with the
standard TCs rather than the special-case TCs being used in this MIB.

Interoperability in the world of network management protocols, like
SNMP and MIBs, is all about making it possible for NM applications to
talk to managed devices in a manner that is consistent and
vendor-neutral, and managed-technology-neutral. That is why SNMP has a
standard set of error codes, rather than different error codes for
each managed technology. That is why SMIv2 organizes data into
two-dimensional tables rather than in deep nested structures, even if
the underlying technology uses deep nested structures. That is why
SNMP has standard datatypes, rather than different datatypes for each
managed protocol. The special-case datatypes being proposed as TCs in
this MIB module seem to be simply designer-preference - we like 0-1
better than 1-2. 

I think there is a strong interoperability justification for using
TruthValue TC rather than MIB-specific TCs with the same purpose.  

Over thwe past ten years or so, we have had it drilled into our heads
by the user community that we need to meet the interoperability needs
of the readers and users of MIB modules, such as operators and NM
application developers, more than the personal preferences of the MIB
module writers.

I think this MIB should use TruthValue, not special-case TCs.

dbh

> Sent: Monday, February 16, 2009 7:29 AM
> To: Moti Morgenstern; David B Harrington

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 16 Feb 2009 16:02:48 +0100

I support David's position. As I said, I could live with multiple
'special' TCs, but this is far from optimal, so I strongly suggest to
the authors to reconsider this issue, in the light of David's arguments.

Dan

> From: David B Harrington [mailto:[email-masked]] 
> Sent: Monday, February 16, 2009 4:56 PM
> To: Romascanu, Dan (Dan); 'Moti Morgenstern'
> Cc: 'MIB Doctors (E-mail)'; [email-masked]; 'Menachem 
> Dodge'; [email-masked]; [email-masked]
> Many NMS applications already have been coded to present the 
> values as "true" and "false" for Truthvalue TCs. When those 
> many NMS applications parse this MIB module and get the 
> special-case TCs, the NM application writer will need to 
> write new special-case code for these special-case TCs.
> 
> People who helped develop the managed protocol are probably 
> NOT the same people who are going to work on the helpdesk or 
> in the IT department monitoring the values and behaviors of 
> the network on a daily basis, and are not the people who will 
> write NM applications (unless they will write special-case NM 
> applications for this MIB module).
> 
> So while it might be more "natural" for the protocol 
> designers to think in terms of 0-1, the end-users of the MIB 
> are accustomed to TruthValue TCs, and NMS applications 
> already know how to deal with the standard TCs rather than 
> the special-case TCs being used in this MIB.
> 
> Interoperability in the world of network management 
> protocols, like SNMP and MIBs, is all about making it 
> possible for NM applications to talk to managed devices in a 
> manner that is consistent and vendor-neutral, and 
> managed-technology-neutral. That is why SNMP has a standard 
> set of error codes, rather than different error codes for 
> each managed technology. That is why SMIv2 organizes data 
> into two-dimensional tables rather than in deep nested 
> structures, even if the underlying technology uses deep 
> nested structures. That is why SNMP has standard datatypes, 
> rather than different datatypes for each managed protocol. 
> The special-case datatypes being proposed as TCs in this MIB 
> module seem to be simply designer-preference - we like 0-1 
> better than 1-2. 
> 
> I think there is a strong interoperability justification for 
> using TruthValue TC rather than MIB-specific TCs with the 
> same purpose.  
> 
> Over thwe past ten years or so, we have had it drilled into 
> our heads by the user community that we need to meet the 
> interoperability needs of the readers and users of MIB 
> modules, such as operators and NM application developers, 
> more than the personal preferences of the MIB module writers.
> 
> > > -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").
> > 
> > > 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?
> 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.
> > 
> > OK
> > 
> > > 
> > that there are two different tables is the reason of 
> concern because 
> > the tests can happen on the same line simultaneously, at 
> the request 
> > of two different managers, one writing  xdsl2LineCmndConfBpsc and 
> > another xdsl2LineCmndConfLdsf. Can this happen? If not, 
> please explain 
> > what
> we
> > are missing. 
> > 
> > > 
> > > 9)
> 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
> 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.
> > 
> > entity MIB to show up here as well. Sometimes it is better to state 
> > the obvious.
> > 
> > > 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
> > > 
> > > 1) as per RFC4181 the TruthValue TC SHOULD be used in the SYNTAX 
> > > clause of object definitions
> > > assignment scheme for notifications as per section 4.7 
> and Appendix 
> > > D of RFC 4181
> > > 
> > > 3) Xdsl2LineEntry  ::=
> > >    SEQUENCE {
> > > station M1 know when another management station M2 requested a 
> > > measurement, which caused the relevant counter to reset, 
> such that 
> > > We discouraged resetting counters in IETF MIB modules. Can you 
> > > explain why this is necessary?
> > > 
> > > 6) xdsl2LineCmndConfBpscReqCount -  why is this an Unsigned32 and 
> > > not a Counter32?
> > > 
> 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. 
> > > 
> 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.
> > > 
> > > **competing** standard to RFC2662. This does not complement, or 
> > > update, or obsolete RFC2662.
> > > 
> > > compatible they are, but section 4 in this document makes 
> me really 
> > > uneasy as a
> > > I note that rfc2662 does support using the entity mib, while this 
> > > mib module does not. Which makes me wonder about the 
> compatibility

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Mon, 16 Feb 2009 16:14:35 +0100

I agree hat using TruthValue SYNTYAX would be strongly preferred over
using a decicated TC or SYNTAX.

Bert

  ----- Original Message ----- 
  From: David B Harrington 
  To: 'Romascanu, Dan (Dan)' ; 'Moti Morgenstern' 
  Cc: 'MIB Doctors (E-mail)' ; [email-masked] ; 'Menachem Dodge' ; [email-masked] ; [email-masked] 
  Sent: Monday, February 16, 2009 3:55 PM
  Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-adslmib-vdsl2-06.txt

  Hi,

  dbh

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Feb 2009 11:24:06 -0800

> using a decicated TC or SYNTAX.

I haven't read the draft, but the guidelines are subtle.
If the MIB object has semantics of 'true or false',
then TruthValue MUST be used (IMO).

If the semantics are more specific (e.g., enabled/disabled)
then it is not so clear.  Perhaps a new enum value will be needed
in the future.  TruthValue SHOULD be used if the semantics
really are boolean.

> Bert

Andy