Subject: Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ietf-adslmib-vdsl2-06.txt
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Moti Morgenstern" <[email-masked]>, "David B Harrington" <[email-masked]>
Cc: "MIB Doctors \(E-mail\)" <[email-masked]>, [email-masked], Menachem Dodge <[email-masked]>, [email-masked]
Date: Mon, 16 Feb 2009 13:29:18 +0100
List-Id: ADSLMIB <adslmib.ietf.org>

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

Thanks and Regards,

Dan

 

> -----Original Message-----
> 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]
> Subject: RE: [MIB-DOCTORS] AD review of 
> draft-ietf-adslmib-vdsl2-06.txt
> 
> 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"). 

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

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

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

Content-class: urn:content-classes:message
Date: Mon, 16 Feb 2009 16:02:48 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "David B Harrington" <[email-masked]>, "Moti Morgenstern" <[email-masked]>
Cc: "MIB Doctors \(E-mail\)" <[email-masked]>, [email-masked], Menachem Dodge <[email-masked]>, [email-masked]
Subject: Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ietf-adslmib-vdsl2-06.txt

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

> -----Original Message-----
> 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]
> Subject: RE: [MIB-DOCTORS] AD review of 
> draft-ietf-adslmib-vdsl2-06.txt
> 
> 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
> 
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> > Sent: Monday, February 16, 2009 7:29 AM
> > To: 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
> > 
> > See my answers in-line. David, please jump in if you have
> objections.
> > 
> > Thanks and Regards,
> > 
> > Dan
> > 
> > 
> >  
> > 
> > > -----Original Message-----
> > > 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]
> > > Subject: RE: [MIB-DOCTORS] AD review of 
> > > draft-ietf-adslmib-vdsl2-06.txt
> > > 
> > > 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").
> > 
> > OK - still not best IMO but I can live with this. 
> > 
> > > 
> > > 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.  
> > 
> > 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
> > > 
> > > -----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]
> > > 
> > 
> 
> 

From: "Bert Wijnen \(IETF\)" <[email-masked]>
To: "David B Harrington" <[email-masked]>, "'Romascanu, Dan \(Dan\)'" <[email-masked]>, "'Moti Morgenstern'" <[email-masked]>
Date: Mon, 16 Feb 2009 16:14:35 +0100
Organization: Consultant
Cc: "'MIB Doctors \(E-mail\)'" <[email-masked]>, [email-masked], 'Menachem Dodge' <[email-masked]>, [email-masked]
Subject: Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ietf-adslmib-vdsl2-06.txt

This is a multi-part message in MIME format.

------=_NextPart_000_0E28_01C99051.A8EE25A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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,

  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

  > -----Original Message-----
  > From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
  > Sent: Monday, February 16, 2009 7:29 AM
  > To: 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
  > 
  > See my answers in-line. David, please jump in if you have
  objections.
  > 
  > Thanks and Regards,
  > 
  > Dan
  > 
  > 
  >  
  > 
  > > -----Original Message-----
  > > 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]
  > > Subject: RE: [MIB-DOCTORS] AD review of 
  > > draft-ietf-adslmib-vdsl2-06.txt
  > > 
  > > 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"). 
  > 
  > OK - still not best IMO but I can live with this. 
  > 
  > > 
  > > 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.  
  > 
  > 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
  > > 
  > > -----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

------=_NextPart_000_0E28_01C99051.A8EE25A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6001.18203" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>I agree hat using TruthValue SYNTYAX would be strongly 
preferred over</FONT></DIV>
<DIV><FONT size=2>using a decicated TC or SYNTAX.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Bert</FONT></DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">&nbsp;</DIV>
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=[email-masked] href="mailto:[email-masked]">David 
  B Harrington</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">'Romascanu, Dan (Dan)'</A> ; <A 
  title=[email-masked] 
  href="mailto:[email-masked]">'Moti Morgenstern'</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">'MIB Doctors (E-mail)'</A> ; <A 
  title=[email-masked] href="mailto:[email-masked]">[email-masked]</A> ; 
  <A title=[email-masked] 
  href="mailto:[email-masked]">'Menachem Dodge'</A> ; <A 
  title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> ; <A 
  title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Monday, February 16, 2009 3:55 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [MIB-DOCTORS] AD review of 
  draft-ietf-adslmib-vdsl2-06.txt</DIV>
  <DIV><BR></DIV>Hi,<BR><BR>It is almost always important to remember the 
  audience for a MIB. <BR>This MIB will be used by operators and NMS 
  developers.<BR><BR>Operators and NMS developers are accustomed to Truthvalue 
  TCs.<BR>Many NMS applications already have been coded to present the values 
  as<BR>"true" and "false" for Truthvalue TCs. When those many 
  NMS<BR>applications parse this MIB module and get the special-case TCs, 
  the<BR>NM application writer will need to write new special-case code 
  for<BR>these special-case TCs.<BR><BR>People who helped develop the managed 
  protocol are probably NOT the<BR>same people who are going to work on the 
  helpdesk or in the IT<BR>department monitoring the values and behaviors of the 
  network on a<BR>daily basis, and are not the people who will write NM 
  applications<BR>(unless they will write special-case NM applications for this 
  MIB<BR>module).<BR><BR>So while it might be more "natural" for the protocol 
  designers to<BR>think in terms of 0-1, the end-users of the MIB are accustomed 
  to<BR>TruthValue TCs, and NMS applications already know how to deal with 
  the<BR>standard TCs rather than the special-case TCs being used in this 
  MIB.<BR><BR>Interoperability in the world of network management protocols, 
  like<BR>SNMP and MIBs, is all about making it possible for NM applications 
  to<BR>talk to managed devices in a manner that is consistent 
  and<BR>vendor-neutral, and managed-technology-neutral. That is why SNMP has 
  a<BR>standard set of error codes, rather than different error codes 
  for<BR>each managed technology. That is why SMIv2 organizes data 
  into<BR>two-dimensional tables rather than in deep nested structures, even 
  if<BR>the underlying technology uses deep nested structures. That is 
  why<BR>SNMP has standard datatypes, rather than different datatypes for 
  each<BR>managed protocol. The special-case datatypes being proposed as TCs 
  in<BR>this MIB module seem to be simply designer-preference - we like 
  0-1<BR>better than 1-2. <BR><BR>I think there is a strong interoperability 
  justification for using<BR>TruthValue TC rather than MIB-specific TCs with the 
  same purpose.&nbsp; <BR><BR>Over thwe past ten years or so, we have had it 
  drilled into our heads<BR>by the user community that we need to meet the 
  interoperability needs<BR>of the readers and users of MIB modules, such as 
  operators and NM<BR>application developers, more than the personal preferences 
  of the MIB<BR>module writers.<BR><BR>I think this MIB should use TruthValue, 
  not special-case TCs.<BR><BR>dbh<BR><BR>&gt; -----Original 
  Message-----<BR>&gt; From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
  <BR>&gt; Sent: Monday, February 16, 2009 7:29 AM<BR>&gt; To: Moti Morgenstern; 
  David B Harrington<BR>&gt; Cc: MIB Doctors (E-mail); <A 
  href="mailto:[email-masked]">[email-masked]</A>; Menachem Dodge; <BR>&gt; 
  <A href="mailto:[email-masked]">[email-masked]</A>; <A 
  href="mailto:[email-masked]">[email-masked]</A><BR>&gt; 
  Subject: RE: [MIB-DOCTORS] AD review of <BR>&gt; 
  draft-ietf-adslmib-vdsl2-06.txt<BR>&gt; <BR>&gt; See my answers in-line. 
  David, please jump in if you have<BR>objections.<BR>&gt; <BR>&gt; Thanks and 
  Regards,<BR>&gt; <BR>&gt; Dan<BR>&gt; <BR>&gt; <BR>&gt;&nbsp; <BR>&gt; 
  <BR>&gt; &gt; -----Original Message-----<BR>&gt; &gt; From: Moti Morgenstern 
  [mailto:[email-masked]] <BR>&gt; &gt; Sent: Friday, January 30, 
  2009 12:40 PM<BR>&gt; &gt; To: Romascanu, Dan (Dan); David B 
  Harrington<BR>&gt; &gt; Cc: MIB Doctors (E-mail); <A 
  href="mailto:[email-masked]">[email-masked]</A>; Menachem Dodge; <BR>&gt; 
  &gt; <A href="mailto:[email-masked]">[email-masked]</A>; 
  <A 
  href="mailto:[email-masked]">[email-masked]</A><BR>&gt; 
  &gt; Subject: RE: [MIB-DOCTORS] AD review of <BR>&gt; &gt; 
  draft-ietf-adslmib-vdsl2-06.txt<BR>&gt; &gt; <BR>&gt; &gt; Hi Dan and 
  David,<BR>&gt; &gt; <BR>&gt; &gt; The editors reviewed the additional comments 
  against revision <BR>&gt; &gt; -06 and our response is the following (numbered 
  according to <BR>&gt; &gt; the comment numbers):<BR>&gt; &gt; <BR>&gt; &gt; 1) 
  As explained in our previous reference to this issue, we <BR>&gt; &gt; prefer 
  the special TCs we use instead of replacing them with <BR>&gt; &gt; the 
  TruthValue TC, which we do use where appropriate. This is <BR>&gt; &gt; also 
  because the use of TrutrhValue TC is not mandatory (That <BR>&gt; &gt; can 
  easily understood from the [RFC2119] interpretation of <BR>&gt; &gt; "SHOULD 
  NOT"). <BR>&gt; <BR>&gt; OK - still not best IMO but I can live with this. 
  <BR>&gt; <BR>&gt; &gt; <BR>&gt; &gt; 2) The comment is not so clear. <BR>&gt; 
  &gt; Do you mean that, instead of xdsl2Notifications OBJECT <BR>&gt; &gt; 
  IDENTIFIER ::= { vdsl2 0 } we should use xdsl2Notifications <BR>&gt; &gt; 
  OBJECT IDENTIFIER ::= { vdsl2MIB 0 } so the notifications <BR>&gt; &gt; will 
  reside directly under the MODULE-ENTITY?<BR>&gt; &gt; We'll appreciate a quick 
  answer for this, if possible.&nbsp; <BR>&gt; <BR>&gt; I clarified this I think 
  in the separate mail sent yesterday. <BR>&gt; <BR>&gt; &gt; <BR>&gt; &gt; 3) 
  We'll fix the abbreviation inconsistency reported.<BR>&gt; <BR>&gt; Thanks. 
  <BR>&gt; <BR>&gt; &gt; <BR>&gt; &gt; 4-6) xdsl2LineCmndConfBpscReqCount will 
  be renamed as <BR>&gt; &gt; suggested and we'll also change its syntax. 
  However, we <BR>&gt; &gt; believe that there is a misunderstanding of the 
  mechanism for <BR>&gt; &gt; which we use that object. Therefore we intend to 
  change the <BR>&gt; &gt; DESCRIPTION clauses of this object and 
  xdsl2LineCmndConfBpsc <BR>&gt; &gt; to clarify the dynamic behavior of the 
  procedure. The main <BR>&gt; &gt; point to explain is that the SNMP agent does 
  not allow <BR>&gt; &gt; interrupting a process which is in progress. The 
  counter only <BR>&gt; &gt; allows the manager to identify the reported 
  measurements are <BR>&gt; &gt; result of "his" process (i.e., they may belong 
  to a process <BR>&gt; &gt; that was executed later on, after his process was 
  already <BR>&gt; &gt; complete).&nbsp;&nbsp; <BR>&gt; <BR>&gt; OK - pending on 
  the exact edits you need to come with. <BR>&gt; <BR>&gt; &gt; <BR>&gt; &gt; 7) 
  The results of a line diagnostic tests have their own <BR>&gt; &gt; table 
  (xdsl2SCStatusSegmentTable) and therefore <BR>&gt; &gt; xdsl2LineSegmentTable 
  is not overloaded.<BR>&gt; <BR>&gt; OK<BR>&gt; <BR>&gt; &gt; <BR>&gt; &gt; 8) 
  The xdsl2LineCmndConfBpsc and xdsl2LineCmndConfLdsf are <BR>&gt; &gt; 
  associated with different results tables.<BR>&gt; <BR>&gt; I am not sure that 
  you understood our concern here. Exactly the fact<BR>&gt; that there are two 
  different tables is the reason of concern <BR>&gt; because the<BR>&gt; tests 
  can happen on the same line simultaneously, at the <BR>&gt; request of 
  two<BR>&gt; different managers, one writing&nbsp; xdsl2LineCmndConfBpsc and 
  another<BR>&gt; xdsl2LineCmndConfLdsf. Can this happen? If not, please explain 
  what<BR>we<BR>&gt; are missing. <BR>&gt; <BR>&gt; &gt; <BR>&gt; &gt; 
  9)<BR>&gt; &gt; a) The document already describes the coexistence of RFC 
  <BR>&gt; &gt; 2662, RFC 4706 and the current document. We can summarize 
  <BR>&gt; &gt; that RFC2662 is relevant only for managing modems that do not 
  <BR>&gt; &gt; support any DSL technology other than ADSL (e.g., G.992.1/2) 
  <BR>&gt; &gt; especially if were produced prior to approval of ITU-T <BR>&gt; 
  &gt; G.997.1 rev 3 . RFC 4706 is more appropriate for managing <BR>&gt; &gt; 
  modems that support ADSL2 technology variants (with or <BR>&gt; &gt; without 
  being able to support the legacy ADSL). The current <BR>&gt; &gt; document 
  supports all ADSL, ASDSL2 and VDSL2 standards but it <BR>&gt; &gt; assumes a 
  more sophisticated management model, which older <BR>&gt; &gt; modems (even 
  ADSL2 ones) may not be able to support. <BR>&gt; &gt; b) It's important to 
  notice that each modem can indicate, by <BR>&gt; &gt; the ifType, what 
  (specific) MIB it supports. E.g., It's <BR>&gt; &gt; possible to upgrade from 
  RFC 2662 to 4706 MIB, but it <BR>&gt; &gt; requires a software change on both 
  sides of the management <BR>&gt; &gt; interface and also a database 
  conversion.&nbsp;&nbsp; <BR>&gt; <BR>&gt; The two issues above seem to be 
  important enough to be explicitly<BR>&gt; mentioned in the document. 
  <BR>&gt;&nbsp; <BR>&gt; &gt; c) We do not agree that "rfc2662 does support 
  using the <BR>&gt; &gt; entity mib". All it says is that implementing the 
  entity MIB <BR>&gt; &gt; is optional and that, if implemented, it should 
  include a row <BR>&gt; &gt; for the the ATU-C or ATU-R based on the agent 
  lcation. This <BR>&gt; &gt; is so obvious that it's not a surprise no other 
  xDSL line MIB <BR>&gt; &gt; (e.g., RFC 3728 (vdsl), RFC 4319 (shdsl), RFC 4706 
  (adsl2)) <BR>&gt; &gt; refers to that. <BR>&gt; <BR>&gt; I guess that David's 
  intent was that he expected this reference to<BR>the<BR>&gt; entity MIB to 
  show up here as well. Sometimes it is better to <BR>&gt; state the<BR>&gt; 
  obvious. <BR>&gt; <BR>&gt; &gt; By the way, note that even RFC 2662 
  understands that there <BR>&gt; &gt; can be a row in the entity MIB for either 
  the ATU-C or ATU-R, <BR>&gt; &gt; not both. This strengthen our response to 
  Dan's previous <BR>&gt; &gt; comment T8 that referred to the entity MIB.&nbsp; 
  <BR>&gt; &gt; <BR>&gt; &gt; Thanks for your efforts,<BR>&gt; &gt; Moti 
  Morgenstern<BR>&gt; &gt; <BR>&gt; &gt; -----Original Message-----<BR>&gt; &gt; 
  From: Romascanu, Dan (Dan) [mailto:[email-masked]]<BR>&gt; &gt; Sent: 
  Thursday, January 22, 2009 10:42 PM<BR>&gt; &gt; To: Romascanu, Dan (Dan); 
  Moti Morgenstern; David B Harrington<BR>&gt; &gt; Cc: MIB Doctors (E-mail); <A 
  href="mailto:[email-masked]">[email-masked]</A>; Menachem Dodge; <BR>&gt; 
  &gt; <A href="mailto:[email-masked]">[email-masked]</A>; 
  <A 
  href="mailto:[email-masked]">[email-masked]</A><BR>&gt; 
  &gt; Subject: RE: [MIB-DOCTORS] AD review of <BR>&gt; &gt; 
  draft-ietf-adslmib-vdsl2-06.txt<BR>&gt; &gt; <BR>&gt; &gt; Hi Moti,<BR>&gt; 
  &gt; <BR>&gt; &gt; There are some more comments from David Harrington listed 
  below. <BR>&gt; &gt; <BR>&gt; &gt; Please address them in the new version of 
  the MIB module and <BR>&gt; &gt; of the document. <BR>&gt; &gt; <BR>&gt; &gt; 
  1) as per RFC4181 the TruthValue TC SHOULD be used in the <BR>&gt; &gt; SYNTAX 
  clause of object definitions<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; that require 
  a Boolean type.&nbsp; MIB modules SHOULD NOT use <BR>&gt; &gt; 
  enumerated<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER types or define TCs 
  that duplicate its semantics.<BR>&gt; &gt; <BR>&gt; &gt; 2) the MIB 
  organization does not follow the RECOMMENDED OID <BR>&gt; &gt; assignment 
  scheme for notifications as per section 4.7 and <BR>&gt; &gt; Appendix D of 
  RFC 4181<BR>&gt; &gt; <BR>&gt; &gt; 3) Xdsl2LineEntry&nbsp; ::=<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp; SEQUENCE {<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineCnfgTemplate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  SnmpAdminString,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineCnfgFallbackTemplate&nbsp;&nbsp;&nbsp; SnmpAdminString,<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineAlarmCnfgTemplate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  SnmpAdminString,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineCmndConfPmsf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2ConfPmsForce,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineCmndConfLdsf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2LineLdsf,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineCmndConfLdsfFailReason&nbsp; Xdsl2LdsfResult,<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineCmndConfBpsc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2LineBpsc,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineCmndConfBpscFailReason&nbsp; Xdsl2BpscResult,<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineCmndConfBpscReqCount&nbsp;&nbsp;&nbsp; Unsigned32,<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineCmndAutomodeColdStart&nbsp;&nbsp; TruthValue,<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineCmndConfReset&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2LineReset,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusActTemplate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  SnmpAdminString,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusXtuTransSys&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2TransmissionModeType,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusPwrMngState&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2PowerMngState,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusInitResult&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2InitResult,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusLastStateDs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2LastTransmittedState,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusLastStateUs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2LastTransmittedState,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusXtur&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2LineStatus,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusXtuc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2LineStatus,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusAttainableRateDs&nbsp; Unsigned32,<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xdsl2LineStatusAttainableRateUs&nbsp; 
  Unsigned32,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusActPsdDs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Integer32,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusActPsdUs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Integer32,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusActAtpDs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Integer32,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusActAtpUs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Integer32,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusActProfile&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2LineProfiles,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusActLimitMask&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2LineLimitMask,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusActUs0Mask&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2LineUs0Mask,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusActSnrModeDs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2LineSnrMode,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusActSnrModeUs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2LineSnrMode,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusElectricalLength&nbsp; Unsigned32,<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusTssiDs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2Tssi,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusTssiUs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2Tssi,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusMrefPsdDs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2MrefPsdDs,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusMrefPsdUs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Xdsl2MrefPsdUs,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusTrellisDs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  TruthValue,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusTrellisUs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  TruthValue,<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  xdsl2LineStatusActualCe&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Unsigned32<BR>&gt; &gt;&nbsp;&nbsp;&nbsp; }<BR>&gt; &gt; <BR>&gt; &gt; Check 
  out inconsistent abbreviations, such as <BR>&gt; &gt; 
  xdsl2LineCnfgFallbackTemplate which points to the <BR>&gt; &gt; 
  xdsl2LineConfTemplateTable. (cnfg and conf both mean <BR>&gt; &gt; 
  configuration) I note that RFC2662 uses "conf" consistently.<BR>&gt; &gt; 
  <BR>&gt; &gt; 4)The counter&nbsp; xdsl2LineCmndConfBpscReqCount let's 
  management <BR>&gt; &gt; station M1 know when another management station M2 
  requested <BR>&gt; &gt; a measurement, which caused the relevant counter to 
  reset, <BR>&gt; &gt; such that M1's measurement is no longer valid. <BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "SNMP managers can use this attribute 
  to check that the<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  measurement results retrieved by the manager where not <BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; interupted by another 
  measurement request."<BR>&gt; &gt; <BR>&gt; &gt; We discouraged resetting 
  counters in IETF MIB modules. Can <BR>&gt; &gt; you explain why this is 
  necessary? <BR>&gt; &gt; <BR>&gt; &gt; 5) The naming conventions for counters 
  are not being followed <BR>&gt; &gt; - xdsl2LineCmndConfBpscReqCount should 
  probably be <BR>&gt; &gt; xdsl2LineCmndConfBpscRequests.<BR>&gt; &gt; <BR>&gt; 
  &gt; 6) xdsl2LineCmndConfBpscReqCount -&nbsp; why is this an Unsigned32 
  <BR>&gt; &gt; and not a Counter32?<BR>&gt; &gt; <BR>&gt; &gt; 7) I am a bit 
  concerned about the table that actually <BR>&gt; &gt; contains the measurement 
  - the xdsl2LineSegmentTable&nbsp; The <BR>&gt; &gt; actual measurement is in 
  xdsl2LineSegmentBitsAlloc. It <BR>&gt; &gt; appears the value is overloaded to 
  provide subcarrier <BR>&gt; &gt; allocation status, as well as the result of a 
  line diagnostic<BR>test. <BR>&gt; &gt; <BR>&gt; &gt; 8) from security 
  considerations "Unauthorized changes to <BR>&gt; &gt; xdsl2LineCmndConfBpsc 
  could cause an unscheduled bits per <BR>&gt; &gt; subcarrier measurement to be 
  carried out on the line.", and <BR>&gt; &gt; "Unauthorized changes to 
  xdsl2LineCmndConfLdsf could cause an <BR>&gt; &gt; unscheduled line test to be 
  carried out on the line." Since <BR>&gt; &gt; these two measurements report 
  using the same object, and <BR>&gt; &gt; since one measurement can interfere 
  with the validity of the <BR>&gt; &gt; measurement requested by a different 
  manager, this seems to <BR>&gt; &gt; have serious issues of information 
  reliability.<BR>&gt; &gt; <BR>&gt; &gt; 9) On a larger scale, I am concerned 
  that this appears to be a<BR>&gt; &gt; **competing** standard to RFC2662. This 
  does not complement, <BR>&gt; &gt; or update, or obsolete RFC2662.<BR>&gt; 
  &gt; <BR>&gt; &gt; I have not yet gone into the two mib modules to determine 
  how <BR>&gt; &gt; compatible they are, but section 4 in this document makes me 
  <BR>&gt; &gt; really uneasy as a<BR>&gt; &gt; (previous) management app 
  designer. Can a device support both <BR>&gt; &gt; mib modules simultaneously? 
  Can a management app use both MIB <BR>&gt; &gt; modules simultaneously to 
  manage the same ADSL functions on <BR>&gt; a device?<BR>&gt; &gt; <BR>&gt; 
  &gt; I note that rfc2662 does support using the entity mib, while <BR>&gt; 
  &gt; this mib module does not. Which makes me wonder about the <BR>&gt; &gt; 
  compatibility between the two mib modules.<BR>&gt; &gt; <BR>&gt; &gt; Thanks 
  and Regards,<BR>&gt; &gt; <BR>&gt; &gt; Dan<BR>&gt; &gt; <BR>&gt; &gt; 
  <BR>&gt; &gt; <BR>&gt; &gt; &gt; -----Original Message-----<BR>&gt; &gt; &gt; 
  From: <A 
  href="mailto:[email-masked]">[email-masked]</A><BR>&gt; 
  &gt; <BR>&gt; 
  <BR><BR>_______________________________________________<BR>MIB-DOCTORS mailing 
  list<BR><A href="mailto:[email-masked]">[email-masked]</A><BR><A 
  href="https://www.ietf.org/mailman/listinfo/mib-doctors">https://www.ietf.org/mailman/listinfo/mib-doctors</A><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0E28_01C99051.A8EE25A0--

From: "David B Harrington" <[email-masked]>
To: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, "'Moti Morgenstern'" <[email-masked]>
Date: Mon, 16 Feb 2009 09:55:57 -0500
Cc: "'MIB Doctors \(E-mail\)'" <[email-masked]>, [email-masked], 'Menachem Dodge' <[email-masked]>, [email-masked]
Subject: Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ietf-adslmib-vdsl2-06.txt

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

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Monday, February 16, 2009 7:29 AM
> To: 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
> 
> See my answers in-line. David, please jump in if you have
objections.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
>  
> 
> > -----Original Message-----
> > 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]
> > Subject: RE: [MIB-DOCTORS] AD review of 
> > draft-ietf-adslmib-vdsl2-06.txt
> > 
> > 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"). 
> 
> OK - still not best IMO but I can live with this. 
> 
> > 
> > 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.  
> 
> 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
> > 
> > -----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]
> > 
> 

Date: Mon, 16 Feb 2009 11:24:06 -0800
From: Andy Bierman <[email-masked]>
To: "Bert Wijnen (IETF)" <[email-masked]>
Cc: David B Harrington <[email-masked]>, [email-masked], "'MIB Doctors \(E-mail\)'" <[email-masked]>, [email-masked], 'Menachem Dodge' <[email-masked]>, 'Moti Morgenstern' <[email-masked]>
Subject: Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ietf-adslmib-vdsl2-06.txt

Bert Wijnen (IETF) wrote:
> I agree hat using TruthValue SYNTYAX would be strongly preferred over
> 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

From: Scott Baillie <[email-masked]>
To: [email-masked]
Date: Sun, 22 Feb 2009 23:57:57 +1100
Cc: David B Harrington <[email-masked]>, 'Menachem Dodge' <[email-masked]>, "MIB Doctors \(E-mail\)" <[email-masked]>, "Bert Wijnen \(IETF\)" <[email-masked]>, Andy Bierman <[email-masked]>, 'Moti Morgenstern' <[email-masked]>
Subject: Re: [Adslmib] [MIB-DOCTORS] AD review of	draft-ietf-adslmib-vdsl2-06.txt

Hi All,

As one of the draft MIB editors I thought I would chime in
on the issue of the use of the TruthValue type for
boolean parameters.

I agree that the use of primitive data types where possible is
a desirable thing. I also agree that defining a new type that
is equivalent to an existing primitive type is undesirable.
In the case of the VDSL2 MIB, there is a reason why the
MIB authors have chosen to define a new type rather than use
a standard type ( see below ).

I do not entirely agree with the position put forward by David
( 2009-Feb-16 ) regarding NMS developers.
NMS developers have to support standard data types and new data
types ( TC's ) when dealing with any MIB. Our choice of using a
TC rather than a TruthValue does not significantly impact the
NMS developer.

Also, the long section in David's message regarding interoperability
of the SNMP protocol is a way overblown response to our minor sin
of using a TC rather than a TruthValue. Our choice of using a TC
does not diminish the vendor-neutral, and managed-technology-neutral
nature of the SNMP protocol.

I would like to state the 2 main reasons why we chose to define a
new TC rather than use a standard TruthValue type.

Reason 1
--------
The VDSL2 MIB is largely based on the ITU document G.997.1.
The ITU document specifies all of the VDSL2 management parameters
and their values. At the moment, the current VDSL2 draft exactly
matches all of the parameters in the ITU document and exactly
matches all of their values. This is a huge advantage, it means
that there is one source document you can turn to when managing
XDSL technology.
If we were to use the TruthValue type as suggested then we would
lose the tight coupling between the source document ( G.997.1 )
and the SNMP MIB that we currently enjoy.
If we cannot guarantee that the MIB values are the same as the
values specified in the source document then I believe that this
will lead to negative consequences that are worse than the minor
sin of using a TC instead of TruthValue.

Reason 2
--------
The source document ( G.997.1 ) is a work in progress and
can be revised in subsequent publications. It is permissible
to add new enumerated values at the end of an existing 
enumerated type because this type of change is backward
compatible. If the ITU add a new enumerated value to an
existing boolean parameter then we would be forced to change
the type from TruthValue to a TC which would have negative
consequences for NMS developers.

Summary
-------
We recognise that the use of standard types is preferable
where possible but in the case of the VDSL2 MIB, the advantages
of having the MIB identical to the source document far
out weigh the advantages of using standard types.

Regards,

Scott.

Content-class: urn:content-classes:message
Date: Sun, 22 Feb 2009 14:49:27 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Scott Baillie" <[email-masked]>, <[email-masked]>
Cc: David B Harrington <[email-masked]>, Menachem Dodge <[email-masked]>, "MIB Doctors \(E-mail\)" <[email-masked]>, "Bert Wijnen \(IETF\)" <[email-masked]>, Andy Bierman <[email-masked]>, Moti Morgenstern <[email-masked]>
Subject: Re: [Adslmib] [MIB-DOCTORS] AD review ofdraft-ietf-adslmib-vdsl2-06.txt

Hi Scott,

A few comments and clarification questions: 

> Our choice of 
> using a TC rather than a TruthValue does not significantly 
> impact the NMS developer.

Well, it does add the need to support a new TC, rather than the
TruthValue TC which is already supported by any management application.
There should be good reasons to do it. 

> If we cannot guarantee that the MIB values are the same as 
> the values specified in the source document then I believe 
> that this will lead to negative consequences that are worse 
> than the minor sin of using a TC instead of TruthValue.

Can you explain this? What are the negative consequences? 

> The source document ( G.997.1 ) is a work in progress and can 
> be revised in subsequent publications. It is permissible to 
> add new enumerated values at the end of an existing 
> enumerated type because this type of change is backward 
> compatible. If the ITU add a new enumerated value to an 
> existing boolean parameter then we would be forced to change 
> the type from TruthValue to a TC which would have negative 
> consequences for NMS developers.

This would be indeed a strong argument in favor of using another TC than
TruthValue. I do not see however how this argument applies to
Xdsl2LineSnrMode (can any other state than virtual noise enabled or
disabled ever exist?) and to Xdsl2LineReset (which seems to have two
states: reset or idle = no reset). How could these two be extended in
the future? 

Thanks and Regards,

Dan

> -----Original Message-----
> From: Scott Baillie [mailto:[email-masked]] 
> Sent: Sunday, February 22, 2009 2:58 PM
> To: [email-masked]
> Cc: Andy Bierman; Bert Wijnen (IETF); David B Harrington; 
> 'Menachem Dodge'; 'Moti Morgenstern'; Romascanu, Dan (Dan); 
> MIB Doctors (E-mail)
> Subject: Re: [Adslmib] [MIB-DOCTORS] AD review 
> ofdraft-ietf-adslmib-vdsl2-06.txt
> 
> Hi All,
> 
> As one of the draft MIB editors I thought I would chime in on 
> the issue of the use of the TruthValue type for boolean parameters.
> 
> I agree that the use of primitive data types where possible 
> is a desirable thing. I also agree that defining a new type 
> that is equivalent to an existing primitive type is undesirable.
> In the case of the VDSL2 MIB, there is a reason why the MIB 
> authors have chosen to define a new type rather than use a 
> standard type ( see below ).
> 
> I do not entirely agree with the position put forward by 
> David ( 2009-Feb-16 ) regarding NMS developers.
> NMS developers have to support standard data types and new 
> data types ( TC's ) when dealing with any MIB. Our choice of 
> using a TC rather than a TruthValue does not significantly 
> impact the NMS developer.
> 
> Also, the long section in David's message regarding 
> interoperability of the SNMP protocol is a way overblown 
> response to our minor sin of using a TC rather than a 
> TruthValue. Our choice of using a TC does not diminish the 
> vendor-neutral, and managed-technology-neutral nature of the 
> SNMP protocol.
> 
> I would like to state the 2 main reasons why we chose to 
> define a new TC rather than use a standard TruthValue type.
> 
> 
> Reason 1
> --------
> The VDSL2 MIB is largely based on the ITU document G.997.1.
> The ITU document specifies all of the VDSL2 management 
> parameters and their values. At the moment, the current VDSL2 
> draft exactly matches all of the parameters in the ITU 
> document and exactly matches all of their values. This is a 
> huge advantage, it means that there is one source document 
> you can turn to when managing XDSL technology.
> If we were to use the TruthValue type as suggested then we 
> would lose the tight coupling between the source document ( 
> G.997.1 ) and the SNMP MIB that we currently enjoy.
> If we cannot guarantee that the MIB values are the same as 
> the values specified in the source document then I believe 
> that this will lead to negative consequences that are worse 
> than the minor sin of using a TC instead of TruthValue.
> 
> 
> Reason 2
> --------
> The source document ( G.997.1 ) is a work in progress and can 
> be revised in subsequent publications. It is permissible to 
> add new enumerated values at the end of an existing 
> enumerated type because this type of change is backward 
> compatible. If the ITU add a new enumerated value to an 
> existing boolean parameter then we would be forced to change 
> the type from TruthValue to a TC which would have negative 
> consequences for NMS developers.
> 
> 
> Summary
> -------
> We recognise that the use of standard types is preferable
> where possible but in the case of the VDSL2 MIB, the advantages
> of having the MIB identical to the source document far
> out weigh the advantages of using standard types.
> 
> 
> 
> Regards,
> 
> Scott.
> 
> 
> 
> 
> 
> 
> 

From: Scott Baillie <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 23 Feb 2009 05:42:15 +1100
Cc: David B Harrington <[email-masked]>, [email-masked], Menachem Dodge <[email-masked]>, "MIB Doctors \(E-mail\)" <[email-masked]>, "Bert Wijnen \(IETF\)" <[email-masked]>, Andy Bierman <[email-masked]>, Moti Morgenstern <[email-masked]>
Subject: Re: [Adslmib] [MIB-DOCTORS] AD review	ofdraft-ietf-adslmib-vdsl2-06.txt

Hi Dan,

A few extra comments in line below :

On Sun, 2009-02-22 at 14:49 +0100, Romascanu, Dan (Dan) wrote:
> Hi Scott,
> 
> A few comments and clarification questions: 
> 
> > Our choice of 
> > using a TC rather than a TruthValue does not significantly 
> > impact the NMS developer.
> 
> Well, it does add the need to support a new TC, rather than the
> TruthValue TC which is already supported by any management application.
> There should be good reasons to do it. 
SAB : I feel this argument is a little exaggerated because NMS
    : developers already have to support standard types and
    : user defined types in any given MIB.
    : Adding a few extra TC's to this MIB does not
    : significantly increase the task for NMS developers.
    : We believe that keeping the MIB values in line with
    : the source document is an important enough reason 
    : to define our own TC.
> 
> > If we cannot guarantee that the MIB values are the same as 
> > the values specified in the source document then I believe 
> > that this will lead to negative consequences that are worse 
> > than the minor sin of using a TC instead of TruthValue.
> 
> Can you explain this? What are the negative consequences? 
SAB : There is the potential for negative consequences if a
    : translation is required between the values in the MIB
    : and the source document. On every parameter in the
    : VDSL2 MIB we reference the corresponding parameter in
    : the ITU document.
    : Readers come to expect that the parameters
    : defined in the ITU document are the same ones that
    : are defined in the MIB. If we use the TruthValue type
    : as suggested then 98% of the MIB will be identical to
    : the source document and 2% of the MIB values will require
    : an arbitrary translation.
    : The intention of the authors is to have a direct mapping
    : between the source document and the MIB.
    : The ITU document has been adopted widely by Vendors and
    : there are many solutions available that comply with the ITU
    : specification such as XDSL chip sets and software stacks.
    : If we keep the MIB identical to the ITU document then
    : no translation is required between these compliant systems
    : and a single document is all that is required to understand
    : them all.
> 
> > The source document ( G.997.1 ) is a work in progress and can 
> > be revised in subsequent publications. It is permissible to 
> > add new enumerated values at the end of an existing 
> > enumerated type because this type of change is backward 
> > compatible. If the ITU add a new enumerated value to an 
> > existing boolean parameter then we would be forced to change 
> > the type from TruthValue to a TC which would have negative 
> > consequences for NMS developers.
> 
> This would be indeed a strong argument in favor of using another TC than
> TruthValue. I do not see however how this argument applies to
> Xdsl2LineSnrMode (can any other state than virtual noise enabled or
> disabled ever exist?) and to Xdsl2LineReset (which seems to have two
> states: reset or idle = no reset). How could these two be extended in
> the future? 
SAB : We are not the authors of the source document so we cannot
    : make any guarantees on their behalf and we cannot anticipate
    : how the ITU document may be changed in the future.
    : I agree that several of the parameters appear to be boolean
    : in nature.
    : If the ITU document uses names like 'reset' and 'idle' then
    : I would prefer to keep those names rather than replace them
    : with 'true' and 'false'. The ITU names carry more meaning
    : and they provide a common vocabulary that can be used and
    : understood by anyone that implements solutions based on
    : the source document.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> > -----Original Message-----
> > From: Scott Baillie [mailto:[email-masked]] 
> > Sent: Sunday, February 22, 2009 2:58 PM
> > To: [email-masked]
> > Cc: Andy Bierman; Bert Wijnen (IETF); David B Harrington; 
> > 'Menachem Dodge'; 'Moti Morgenstern'; Romascanu, Dan (Dan); 
> > MIB Doctors (E-mail)
> > Subject: Re: [Adslmib] [MIB-DOCTORS] AD review 
> > ofdraft-ietf-adslmib-vdsl2-06.txt
> > 
> > Hi All,
> > 
> > As one of the draft MIB editors I thought I would chime in on 
> > the issue of the use of the TruthValue type for boolean parameters.
> > 
> > I agree that the use of primitive data types where possible 
> > is a desirable thing. I also agree that defining a new type 
> > that is equivalent to an existing primitive type is undesirable.
> > In the case of the VDSL2 MIB, there is a reason why the MIB 
> > authors have chosen to define a new type rather than use a 
> > standard type ( see below ).
> > 
> > I do not entirely agree with the position put forward by 
> > David ( 2009-Feb-16 ) regarding NMS developers.
> > NMS developers have to support standard data types and new 
> > data types ( TC's ) when dealing with any MIB. Our choice of 
> > using a TC rather than a TruthValue does not significantly 
> > impact the NMS developer.
> > 
> > Also, the long section in David's message regarding 
> > interoperability of the SNMP protocol is a way overblown 
> > response to our minor sin of using a TC rather than a 
> > TruthValue. Our choice of using a TC does not diminish the 
> > vendor-neutral, and managed-technology-neutral nature of the 
> > SNMP protocol.
> > 
> > I would like to state the 2 main reasons why we chose to 
> > define a new TC rather than use a standard TruthValue type.
> > 
> > 
> > Reason 1
> > --------
> > The VDSL2 MIB is largely based on the ITU document G.997.1.
> > The ITU document specifies all of the VDSL2 management 
> > parameters and their values. At the moment, the current VDSL2 
> > draft exactly matches all of the parameters in the ITU 
> > document and exactly matches all of their values. This is a 
> > huge advantage, it means that there is one source document 
> > you can turn to when managing XDSL technology.
> > If we were to use the TruthValue type as suggested then we 
> > would lose the tight coupling between the source document ( 
> > G.997.1 ) and the SNMP MIB that we currently enjoy.
> > If we cannot guarantee that the MIB values are the same as 
> > the values specified in the source document then I believe 
> > that this will lead to negative consequences that are worse 
> > than the minor sin of using a TC instead of TruthValue.
> > 
> > 
> > Reason 2
> > --------
> > The source document ( G.997.1 ) is a work in progress and can 
> > be revised in subsequent publications. It is permissible to 
> > add new enumerated values at the end of an existing 
> > enumerated type because this type of change is backward 
> > compatible. If the ITU add a new enumerated value to an 
> > existing boolean parameter then we would be forced to change 
> > the type from TruthValue to a TC which would have negative 
> > consequences for NMS developers.
> > 
> > 
> > Summary
> > -------
> > We recognise that the use of standard types is preferable
> > where possible but in the case of the VDSL2 MIB, the advantages
> > of having the MIB identical to the source document far
> > out weigh the advantages of using standard types.
> > 
> > 
> > 
> > Regards,
> > 
> > Scott.
> > 
> > 
> > 
> > 
> > 
> > 
> > 

Content-class: urn:content-classes:message
Date: Mon, 23 Feb 2009 11:40:29 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Scott Baillie" <[email-masked]>
Cc: David B Harrington <[email-masked]>, [email-masked], Menachem Dodge <[email-masked]>, "MIB Doctors \(E-mail\)" <[email-masked]>, "Bert Wijnen \(IETF\)" <[email-masked]>, Andy Bierman <[email-masked]>, Moti Morgenstern <[email-masked]>
Subject: Re: [Adslmib] [MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hi Scott,

See in-line. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: Scott Baillie [mailto:[email-masked]] 
> Sent: Sunday, February 22, 2009 8:42 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; Andy Bierman; Bert Wijnen (IETF); David 
> B Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors (E-mail)
> Subject: RE: [Adslmib] [MIB-DOCTORS] AD 
> reviewofdraft-ietf-adslmib-vdsl2-06.txt
> 
> Hi Dan,
> 
> A few extra comments in line below :
> 
> On Sun, 2009-02-22 at 14:49 +0100, Romascanu, Dan (Dan) wrote:
> > Hi Scott,
> > 
> > A few comments and clarification questions: 
> > 
> > > Our choice of
> > > using a TC rather than a TruthValue does not significantly impact 
> > > the NMS developer.
> > 
> > Well, it does add the need to support a new TC, rather than the 
> > TruthValue TC which is already supported by any management 
> application.
> > There should be good reasons to do it. 
> SAB : I feel this argument is a little exaggerated because NMS
>     : developers already have to support standard types and
>     : user defined types in any given MIB.
>     : Adding a few extra TC's to this MIB does not
>     : significantly increase the task for NMS developers.
>     : We believe that keeping the MIB values in line with
>     : the source document is an important enough reason 
>     : to define our own TC.

We disagree.

The chances of a network operator to read a source document from ITU-T
is relatively low. On the other hand, operators need to manage multiple
technologies, not only DSL, so the need for consistency in terminology
works in the opposite direction than the one that you are supporting. 

> > 
> > > If we cannot guarantee that the MIB values are the same as the 
> > > values specified in the source document then I believe that this 
> > > will lead to negative consequences that are worse than 
> the minor sin 
> > > of using a TC instead of TruthValue.
> > 
> > Can you explain this? What are the negative consequences? 
> SAB : There is the potential for negative consequences if a
>     : translation is required between the values in the MIB
>     : and the source document. On every parameter in the
>     : VDSL2 MIB we reference the corresponding parameter in
>     : the ITU document.
>     : Readers come to expect that the parameters
>     : defined in the ITU document are the same ones that
>     : are defined in the MIB. If we use the TruthValue type
>     : as suggested then 98% of the MIB will be identical to
>     : the source document and 2% of the MIB values will require
>     : an arbitrary translation.
>     : The intention of the authors is to have a direct mapping
>     : between the source document and the MIB.
>     : The ITU document has been adopted widely by Vendors and
>     : there are many solutions available that comply with the ITU
>     : specification such as XDSL chip sets and software stacks.
>     : If we keep the MIB identical to the ITU document then
>     : no translation is required between these compliant systems
>     : and a single document is all that is required to understand
>     : them all.
> > 
> > > The source document ( G.997.1 ) is a work in progress and can be 
> > > revised in subsequent publications. It is permissible to add new 
> > > enumerated values at the end of an existing enumerated 
> type because 
> > > this type of change is backward compatible. If the ITU add a new 
> > > enumerated value to an existing boolean parameter then we 
> would be 
> > > forced to change the type from TruthValue to a TC which 
> would have 
> > > negative consequences for NMS developers.
> > 
> > This would be indeed a strong argument in favor of using another TC 
> > than TruthValue. I do not see however how this argument applies to 
> > Xdsl2LineSnrMode (can any other state than virtual noise enabled or 
> > disabled ever exist?) and to Xdsl2LineReset (which seems to have two
> > states: reset or idle = no reset). How could these two be 
> extended in 
> > the future?
> SAB : We are not the authors of the source document so we cannot
>     : make any guarantees on their behalf and we cannot anticipate
>     : how the ITU document may be changed in the future.
>     : I agree that several of the parameters appear to be boolean
>     : in nature.
>     : If the ITU document uses names like 'reset' and 'idle' then
>     : I would prefer to keep those names rather than replace them
>     : with 'true' and 'false'. The ITU names carry more meaning
>     : and they provide a common vocabulary that can be used and
>     : understood by anyone that implements solutions based on
>     : the source document.

What is the semantics of 'idle' that would be lost? 

I do not hear a strong argument for new TCs, but an acknowledgement that
' that several of the parameters appear to be boolean in nature'. My
recommendation is to take out these TCs and change the SYNTAX of the
respective objects in the next version of the document to TruthValue. 

> > 
> > Thanks and Regards,
> > 
> > Dan
> > 
> > 
> > > -----Original Message-----
> > > From: Scott Baillie [mailto:[email-masked]]
> > > Sent: Sunday, February 22, 2009 2:58 PM
> > > To: [email-masked]
> > > Cc: Andy Bierman; Bert Wijnen (IETF); David B Harrington; 
> 'Menachem 
> > > Dodge'; 'Moti Morgenstern'; Romascanu, Dan (Dan); MIB Doctors 
> > > (E-mail)
> > > Subject: Re: [Adslmib] [MIB-DOCTORS] AD review 
> > > ofdraft-ietf-adslmib-vdsl2-06.txt
> > > 
> > > Hi All,
> > > 
> > > As one of the draft MIB editors I thought I would chime in on the 
> > > issue of the use of the TruthValue type for boolean parameters.
> > > 
> > > I agree that the use of primitive data types where possible is a 
> > > desirable thing. I also agree that defining a new type that is 
> > > equivalent to an existing primitive type is undesirable.
> > > In the case of the VDSL2 MIB, there is a reason why the 
> MIB authors 
> > > have chosen to define a new type rather than use a 
> standard type ( 
> > > see below ).
> > > 
> > > I do not entirely agree with the position put forward by David ( 
> > > 2009-Feb-16 ) regarding NMS developers.
> > > NMS developers have to support standard data types and new data 
> > > types ( TC's ) when dealing with any MIB. Our choice of 
> using a TC 
> > > rather than a TruthValue does not significantly impact the NMS 
> > > developer.
> > > 
> > > Also, the long section in David's message regarding 
> interoperability 
> > > of the SNMP protocol is a way overblown response to our 
> minor sin of 
> > > using a TC rather than a TruthValue. Our choice of using 
> a TC does 
> > > not diminish the vendor-neutral, and managed-technology-neutral 
> > > nature of the SNMP protocol.
> > > 
> > > I would like to state the 2 main reasons why we chose to define a 
> > > new TC rather than use a standard TruthValue type.
> > > 
> > > 
> > > Reason 1
> > > --------
> > > The VDSL2 MIB is largely based on the ITU document G.997.1.
> > > The ITU document specifies all of the VDSL2 management parameters 
> > > and their values. At the moment, the current VDSL2 draft exactly 
> > > matches all of the parameters in the ITU document and exactly 
> > > matches all of their values. This is a huge advantage, it 
> means that 
> > > there is one source document you can turn to when managing XDSL 
> > > technology.
> > > If we were to use the TruthValue type as suggested then we would 
> > > lose the tight coupling between the source document (
> > > G.997.1 ) and the SNMP MIB that we currently enjoy.
> > > If we cannot guarantee that the MIB values are the same as the 
> > > values specified in the source document then I believe that this 
> > > will lead to negative consequences that are worse than 
> the minor sin 
> > > of using a TC instead of TruthValue.
> > > 
> > > 
> > > Reason 2
> > > --------
> > > The source document ( G.997.1 ) is a work in progress and can be 
> > > revised in subsequent publications. It is permissible to add new 
> > > enumerated values at the end of an existing enumerated 
> type because 
> > > this type of change is backward compatible. If the ITU add a new 
> > > enumerated value to an existing boolean parameter then we 
> would be 
> > > forced to change the type from TruthValue to a TC which 
> would have 
> > > negative consequences for NMS developers.
> > > 
> > > 
> > > Summary
> > > -------
> > > We recognise that the use of standard types is preferable
> > > where possible but in the case of the VDSL2 MIB, the advantages
> > > of having the MIB identical to the source document far
> > > out weigh the advantages of using standard types.
> > > 
> > > 
> > > 
> > > Regards,
> > > 
> > > Scott.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> 
> 

From: Scott Baillie <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 23 Feb 2009 22:02:03 +1100
Cc: David B Harrington <[email-masked]>, [email-masked], Menachem Dodge <[email-masked]>, "MIB Doctors \(E-mail\)" <[email-masked]>, "Bert Wijnen \(IETF\)" <[email-masked]>, Andy Bierman <[email-masked]>, Moti Morgenstern <[email-masked]>
Subject: Re: [Adslmib] [MIB-DOCTORS] AD	reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hi Dan,

See my comments in line.

Regards,

Scott.

On Mon, 2009-02-23 at 11:40 +0100, Romascanu, Dan (Dan) wrote:
> Hi Scott,
> 
> See in-line. 
> 
> Thanks and Regards,
> 
> Dan
>  
> 
> > -----Original Message-----
> > From: Scott Baillie [mailto:[email-masked]] 
> > Sent: Sunday, February 22, 2009 8:42 PM
> > To: Romascanu, Dan (Dan)
> > Cc: [email-masked]; Andy Bierman; Bert Wijnen (IETF); David 
> > B Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors (E-mail)
> > Subject: RE: [Adslmib] [MIB-DOCTORS] AD 
> > reviewofdraft-ietf-adslmib-vdsl2-06.txt
> > 
> > Hi Dan,
> > 
> > A few extra comments in line below :
> > 
> > On Sun, 2009-02-22 at 14:49 +0100, Romascanu, Dan (Dan) wrote:
> > > Hi Scott,
> > > 
> > > A few comments and clarification questions: 
> > > 
> > > > Our choice of
> > > > using a TC rather than a TruthValue does not significantly impact 
> > > > the NMS developer.
> > > 
> > > Well, it does add the need to support a new TC, rather than the 
> > > TruthValue TC which is already supported by any management 
> > application.
> > > There should be good reasons to do it. 
> > SAB : I feel this argument is a little exaggerated because NMS
> >     : developers already have to support standard types and
> >     : user defined types in any given MIB.
> >     : Adding a few extra TC's to this MIB does not
> >     : significantly increase the task for NMS developers.
> >     : We believe that keeping the MIB values in line with
> >     : the source document is an important enough reason 
> >     : to define our own TC.
> 
> We disagree.
> 
> The chances of a network operator to read a source document from ITU-T
> is relatively low. On the other hand, operators need to manage multiple
> technologies, not only DSL, so the need for consistency in terminology
> works in the opposite direction than the one that you are supporting. 
> 
SAB : We ( the MIB authors ) disagree with this objection.
    : The choice of using a TC instead of a TruthValue does not
    : make the VDSL2 MIB inconsistent and it does not require
    : the network operator to read the source document.
    : If a network operator needs to communicate with another
    : ITU compliant vendor then the need for consistency in
    : terminology is important. Our choice of using a TC does
    : not impose an impediment on the network operator.
> 
> > > 
> > > > If we cannot guarantee that the MIB values are the same as the 
> > > > values specified in the source document then I believe that this 
> > > > will lead to negative consequences that are worse than 
> > the minor sin 
> > > > of using a TC instead of TruthValue.
> > > 
> > > Can you explain this? What are the negative consequences? 
> > SAB : There is the potential for negative consequences if a
> >     : translation is required between the values in the MIB
> >     : and the source document. On every parameter in the
> >     : VDSL2 MIB we reference the corresponding parameter in
> >     : the ITU document.
> >     : Readers come to expect that the parameters
> >     : defined in the ITU document are the same ones that
> >     : are defined in the MIB. If we use the TruthValue type
> >     : as suggested then 98% of the MIB will be identical to
> >     : the source document and 2% of the MIB values will require
> >     : an arbitrary translation.
> >     : The intention of the authors is to have a direct mapping
> >     : between the source document and the MIB.
> >     : The ITU document has been adopted widely by Vendors and
> >     : there are many solutions available that comply with the ITU
> >     : specification such as XDSL chip sets and software stacks.
> >     : If we keep the MIB identical to the ITU document then
> >     : no translation is required between these compliant systems
> >     : and a single document is all that is required to understand
> >     : them all.
> > > 
> > > > The source document ( G.997.1 ) is a work in progress and can be 
> > > > revised in subsequent publications. It is permissible to add new 
> > > > enumerated values at the end of an existing enumerated 
> > type because 
> > > > this type of change is backward compatible. If the ITU add a new 
> > > > enumerated value to an existing boolean parameter then we 
> > would be 
> > > > forced to change the type from TruthValue to a TC which 
> > would have 
> > > > negative consequences for NMS developers.
> > > 
> > > This would be indeed a strong argument in favor of using another TC 
> > > than TruthValue. I do not see however how this argument applies to 
> > > Xdsl2LineSnrMode (can any other state than virtual noise enabled or 
> > > disabled ever exist?) and to Xdsl2LineReset (which seems to have two
> > > states: reset or idle = no reset). How could these two be 
> > extended in 
> > > the future?
> > SAB : We are not the authors of the source document so we cannot
> >     : make any guarantees on their behalf and we cannot anticipate
> >     : how the ITU document may be changed in the future.
> >     : I agree that several of the parameters appear to be boolean
> >     : in nature.
> >     : If the ITU document uses names like 'reset' and 'idle' then
> >     : I would prefer to keep those names rather than replace them
> >     : with 'true' and 'false'. The ITU names carry more meaning
> >     : and they provide a common vocabulary that can be used and
> >     : understood by anyone that implements solutions based on
> >     : the source document.
> 
> What is the semantics of 'idle' that would be lost? 
> 
SAB : I have always considered that using appropriate names is
    : important. The term 'idle' will be understood by other
    : ITU compliant vendors but 'false' wont be.
> I do not hear a strong argument for new TCs, but an acknowledgement that
> ' that several of the parameters appear to be boolean in nature'. My
> recommendation is to take out these TCs and change the SYNTAX of the
> respective objects in the next version of the document to TruthValue. 
> 
SAB : We never stated that there are no boolean parameters, we just
    : stated that we have a good reason for not using the
    : TruthValue type.
> 
> > > 
> > > Thanks and Regards,
> > > 
> > > Dan
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Scott Baillie [mailto:[email-masked]]
> > > > Sent: Sunday, February 22, 2009 2:58 PM
> > > > To: [email-masked]
> > > > Cc: Andy Bierman; Bert Wijnen (IETF); David B Harrington; 
> > 'Menachem 
> > > > Dodge'; 'Moti Morgenstern'; Romascanu, Dan (Dan); MIB Doctors 
> > > > (E-mail)
> > > > Subject: Re: [Adslmib] [MIB-DOCTORS] AD review 
> > > > ofdraft-ietf-adslmib-vdsl2-06.txt
> > > > 
> > > > Hi All,
> > > > 
> > > > As one of the draft MIB editors I thought I would chime in on the 
> > > > issue of the use of the TruthValue type for boolean parameters.
> > > > 
> > > > I agree that the use of primitive data types where possible is a 
> > > > desirable thing. I also agree that defining a new type that is 
> > > > equivalent to an existing primitive type is undesirable.
> > > > In the case of the VDSL2 MIB, there is a reason why the 
> > MIB authors 
> > > > have chosen to define a new type rather than use a 
> > standard type ( 
> > > > see below ).
> > > > 
> > > > I do not entirely agree with the position put forward by David ( 
> > > > 2009-Feb-16 ) regarding NMS developers.
> > > > NMS developers have to support standard data types and new data 
> > > > types ( TC's ) when dealing with any MIB. Our choice of 
> > using a TC 
> > > > rather than a TruthValue does not significantly impact the NMS 
> > > > developer.
> > > > 
> > > > Also, the long section in David's message regarding 
> > interoperability 
> > > > of the SNMP protocol is a way overblown response to our 
> > minor sin of 
> > > > using a TC rather than a TruthValue. Our choice of using 
> > a TC does 
> > > > not diminish the vendor-neutral, and managed-technology-neutral 
> > > > nature of the SNMP protocol.
> > > > 
> > > > I would like to state the 2 main reasons why we chose to define a 
> > > > new TC rather than use a standard TruthValue type.
> > > > 
> > > > 
> > > > Reason 1
> > > > --------
> > > > The VDSL2 MIB is largely based on the ITU document G.997.1.
> > > > The ITU document specifies all of the VDSL2 management parameters 
> > > > and their values. At the moment, the current VDSL2 draft exactly 
> > > > matches all of the parameters in the ITU document and exactly 
> > > > matches all of their values. This is a huge advantage, it 
> > means that 
> > > > there is one source document you can turn to when managing XDSL 
> > > > technology.
> > > > If we were to use the TruthValue type as suggested then we would 
> > > > lose the tight coupling between the source document (
> > > > G.997.1 ) and the SNMP MIB that we currently enjoy.
> > > > If we cannot guarantee that the MIB values are the same as the 
> > > > values specified in the source document then I believe that this 
> > > > will lead to negative consequences that are worse than 
> > the minor sin 
> > > > of using a TC instead of TruthValue.
> > > > 
> > > > 
> > > > Reason 2
> > > > --------
> > > > The source document ( G.997.1 ) is a work in progress and can be 
> > > > revised in subsequent publications. It is permissible to add new 
> > > > enumerated values at the end of an existing enumerated 
> > type because 
> > > > this type of change is backward compatible. If the ITU add a new 
> > > > enumerated value to an existing boolean parameter then we 
> > would be 
> > > > forced to change the type from TruthValue to a TC which 
> > would have 
> > > > negative consequences for NMS developers.
> > > > 
> > > > 
> > > > Summary
> > > > -------
> > > > We recognise that the use of standard types is preferable
> > > > where possible but in the case of the VDSL2 MIB, the advantages
> > > > of having the MIB identical to the source document far
> > > > out weigh the advantages of using standard types.
> > > > 
> > > > 
> > > > 
> > > > Regards,
> > > > 
> > > > Scott.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > 
> > 

From: Scott Baillie <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 24 Feb 2009 00:19:07 +1100
Cc: David B Harrington <[email-masked]>, [email-masked], Andy Bierman <[email-masked]>, "MIB Doctors \(E-mail\)" <[email-masked]>, Moti Morgenstern <[email-masked]>, Menachem Dodge <[email-masked]>, "Bert Wijnen \(IETF\)" <[email-masked]>
Subject: [Adslmib] Summary of discussion regarding the use of TruthValue

Hi All,

There has been no consensus at this time on the issue of
using the TruthValue type for boolean objects.

Below is a summary of the discussion so far :

- A number of ADSLMIB contributors have requested that
  the TruthValue type be used for parameters that have
  a boolean nature.

- The MIB authors believe that keeping the MIB identical
  to the source document is more important than following
  the convention regarding TruthValue.

Conclusion
----------
When multiple MIB experts unanimously urge me to make a change
I am reluctant to ignore that advice.
In this case though, I do feel justified in my position
and I have considered both sides of the issue and I
am unlikely to change my mind unless some sort of
new evidence comes to light.

Regards,

Scott.

Content-class: urn:content-classes:message
Date: Mon, 23 Feb 2009 14:49:44 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "David B Harrington" <[email-masked]>, "Scott Baillie" <[email-masked]>
Cc: [email-masked], Menachem Dodge <[email-masked]>, "MIB Doctors \(E-mail\)" <[email-masked]>, "Bert Wijnen \(IETF\)" <[email-masked]>, Andy Bierman <[email-masked]>, Moti Morgenstern <[email-masked]>
Subject: Re: [Adslmib] [MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

I would be interested to hear if there are other opinions from the ADSL
MIB Working Group, excluding the editors. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]] 
> Sent: Monday, February 23, 2009 3:44 PM
> To: Romascanu, Dan (Dan); 'Scott Baillie'
> Cc: [email-masked]; 'Andy Bierman'; 'Bert Wijnen (IETF)'; 
> 'Menachem Dodge'; 'Moti Morgenstern'; 'MIB Doctors (E-mail)'
> Subject: RE: [Adslmib] [MIB-DOCTORS] AD 
> reviewofdraft-ietf-adslmib-vdsl2-06.txt
> 
> Hi,
> 
> The WG obviously did consider this issue, then made an 
> engineering decision.
> I think they have made a reasonable case for using their TCs. 
> I think we should back off and let them publish with their TCs.
> 
> dbh
> 
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> > Sent: Monday, February 23, 2009 5:40 AM
> > To: Scott Baillie
> > Cc: [email-masked]; Andy Bierman; Bert Wijnen (IETF); David B 
> > Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors (E-mail)
> > Subject: RE: [Adslmib] [MIB-DOCTORS] AD 
> > reviewofdraft-ietf-adslmib-vdsl2-06.txt
> > 
> > Hi Scott,
> > 
> > See in-line. 
> > 
> > Thanks and Regards,
> > 
> > Dan
> >  
> > 
> > > -----Original Message-----
> > > From: Scott Baillie [mailto:[email-masked]]
> > > Sent: Sunday, February 22, 2009 8:42 PM
> > > To: Romascanu, Dan (Dan)
> > > Cc: [email-masked]; Andy Bierman; Bert Wijnen (IETF); David B 
> > > Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors
> (E-mail)
> > > Subject: RE: [Adslmib] [MIB-DOCTORS] AD 
> > > reviewofdraft-ietf-adslmib-vdsl2-06.txt
> > > 
> > > Hi Dan,
> > > 
> > > A few extra comments in line below :
> > > 
> > > On Sun, 2009-02-22 at 14:49 +0100, Romascanu, Dan (Dan) wrote:
> > > > Hi Scott,
> > > > 
> > > > A few comments and clarification questions: 
> > > > 
> > > > > Our choice of
> > > > > using a TC rather than a TruthValue does not
> > significantly impact
> > > > > the NMS developer.
> > > > 
> > > > Well, it does add the need to support a new TC, rather than the 
> > > > TruthValue TC which is already supported by any management
> > > application.
> > > > There should be good reasons to do it. 
> > > SAB : I feel this argument is a little exaggerated because NMS
> > >     : developers already have to support standard types and
> > >     : user defined types in any given MIB.
> > >     : Adding a few extra TC's to this MIB does not
> > >     : significantly increase the task for NMS developers.
> > >     : We believe that keeping the MIB values in line with
> > >     : the source document is an important enough reason 
> > >     : to define our own TC.
> > 
> > We disagree.
> > 
> > The chances of a network operator to read a source document from
> ITU-T
> > is relatively low. On the other hand, operators need to manage 
> > multiple technologies, not only DSL, so the need for consistency in
> terminology
> > works in the opposite direction than the one that you are
> supporting. 
> > 
> > 
> > > > 
> > > > > If we cannot guarantee that the MIB values are the same as the
> 
> > > > > values specified in the source document then I believe
> > that this
> > > > > will lead to negative consequences that are worse than
> > > the minor sin
> > > > > of using a TC instead of TruthValue.
> > > > 
> > > > Can you explain this? What are the negative consequences? 
> > > SAB : There is the potential for negative consequences if a
> > >     : translation is required between the values in the MIB
> > >     : and the source document. On every parameter in the
> > >     : VDSL2 MIB we reference the corresponding parameter in
> > >     : the ITU document.
> > >     : Readers come to expect that the parameters
> > >     : defined in the ITU document are the same ones that
> > >     : are defined in the MIB. If we use the TruthValue type
> > >     : as suggested then 98% of the MIB will be identical to
> > >     : the source document and 2% of the MIB values will require
> > >     : an arbitrary translation.
> > >     : The intention of the authors is to have a direct mapping
> > >     : between the source document and the MIB.
> > >     : The ITU document has been adopted widely by Vendors and
> > >     : there are many solutions available that comply with the ITU
> > >     : specification such as XDSL chip sets and software stacks.
> > >     : If we keep the MIB identical to the ITU document then
> > >     : no translation is required between these compliant systems
> > >     : and a single document is all that is required to understand
> > >     : them all.
> > > > 
> > > > > The source document ( G.997.1 ) is a work in progress
> > and can be
> > > > > revised in subsequent publications. It is permissible
> > to add new
> > > > > enumerated values at the end of an existing enumerated
> > > type because
> > > > > this type of change is backward compatible. If the ITU
> > add a new
> > > > > enumerated value to an existing boolean parameter then we
> > > would be
> > > > > forced to change the type from TruthValue to a TC which
> > > would have
> > > > > negative consequences for NMS developers.
> > > > 
> > > > This would be indeed a strong argument in favor of using
> > another TC
> > > > than TruthValue. I do not see however how this argument
> > applies to
> > > > Xdsl2LineSnrMode (can any other state than virtual noise
> > enabled or
> > > > disabled ever exist?) and to Xdsl2LineReset (which seems
> > to have two
> > > > states: reset or idle = no reset). How could these two be
> > > extended in
> > > > the future?
> > > SAB : We are not the authors of the source document so we cannot
> > >     : make any guarantees on their behalf and we cannot anticipate
> > >     : how the ITU document may be changed in the future.
> > >     : I agree that several of the parameters appear to be boolean
> > >     : in nature.
> > >     : If the ITU document uses names like 'reset' and 'idle' then
> > >     : I would prefer to keep those names rather than replace them
> > >     : with 'true' and 'false'. The ITU names carry more meaning
> > >     : and they provide a common vocabulary that can be used and
> > >     : understood by anyone that implements solutions based on
> > >     : the source document.
> > 
> > What is the semantics of 'idle' that would be lost? 
> > 
> > I do not hear a strong argument for new TCs, but an acknowledgement 
> > that ' that several of the parameters appear to be boolean 
> in nature'. 
> > My recommendation is to take out these TCs and change the SYNTAX of 
> > the respective objects in the next version of the document to
> TruthValue. 
> > 
> > 
> > > > 
> > > > Thanks and Regards,
> > > > 
> > > > Dan
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Scott Baillie [mailto:[email-masked]]
> > > > > Sent: Sunday, February 22, 2009 2:58 PM
> > > > > To: [email-masked]
> > > > > Cc: Andy Bierman; Bert Wijnen (IETF); David B Harrington;
> > > 'Menachem
> > > > > Dodge'; 'Moti Morgenstern'; Romascanu, Dan (Dan); MIB Doctors
> > > > > (E-mail)
> > > > > Subject: Re: [Adslmib] [MIB-DOCTORS] AD review 
> > > > > ofdraft-ietf-adslmib-vdsl2-06.txt
> > > > > 
> > > > > Hi All,
> > > > > 
> > > > > As one of the draft MIB editors I thought I would chime
> > in on the
> > > > > issue of the use of the TruthValue type for boolean
> parameters.
> > > > > 
> > > > > I agree that the use of primitive data types where
> > possible is a
> > > > > desirable thing. I also agree that defining a new type that is
> 
> > > > > equivalent to an existing primitive type is undesirable.
> > > > > In the case of the VDSL2 MIB, there is a reason why the 
> > > MIB authors 
> > > > > have chosen to define a new type rather than use a 
> > > standard type ( 
> > > > > see below ).
> > > > > 
> > > > > I do not entirely agree with the position put forward 
> > by David ( 
> > > > > 2009-Feb-16 ) regarding NMS developers.
> > > > > NMS developers have to support standard data types and new
> data 
> > > > > types ( TC's ) when dealing with any MIB. Our choice of 
> > > using a TC 
> > > > > rather than a TruthValue does not significantly impact the NMS
> 
> > > > > developer.
> > > > > 
> > > > > Also, the long section in David's message regarding 
> > > interoperability 
> > > > > of the SNMP protocol is a way overblown response to our 
> > > minor sin of 
> > > > > using a TC rather than a TruthValue. Our choice of using 
> > > a TC does 
> > > > > not diminish the vendor-neutral, and
> managed-technology-neutral 
> > > > > nature of the SNMP protocol.
> > > > > 
> > > > > I would like to state the 2 main reasons why we chose 
> > to define a 
> > > > > new TC rather than use a standard TruthValue type.
> > > > > 
> > > > > 
> > > > > Reason 1
> > > > > --------
> > > > > The VDSL2 MIB is largely based on the ITU document G.997.1.
> > > > > The ITU document specifies all of the VDSL2 management 
> > parameters 
> > > > > and their values. At the moment, the current VDSL2 
> > draft exactly 
> > > > > matches all of the parameters in the ITU document and exactly 
> > > > > matches all of their values. This is a huge advantage, it 
> > > means that 
> > > > > there is one source document you can turn to when managing
> XDSL 
> > > > > technology.
> > > > > If we were to use the TruthValue type as suggested then 
> > we would 
> > > > > lose the tight coupling between the source document (
> > > > > G.997.1 ) and the SNMP MIB that we currently enjoy.
> > > > > If we cannot guarantee that the MIB values are the same as the
> 
> > > > > values specified in the source document then I believe 
> > that this 
> > > > > will lead to negative consequences that are worse than 
> > > the minor sin 
> > > > > of using a TC instead of TruthValue.
> > > > > 
> > > > > 
> > > > > Reason 2
> > > > > --------
> > > > > The source document ( G.997.1 ) is a work in progress 
> > and can be 
> > > > > revised in subsequent publications. It is permissible 
> > to add new 
> > > > > enumerated values at the end of an existing enumerated 
> > > type because 
> > > > > this type of change is backward compatible. If the ITU 
> > add a new 
> > > > > enumerated value to an existing boolean parameter then we 
> > > would be 
> > > > > forced to change the type from TruthValue to a TC which 
> > > would have 
> > > > > negative consequences for NMS developers.
> > > > > 
> > > > > 
> > > > > Summary
> > > > > -------
> > > > > We recognise that the use of standard types is preferable
> > > > > where possible but in the case of the VDSL2 MIB, the
> advantages
> > > > > of having the MIB identical to the source document far
> > > > > out weigh the advantages of using standard types.
> > > > > 
> > > > > 
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Scott.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > 
> > > 
> > 
> 
> 

From: "Bert Wijnen \(IETF\)" <[email-masked]>
To: "David B Harrington" <[email-masked]>, "'Romascanu, Dan \(Dan\)'" <[email-masked]>, "'Scott Baillie'" <[email-masked]>
Date: Mon, 23 Feb 2009 15:01:15 +0100
Organization: Consultant
Cc: "'MIB Doctors \(E-mail\)'" <[email-masked]>, [email-masked], 'Andy Bierman' <[email-masked]>, 'Moti Morgenstern' <[email-masked]>, 'Menachem Dodge' <[email-masked]>
Subject: Re: [Adslmib] [MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

This is a multi-part message in MIME format.

------=_NextPart_000_097F_01C995C7.934EB810
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Although I personally think it would be better to use TruthValue in the case of
a boolean, I also do believe that the TCs that are now used are NOT a FATAL flaw.
So... although I am not 100% happy with it, I can live with it.

Bert
  ----- Original Message ----- 
  From: David B Harrington 
  To: 'Romascanu, Dan (Dan)' ; 'Scott Baillie' 
  Cc: [email-masked] ; 'Andy Bierman' ; 'Bert Wijnen (IETF)' ; 'Menachem Dodge' ; 'Moti Morgenstern' ; 'MIB Doctors (E-mail)' 
  Sent: Monday, February 23, 2009 2:44 PM
  Subject: RE: [Adslmib] [MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

  Hi,

  The WG obviously did consider this issue, then made an engineering
  decision.
  I think they have made a reasonable case for using their TCs. 
  I think we should back off and let them publish with their TCs.

  dbh

  > -----Original Message-----
  > From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
  > Sent: Monday, February 23, 2009 5:40 AM
  > To: Scott Baillie
  > Cc: [email-masked]; Andy Bierman; Bert Wijnen (IETF); David 
  > B Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors (E-mail)
  > Subject: RE: [Adslmib] [MIB-DOCTORS] AD 
  > reviewofdraft-ietf-adslmib-vdsl2-06.txt
  > 
  > Hi Scott,
  > 
  > See in-line. 
  > 
  > Thanks and Regards,
  > 
  > Dan
  >  
  > 
  > > -----Original Message-----
  > > From: Scott Baillie [mailto:[email-masked]] 
  > > Sent: Sunday, February 22, 2009 8:42 PM
  > > To: Romascanu, Dan (Dan)
  > > Cc: [email-masked]; Andy Bierman; Bert Wijnen (IETF); David 
  > > B Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors
  (E-mail)
  > > Subject: RE: [Adslmib] [MIB-DOCTORS] AD 
  > > reviewofdraft-ietf-adslmib-vdsl2-06.txt
  > > 
  > > Hi Dan,
  > > 
  > > A few extra comments in line below :
  > > 
  > > On Sun, 2009-02-22 at 14:49 +0100, Romascanu, Dan (Dan) wrote:
  > > > Hi Scott,
  > > > 
  > > > A few comments and clarification questions: 
  > > > 
  > > > > Our choice of
  > > > > using a TC rather than a TruthValue does not 
  > significantly impact 
  > > > > the NMS developer.
  > > > 
  > > > Well, it does add the need to support a new TC, rather than the 
  > > > TruthValue TC which is already supported by any management 
  > > application.
  > > > There should be good reasons to do it. 
  > > SAB : I feel this argument is a little exaggerated because NMS
  > >     : developers already have to support standard types and
  > >     : user defined types in any given MIB.
  > >     : Adding a few extra TC's to this MIB does not
  > >     : significantly increase the task for NMS developers.
  > >     : We believe that keeping the MIB values in line with
  > >     : the source document is an important enough reason 
  > >     : to define our own TC.
  > 
  > We disagree.
  > 
  > The chances of a network operator to read a source document from
  ITU-T
  > is relatively low. On the other hand, operators need to 
  > manage multiple
  > technologies, not only DSL, so the need for consistency in
  terminology
  > works in the opposite direction than the one that you are
  supporting. 
  > 
  > 
  > > > 
  > > > > If we cannot guarantee that the MIB values are the same as the

  > > > > values specified in the source document then I believe 
  > that this 
  > > > > will lead to negative consequences that are worse than 
  > > the minor sin 
  > > > > of using a TC instead of TruthValue.
  > > > 
  > > > Can you explain this? What are the negative consequences? 
  > > SAB : There is the potential for negative consequences if a
  > >     : translation is required between the values in the MIB
  > >     : and the source document. On every parameter in the
  > >     : VDSL2 MIB we reference the corresponding parameter in
  > >     : the ITU document.
  > >     : Readers come to expect that the parameters
  > >     : defined in the ITU document are the same ones that
  > >     : are defined in the MIB. If we use the TruthValue type
  > >     : as suggested then 98% of the MIB will be identical to
  > >     : the source document and 2% of the MIB values will require
  > >     : an arbitrary translation.
  > >     : The intention of the authors is to have a direct mapping
  > >     : between the source document and the MIB.
  > >     : The ITU document has been adopted widely by Vendors and
  > >     : there are many solutions available that comply with the ITU
  > >     : specification such as XDSL chip sets and software stacks.
  > >     : If we keep the MIB identical to the ITU document then
  > >     : no translation is required between these compliant systems
  > >     : and a single document is all that is required to understand
  > >     : them all.
  > > > 
  > > > > The source document ( G.997.1 ) is a work in progress 
  > and can be 
  > > > > revised in subsequent publications. It is permissible 
  > to add new 
  > > > > enumerated values at the end of an existing enumerated 
  > > type because 
  > > > > this type of change is backward compatible. If the ITU 
  > add a new 
  > > > > enumerated value to an existing boolean parameter then we 
  > > would be 
  > > > > forced to change the type from TruthValue to a TC which 
  > > would have 
  > > > > negative consequences for NMS developers.
  > > > 
  > > > This would be indeed a strong argument in favor of using 
  > another TC 
  > > > than TruthValue. I do not see however how this argument 
  > applies to 
  > > > Xdsl2LineSnrMode (can any other state than virtual noise 
  > enabled or 
  > > > disabled ever exist?) and to Xdsl2LineReset (which seems 
  > to have two
  > > > states: reset or idle = no reset). How could these two be 
  > > extended in 
  > > > the future?
  > > SAB : We are not the authors of the source document so we cannot
  > >     : make any guarantees on their behalf and we cannot anticipate
  > >     : how the ITU document may be changed in the future.
  > >     : I agree that several of the parameters appear to be boolean
  > >     : in nature.
  > >     : If the ITU document uses names like 'reset' and 'idle' then
  > >     : I would prefer to keep those names rather than replace them
  > >     : with 'true' and 'false'. The ITU names carry more meaning
  > >     : and they provide a common vocabulary that can be used and
  > >     : understood by anyone that implements solutions based on
  > >     : the source document.
  > 
  > What is the semantics of 'idle' that would be lost? 
  > 
  > I do not hear a strong argument for new TCs, but an 
  > acknowledgement that
  > ' that several of the parameters appear to be boolean in nature'. My
  > recommendation is to take out these TCs and change the SYNTAX of the
  > respective objects in the next version of the document to
  TruthValue. 
  > 
  > 
  > > > 
  > > > Thanks and Regards,
  > > > 
  > > > Dan
  > > > 
  > > > 
  > > > > -----Original Message-----
  > > > > From: Scott Baillie [mailto:[email-masked]]
  > > > > Sent: Sunday, February 22, 2009 2:58 PM
  > > > > To: [email-masked]
  > > > > Cc: Andy Bierman; Bert Wijnen (IETF); David B Harrington; 
  > > 'Menachem 
  > > > > Dodge'; 'Moti Morgenstern'; Romascanu, Dan (Dan); MIB Doctors 
  > > > > (E-mail)
  > > > > Subject: Re: [Adslmib] [MIB-DOCTORS] AD review 
  > > > > ofdraft-ietf-adslmib-vdsl2-06.txt
  > > > > 
  > > > > Hi All,
  > > > > 
  > > > > As one of the draft MIB editors I thought I would chime 
  > in on the 
  > > > > issue of the use of the TruthValue type for boolean
  parameters.
  > > > > 
  > > > > I agree that the use of primitive data types where 
  > possible is a 
  > > > > desirable thing. I also agree that defining a new type that is

  > > > > equivalent to an existing primitive type is undesirable.
  > > > > In the case of the VDSL2 MIB, there is a reason why the 
  > > MIB authors 
  > > > > have chosen to define a new type rather than use a 
  > > standard type ( 
  > > > > see below ).
  > > > > 
  > > > > I do not entirely agree with the position put forward 
  > by David ( 
  > > > > 2009-Feb-16 ) regarding NMS developers.
  > > > > NMS developers have to support standard data types and new
  data 
  > > > > types ( TC's ) when dealing with any MIB. Our choice of 
  > > using a TC 
  > > > > rather than a TruthValue does not significantly impact the NMS

  > > > > developer.
  > > > > 
  > > > > Also, the long section in David's message regarding 
  > > interoperability 
  > > > > of the SNMP protocol is a way overblown response to our 
  > > minor sin of 
  > > > > using a TC rather than a TruthValue. Our choice of using 
  > > a TC does 
  > > > > not diminish the vendor-neutral, and
  managed-technology-neutral 
  > > > > nature of the SNMP protocol.
  > > > > 
  > > > > I would like to state the 2 main reasons why we chose 
  > to define a 
  > > > > new TC rather than use a standard TruthValue type.
  > > > > 
  > > > > 
  > > > > Reason 1
  > > > > --------
  > > > > The VDSL2 MIB is largely based on the ITU document G.997.1.
  > > > > The ITU document specifies all of the VDSL2 management 
  > parameters 
  > > > > and their values. At the moment, the current VDSL2 
  > draft exactly 
  > > > > matches all of the parameters in the ITU document and exactly 
  > > > > matches all of their values. This is a huge advantage, it 
  > > means that 
  > > > > there is one source document you can turn to when managing
  XDSL 
  > > > > technology.
  > > > > If we were to use the TruthValue type as suggested then 
  > we would 
  > > > > lose the tight coupling between the source document (
  > > > > G.997.1 ) and the SNMP MIB that we currently enjoy.
  > > > > If we cannot guarantee that the MIB values are the same as the

  > > > > values specified in the source document then I believe 
  > that this 
  > > > > will lead to negative consequences that are worse than 
  > > the minor sin 
  > > > > of using a TC instead of TruthValue.
  > > > > 
  > > > > 
  > > > > Reason 2
  > > > > --------
  > > > > The source document ( G.997.1 ) is a work in progress 
  > and can be 
  > > > > revised in subsequent publications. It is permissible 
  > to add new 
  > > > > enumerated values at the end of an existing enumerated 
  > > type because 
  > > > > this type of change is backward compatible. If the ITU 
  > add a new 
  > > > > enumerated value to an existing boolean parameter then we 
  > > would be 
  > > > > forced to change the type from TruthValue to a TC which 
  > > would have 
  > > > > negative consequences for NMS developers.
  > > > > 
  > > > > 
  > > > > Summary
  > > > > -------
  > > > > We recognise that the use of standard types is preferable
  > > > > where possible but in the case of the VDSL2 MIB, the
  advantages
  > > > > of having the MIB identical to the source document far
  > > > > out weigh the advantages of using standard types.
  > > > > 
  > > > > 
  > > > > 
  > > > > Regards,
  > > > > 
  > > > > Scott.
  > > > > 
  > > > > 
  > > > > 
  > > > > 
  > > > > 
  > > > > 
  > > > > 
  > > 
  > > 
  > 

------=_NextPart_000_097F_01C995C7.934EB810
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6001.18203" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>Although I personally think it would be better to use 
TruthValue in the case of</FONT></DIV>
<DIV><FONT size=2>a boolean, I also do believe that the TCs that are now used 
are&nbsp;NOT a FATAL flaw.</FONT></DIV>
<DIV><FONT size=2>So... although I am not 100% happy with it, I can live with 
it.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Bert</FONT></DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=[email-masked] href="mailto:[email-masked]">David 
  B Harrington</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">'Romascanu, Dan (Dan)'</A> ; <A 
  title=[email-masked] href="mailto:[email-masked]">'Scott 
  Baillie'</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=[email-masked] 
  href="mailto:[email-masked]">[email-masked]</A> ; <A 
  title=[email-masked] href="mailto:[email-masked]">'Andy 
  Bierman'</A> ; <A title=[email-masked] 
  href="mailto:[email-masked]">'Bert Wijnen (IETF)'</A> ; <A 
  title=[email-masked] 
  href="mailto:[email-masked]">'Menachem Dodge'</A> ; <A 
  title=[email-masked] 
  href="mailto:[email-masked]">'Moti Morgenstern'</A> ; <A 
  title=[email-masked] href="mailto:[email-masked]">'MIB Doctors 
  (E-mail)'</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Monday, February 23, 2009 2:44 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> RE: [Adslmib] [MIB-DOCTORS] AD 
  reviewofdraft-ietf-adslmib-vdsl2-06.txt</DIV>
  <DIV><BR></DIV>Hi,<BR><BR>The WG obviously did consider this issue, then made 
  an engineering<BR>decision.<BR>I think they have made a reasonable case for 
  using their TCs. <BR>I think we should back off and let them publish with 
  their TCs.<BR><BR>dbh<BR><BR>&gt; -----Original Message-----<BR>&gt; From: 
  Romascanu, Dan (Dan) [mailto:[email-masked]] <BR>&gt; Sent: Monday, 
  February 23, 2009 5:40 AM<BR>&gt; To: Scott Baillie<BR>&gt; Cc: <A 
  href="mailto:[email-masked]">[email-masked]</A>; Andy Bierman; Bert Wijnen 
  (IETF); David <BR>&gt; B Harrington; Menachem Dodge; Moti Morgenstern; MIB 
  Doctors (E-mail)<BR>&gt; Subject: RE: [Adslmib] [MIB-DOCTORS] AD <BR>&gt; 
  reviewofdraft-ietf-adslmib-vdsl2-06.txt<BR>&gt; <BR>&gt; Hi Scott,<BR>&gt; 
  <BR>&gt; See in-line. <BR>&gt; <BR>&gt; Thanks and Regards,<BR>&gt; <BR>&gt; 
  Dan<BR>&gt;&nbsp; <BR>&gt; <BR>&gt; &gt; -----Original Message-----<BR>&gt; 
  &gt; From: Scott Baillie [mailto:[email-masked]] <BR>&gt; &gt; Sent: 
  Sunday, February 22, 2009 8:42 PM<BR>&gt; &gt; To: Romascanu, Dan 
  (Dan)<BR>&gt; &gt; Cc: <A href="mailto:[email-masked]">[email-masked]</A>; 
  Andy Bierman; Bert Wijnen (IETF); David <BR>&gt; &gt; B Harrington; Menachem 
  Dodge; Moti Morgenstern; MIB Doctors<BR>(E-mail)<BR>&gt; &gt; Subject: RE: 
  [Adslmib] [MIB-DOCTORS] AD <BR>&gt; &gt; 
  reviewofdraft-ietf-adslmib-vdsl2-06.txt<BR>&gt; &gt; <BR>&gt; &gt; Hi 
  Dan,<BR>&gt; &gt; <BR>&gt; &gt; A few extra comments in line below :<BR>&gt; 
  &gt; <BR>&gt; &gt; On Sun, 2009-02-22 at 14:49 +0100, Romascanu, Dan (Dan) 
  wrote:<BR>&gt; &gt; &gt; Hi Scott,<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; A few 
  comments and clarification questions: <BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; 
  &gt; Our choice of<BR>&gt; &gt; &gt; &gt; using a TC rather than a TruthValue 
  does not <BR>&gt; significantly impact <BR>&gt; &gt; &gt; &gt; the NMS 
  developer.<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; Well, it does add the need to 
  support a new TC, rather than the <BR>&gt; &gt; &gt; TruthValue TC which is 
  already supported by any management <BR>&gt; &gt; application.<BR>&gt; &gt; 
  &gt; There should be good reasons to do it. <BR>&gt; &gt; SAB : I feel this 
  argument is a little exaggerated because NMS<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp; : developers already have to support standard 
  types and<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : user defined types in any 
  given MIB.<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : Adding a few extra TC's to 
  this MIB does not<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : significantly 
  increase the task for NMS developers.<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : 
  We believe that keeping the MIB values in line with<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp; : the source document is an important enough 
  reason <BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : to define our own TC.<BR>&gt; 
  <BR>&gt; We disagree.<BR>&gt; <BR>&gt; The chances of a network operator to 
  read a source document from<BR>ITU-T<BR>&gt; is relatively low. On the other 
  hand, operators need to <BR>&gt; manage multiple<BR>&gt; technologies, not 
  only DSL, so the need for consistency in<BR>terminology<BR>&gt; works in the 
  opposite direction than the one that you are<BR>supporting. <BR>&gt; <BR>&gt; 
  <BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; &gt; If we cannot guarantee that the MIB 
  values are the same as the<BR><BR>&gt; &gt; &gt; &gt; values specified in the 
  source document then I believe <BR>&gt; that this <BR>&gt; &gt; &gt; &gt; will 
  lead to negative consequences that are worse than <BR>&gt; &gt; the minor sin 
  <BR>&gt; &gt; &gt; &gt; of using a TC instead of TruthValue.<BR>&gt; &gt; &gt; 
  <BR>&gt; &gt; &gt; Can you explain this? What are the negative consequences? 
  <BR>&gt; &gt; SAB : There is the potential for negative consequences if 
  a<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : translation is required between the 
  values in the MIB<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : and the source 
  document. On every parameter in the<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : 
  VDSL2 MIB we reference the corresponding parameter in<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp; : the ITU document.<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp; : Readers come to expect that the 
  parameters<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : defined in the ITU document 
  are the same ones that<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : are defined in 
  the MIB. If we use the TruthValue type<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : 
  as suggested then 98% of the MIB will be identical to<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp; : the source document and 2% of the MIB values 
  will require<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : an arbitrary 
  translation.<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : The intention of the 
  authors is to have a direct mapping<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : 
  between the source document and the MIB.<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; 
  : The ITU document has been adopted widely by Vendors and<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp; : there are many solutions available that comply 
  with the ITU<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : specification such as XDSL 
  chip sets and software stacks.<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : If we 
  keep the MIB identical to the ITU document then<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp; : no translation is required between these 
  compliant systems<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : and a single document 
  is all that is required to understand<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : 
  them all.<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; &gt; The source document ( 
  G.997.1 ) is a work in progress <BR>&gt; and can be <BR>&gt; &gt; &gt; &gt; 
  revised in subsequent publications. It is permissible <BR>&gt; to add new 
  <BR>&gt; &gt; &gt; &gt; enumerated values at the end of an existing enumerated 
  <BR>&gt; &gt; type because <BR>&gt; &gt; &gt; &gt; this type of change is 
  backward compatible. If the ITU <BR>&gt; add a new <BR>&gt; &gt; &gt; &gt; 
  enumerated value to an existing boolean parameter then we <BR>&gt; &gt; would 
  be <BR>&gt; &gt; &gt; &gt; forced to change the type from TruthValue to a TC 
  which <BR>&gt; &gt; would have <BR>&gt; &gt; &gt; &gt; negative consequences 
  for NMS developers.<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; This would be indeed 
  a strong argument in favor of using <BR>&gt; another TC <BR>&gt; &gt; &gt; 
  than TruthValue. I do not see however how this argument <BR>&gt; applies to 
  <BR>&gt; &gt; &gt; Xdsl2LineSnrMode (can any other state than virtual noise 
  <BR>&gt; enabled or <BR>&gt; &gt; &gt; disabled ever exist?) and to 
  Xdsl2LineReset (which seems <BR>&gt; to have two<BR>&gt; &gt; &gt; states: 
  reset or idle = no reset). How could these two be <BR>&gt; &gt; extended in 
  <BR>&gt; &gt; &gt; the future?<BR>&gt; &gt; SAB : We are not the authors of 
  the source document so we cannot<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : make 
  any guarantees on their behalf and we cannot anticipate<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp; : how the ITU document may be changed in the 
  future.<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : I agree that several of the 
  parameters appear to be boolean<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : in 
  nature.<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : If the ITU document uses names 
  like 'reset' and 'idle' then<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : I would 
  prefer to keep those names rather than replace them<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp; : with 'true' and 'false'. The ITU names carry 
  more meaning<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : and they provide a common 
  vocabulary that can be used and<BR>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; : 
  understood by anyone that implements solutions based on<BR>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp; : the source document.<BR>&gt; <BR>&gt; What is 
  the semantics of 'idle' that would be lost? <BR>&gt; <BR>&gt; I do not hear a 
  strong argument for new TCs, but an <BR>&gt; acknowledgement that<BR>&gt; ' 
  that several of the parameters appear to be boolean in nature'. My<BR>&gt; 
  recommendation is to take out these TCs and change the SYNTAX of the<BR>&gt; 
  respective objects in the next version of the document to<BR>TruthValue. 
  <BR>&gt; <BR>&gt; <BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; Thanks and 
  Regards,<BR>&gt; &gt; &gt; <BR>&gt; &gt; &gt; Dan<BR>&gt; &gt; &gt; <BR>&gt; 
  &gt; &gt; <BR>&gt; &gt; &gt; &gt; -----Original Message-----<BR>&gt; &gt; &gt; 
  &gt; From: Scott Baillie [mailto:[email-masked]]<BR>&gt; &gt; &gt; 
  &gt; Sent: Sunday, February 22, 2009 2:58 PM<BR>&gt; &gt; &gt; &gt; To: <A 
  href="mailto:[email-masked]">[email-masked]</A><BR>&gt; &gt; &gt; &gt; Cc: 
  Andy Bierman; Bert Wijnen (IETF); David B Harrington; <BR>&gt; &gt; 'Menachem 
  <BR>&gt; &gt; &gt; &gt; Dodge'; 'Moti Morgenstern'; Romascanu, Dan (Dan); MIB 
  Doctors <BR>&gt; &gt; &gt; &gt; (E-mail)<BR>&gt; &gt; &gt; &gt; Subject: Re: 
  [Adslmib] [MIB-DOCTORS] AD review <BR>&gt; &gt; &gt; &gt; 
  ofdraft-ietf-adslmib-vdsl2-06.txt<BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; &gt; 
  &gt; Hi All,<BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; &gt; &gt; As one of the 
  draft MIB editors I thought I would chime <BR>&gt; in on the <BR>&gt; &gt; 
  &gt; &gt; issue of the use of the TruthValue type for 
  boolean<BR>parameters.<BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; &gt; &gt; I agree 
  that the use of primitive data types where <BR>&gt; possible is a <BR>&gt; 
  &gt; &gt; &gt; desirable thing. I also agree that defining a new type that 
  is<BR><BR>&gt; &gt; &gt; &gt; equivalent to an existing primitive type is 
  undesirable.<BR>&gt; &gt; &gt; &gt; In the case of the VDSL2 MIB, there is a 
  reason why the <BR>&gt; &gt; MIB authors <BR>&gt; &gt; &gt; &gt; have chosen 
  to define a new type rather than use a <BR>&gt; &gt; standard type ( <BR>&gt; 
  &gt; &gt; &gt; see below ).<BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; &gt; &gt; I 
  do not entirely agree with the position put forward <BR>&gt; by David ( 
  <BR>&gt; &gt; &gt; &gt; 2009-Feb-16 ) regarding NMS developers.<BR>&gt; &gt; 
  &gt; &gt; NMS developers have to support standard data types and new<BR>data 
  <BR>&gt; &gt; &gt; &gt; types ( TC's ) when dealing with any MIB. Our choice 
  of <BR>&gt; &gt; using a TC <BR>&gt; &gt; &gt; &gt; rather than a TruthValue 
  does not significantly impact the NMS<BR><BR>&gt; &gt; &gt; &gt; 
  developer.<BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; &gt; &gt; Also, the long 
  section in David's message regarding <BR>&gt; &gt; interoperability <BR>&gt; 
  &gt; &gt; &gt; of the SNMP protocol is a way overblown response to our 
  <BR>&gt; &gt; minor sin of <BR>&gt; &gt; &gt; &gt; using a TC rather than a 
  TruthValue. Our choice of using <BR>&gt; &gt; a TC does <BR>&gt; &gt; &gt; 
  &gt; not diminish the vendor-neutral, and<BR>managed-technology-neutral 
  <BR>&gt; &gt; &gt; &gt; nature of the SNMP protocol.<BR>&gt; &gt; &gt; &gt; 
  <BR>&gt; &gt; &gt; &gt; I would like to state the 2 main reasons why we chose 
  <BR>&gt; to define a <BR>&gt; &gt; &gt; &gt; new TC rather than use a standard 
  TruthValue type.<BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; 
  &gt; &gt; Reason 1<BR>&gt; &gt; &gt; &gt; --------<BR>&gt; &gt; &gt; &gt; The 
  VDSL2 MIB is largely based on the ITU document G.997.1.<BR>&gt; &gt; &gt; &gt; 
  The ITU document specifies all of the VDSL2 management <BR>&gt; parameters 
  <BR>&gt; &gt; &gt; &gt; and their values. At the moment, the current VDSL2 
  <BR>&gt; draft exactly <BR>&gt; &gt; &gt; &gt; matches all of the parameters 
  in the ITU document and exactly <BR>&gt; &gt; &gt; &gt; matches all of their 
  values. This is a huge advantage, it <BR>&gt; &gt; means that <BR>&gt; &gt; 
  &gt; &gt; there is one source document you can turn to when managing<BR>XDSL 
  <BR>&gt; &gt; &gt; &gt; technology.<BR>&gt; &gt; &gt; &gt; If we were to use 
  the TruthValue type as suggested then <BR>&gt; we would <BR>&gt; &gt; &gt; 
  &gt; lose the tight coupling between the source document (<BR>&gt; &gt; &gt; 
  &gt; G.997.1 ) and the SNMP MIB that we currently enjoy.<BR>&gt; &gt; &gt; 
  &gt; If we cannot guarantee that the MIB values are the same as 
  the<BR><BR>&gt; &gt; &gt; &gt; values specified in the source document then I 
  believe <BR>&gt; that this <BR>&gt; &gt; &gt; &gt; will lead to negative 
  consequences that are worse than <BR>&gt; &gt; the minor sin <BR>&gt; &gt; 
  &gt; &gt; of using a TC instead of TruthValue.<BR>&gt; &gt; &gt; &gt; <BR>&gt; 
  &gt; &gt; &gt; <BR>&gt; &gt; &gt; &gt; Reason 2<BR>&gt; &gt; &gt; &gt; 
  --------<BR>&gt; &gt; &gt; &gt; The source document ( G.997.1 ) is a work in 
  progress <BR>&gt; and can be <BR>&gt; &gt; &gt; &gt; revised in subsequent 
  publications. It is permissible <BR>&gt; to add new <BR>&gt; &gt; &gt; &gt; 
  enumerated values at the end of an existing enumerated <BR>&gt; &gt; type 
  because <BR>&gt; &gt; &gt; &gt; this type of change is backward compatible. If 
  the ITU <BR>&gt; add a new <BR>&gt; &gt; &gt; &gt; enumerated value to an 
  existing boolean parameter then we <BR>&gt; &gt; would be <BR>&gt; &gt; &gt; 
  &gt; forced to change the type from TruthValue to a TC which <BR>&gt; &gt; 
  would have <BR>&gt; &gt; &gt; &gt; negative consequences for NMS 
  developers.<BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; &gt; 
  &gt; Summary<BR>&gt; &gt; &gt; &gt; -------<BR>&gt; &gt; &gt; &gt; We 
  recognise that the use of standard types is preferable<BR>&gt; &gt; &gt; &gt; 
  where possible but in the case of the VDSL2 MIB, the<BR>advantages<BR>&gt; 
  &gt; &gt; &gt; of having the MIB identical to the source document far<BR>&gt; 
  &gt; &gt; &gt; out weigh the advantages of using standard types.<BR>&gt; &gt; 
  &gt; &gt; <BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; &gt; 
  &gt; Regards,<BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; &gt; &gt; Scott.<BR>&gt; 
  &gt; &gt; &gt; <BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; 
  &gt; &gt; <BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; &gt; &gt; <BR>&gt; &gt; &gt; 
  &gt; <BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; <BR><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_097F_01C995C7.934EB810--

From: Scott Baillie <[email-masked]>
To: [email-masked], "MIB Doctors (E-mail)" <[email-masked]>
Date: Tue, 24 Feb 2009 03:15:10 +1100
Cc: David B Harrington <[email-masked]>, Andy Bierman <[email-masked]>, Moti Morgenstern <[email-masked]>, Menachem Dodge <[email-masked]>, "Bert Wijnen \(IETF\)" <[email-masked]>
Subject: [Adslmib] The measurement tables in the VDSL2 MIB

Hi All,

There has been some confusion surrounding the measurement
tables in the VDSL2 MIB.
The tables that I am refering to are xdsl2LineSegmentTable and
the SCStatus tables xdsl2SCStatusTable, xdsl2SCStatusBandTable
and xdsl2SCStatusSegmentTable.

I would like to explain the intended purpose of these tables
and how they relate to each other.
After I have explained these tables, I am hoping the WG
will have a better understanding and will help me to
revise the deficencies in the descriptions that have
been pointed out.

SCStatus tables ( xdsl2SCStatus*Table )
---------------------------------------
The SCStatus tables hold the results of a line diagnostic test.
The line diagnostic test is initiated using the
xdsl2LineCmndConfLdsf object.
The XDSL line undergoing the test must first be placed
into the no power state ( L3 state ) prior to initiating
the test.

Dynamic measurement table (xdsl2LineSegmentTable)
-------------------------------------------------
The xdsl2LineSegmentTable holds the results of a
bits-per-subcarrier measurement.
The measurement is initiated using the xdsl2LineCmndConfBpsc
object.
The XDSL line undergoing the measurement must be in
the full power state ( L0 state ) prior to initiating
the test.

Relationship between measurement tables
---------------------------------------
The dynamic measurement table and the SCStatus tables are
independent.
The dynamic measurement is performed when the modems are in
sync ( showtime ) and customer data is being transmitted by
the modems.
The line diagnostic test is performed when the modems are in
no power mode ( L3 ) and no customer data is being transmitted.
These two measurement types are performed at different times
and each measurement type has its own results table and its
own initiation variable.
The thing that is in common with these tables is that both
measurement types will measure the bits-per-subcarrier value
but there is no "overloading" of meaning.

Request Counter (xdsl2LineCmndConfBpscReqCount)
-----------------------------------------------
There have been some question regarding the request
counter and what it is supposed to do so I would like
to explain the purpose of this object.
The purpose of the request counter is to protect the
integrity of the results table ( xdsl2LineSegmentTable )
in the presence of two SNMP managers.
We cannot guarantee that the measurement results can
be fetched atomically because fetching the results may
involve multiple SNMP GET requests ( see below for reason ).
If manager 1 fetches the results using multiple GET
requests then manager 2 can issue a SET request in the
middle of the GET requests.
The implication of this is that manager 1 has no guarantee
that the results fetched using multiple GET requests
belong to the same measurement event.
The request counter solves this problem by giving the
manager a guarantee that no new measurements were
initiated while reading back the measurement results.
The request counter starts at zero and counts up by one
every time a measurement request is initiated,
eventually it overflows to zero and then continues
counting up.

Multiple PDU's are required to fetch the results
------------------------------------------------
The results from the measurement can be very large
and dont fit into a single SNMP PDU. Given that
the MTU for ethernet is 1500, we have ensured that
no single MIB object is larger than 1024 octets.
Note that the measurement tables all have a 'segment'
index which allow the MIB to store data objects
that are larger than 1024 octets.

Any comments or suggestions would be most helpful
as I am in the process of revising the MIB text.

Regards,

Scott.

From: "David B Harrington" <[email-masked]>
To: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, "'Scott Baillie'" <[email-masked]>
Date: Mon, 23 Feb 2009 08:44:04 -0500
Cc: [email-masked], 'Menachem Dodge' <[email-masked]>, "'MIB Doctors \(E-mail\)'" <[email-masked]>, "'Bert Wijnen \(IETF\)'" <[email-masked]>, 'Andy Bierman' <[email-masked]>, 'Moti Morgenstern' <[email-masked]>
Subject: Re: [Adslmib] [MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hi,

The WG obviously did consider this issue, then made an engineering
decision.
I think they have made a reasonable case for using their TCs. 
I think we should back off and let them publish with their TCs.

dbh

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Monday, February 23, 2009 5:40 AM
> To: Scott Baillie
> Cc: [email-masked]; Andy Bierman; Bert Wijnen (IETF); David 
> B Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors (E-mail)
> Subject: RE: [Adslmib] [MIB-DOCTORS] AD 
> reviewofdraft-ietf-adslmib-vdsl2-06.txt
> 
> Hi Scott,
> 
> See in-line. 
> 
> Thanks and Regards,
> 
> Dan
>  
> 
> > -----Original Message-----
> > From: Scott Baillie [mailto:[email-masked]] 
> > Sent: Sunday, February 22, 2009 8:42 PM
> > To: Romascanu, Dan (Dan)
> > Cc: [email-masked]; Andy Bierman; Bert Wijnen (IETF); David 
> > B Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors
(E-mail)
> > Subject: RE: [Adslmib] [MIB-DOCTORS] AD 
> > reviewofdraft-ietf-adslmib-vdsl2-06.txt
> > 
> > Hi Dan,
> > 
> > A few extra comments in line below :
> > 
> > On Sun, 2009-02-22 at 14:49 +0100, Romascanu, Dan (Dan) wrote:
> > > Hi Scott,
> > > 
> > > A few comments and clarification questions: 
> > > 
> > > > Our choice of
> > > > using a TC rather than a TruthValue does not 
> significantly impact 
> > > > the NMS developer.
> > > 
> > > Well, it does add the need to support a new TC, rather than the 
> > > TruthValue TC which is already supported by any management 
> > application.
> > > There should be good reasons to do it. 
> > SAB : I feel this argument is a little exaggerated because NMS
> >     : developers already have to support standard types and
> >     : user defined types in any given MIB.
> >     : Adding a few extra TC's to this MIB does not
> >     : significantly increase the task for NMS developers.
> >     : We believe that keeping the MIB values in line with
> >     : the source document is an important enough reason 
> >     : to define our own TC.
> 
> We disagree.
> 
> The chances of a network operator to read a source document from
ITU-T
> is relatively low. On the other hand, operators need to 
> manage multiple
> technologies, not only DSL, so the need for consistency in
terminology
> works in the opposite direction than the one that you are
supporting. 
> 
> 
> > > 
> > > > If we cannot guarantee that the MIB values are the same as the

> > > > values specified in the source document then I believe 
> that this 
> > > > will lead to negative consequences that are worse than 
> > the minor sin 
> > > > of using a TC instead of TruthValue.
> > > 
> > > Can you explain this? What are the negative consequences? 
> > SAB : There is the potential for negative consequences if a
> >     : translation is required between the values in the MIB
> >     : and the source document. On every parameter in the
> >     : VDSL2 MIB we reference the corresponding parameter in
> >     : the ITU document.
> >     : Readers come to expect that the parameters
> >     : defined in the ITU document are the same ones that
> >     : are defined in the MIB. If we use the TruthValue type
> >     : as suggested then 98% of the MIB will be identical to
> >     : the source document and 2% of the MIB values will require
> >     : an arbitrary translation.
> >     : The intention of the authors is to have a direct mapping
> >     : between the source document and the MIB.
> >     : The ITU document has been adopted widely by Vendors and
> >     : there are many solutions available that comply with the ITU
> >     : specification such as XDSL chip sets and software stacks.
> >     : If we keep the MIB identical to the ITU document then
> >     : no translation is required between these compliant systems
> >     : and a single document is all that is required to understand
> >     : them all.
> > > 
> > > > The source document ( G.997.1 ) is a work in progress 
> and can be 
> > > > revised in subsequent publications. It is permissible 
> to add new 
> > > > enumerated values at the end of an existing enumerated 
> > type because 
> > > > this type of change is backward compatible. If the ITU 
> add a new 
> > > > enumerated value to an existing boolean parameter then we 
> > would be 
> > > > forced to change the type from TruthValue to a TC which 
> > would have 
> > > > negative consequences for NMS developers.
> > > 
> > > This would be indeed a strong argument in favor of using 
> another TC 
> > > than TruthValue. I do not see however how this argument 
> applies to 
> > > Xdsl2LineSnrMode (can any other state than virtual noise 
> enabled or 
> > > disabled ever exist?) and to Xdsl2LineReset (which seems 
> to have two
> > > states: reset or idle = no reset). How could these two be 
> > extended in 
> > > the future?
> > SAB : We are not the authors of the source document so we cannot
> >     : make any guarantees on their behalf and we cannot anticipate
> >     : how the ITU document may be changed in the future.
> >     : I agree that several of the parameters appear to be boolean
> >     : in nature.
> >     : If the ITU document uses names like 'reset' and 'idle' then
> >     : I would prefer to keep those names rather than replace them
> >     : with 'true' and 'false'. The ITU names carry more meaning
> >     : and they provide a common vocabulary that can be used and
> >     : understood by anyone that implements solutions based on
> >     : the source document.
> 
> What is the semantics of 'idle' that would be lost? 
> 
> I do not hear a strong argument for new TCs, but an 
> acknowledgement that
> ' that several of the parameters appear to be boolean in nature'. My
> recommendation is to take out these TCs and change the SYNTAX of the
> respective objects in the next version of the document to
TruthValue. 
> 
> 
> > > 
> > > Thanks and Regards,
> > > 
> > > Dan
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Scott Baillie [mailto:[email-masked]]
> > > > Sent: Sunday, February 22, 2009 2:58 PM
> > > > To: [email-masked]
> > > > Cc: Andy Bierman; Bert Wijnen (IETF); David B Harrington; 
> > 'Menachem 
> > > > Dodge'; 'Moti Morgenstern'; Romascanu, Dan (Dan); MIB Doctors 
> > > > (E-mail)
> > > > Subject: Re: [Adslmib] [MIB-DOCTORS] AD review 
> > > > ofdraft-ietf-adslmib-vdsl2-06.txt
> > > > 
> > > > Hi All,
> > > > 
> > > > As one of the draft MIB editors I thought I would chime 
> in on the 
> > > > issue of the use of the TruthValue type for boolean
parameters.
> > > > 
> > > > I agree that the use of primitive data types where 
> possible is a 
> > > > desirable thing. I also agree that defining a new type that is

> > > > equivalent to an existing primitive type is undesirable.
> > > > In the case of the VDSL2 MIB, there is a reason why the 
> > MIB authors 
> > > > have chosen to define a new type rather than use a 
> > standard type ( 
> > > > see below ).
> > > > 
> > > > I do not entirely agree with the position put forward 
> by David ( 
> > > > 2009-Feb-16 ) regarding NMS developers.
> > > > NMS developers have to support standard data types and new
data 
> > > > types ( TC's ) when dealing with any MIB. Our choice of 
> > using a TC 
> > > > rather than a TruthValue does not significantly impact the NMS

> > > > developer.
> > > > 
> > > > Also, the long section in David's message regarding 
> > interoperability 
> > > > of the SNMP protocol is a way overblown response to our 
> > minor sin of 
> > > > using a TC rather than a TruthValue. Our choice of using 
> > a TC does 
> > > > not diminish the vendor-neutral, and
managed-technology-neutral 
> > > > nature of the SNMP protocol.
> > > > 
> > > > I would like to state the 2 main reasons why we chose 
> to define a 
> > > > new TC rather than use a standard TruthValue type.
> > > > 
> > > > 
> > > > Reason 1
> > > > --------
> > > > The VDSL2 MIB is largely based on the ITU document G.997.1.
> > > > The ITU document specifies all of the VDSL2 management 
> parameters 
> > > > and their values. At the moment, the current VDSL2 
> draft exactly 
> > > > matches all of the parameters in the ITU document and exactly 
> > > > matches all of their values. This is a huge advantage, it 
> > means that 
> > > > there is one source document you can turn to when managing
XDSL 
> > > > technology.
> > > > If we were to use the TruthValue type as suggested then 
> we would 
> > > > lose the tight coupling between the source document (
> > > > G.997.1 ) and the SNMP MIB that we currently enjoy.
> > > > If we cannot guarantee that the MIB values are the same as the

> > > > values specified in the source document then I believe 
> that this 
> > > > will lead to negative consequences that are worse than 
> > the minor sin 
> > > > of using a TC instead of TruthValue.
> > > > 
> > > > 
> > > > Reason 2
> > > > --------
> > > > The source document ( G.997.1 ) is a work in progress 
> and can be 
> > > > revised in subsequent publications. It is permissible 
> to add new 
> > > > enumerated values at the end of an existing enumerated 
> > type because 
> > > > this type of change is backward compatible. If the ITU 
> add a new 
> > > > enumerated value to an existing boolean parameter then we 
> > would be 
> > > > forced to change the type from TruthValue to a TC which 
> > would have 
> > > > negative consequences for NMS developers.
> > > > 
> > > > 
> > > > Summary
> > > > -------
> > > > We recognise that the use of standard types is preferable
> > > > where possible but in the case of the VDSL2 MIB, the
advantages
> > > > of having the MIB identical to the source document far
> > > > out weigh the advantages of using standard types.
> > > > 
> > > > 
> > > > 
> > > > Regards,
> > > > 
> > > > Scott.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > 
> > 
> 

From: Menachem Dodge <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 25 Feb 2009 20:38:28 +0200
Accept-Language: en-US
acceptlanguage: en-US
Subject: [Adslmib] FW: [MIB-DOCTORS] AD	reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hi All,

As Dan has requested, your opinions regarding the issue of using a TC rather than a TruthValue, would be highly appreciated.

Thank you kindly.
Menachem

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, February 23, 2009 3:50 PM
To: David B Harrington; Scott Baillie
Cc: [email-masked]; Menachem Dodge; MIB Doctors (E-mail); Bert Wijnen (IETF); Andy Bierman; Moti Morgenstern
Subject: Re: [Adslmib] [MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

I would be interested to hear if there are other opinions from the ADSL
MIB Working Group, excluding the editors. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]] 
> Sent: Monday, February 23, 2009 3:44 PM
> To: Romascanu, Dan (Dan); 'Scott Baillie'
> Cc: [email-masked]; 'Andy Bierman'; 'Bert Wijnen (IETF)'; 
> 'Menachem Dodge'; 'Moti Morgenstern'; 'MIB Doctors (E-mail)'
> Subject: RE: [Adslmib] [MIB-DOCTORS] AD 
> reviewofdraft-ietf-adslmib-vdsl2-06.txt
> 
> Hi,
> 
> The WG obviously did consider this issue, then made an 
> engineering decision.
> I think they have made a reasonable case for using their TCs. 
> I think we should back off and let them publish with their TCs.
> 
> dbh
> 
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> > Sent: Monday, February 23, 2009 5:40 AM
> > To: Scott Baillie
> > Cc: [email-masked]; Andy Bierman; Bert Wijnen (IETF); David B 
> > Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors (E-mail)
> > Subject: RE: [Adslmib] [MIB-DOCTORS] AD 
> > reviewofdraft-ietf-adslmib-vdsl2-06.txt
> > 
> > Hi Scott,
> > 
> > See in-line. 
> > 
> > Thanks and Regards,
> > 
> > Dan
> >  
> > 
> > > -----Original Message-----
> > > From: Scott Baillie [mailto:[email-masked]]
> > > Sent: Sunday, February 22, 2009 8:42 PM
> > > To: Romascanu, Dan (Dan)
> > > Cc: [email-masked]; Andy Bierman; Bert Wijnen (IETF); David B 
> > > Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors
> (E-mail)
> > > Subject: RE: [Adslmib] [MIB-DOCTORS] AD 
> > > reviewofdraft-ietf-adslmib-vdsl2-06.txt
> > > 
> > > Hi Dan,
> > > 
> > > A few extra comments in line below :
> > > 
> > > On Sun, 2009-02-22 at 14:49 +0100, Romascanu, Dan (Dan) wrote:
> > > > Hi Scott,
> > > > 
> > > > A few comments and clarification questions: 
> > > > 
> > > > > Our choice of
> > > > > using a TC rather than a TruthValue does not
> > significantly impact
> > > > > the NMS developer.
> > > > 
> > > > Well, it does add the need to support a new TC, rather than the 
> > > > TruthValue TC which is already supported by any management
> > > application.
> > > > There should be good reasons to do it. 
> > > SAB : I feel this argument is a little exaggerated because NMS
> > >     : developers already have to support standard types and
> > >     : user defined types in any given MIB.
> > >     : Adding a few extra TC's to this MIB does not
> > >     : significantly increase the task for NMS developers.
> > >     : We believe that keeping the MIB values in line with
> > >     : the source document is an important enough reason 
> > >     : to define our own TC.
> > 
> > We disagree.
> > 
> > The chances of a network operator to read a source document from
> ITU-T
> > is relatively low. On the other hand, operators need to manage 
> > multiple technologies, not only DSL, so the need for consistency in
> terminology
> > works in the opposite direction than the one that you are
> supporting. 
> > 
> > 
> > > > 
> > > > > If we cannot guarantee that the MIB values are the same as the
> 
> > > > > values specified in the source document then I believe
> > that this
> > > > > will lead to negative consequences that are worse than
> > > the minor sin
> > > > > of using a TC instead of TruthValue.
> > > > 
> > > > Can you explain this? What are the negative consequences? 
> > > SAB : There is the potential for negative consequences if a
> > >     : translation is required between the values in the MIB
> > >     : and the source document. On every parameter in the
> > >     : VDSL2 MIB we reference the corresponding parameter in
> > >     : the ITU document.
> > >     : Readers come to expect that the parameters
> > >     : defined in the ITU document are the same ones that
> > >     : are defined in the MIB. If we use the TruthValue type
> > >     : as suggested then 98% of the MIB will be identical to
> > >     : the source document and 2% of the MIB values will require
> > >     : an arbitrary translation.
> > >     : The intention of the authors is to have a direct mapping
> > >     : between the source document and the MIB.
> > >     : The ITU document has been adopted widely by Vendors and
> > >     : there are many solutions available that comply with the ITU
> > >     : specification such as XDSL chip sets and software stacks.
> > >     : If we keep the MIB identical to the ITU document then
> > >     : no translation is required between these compliant systems
> > >     : and a single document is all that is required to understand
> > >     : them all.
> > > > 
> > > > > The source document ( G.997.1 ) is a work in progress
> > and can be
> > > > > revised in subsequent publications. It is permissible
> > to add new
> > > > > enumerated values at the end of an existing enumerated
> > > type because
> > > > > this type of change is backward compatible. If the ITU
> > add a new
> > > > > enumerated value to an existing boolean parameter then we
> > > would be
> > > > > forced to change the type from TruthValue to a TC which
> > > would have
> > > > > negative consequences for NMS developers.
> > > > 
> > > > This would be indeed a strong argument in favor of using
> > another TC
> > > > than TruthValue. I do not see however how this argument
> > applies to
> > > > Xdsl2LineSnrMode (can any other state than virtual noise
> > enabled or
> > > > disabled ever exist?) and to Xdsl2LineReset (which seems
> > to have two
> > > > states: reset or idle = no reset). How could these two be
> > > extended in
> > > > the future?
> > > SAB : We are not the authors of the source document so we cannot
> > >     : make any guarantees on their behalf and we cannot anticipate
> > >     : how the ITU document may be changed in the future.
> > >     : I agree that several of the parameters appear to be boolean
> > >     : in nature.
> > >     : If the ITU document uses names like 'reset' and 'idle' then
> > >     : I would prefer to keep those names rather than replace them
> > >     : with 'true' and 'false'. The ITU names carry more meaning
> > >     : and they provide a common vocabulary that can be used and
> > >     : understood by anyone that implements solutions based on
> > >     : the source document.
> > 
> > What is the semantics of 'idle' that would be lost? 
> > 
> > I do not hear a strong argument for new TCs, but an acknowledgement 
> > that ' that several of the parameters appear to be boolean 
> in nature'. 
> > My recommendation is to take out these TCs and change the SYNTAX of 
> > the respective objects in the next version of the document to
> TruthValue. 
> > 
> > 
> > > > 
> > > > Thanks and Regards,
> > > > 
> > > > Dan
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Scott Baillie [mailto:[email-masked]]
> > > > > Sent: Sunday, February 22, 2009 2:58 PM
> > > > > To: [email-masked]
> > > > > Cc: Andy Bierman; Bert Wijnen (IETF); David B Harrington;
> > > 'Menachem
> > > > > Dodge'; 'Moti Morgenstern'; Romascanu, Dan (Dan); MIB Doctors
> > > > > (E-mail)
> > > > > Subject: Re: [Adslmib] [MIB-DOCTORS] AD review 
> > > > > ofdraft-ietf-adslmib-vdsl2-06.txt
> > > > > 
> > > > > Hi All,
> > > > > 
> > > > > As one of the draft MIB editors I thought I would chime
> > in on the
> > > > > issue of the use of the TruthValue type for boolean
> parameters.
> > > > > 
> > > > > I agree that the use of primitive data types where
> > possible is a
> > > > > desirable thing. I also agree that defining a new type that is
> 
> > > > > equivalent to an existing primitive type is undesirable.
> > > > > In the case of the VDSL2 MIB, there is a reason why the 
> > > MIB authors 
> > > > > have chosen to define a new type rather than use a 
> > > standard type ( 
> > > > > see below ).
> > > > > 
> > > > > I do not entirely agree with the position put forward 
> > by David ( 
> > > > > 2009-Feb-16 ) regarding NMS developers.
> > > > > NMS developers have to support standard data types and new
> data 
> > > > > types ( TC's ) when dealing with any MIB. Our choice of 
> > > using a TC 
> > > > > rather than a TruthValue does not significantly impact the NMS
> 
> > > > > developer.
> > > > > 
> > > > > Also, the long section in David's message regarding 
> > > interoperability 
> > > > > of the SNMP protocol is a way overblown response to our 
> > > minor sin of 
> > > > > using a TC rather than a TruthValue. Our choice of using 
> > > a TC does 
> > > > > not diminish the vendor-neutral, and
> managed-technology-neutral 
> > > > > nature of the SNMP protocol.
> > > > > 
> > > > > I would like to state the 2 main reasons why we chose 
> > to define a 
> > > > > new TC rather than use a standard TruthValue type.
> > > > > 
> > > > > 
> > > > > Reason 1
> > > > > --------
> > > > > The VDSL2 MIB is largely based on the ITU document G.997.1.
> > > > > The ITU document specifies all of the VDSL2 management 
> > parameters 
> > > > > and their values. At the moment, the current VDSL2 
> > draft exactly 
> > > > > matches all of the parameters in the ITU document and exactly 
> > > > > matches all of their values. This is a huge advantage, it 
> > > means that 
> > > > > there is one source document you can turn to when managing
> XDSL 
> > > > > technology.
> > > > > If we were to use the TruthValue type as suggested then 
> > we would 
> > > > > lose the tight coupling between the source document (
> > > > > G.997.1 ) and the SNMP MIB that we currently enjoy.
> > > > > If we cannot guarantee that the MIB values are the same as the
> 
> > > > > values specified in the source document then I believe 
> > that this 
> > > > > will lead to negative consequences that are worse than 
> > > the minor sin 
> > > > > of using a TC instead of TruthValue.
> > > > > 
> > > > > 
> > > > > Reason 2
> > > > > --------
> > > > > The source document ( G.997.1 ) is a work in progress 
> > and can be 
> > > > > revised in subsequent publications. It is permissible 
> > to add new 
> > > > > enumerated values at the end of an existing enumerated 
> > > type because 
> > > > > this type of change is backward compatible. If the ITU 
> > add a new 
> > > > > enumerated value to an existing boolean parameter then we 
> > > would be 
> > > > > forced to change the type from TruthValue to a TC which 
> > > would have 
> > > > > negative consequences for NMS developers.
> > > > > 
> > > > > 
> > > > > Summary
> > > > > -------
> > > > > We recognise that the use of standard types is preferable
> > > > > where possible but in the case of the VDSL2 MIB, the
> advantages
> > > > > of having the MIB identical to the source document far
> > > > > out weigh the advantages of using standard types.
> > > > > 
> > > > > 
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Scott.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > 
> > > 
> > 
> 
> 
_______________________________________________
Adslmib mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/adslmib

From: Victor Sperry <[email-masked]>
To: Menachem Dodge <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 25 Feb 2009 11:09:55 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Adslmib] FW: [MIB-DOCTORS]	AD	reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hello Manachem et al,

For years, I have written software for xDSL access equipment. I have written xDSL drivers and xDSL middleware for DSLAMs and multi-service access equipment such as the Paradyne 8820 DSLAM, Zhone Malc, and Calix C7. So my perspective is that of somebody who has to marry MIBs to xDSL chip vendors' API. I have never been an NMS developer.

This is what I see as important, from most important to least important.
1. Ratify and publish the VDSL2 MIB as an RFC.
2. Have the MIB match G.997.1 as much as possible.
3. Simplify the MIB, because it is extremely time-consuming to understand, let alone implement.
4. Use TruthValues instead of TCs.

I see the TruthValue vs TC argument as being akin to arguing over whether or not a developer has followed corporate coding standards. It is a valid concern, but not so important that it should delay the ratification of the document which has been fairly stable for over a year now.

And for what it's worth, I realize that my concerns #2 and #3 are at odds with each other. #2 is more important than #3.

Vic Sperry
Calix Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Menachem Dodge
Sent: Wednesday, February 25, 2009 10:38 AM
To: [email-masked]
Subject: [Adslmib] FW: [MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hi All,

As Dan has requested, your opinions regarding the issue of using a TC rather than a TruthValue, would be highly appreciated.

Thank you kindly.
Menachem

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, February 23, 2009 3:50 PM
To: David B Harrington; Scott Baillie
Cc: [email-masked]; Menachem Dodge; MIB Doctors (E-mail); Bert Wijnen (IETF); Andy Bierman; Moti Morgenstern
Subject: Re: [Adslmib] [MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

I would be interested to hear if there are other opinions from the ADSL
MIB Working Group, excluding the editors.

Thanks and Regards,

Dan

> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]]
> Sent: Monday, February 23, 2009 3:44 PM
> To: Romascanu, Dan (Dan); 'Scott Baillie'
> Cc: [email-masked]; 'Andy Bierman'; 'Bert Wijnen (IETF)';
> 'Menachem Dodge'; 'Moti Morgenstern'; 'MIB Doctors (E-mail)'
> Subject: RE: [Adslmib] [MIB-DOCTORS] AD
> reviewofdraft-ietf-adslmib-vdsl2-06.txt
>
> Hi,
>
> The WG obviously did consider this issue, then made an
> engineering decision.
> I think they have made a reasonable case for using their TCs.
> I think we should back off and let them publish with their TCs.
>
> dbh
>
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> > Sent: Monday, February 23, 2009 5:40 AM
> > To: Scott Baillie
> > Cc: [email-masked]; Andy Bierman; Bert Wijnen (IETF); David B
> > Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors (E-mail)
> > Subject: RE: [Adslmib] [MIB-DOCTORS] AD
> > reviewofdraft-ietf-adslmib-vdsl2-06.txt
> >
> > Hi Scott,
> >
> > See in-line.
> >
> > Thanks and Regards,
> >
> > Dan
> >
> >
> > > -----Original Message-----
> > > From: Scott Baillie [mailto:[email-masked]]
> > > Sent: Sunday, February 22, 2009 8:42 PM
> > > To: Romascanu, Dan (Dan)
> > > Cc: [email-masked]; Andy Bierman; Bert Wijnen (IETF); David B
> > > Harrington; Menachem Dodge; Moti Morgenstern; MIB Doctors
> (E-mail)
> > > Subject: RE: [Adslmib] [MIB-DOCTORS] AD
> > > reviewofdraft-ietf-adslmib-vdsl2-06.txt
> > >
> > > Hi Dan,
> > >
> > > A few extra comments in line below :
> > >
> > > On Sun, 2009-02-22 at 14:49 +0100, Romascanu, Dan (Dan) wrote:
> > > > Hi Scott,
> > > >
> > > > A few comments and clarification questions:
> > > >
> > > > > Our choice of
> > > > > using a TC rather than a TruthValue does not
> > significantly impact
> > > > > the NMS developer.
> > > >
> > > > Well, it does add the need to support a new TC, rather than the
> > > > TruthValue TC which is already supported by any management
> > > application.
> > > > There should be good reasons to do it.
> > > SAB : I feel this argument is a little exaggerated because NMS
> > >     : developers already have to support standard types and
> > >     : user defined types in any given MIB.
> > >     : Adding a few extra TC's to this MIB does not
> > >     : significantly increase the task for NMS developers.
> > >     : We believe that keeping the MIB values in line with
> > >     : the source document is an important enough reason
> > >     : to define our own TC.
> >
> > We disagree.
> >
> > The chances of a network operator to read a source document from
> ITU-T
> > is relatively low. On the other hand, operators need to manage
> > multiple technologies, not only DSL, so the need for consistency in
> terminology
> > works in the opposite direction than the one that you are
> supporting.
> >
> >
> > > >
> > > > > If we cannot guarantee that the MIB values are the same as the
>
> > > > > values specified in the source document then I believe
> > that this
> > > > > will lead to negative consequences that are worse than
> > > the minor sin
> > > > > of using a TC instead of TruthValue.
> > > >
> > > > Can you explain this? What are the negative consequences?
> > > SAB : There is the potential for negative consequences if a
> > >     : translation is required between the values in the MIB
> > >     : and the source document. On every parameter in the
> > >     : VDSL2 MIB we reference the corresponding parameter in
> > >     : the ITU document.
> > >     : Readers come to expect that the parameters
> > >     : defined in the ITU document are the same ones that
> > >     : are defined in the MIB. If we use the TruthValue type
> > >     : as suggested then 98% of the MIB will be identical to
> > >     : the source document and 2% of the MIB values will require
> > >     : an arbitrary translation.
> > >     : The intention of the authors is to have a direct mapping
> > >     : between the source document and the MIB.
> > >     : The ITU document has been adopted widely by Vendors and
> > >     : there are many solutions available that comply with the ITU
> > >     : specification such as XDSL chip sets and software stacks.
> > >     : If we keep the MIB identical to the ITU document then
> > >     : no translation is required between these compliant systems
> > >     : and a single document is all that is required to understand
> > >     : them all.
> > > >
> > > > > The source document ( G.997.1 ) is a work in progress
> > and can be
> > > > > revised in subsequent publications. It is permissible
> > to add new
> > > > > enumerated values at the end of an existing enumerated
> > > type because
> > > > > this type of change is backward compatible. If the ITU
> > add a new
> > > > > enumerated value to an existing boolean parameter then we
> > > would be
> > > > > forced to change the type from TruthValue to a TC which
> > > would have
> > > > > negative consequences for NMS developers.
> > > >
> > > > This would be indeed a strong argument in favor of using
> > another TC
> > > > than TruthValue. I do not see however how this argument
> > applies to
> > > > Xdsl2LineSnrMode (can any other state than virtual noise
> > enabled or
> > > > disabled ever exist?) and to Xdsl2LineReset (which seems
> > to have two
> > > > states: reset or idle = no reset). How could these two be
> > > extended in
> > > > the future?
> > > SAB : We are not the authors of the source document so we cannot
> > >     : make any guarantees on their behalf and we cannot anticipate
> > >     : how the ITU document may be changed in the future.
> > >     : I agree that several of the parameters appear to be boolean
> > >     : in nature.
> > >     : If the ITU document uses names like 'reset' and 'idle' then
> > >     : I would prefer to keep those names rather than replace them
> > >     : with 'true' and 'false'. The ITU names carry more meaning
> > >     : and they provide a common vocabulary that can be used and
> > >     : understood by anyone that implements solutions based on
> > >     : the source document.
> >
> > What is the semantics of 'idle' that would be lost?
> >
> > I do not hear a strong argument for new TCs, but an acknowledgement
> > that ' that several of the parameters appear to be boolean
> in nature'.
> > My recommendation is to take out these TCs and change the SYNTAX of
> > the respective objects in the next version of the document to
> TruthValue.
> >
> >
> > > >
> > > > Thanks and Regards,
> > > >
> > > > Dan
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Scott Baillie [mailto:[email-masked]]
> > > > > Sent: Sunday, February 22, 2009 2:58 PM
> > > > > To: [email-masked]
> > > > > Cc: Andy Bierman; Bert Wijnen (IETF); David B Harrington;
> > > 'Menachem
> > > > > Dodge'; 'Moti Morgenstern'; Romascanu, Dan (Dan); MIB Doctors
> > > > > (E-mail)
> > > > > Subject: Re: [Adslmib] [MIB-DOCTORS] AD review
> > > > > ofdraft-ietf-adslmib-vdsl2-06.txt
> > > > >
> > > > > Hi All,
> > > > >
> > > > > As one of the draft MIB editors I thought I would chime
> > in on the
> > > > > issue of the use of the TruthValue type for boolean
> parameters.
> > > > >
> > > > > I agree that the use of primitive data types where
> > possible is a
> > > > > desirable thing. I also agree that defining a new type that is
>
> > > > > equivalent to an existing primitive type is undesirable.
> > > > > In the case of the VDSL2 MIB, there is a reason why the
> > > MIB authors
> > > > > have chosen to define a new type rather than use a
> > > standard type (
> > > > > see below ).
> > > > >
> > > > > I do not entirely agree with the position put forward
> > by David (
> > > > > 2009-Feb-16 ) regarding NMS developers.
> > > > > NMS developers have to support standard data types and new
> data
> > > > > types ( TC's ) when dealing with any MIB. Our choice of
> > > using a TC
> > > > > rather than a TruthValue does not significantly impact the NMS
>
> > > > > developer.
> > > > >
> > > > > Also, the long section in David's message regarding
> > > interoperability
> > > > > of the SNMP protocol is a way overblown response to our
> > > minor sin of
> > > > > using a TC rather than a TruthValue. Our choice of using
> > > a TC does
> > > > > not diminish the vendor-neutral, and
> managed-technology-neutral
> > > > > nature of the SNMP protocol.
> > > > >
> > > > > I would like to state the 2 main reasons why we chose
> > to define a
> > > > > new TC rather than use a standard TruthValue type.
> > > > >
> > > > >
> > > > > Reason 1
> > > > > --------
> > > > > The VDSL2 MIB is largely based on the ITU document G.997.1.
> > > > > The ITU document specifies all of the VDSL2 management
> > parameters
> > > > > and their values. At the moment, the current VDSL2
> > draft exactly
> > > > > matches all of the parameters in the ITU document and exactly
> > > > > matches all of their values. This is a huge advantage, it
> > > means that
> > > > > there is one source document you can turn to when managing
> XDSL
> > > > > technology.
> > > > > If we were to use the TruthValue type as suggested then
> > we would
> > > > > lose the tight coupling between the source document (
> > > > > G.997.1 ) and the SNMP MIB that we currently enjoy.
> > > > > If we cannot guarantee that the MIB values are the same as the
>
> > > > > values specified in the source document then I believe
> > that this
> > > > > will lead to negative consequences that are worse than
> > > the minor sin
> > > > > of using a TC instead of TruthValue.
> > > > >
> > > > >
> > > > > Reason 2
> > > > > --------
> > > > > The source document ( G.997.1 ) is a work in progress
> > and can be
> > > > > revised in subsequent publications. It is permissible
> > to add new
> > > > > enumerated values at the end of an existing enumerated
> > > type because
> > > > > this type of change is backward compatible. If the ITU
> > add a new
> > > > > enumerated value to an existing boolean parameter then we
> > > would be
> > > > > forced to change the type from TruthValue to a TC which
> > > would have
> > > > > negative consequences for NMS developers.
> > > > >
> > > > >
> > > > > Summary
> > > > > -------
> > > > > We recognise that the use of standard types is preferable
> > > > > where possible but in the case of the VDSL2 MIB, the
> advantages
> > > > > of having the MIB identical to the source document far
> > > > > out weigh the advantages of using standard types.
> > > > >
> > > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Scott.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> >
>
>
_______________________________________________
Adslmib mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/adslmib
_______________________________________________
Adslmib mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/adslmib

Content-class: urn:content-classes:message
Date: Wed, 25 Feb 2009 21:13:55 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Victor Sperry" <[email-masked]>, "Menachem Dodge" <[email-masked]>, <[email-masked]>
Subject: Re: [Adslmib] FW:[MIB-DOCTORS]	AD	reviewofdraft-ietf-adslmib-vdsl2-06.txt

This is a multi-part message in MIME format.

------_=_NextPart_001_01C99786.1A262A77
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Victor,

Thank you for your feedback. I am glad to hear that people implementing agents in this space participate in this work. I have a question not directly related to the question asked by Menachem. What is your opinion about the size of this MIB module and its implementability on agents?  

Thanks and Regards,

Dan

-----Original Message-----
From: [email-masked] on behalf of Victor Sperry
Sent: Wed 2/25/2009 9:09 PM
To: Menachem Dodge; [email-masked]
Subject: Re: [Adslmib] FW:[MIB-DOCTORS]	AD	reviewofdraft-ietf-adslmib-vdsl2-06.txt
 
Hello Manachem et al,

For years, I have written software for xDSL access equipment. I have written xDSL drivers and xDSL middleware for DSLAMs and multi-service access equipment such as the Paradyne 8820 DSLAM, Zhone Malc, and Calix C7. So my perspective is that of somebody who has to marry MIBs to xDSL chip vendors' API. I have never been an NMS developer.

This is what I see as important, from most important to least important.
1. Ratify and publish the VDSL2 MIB as an RFC.
2. Have the MIB match G.997.1 as much as possible.
3. Simplify the MIB, because it is extremely time-consuming to understand, let alone implement.
4. Use TruthValues instead of TCs.

I see the TruthValue vs TC argument as being akin to arguing over whether or not a developer has followed corporate coding standards. It is a valid concern, but not so important that it should delay the ratification of the document which has been fairly stable for over a year now.

And for what it's worth, I realize that my concerns #2 and #3 are at odds with each other. #2 is more important than #3.

Vic Sperry
Calix Networks

------_=_NextPart_001_01C99786.1A262A77
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>RE: [Adslmib] FW:[MIB-DOCTORS]	AD	reviewofdraft-ietf-adslmib-vdsl2-06.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>Hi Victor,<BR>
<BR>
Thank you for your feedback. I am glad to hear that people implementing agents in this space participate in this work. I have a question not directly related to the question asked by Menachem. What is your opinion about the size of this MIB module and its implementability on agents?&nbsp;<BR>
<BR>
Thanks and Regards,<BR>
<BR>
Dan<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of Victor Sperry<BR>
Sent: Wed 2/25/2009 9:09 PM<BR>
To: Menachem Dodge; [email-masked]<BR>
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reviewofdraft-ietf-adslmib-vdsl2-06.txt<BR>
<BR>
Hello Manachem et al,<BR>
<BR>
For years, I have written software for xDSL access equipment. I have written xDSL drivers and xDSL middleware for DSLAMs and multi-service access equipment such as the Paradyne 8820 DSLAM, Zhone Malc, and Calix C7. So my perspective is that of somebody who has to marry MIBs to xDSL chip vendors' API. I have never been an NMS developer.<BR>
<BR>
This is what I see as important, from most important to least important.<BR>
1. Ratify and publish the VDSL2 MIB as an RFC.<BR>
2. Have the MIB match G.997.1 as much as possible.<BR>
3. Simplify the MIB, because it is extremely time-consuming to understand, let alone implement.<BR>
4. Use TruthValues instead of TCs.<BR>
<BR>
I see the TruthValue vs TC argument as being akin to arguing over whether or not a developer has followed corporate coding standards. It is a valid concern, but not so important that it should delay the ratification of the document which has been fairly stable for over a year now.<BR>
<BR>
And for what it's worth, I realize that my concerns #2 and #3 are at odds with each other. #2 is more important than #3.<BR>
<BR>
Vic Sperry<BR>
Calix Networks<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C99786.1A262A77--

Content-class: urn:content-classes:message
Date: Wed, 25 Feb 2009 15:38:07 -0600
From: "Ray, Robert E. (MSFC-NNM05AB50C)" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: [Adslmib] FW: [MIB-DOCTORS]

>Hi All,
>
>As Dan has requested, your opinions regarding the issue of using a 
>TC rather than a TruthValue, would be highly appreciated.
>
>Thank you kindly.
>Menachem

My (pragmatic) thought:

Either way, some implementer will get it wrong.  

It if gets the document past the MIB Doctors, agree to the change (TC to
TruthValue) and move on.  

Regards,
Bob Ray

From: Victor Sperry <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>, Menachem Dodge <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 25 Feb 2009 14:04:56 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Adslmib] FW:[MIB-DOCTORS]	AD	reviewofdraft-ietf-adslmib-vdsl2-06.txt

--_000_B695476A22E88B4AB7D32915B4C81ED20DFB2009EDPETWMAIL1cali_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Dan,

Since you ask, I think the MIB is huge and in some cases impractical. For example I could not figure out how to implement xdsl2LineConfProfModeSpecTable for every possible value of xdsl2LConfProfXdslMode. Equipment vendors will select a subset of the MIB to implement. But I think it needs to be ratified. It doesn't need to be perfect in its first RFC form.

And for the record, I did not implement an SNMP agent. I used the MIB in a design as a chip-independent driver API. And also for the record, that approach turned out to be impractical due to time constraints and the need to remain compatible with older APIs already in our system.

Vic

From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Wednesday, February 25, 2009 12:14 PM
To: Victor Sperry; Menachem Dodge; [email-masked]
Subject: RE: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hi Victor,

Thank you for your feedback. I am glad to hear that people implementing agents in this space participate in this work. I have a question not directly related to the question asked by Menachem. What is your opinion about the size of this MIB module and its implementability on agents?

Thanks and Regards,

Dan

-----Original Message-----
From: [email-masked] on behalf of Victor Sperry
Sent: Wed 2/25/2009 9:09 PM
To: Menachem Dodge; [email-masked]
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD      reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hello Manachem et al,

For years, I have written software for xDSL access equipment. I have written xDSL drivers and xDSL middleware for DSLAMs and multi-service access equipment such as the Paradyne 8820 DSLAM, Zhone Malc, and Calix C7. So my perspective is that of somebody who has to marry MIBs to xDSL chip vendors' API. I have never been an NMS developer.

This is what I see as important, from most important to least important.
1. Ratify and publish the VDSL2 MIB as an RFC.
2. Have the MIB match G.997.1 as much as possible.
3. Simplify the MIB, because it is extremely time-consuming to understand, let alone implement.
4. Use TruthValues instead of TCs.

I see the TruthValue vs TC argument as being akin to arguing over whether or not a developer has followed corporate coding standards. It is a valid concern, but not so important that it should delay the ratification of the document which has been fairly stable for over a year now.

And for what it's worth, I realize that my concerns #2 and #3 are at odds with each other. #2 is more important than #3.

Vic Sperry
Calix Networks

--_000_B695476A22E88B4AB7D32915B4C81ED20DFB2009EDPETWMAIL1cali_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:D="DAV:" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="&#1;" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<title>RE: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi Dan,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Since you ask, I think the MIB is huge and in some cases impractical.
For example I could not figure out how to implement xdsl2LineConfProfModeSpecTable
for every possible value of xdsl2LConfProfXdslMode. Equipment vendors will
select a subset of the MIB to implement. But I think it needs to be ratified.
It doesn&#8217;t need to be perfect in its first RFC form.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>And for the record, I did not implement an SNMP agent. I used
the MIB in a design as a chip-independent driver API. And also for the record,
that approach turned out to be impractical due to time constraints and the need
to remain compatible with older APIs already in our system.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Vic<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Romascanu, Dan
(Dan) [mailto:[email-masked]] <br>
<b>Sent:</b> Wednesday, February 25, 2009 12:14 PM<br>
<b>To:</b> Victor Sperry; Menachem Dodge; [email-masked]<br>
<b>Subject:</b> RE: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p><span style='font-size:10.0pt'>Hi Victor,<br>
<br>
Thank you for your feedback. I am glad to hear that people implementing agents
in this space participate in this work. I have a question not directly related
to the question asked by Menachem. What is your opinion about the size of this
MIB module and its implementability on agents?&nbsp;<br>
<br>
Thanks and Regards,<br>
<br>
Dan<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: [email-masked] on behalf of Victor Sperry<br>
Sent: Wed 2/25/2009 9:09 PM<br>
To: Menachem Dodge; [email-masked]<br>
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reviewofdraft-ietf-adslmib-vdsl2-06.txt<br>
<br>
Hello Manachem et al,<br>
<br>
For years, I have written software for xDSL access equipment. I have written
xDSL drivers and xDSL middleware for DSLAMs and multi-service access equipment
such as the Paradyne 8820 DSLAM, Zhone Malc, and Calix C7. So my perspective is
that of somebody who has to marry MIBs to xDSL chip vendors' API. I have never
been an NMS developer.<br>
<br>
This is what I see as important, from most important to least important.<br>
1. Ratify and publish the VDSL2 MIB as an RFC.<br>
2. Have the MIB match G.997.1 as much as possible.<br>
3. Simplify the MIB, because it is extremely time-consuming to understand, let
alone implement.<br>
4. Use TruthValues instead of TCs.<br>
<br>
I see the TruthValue vs TC argument as being akin to arguing over whether or
not a developer has followed corporate coding standards. It is a valid concern,
but not so important that it should delay the ratification of the document
which has been fairly stable for over a year now.<br>
<br>
And for what it's worth, I realize that my concerns #2 and #3 are at odds with
each other. #2 is more important than #3.<br>
<br>
Vic Sperry<br>
Calix Networks</span><o:p></o:p></p>

</div>

</body>

</html>

--_000_B695476A22E88B4AB7D32915B4C81ED20DFB2009EDPETWMAIL1cali_--

From: Menachem Dodge <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 26 Feb 2009 09:58:22 +0200
Accept-Language: en-US
acceptlanguage: en-US
Subject: [Adslmib] Vdsl2 MIB

Hi All,

	Firstly, thanks to Victor and Robert for their comments on the Vdsl2 MIB.

	Scott was also looking for some feedback on the measurement tables, (see below) so would anyone like to express an opinion, it would be most appreciated as the editors are currently working on completing the next draft.

	Best Regards,
	Menachem

-----Original Message-----
From: Scott Baillie [mailto:[email-masked]] 
Sent: Monday, February 23, 2009 6:15 PM
To: [email-masked]; MIB Doctors (E-mail)
Cc: Romascanu, Dan (Dan); David B Harrington; Andy Bierman; Moti Morgenstern; Menachem Dodge; Bert Wijnen (IETF)
Subject: The measurement tables in the VDSL2 MIB

Hi All,

There has been some confusion surrounding the measurement
tables in the VDSL2 MIB.
The tables that I am refering to are xdsl2LineSegmentTable and
the SCStatus tables xdsl2SCStatusTable, xdsl2SCStatusBandTable
and xdsl2SCStatusSegmentTable.

I would like to explain the intended purpose of these tables
and how they relate to each other.
After I have explained these tables, I am hoping the WG
will have a better understanding and will help me to
revise the deficencies in the descriptions that have
been pointed out.

SCStatus tables ( xdsl2SCStatus*Table )
---------------------------------------
The SCStatus tables hold the results of a line diagnostic test.
The line diagnostic test is initiated using the
xdsl2LineCmndConfLdsf object.
The XDSL line undergoing the test must first be placed
into the no power state ( L3 state ) prior to initiating
the test.

Dynamic measurement table (xdsl2LineSegmentTable)
-------------------------------------------------
The xdsl2LineSegmentTable holds the results of a
bits-per-subcarrier measurement.
The measurement is initiated using the xdsl2LineCmndConfBpsc
object.
The XDSL line undergoing the measurement must be in
the full power state ( L0 state ) prior to initiating
the test.

Relationship between measurement tables
---------------------------------------
The dynamic measurement table and the SCStatus tables are
independent.
The dynamic measurement is performed when the modems are in
sync ( showtime ) and customer data is being transmitted by
the modems.
The line diagnostic test is performed when the modems are in
no power mode ( L3 ) and no customer data is being transmitted.
These two measurement types are performed at different times
and each measurement type has its own results table and its
own initiation variable.
The thing that is in common with these tables is that both
measurement types will measure the bits-per-subcarrier value
but there is no "overloading" of meaning.

Request Counter (xdsl2LineCmndConfBpscReqCount)
-----------------------------------------------
There have been some question regarding the request
counter and what it is supposed to do so I would like
to explain the purpose of this object.
The purpose of the request counter is to protect the
integrity of the results table ( xdsl2LineSegmentTable )
in the presence of two SNMP managers.
We cannot guarantee that the measurement results can
be fetched atomically because fetching the results may
involve multiple SNMP GET requests ( see below for reason ).
If manager 1 fetches the results using multiple GET
requests then manager 2 can issue a SET request in the
middle of the GET requests.
The implication of this is that manager 1 has no guarantee
that the results fetched using multiple GET requests
belong to the same measurement event.
The request counter solves this problem by giving the
manager a guarantee that no new measurements were
initiated while reading back the measurement results.
The request counter starts at zero and counts up by one
every time a measurement request is initiated,
eventually it overflows to zero and then continues
counting up.

Multiple PDU's are required to fetch the results
------------------------------------------------
The results from the measurement can be very large
and dont fit into a single SNMP PDU. Given that
the MTU for ethernet is 1500, we have ensured that
no single MIB object is larger than 1024 octets.
Note that the measurement tables all have a 'segment'
index which allow the MIB to store data objects
that are larger than 1024 octets.

Any comments or suggestions would be most helpful
as I am in the process of revising the MIB text.

Regards,

Scott.

From: Moti Morgenstern <[email-masked]>
To: Victor Sperry <[email-masked]>
Date: Thu, 26 Feb 2009 10:23:07 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, Menachem Dodge <[email-masked]>
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

--_000_741F3E4A466A1D439C616902C7F8A8C6D4D057DE98ILPTMAIL02eci_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Victor,

I agree that the MIB is relatively big and that's natural for equipment vendors to decide what tables they wish to implement in each phase of their product life. Sometimes it can also go down to a per attribute decision. For example, PM thresholds and notifications will not be the first sections you implement if you have a Time-To-Market problem because configuration is normally more important.

Regarding to the mode-specific configuration, you actually touched a very good issue: Do we really need a row "for every possible value of xdsl2LConfProfXdslMode"?

So, just to clarify the terminology, you never create rows in the mode-specific table for "values of xdsl2LConfProfXdslMode" but only for those DSL modes that are enabled (it's a bitmap) in the specific configuration profile. In other words, you need to deal only with the specific "value" that you use in the related configuration profile.

In the IETF draft MIB only the "default row" is mandatory. It's up to the operator to decide that several enabled DSL modes in the configuration profile are so distinct that they require separate mode-specific configuration (one or more rows). When that happens the operator creates rows for those modes, while all other modes are being covered by the same "default" row.

Regards,
Moti

From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Sperry
Sent: Thursday, February 26, 2009 12:05 AM
To: Romascanu, Dan (Dan); Menachem Dodge; [email-masked]
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hi Dan,

Since you ask, I think the MIB is huge and in some cases impractical. For example I could not figure out how to implement xdsl2LineConfProfModeSpecTable for every possible value of xdsl2LConfProfXdslMode. Equipment vendors will select a subset of the MIB to implement. But I think it needs to be ratified. It doesn't need to be perfect in its first RFC form.

And for the record, I did not implement an SNMP agent. I used the MIB in a design as a chip-independent driver API. And also for the record, that approach turned out to be impractical due to time constraints and the need to remain compatible with older APIs already in our system.

Vic

From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Wednesday, February 25, 2009 12:14 PM
To: Victor Sperry; Menachem Dodge; [email-masked]
Subject: RE: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hi Victor,

Thank you for your feedback. I am glad to hear that people implementing agents in this space participate in this work. I have a question not directly related to the question asked by Menachem. What is your opinion about the size of this MIB module and its implementability on agents?

Thanks and Regards,

Dan

-----Original Message-----
From: [email-masked] on behalf of Victor Sperry
Sent: Wed 2/25/2009 9:09 PM
To: Menachem Dodge; [email-masked]
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD      reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hello Manachem et al,

For years, I have written software for xDSL access equipment. I have written xDSL drivers and xDSL middleware for DSLAMs and multi-service access equipment such as the Paradyne 8820 DSLAM, Zhone Malc, and Calix C7. So my perspective is that of somebody who has to marry MIBs to xDSL chip vendors' API. I have never been an NMS developer.

This is what I see as important, from most important to least important.
1. Ratify and publish the VDSL2 MIB as an RFC.
2. Have the MIB match G.997.1 as much as possible.
3. Simplify the MIB, because it is extremely time-consuming to understand, let alone implement.
4. Use TruthValues instead of TCs.

I see the TruthValue vs TC argument as being akin to arguing over whether or not a developer has followed corporate coding standards. It is a valid concern, but not so important that it should delay the ratification of the document which has been fairly stable for over a year now.

And for what it's worth, I realize that my concerns #2 and #3 are at odds with each other. #2 is more important than #3.

Vic Sperry
Calix Networks

--_000_741F3E4A466A1D439C616902C7F8A8C6D4D057DE98ILPTMAIL02eci_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:D="DAV:" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="&#1;" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<title>RE: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi Victor,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I agree that the MIB is relatively big and that&#8217;s natural for
equipment vendors to decide what tables they wish to implement in each phase of
their product life. Sometimes it can also go down to a per attribute decision.
For example, PM thresholds and notifications will not be the first sections you
implement if you have a Time-To-Market problem because configuration is
normally more important. <o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Regarding to the mode-specific configuration, you actually touched
a very good issue: Do we really need a row &#8220;</span><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>for
every possible value of xdsl2LConfProfXdslMode</span><span style='font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&#8221;?<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>So, just to clarify the terminology, you never create rows in
the mode-specific table </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>for &#8220;values of xdsl2LConfProfXdslMode</span><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&#8221;
but only for those DSL modes that are enabled (it&#8217;s a bitmap) in the
specific configuration profile. In other words, you need to deal only with the
specific &#8220;value&#8221; that you use in the related configuration profile.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In the IETF draft MIB only the &#8220;default row&#8221; is
mandatory. It&#8217;s up to the operator to decide that several enabled DSL modes
in the configuration profile are so distinct that they require separate mode-specific
configuration (one or more rows). When that happens the operator creates rows
for those modes, while all other modes are being covered by the same &#8220;default&#8221;
row.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Regards,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Moti<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On Behalf Of </b>Victor
Sperry<br>
<b>Sent:</b> Thursday, February 26, 2009 12:05 AM<br>
<b>To:</b> Romascanu, Dan (Dan); Menachem Dodge; [email-masked]<br>
<b>Subject:</b> Re: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi Dan,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Since you ask, I think the MIB is huge and in some cases
impractical. For example I could not figure out how to implement
xdsl2LineConfProfModeSpecTable for every possible value of
xdsl2LConfProfXdslMode. Equipment vendors will select a subset of the MIB to
implement. But I think it needs to be ratified. It doesn&#8217;t need to be
perfect in its first RFC form.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>And for the record, I did not implement an SNMP agent. I used
the MIB in a design as a chip-independent driver API. And also for the record,
that approach turned out to be impractical due to time constraints and the need
to remain compatible with older APIs already in our system.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Vic<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Romascanu, Dan
(Dan) [mailto:[email-masked]] <br>
<b>Sent:</b> Wednesday, February 25, 2009 12:14 PM<br>
<b>To:</b> Victor Sperry; Menachem Dodge; [email-masked]<br>
<b>Subject:</b> RE: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p><span style='font-size:10.0pt'>Hi Victor,<br>
<br>
Thank you for your feedback. I am glad to hear that people implementing agents
in this space participate in this work. I have a question not directly related
to the question asked by Menachem. What is your opinion about the size of this
MIB module and its implementability on agents?&nbsp;<br>
<br>
Thanks and Regards,<br>
<br>
Dan<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: [email-masked] on behalf of Victor Sperry<br>
Sent: Wed 2/25/2009 9:09 PM<br>
To: Menachem Dodge; [email-masked]<br>
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
reviewofdraft-ietf-adslmib-vdsl2-06.txt<br>
<br>
Hello Manachem et al,<br>
<br>
For years, I have written software for xDSL access equipment. I have written
xDSL drivers and xDSL middleware for DSLAMs and multi-service access equipment
such as the Paradyne 8820 DSLAM, Zhone Malc, and Calix C7. So my perspective is
that of somebody who has to marry MIBs to xDSL chip vendors' API. I have never
been an NMS developer.<br>
<br>
This is what I see as important, from most important to least important.<br>
1. Ratify and publish the VDSL2 MIB as an RFC.<br>
2. Have the MIB match G.997.1 as much as possible.<br>
3. Simplify the MIB, because it is extremely time-consuming to understand, let
alone implement.<br>
4. Use TruthValues instead of TCs.<br>
<br>
I see the TruthValue vs TC argument as being akin to arguing over whether or
not a developer has followed corporate coding standards. It is a valid concern,
but not so important that it should delay the ratification of the document
which has been fairly stable for over a year now.<br>
<br>
And for what it's worth, I realize that my concerns #2 and #3 are at odds with
each other. #2 is more important than #3.<br>
<br>
Vic Sperry<br>
Calix Networks</span><o:p></o:p></p>

</div>

</body>

</html>

--_000_741F3E4A466A1D439C616902C7F8A8C6D4D057DE98ILPTMAIL02eci_--

Content-class: urn:content-classes:message
Date: Thu, 26 Feb 2009 09:43:16 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Moti Morgenstern" <[email-masked]>, "Victor Sperry" <[email-masked]>
Cc: [email-masked], Menachem Dodge <[email-masked]>
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

This is a multi-part message in MIME format.

------_=_NextPart_001_01C997EE.44FCA14B
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Moti,
 
In order to be conformant with the MIB module equipment vendors MUST
implement all the objects which are part of the MANDATORY-GROUPS. 
 
If the editors believe that some objects or tables will not be
mandatory, those need to be included in separate groups. 
 
The clarification about the creation of rows in the mode-specific table
should be included in the DESCRIPTION clause to make the issue clear for
other implementers or users of the document. 
 
Regards,
 
Dan

________________________________

	From: Moti Morgenstern [mailto:[email-masked]] 
	Sent: Thursday, February 26, 2009 10:23 AM
	To: Victor Sperry
	Cc: Romascanu, Dan (Dan); Menachem Dodge; [email-masked]
	Subject: RE: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt

	Hi Victor,

	I agree that the MIB is relatively big and that's natural for
equipment vendors to decide what tables they wish to implement in each
phase of their product life. Sometimes it can also go down to a per
attribute decision. For example, PM thresholds and notifications will
not be the first sections you implement if you have a Time-To-Market
problem because configuration is normally more important. 

	Regarding to the mode-specific configuration, you actually
touched a very good issue: Do we really need a row "for every possible
value of xdsl2LConfProfXdslMode"?

	So, just to clarify the terminology, you never create rows in
the mode-specific table for "values of xdsl2LConfProfXdslMode" but only
for those DSL modes that are enabled (it's a bitmap) in the specific
configuration profile. In other words, you need to deal only with the
specific "value" that you use in the related configuration profile.

	In the IETF draft MIB only the "default row" is mandatory. It's
up to the operator to decide that several enabled DSL modes in the
configuration profile are so distinct that they require separate
mode-specific configuration (one or more rows). When that happens the
operator creates rows for those modes, while all other modes are being
covered by the same "default" row.

	Regards,

	Moti

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Victor Sperry
	Sent: Thursday, February 26, 2009 12:05 AM
	To: Romascanu, Dan (Dan); Menachem Dodge; [email-masked]
	Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt

	Hi Dan,

	Since you ask, I think the MIB is huge and in some cases
impractical. For example I could not figure out how to implement
xdsl2LineConfProfModeSpecTable for every possible value of
xdsl2LConfProfXdslMode. Equipment vendors will select a subset of the
MIB to implement. But I think it needs to be ratified. It doesn't need
to be perfect in its first RFC form.

	And for the record, I did not implement an SNMP agent. I used
the MIB in a design as a chip-independent driver API. And also for the
record, that approach turned out to be impractical due to time
constraints and the need to remain compatible with older APIs already in
our system.

	Vic

	From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
	Sent: Wednesday, February 25, 2009 12:14 PM
	To: Victor Sperry; Menachem Dodge; [email-masked]
	Subject: RE: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt

	Hi Victor,
	
	Thank you for your feedback. I am glad to hear that people
implementing agents in this space participate in this work. I have a
question not directly related to the question asked by Menachem. What is
your opinion about the size of this MIB module and its implementability
on agents? 
	
	Thanks and Regards,
	
	Dan

	
	-----Original Message-----
	From: [email-masked] on behalf of Victor Sperry
	Sent: Wed 2/25/2009 9:09 PM
	To: Menachem Dodge; [email-masked]
	Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt
	
	Hello Manachem et al,
	
	For years, I have written software for xDSL access equipment. I
have written xDSL drivers and xDSL middleware for DSLAMs and
multi-service access equipment such as the Paradyne 8820 DSLAM, Zhone
Malc, and Calix C7. So my perspective is that of somebody who has to
marry MIBs to xDSL chip vendors' API. I have never been an NMS
developer.
	
	This is what I see as important, from most important to least
important.
	1. Ratify and publish the VDSL2 MIB as an RFC.
	2. Have the MIB match G.997.1 as much as possible.
	3. Simplify the MIB, because it is extremely time-consuming to
understand, let alone implement.
	4. Use TruthValues instead of TCs.
	
	I see the TruthValue vs TC argument as being akin to arguing
over whether or not a developer has followed corporate coding standards.
It is a valid concern, but not so important that it should delay the
ratification of the document which has been fairly stable for over a
year now.
	
	And for what it's worth, I realize that my concerns #2 and #3
are at odds with each other. #2 is more important than #3.
	
	Vic Sperry
	Calix Networks

------_=_NextPart_001_01C997EE.44FCA14B
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:x = 
"urn:schemas-microsoft-com:office:excel" xmlns:p = 
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a = 
"urn:schemas-microsoft-com:office:access" xmlns:dt = 
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s = 
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs = 
"urn:schemas-microsoft-com:rowset" xmlns:z = "#RowsetSchema" xmlns:b = 
"urn:schemas-microsoft-com:office:publisher" xmlns:ss = 
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:c = 
"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc = 
"urn:schemas-microsoft-com:office:odc" xmlns:oa = 
"urn:schemas-microsoft-com:office:activation" xmlns:html = 
"http://www.w3.org/TR/REC-html40" xmlns:q = 
"http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D = "DAV:" xmlns:x2 = 
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois = 
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir = 
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds = 
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp = 
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc = 
"http://schemas.microsoft.com/data/udc" xmlns:xsd = 
"http://www.w3.org/2001/XMLSchema" xmlns:sub = 
"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec = 
"http://www.w3.org/2001/04/xmlenc#" xmlns:sp = 
"http://schemas.microsoft.com/sharepoint/" xmlns:sps = 
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi = 
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs = 
"http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf = 
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p = 
"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf = 
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss = 
"http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi = 
"http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi = 
"http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver = 
"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m = 
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels = 
"http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp = 
"http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t = 
"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m = 
"http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl = 
"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl = 
"http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" 
XMLNS:Z = "urn:schemas-microsoft-com:" xmlns:st = ""><HEAD><TITLE>RE: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3492" name=GENERATOR>
<STYLE>@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 72.0pt 72.0pt 72.0pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: "Times New Roman","serif"; mso-style-priority: 99; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal
}
SPAN.EmailStyle19 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=EN-US vLink=purple link=blue>
<DIV><SPAN class=109013408-26022009><FONT face=Arial color=#0000ff 
size=2><STRONG><EM></EM></STRONG></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=109013408-26022009><STRONG><EM><FONT face=Arial color=#0000ff 
size=2>Moti,</FONT></EM></STRONG></SPAN></DIV>
<DIV><SPAN class=109013408-26022009><STRONG><EM><FONT face=Arial color=#0000ff 
size=2></FONT></EM></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=109013408-26022009><STRONG><EM><FONT face=Arial color=#0000ff 
size=2>In order to be conformant with the MIB module equipment vendors MUST 
implement all the objects which are part of the MANDATORY-GROUPS. 
</FONT></EM></STRONG></SPAN></DIV>
<DIV><SPAN class=109013408-26022009><STRONG><EM><FONT face=Arial color=#0000ff 
size=2></FONT></EM></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=109013408-26022009><STRONG><EM><FONT face=Arial color=#0000ff 
size=2>If the editors believe that some objects or tables will not be mandatory, 
those need to be included in separate groups. </FONT></EM></STRONG></SPAN></DIV>
<DIV><SPAN class=109013408-26022009><STRONG><EM><FONT face=Arial color=#0000ff 
size=2></FONT></EM></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=109013408-26022009><STRONG><EM><FONT face=Arial color=#0000ff 
size=2>The clarification about the creation of rows in the mode-specific table 
should be included in the DESCRIPTION clause to make the issue clear for other 
implementers or users of the document. </FONT></EM></STRONG></SPAN></DIV>
<DIV><SPAN class=109013408-26022009><STRONG><EM><FONT face=Arial color=#0000ff 
size=2></FONT></EM></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=109013408-26022009><STRONG><EM><FONT face=Arial color=#0000ff 
size=2>Regards,</FONT></EM></STRONG></SPAN></DIV>
<DIV><SPAN class=109013408-26022009><STRONG><EM><FONT face=Arial color=#0000ff 
size=2></FONT></EM></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=109013408-26022009><STRONG><EM><FONT face=Arial color=#0000ff 
size=2>Dan</FONT></EM></STRONG></SPAN></DIV>
<DIV><SPAN class=109013408-26022009></SPAN>&nbsp;</DIV><BR>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> Moti Morgenstern 
  [mailto:[email-masked]] <BR><B>Sent:</B> Thursday, February 26, 
  2009 10:23 AM<BR><B>To:</B> Victor Sperry<BR><B>Cc:</B> Romascanu, Dan (Dan); 
  Menachem Dodge; [email-masked]<BR><B>Subject:</B> RE: [Adslmib] 
  FW:[MIB-DOCTORS] AD 
  reviewofdraft-ietf-adslmib-vdsl2-06.txt<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=Section1>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Hi 
  Victor,<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I 
  agree that the MIB is relatively big and that&#8217;s natural for equipment vendors 
  to decide what tables they wish to implement in each phase of their product 
  life. Sometimes it can also go down to a per attribute decision. For example, 
  PM thresholds and notifications will not be the first sections you implement 
  if you have a Time-To-Market problem because configuration is normally more 
  important. <o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Regarding 
  to the mode-specific configuration, you actually touched a very good issue: Do 
  we really need a row &#8220;</SPAN><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">for 
  every possible value of xdsl2LConfProfXdslMode</SPAN><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">&#8221;?<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">So, 
  just to clarify the terminology, you never create rows in the mode-specific 
  table </SPAN><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">for 
  &#8220;values of xdsl2LConfProfXdslMode</SPAN><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">&#8221; 
  but only for those DSL modes that are enabled (it&#8217;s a bitmap) in the specific 
  configuration profile. In other words, you need to deal only with the specific 
  &#8220;value&#8221; that you use in the related configuration 
  profile.<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">In 
  the IETF draft MIB only the &#8220;default row&#8221; is mandatory. It&#8217;s up to the 
  operator to decide that several enabled DSL modes in the configuration profile 
  are so distinct that they require separate mode-specific configuration (one or 
  more rows). When that happens the operator creates rows for those modes, while 
  all other modes are being covered by the same &#8220;default&#8221; 
  row.<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Regards,<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Moti<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV>
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=MsoNormal><B><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> 
  [email-masked] [mailto:[email-masked]] <B>On Behalf Of 
  </B>Victor Sperry<BR><B>Sent:</B> Thursday, February 26, 2009 12:05 
  AM<BR><B>To:</B> Romascanu, Dan (Dan); Menachem Dodge; 
  [email-masked]<BR><B>Subject:</B> Re: [Adslmib] FW:[MIB-DOCTORS] AD 
  reviewofdraft-ietf-adslmib-vdsl2-06.txt<o:p></o:p></SPAN></P></DIV></DIV>
  <P class=MsoNormal><o:p>&nbsp;</o:p></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Hi 
  Dan,<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Since 
  you ask, I think the MIB is huge and in some cases impractical. For example I 
  could not figure out how to implement xdsl2LineConfProfModeSpecTable for every 
  possible value of xdsl2LConfProfXdslMode. Equipment vendors will select a 
  subset of the MIB to implement. But I think it needs to be ratified. It 
  doesn&#8217;t need to be perfect in its first RFC form.<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">And 
  for the record, I did not implement an SNMP agent. I used the MIB in a design 
  as a chip-independent driver API. And also for the record, that approach 
  turned out to be impractical due to time constraints and the need to remain 
  compatible with older APIs already in our system.<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Vic<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV>
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=MsoNormal><B><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> Romascanu, Dan 
  (Dan) [mailto:[email-masked]] <BR><B>Sent:</B> Wednesday, February 25, 
  2009 12:14 PM<BR><B>To:</B> Victor Sperry; Menachem Dodge; 
  [email-masked]<BR><B>Subject:</B> RE: [Adslmib] FW:[MIB-DOCTORS] AD 
  reviewofdraft-ietf-adslmib-vdsl2-06.txt<o:p></o:p></SPAN></P></DIV></DIV>
  <P class=MsoNormal><o:p>&nbsp;</o:p></P>
  <P><SPAN style="FONT-SIZE: 10pt">Hi Victor,<BR><BR>Thank you for your 
  feedback. I am glad to hear that people implementing agents in this space 
  participate in this work. I have a question not directly related to the 
  question asked by Menachem. What is your opinion about the size of this MIB 
  module and its implementability on agents?&nbsp;<BR><BR>Thanks and 
  Regards,<BR><BR>Dan<BR><BR><BR><BR>-----Original Message-----<BR>From: 
  [email-masked] on behalf of Victor Sperry<BR>Sent: Wed 2/25/2009 
  9:09 PM<BR>To: Menachem Dodge; [email-masked]<BR>Subject: Re: [Adslmib] 
  FW:[MIB-DOCTORS] AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  reviewofdraft-ietf-adslmib-vdsl2-06.txt<BR><BR>Hello Manachem et 
  al,<BR><BR>For years, I have written software for xDSL access equipment. I 
  have written xDSL drivers and xDSL middleware for DSLAMs and multi-service 
  access equipment such as the Paradyne 8820 DSLAM, Zhone Malc, and Calix C7. So 
  my perspective is that of somebody who has to marry MIBs to xDSL chip vendors' 
  API. I have never been an NMS developer.<BR><BR>This is what I see as 
  important, from most important to least important.<BR>1. Ratify and publish 
  the VDSL2 MIB as an RFC.<BR>2. Have the MIB match G.997.1 as much as 
  possible.<BR>3. Simplify the MIB, because it is extremely time-consuming to 
  understand, let alone implement.<BR>4. Use TruthValues instead of 
  TCs.<BR><BR>I see the TruthValue vs TC argument as being akin to arguing over 
  whether or not a developer has followed corporate coding standards. It is a 
  valid concern, but not so important that it should delay the ratification of 
  the document which has been fairly stable for over a year now.<BR><BR>And for 
  what it's worth, I realize that my concerns #2 and #3 are at odds with each 
  other. #2 is more important than #3.<BR><BR>Vic Sperry<BR>Calix 
  Networks</SPAN><o:p></o:p></P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C997EE.44FCA14B--

From: Moti Morgenstern <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 Feb 2009 10:55:25 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, Menachem Dodge <[email-masked]>
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

--_000_741F3E4A466A1D439C616902C7F8A8C6D4D057DEA5ILPTMAIL02eci_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Dan,

Yes, you're right.

1)      The table implementation is mandatory and it is actually an extension of the (mandatory also) configuration table

2)      The "default" row, with the index defMode=1,  should always be present in the table.

3)      Creating more rows is optional based in case the manager need them.

4)      All the above is explicitly described in the DESCRIPTION clause of the table.

Regards,
Moti
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Thursday, February 26, 2009 10:43 AM
To: Moti Morgenstern; Victor Sperry
Cc: Menachem Dodge; [email-masked]
Subject: RE: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

Moti,

In order to be conformant with the MIB module equipment vendors MUST implement all the objects which are part of the MANDATORY-GROUPS.

If the editors believe that some objects or tables will not be mandatory, those need to be included in separate groups.

The clarification about the creation of rows in the mode-specific table should be included in the DESCRIPTION clause to make the issue clear for other implementers or users of the document.

Regards,

Dan

________________________________
From: Moti Morgenstern [mailto:[email-masked]]
Sent: Thursday, February 26, 2009 10:23 AM
To: Victor Sperry
Cc: Romascanu, Dan (Dan); Menachem Dodge; [email-masked]
Subject: RE: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt
Hi Victor,

I agree that the MIB is relatively big and that's natural for equipment vendors to decide what tables they wish to implement in each phase of their product life. Sometimes it can also go down to a per attribute decision. For example, PM thresholds and notifications will not be the first sections you implement if you have a Time-To-Market problem because configuration is normally more important.

Regarding to the mode-specific configuration, you actually touched a very good issue: Do we really need a row "for every possible value of xdsl2LConfProfXdslMode"?

So, just to clarify the terminology, you never create rows in the mode-specific table for "values of xdsl2LConfProfXdslMode" but only for those DSL modes that are enabled (it's a bitmap) in the specific configuration profile. In other words, you need to deal only with the specific "value" that you use in the related configuration profile.

In the IETF draft MIB only the "default row" is mandatory. It's up to the operator to decide that several enabled DSL modes in the configuration profile are so distinct that they require separate mode-specific configuration (one or more rows). When that happens the operator creates rows for those modes, while all other modes are being covered by the same "default" row.

Regards,
Moti

From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Sperry
Sent: Thursday, February 26, 2009 12:05 AM
To: Romascanu, Dan (Dan); Menachem Dodge; [email-masked]
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hi Dan,

Since you ask, I think the MIB is huge and in some cases impractical. For example I could not figure out how to implement xdsl2LineConfProfModeSpecTable for every possible value of xdsl2LConfProfXdslMode. Equipment vendors will select a subset of the MIB to implement. But I think it needs to be ratified. It doesn't need to be perfect in its first RFC form.

And for the record, I did not implement an SNMP agent. I used the MIB in a design as a chip-independent driver API. And also for the record, that approach turned out to be impractical due to time constraints and the need to remain compatible with older APIs already in our system.

Vic

From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Wednesday, February 25, 2009 12:14 PM
To: Victor Sperry; Menachem Dodge; [email-masked]
Subject: RE: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hi Victor,

Thank you for your feedback. I am glad to hear that people implementing agents in this space participate in this work. I have a question not directly related to the question asked by Menachem. What is your opinion about the size of this MIB module and its implementability on agents?

Thanks and Regards,

Dan

-----Original Message-----
From: [email-masked] on behalf of Victor Sperry
Sent: Wed 2/25/2009 9:09 PM
To: Menachem Dodge; [email-masked]
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD      reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hello Manachem et al,

For years, I have written software for xDSL access equipment. I have written xDSL drivers and xDSL middleware for DSLAMs and multi-service access equipment such as the Paradyne 8820 DSLAM, Zhone Malc, and Calix C7. So my perspective is that of somebody who has to marry MIBs to xDSL chip vendors' API. I have never been an NMS developer.

This is what I see as important, from most important to least important.
1. Ratify and publish the VDSL2 MIB as an RFC.
2. Have the MIB match G.997.1 as much as possible.
3. Simplify the MIB, because it is extremely time-consuming to understand, let alone implement.
4. Use TruthValues instead of TCs.

I see the TruthValue vs TC argument as being akin to arguing over whether or not a developer has followed corporate coding standards. It is a valid concern, but not so important that it should delay the ratification of the document which has been fairly stable for over a year now.

And for what it's worth, I realize that my concerns #2 and #3 are at odds with each other. #2 is more important than #3.

Vic Sperry
Calix Networks

--_000_741F3E4A466A1D439C616902C7F8A8C6D4D057DEA5ILPTMAIL02eci_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:D="DAV:" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="&#1;" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1611668573;
	mso-list-type:hybrid;
	mso-list-template-ids:-794279048 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi Dan,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Yes, you&#8217;re right.<o:p></o:p></span></p>

<p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>1)<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span dir=LTR></span><span style='font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The table
implementation is mandatory and it is actually an extension of the (mandatory
also) configuration table<o:p></o:p></span></p>

<p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>2)<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span dir=LTR></span><span style='font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The &#8220;default&#8221;
row, with the index defMode=1, &nbsp;should always be present in the table.<o:p></o:p></span></p>

<p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>3)<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span dir=LTR></span><span style='font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Creating more rows is optional
based in case the manager need them.<o:p></o:p></span></p>

<p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>4)<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span dir=LTR></span><span style='font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>All the above is
explicitly described in the DESCRIPTION clause of the table.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Regards,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Moti<o:p></o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Romascanu, Dan
(Dan) [mailto:[email-masked]] <br>
<b>Sent:</b> Thursday, February 26, 2009 10:43 AM<br>
<b>To:</b> Moti Morgenstern; Victor Sperry<br>
<b>Cc:</b> Menachem Dodge; [email-masked]<br>
<b>Subject:</b> RE: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><em><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Moti,</span></b></em><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><em><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>In order to be conformant with the MIB module equipment vendors
MUST implement all the objects which are part of the MANDATORY-GROUPS. </span></b></em><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><em><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>If the editors believe that some objects or tables will not be
mandatory, those need to be included in separate groups. </span></b></em><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><em><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>The clarification about the creation of rows in the mode-specific
table should be included in the DESCRIPTION clause to make the issue clear for
other implementers or users of the document. </span></b></em><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><em><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Regards,</span></b></em><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><em><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Dan</span></b></em><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<blockquote style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<div class=MsoNormal align=center style='text-align:center'>

<hr size=2 width="100%" align=center>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><span style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Moti Morgenstern
[mailto:[email-masked]] <br>
<b>Sent:</b> Thursday, February 26, 2009 10:23 AM<br>
<b>To:</b> Victor Sperry<br>
<b>Cc:</b> Romascanu, Dan (Dan); Menachem Dodge; [email-masked]<br>
<b>Subject:</b> RE: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt</span><o:p></o:p></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi Victor,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I agree that the MIB is relatively big and that&#8217;s natural
for equipment vendors to decide what tables they wish to implement in each
phase of their product life. Sometimes it can also go down to a per attribute
decision. For example, PM thresholds and notifications will not be the first
sections you implement if you have a Time-To-Market problem because
configuration is normally more important. <o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Regarding to the mode-specific configuration, you actually
touched a very good issue: Do we really need a row &#8220;for every possible
value of xdsl2LConfProfXdslMode&#8221;?<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>So, just to clarify the terminology, you never create rows in
the mode-specific table for &#8220;values of xdsl2LConfProfXdslMode&#8221; but
only for those DSL modes that are enabled (it&#8217;s a bitmap) in the specific
configuration profile. In other words, you need to deal only with the specific
&#8220;value&#8221; that you use in the related configuration profile.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In the IETF draft MIB only the &#8220;default row&#8221; is mandatory.
It&#8217;s up to the operator to decide that several enabled DSL modes in the
configuration profile are so distinct that they require separate mode-specific
configuration (one or more rows). When that happens the operator creates rows
for those modes, while all other modes are being covered by the same
&#8220;default&#8221; row.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Regards,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Moti<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On Behalf Of </b>Victor
Sperry<br>
<b>Sent:</b> Thursday, February 26, 2009 12:05 AM<br>
<b>To:</b> Romascanu, Dan (Dan); Menachem Dodge; [email-masked]<br>
<b>Subject:</b> Re: [Adslmib] FW:[MIB-DOCTORS] AD
reviewofdraft-ietf-adslmib-vdsl2-06.txt<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi Dan,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Since you ask, I think the MIB is huge and in some cases
impractical. For example I could not figure out how to implement
xdsl2LineConfProfModeSpecTable for every possible value of
xdsl2LConfProfXdslMode. Equipment vendors will select a subset of the MIB to
implement. But I think it needs to be ratified. It doesn&#8217;t need to be
perfect in its first RFC form.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>And for the record, I did not implement an SNMP agent. I used
the MIB in a design as a chip-independent driver API. And also for the record,
that approach turned out to be impractical due to time constraints and the need
to remain compatible with older APIs already in our system.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Vic<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Romascanu, Dan
(Dan) [mailto:[email-masked]] <br>
<b>Sent:</b> Wednesday, February 25, 2009 12:14 PM<br>
<b>To:</b> Victor Sperry; Menachem Dodge; [email-masked]<br>
<b>Subject:</b> RE: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p><span style='font-size:10.0pt'>Hi Victor,<br>
<br>
Thank you for your feedback. I am glad to hear that people implementing agents
in this space participate in this work. I have a question not directly related
to the question asked by Menachem. What is your opinion about the size of this
MIB module and its implementability on agents?&nbsp;<br>
<br>
Thanks and Regards,<br>
<br>
Dan<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: [email-masked] on behalf of Victor Sperry<br>
Sent: Wed 2/25/2009 9:09 PM<br>
To: Menachem Dodge; [email-masked]<br>
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
reviewofdraft-ietf-adslmib-vdsl2-06.txt<br>
<br>
Hello Manachem et al,<br>
<br>
For years, I have written software for xDSL access equipment. I have written
xDSL drivers and xDSL middleware for DSLAMs and multi-service access equipment
such as the Paradyne 8820 DSLAM, Zhone Malc, and Calix C7. So my perspective is
that of somebody who has to marry MIBs to xDSL chip vendors' API. I have never
been an NMS developer.<br>
<br>
This is what I see as important, from most important to least important.<br>
1. Ratify and publish the VDSL2 MIB as an RFC.<br>
2. Have the MIB match G.997.1 as much as possible.<br>
3. Simplify the MIB, because it is extremely time-consuming to understand, let
alone implement.<br>
4. Use TruthValues instead of TCs.<br>
<br>
I see the TruthValue vs TC argument as being akin to arguing over whether or
not a developer has followed corporate coding standards. It is a valid concern,
but not so important that it should delay the ratification of the document
which has been fairly stable for over a year now.<br>
<br>
And for what it's worth, I realize that my concerns #2 and #3 are at odds with
each other. #2 is more important than #3.<br>
<br>
Vic Sperry<br>
Calix Networks</span><o:p></o:p></p>

</blockquote>

</div>

</body>

</html>

--_000_741F3E4A466A1D439C616902C7F8A8C6D4D057DEA5ILPTMAIL02eci_--

From: Victor Sperry <[email-masked]>
To: Moti Morgenstern <[email-masked]>
Date: Thu, 26 Feb 2009 07:40:05 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, Menachem Dodge <[email-masked]>
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

--_000_B3A42E0B3D1142908B1BA92F3B2A9A62calixcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_B3A42E0B3D1142908B1BA92F3B2A9A62calixcom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_B3A42E0B3D1142908B1BA92F3B2A9A62calixcom_--

From: Moti Morgenstern <[email-masked]>
To: Victor Sperry <[email-masked]>
Date: Thu, 26 Feb 2009 18:05:31 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, Menachem Dodge <[email-masked]>
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD reviewofdraft-ietf-adslmib-vdsl2-06.txt

--_000_741F3E4A466A1D439C616902C7F8A8C6D4D057DF72ILPTMAIL02eci_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_741F3E4A466A1D439C616902C7F8A8C6D4D057DF72ILPTMAIL02eci_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_741F3E4A466A1D439C616902C7F8A8C6D4D057DF72ILPTMAIL02eci_--

From: Scott Baillie <[email-masked]>
To: Victor Sperry <[email-masked]>
Date: Fri, 27 Feb 2009 03:56:37 +1100
Cc: "[email-masked]" <[email-masked]>, Menachem Dodge <[email-masked]>, Moti Morgenstern <[email-masked]>
Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD	reviewofdraft-ietf-adslmib-vdsl2-06.txt

Hi Victor,

The MIB is an abstract model and it is up to the SNMP
agent implementor to map the hardware they are using to
the abstract model.

It is important that SNMP agent implementations 
reject configuration that is not achieveable by the
underlying hardware.

In the case of your example with the 3 broad categories,
my suggestion is :

1. Add multiple rows into xdsl2LineConfProfModeSpecTable
   for the desired ADSL operating modes.
   Each of these rows will have identical values.
2. Add multiple rows into xdsl2LineConfProfModeSpecTable
   for the desired ADSL2+ operating modes.
   Each of these rows will have identical values.
3. Add multiple rows into xdsl2LineConfProfModeSpecTable
   for the desired VDSL2 operating modes.
   Each of these rows will have identical values.

Yes, it is wasteful to have redundant rows but that is
the price you pay for having an abstract model.

Regards,

Scott.

On Thu, 2009-02-26 at 07:40 -0800, Victor Sperry wrote:
> Moti, Scott, and the rest,
> 
> 
> The intent of row creation in the mode-specific table is clear to me.
> But I could not see how to implement it with the chips I've looked at.
> Conexant and Broadcom both supply some mode-specific provisioning
> items, but the modes are more coarse than what the MIB uses. For
> example, I may be able to provide three mode-specific settings, ADSL,
> ADSL2+, and VDSL2. How would I map the MIB to such a chip? I would
> have to, for example, demand that the operator set exactly all the
> bits that cover every ADSL technology. If he leaves out one bit, or
> sets one too many, I would have to reject the Set operation. It didn't
> seem reasonable to me.  
> 
> 
> Vic
> 
> Sent from my iPhone
> 
> On Feb 26, 2009, at 12:23 AM, "Moti Morgenstern"
> <[email-masked]> wrote:
> 
> 
> 
> > Hi Victor,
> > 
> >  
> > 
> > I agree that the MIB is relatively big and that’s natural for
> > equipment vendors to decide what tables they wish to implement in
> > each phase of their product life. Sometimes it can also go down to a
> > per attribute decision. For example, PM thresholds and notifications
> > will not be the first sections you implement if you have a
> > Time-To-Market problem because configuration is normally more
> > important. 
> > 
> >  
> > 
> > Regarding to the mode-specific configuration, you actually touched a
> > very good issue: Do we really need a row “for every possible value
> > of xdsl2LConfProfXdslMode”?
> > 
> >  
> > 
> > So, just to clarify the terminology, you never create rows in the
> > mode-specific table for “values of xdsl2LConfProfXdslMode” but only
> > for those DSL modes that are enabled (it’s a bitmap) in the specific
> > configuration profile. In other words, you need to deal only with
> > the specific “value” that you use in the related configuration
> > profile.
> > 
> >  
> > 
> > In the IETF draft MIB only the “default row” is mandatory. It’s up
> > to the operator to decide that several enabled DSL modes in the
> > configuration profile are so distinct that they require separate
> > mode-specific configuration (one or more rows). When that happens
> > the operator creates rows for those modes, while all other modes are
> > being covered by the same “default” row.
> > 
> >  
> > 
> > Regards,
> > 
> > Moti
> > 
> >  
> > 
> > From:[email-masked] [mailto:[email-masked]] On
> > Behalf Of Victor Sperry
> > Sent: Thursday, February 26, 2009 12:05 AM
> > To: Romascanu, Dan (Dan); Menachem Dodge; [email-masked]
> > Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD
> > reviewofdraft-ietf-adslmib-vdsl2-06.txt
> > 
> > 
> >  
> > 
> > Hi Dan,
> > 
> >  
> > 
> > Since you ask, I think the MIB is huge and in some cases
> > impractical. For example I could not figure out how to implement
> > xdsl2LineConfProfModeSpecTable for every possible value of
> > xdsl2LConfProfXdslMode. Equipment vendors will select a subset of
> > the MIB to implement. But I think it needs to be ratified. It
> > doesn’t need to be perfect in its first RFC form.
> > 
> >  
> > 
> > And for the record, I did not implement an SNMP agent. I used the
> > MIB in a design as a chip-independent driver API. And also for the
> > record, that approach turned out to be impractical due to time
> > constraints and the need to remain compatible with older APIs
> > already in our system.
> > 
> >  
> > 
> > Vic
> > 
> >  
> > 
> > From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> > Sent: Wednesday, February 25, 2009 12:14 PM
> > To: Victor Sperry; Menachem Dodge; [email-masked]
> > Subject: RE: [Adslmib] FW:[MIB-DOCTORS] AD
> > reviewofdraft-ietf-adslmib-vdsl2-06.txt
> > 
> > 
> >  
> > 
> > Hi Victor,
> > 
> > Thank you for your feedback. I am glad to hear that people
> > implementing agents in this space participate in this work. I have a
> > question not directly related to the question asked by Menachem.
> > What is your opinion about the size of this MIB module and its
> > implementability on agents? 
> > 
> > Thanks and Regards,
> > 
> > Dan
> > 
> > 
> > 
> > -----Original Message-----
> > From: [email-masked] on behalf of Victor Sperry
> > Sent: Wed 2/25/2009 9:09 PM
> > To: Menachem Dodge; [email-masked]
> > Subject: Re: [Adslmib] FW:[MIB-DOCTORS] AD
> > reviewofdraft-ietf-adslmib-vdsl2-06.txt
> > 
> > Hello Manachem et al,
> > 
> > For years, I have written software for xDSL access equipment. I have
> > written xDSL drivers and xDSL middleware for DSLAMs and
> > multi-service access equipment such as the Paradyne 8820 DSLAM,
> > Zhone Malc, and Calix C7. So my perspective is that of somebody who
> > has to marry MIBs to xDSL chip vendors' API. I have never been an
> > NMS developer.
> > 
> > This is what I see as important, from most important to least
> > important.
> > 1. Ratify and publish the VDSL2 MIB as an RFC.
> > 2. Have the MIB match G.997.1 as much as possible.
> > 3. Simplify the MIB, because it is extremely time-consuming to
> > understand, let alone implement.
> > 4. Use TruthValues instead of TCs.
> > 
> > I see the TruthValue vs TC argument as being akin to arguing over
> > whether or not a developer has followed corporate coding standards.
> > It is a valid concern, but not so important that it should delay the
> > ratification of the document which has been fairly stable for over a
> > year now.
> > 
> > And for what it's worth, I realize that my concerns #2 and #3 are at
> > odds with each other. #2 is more important than #3.
> > 
> > Vic Sperry
> > Calix Networks
> > 
> > 
> _______________________________________________
> Adslmib mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/adslmib

From: Scott Baillie <[email-masked]>
To: Victor Sperry <[email-masked]>
Organization: NEC Australia
Date: Thu, 26 Feb 2009 13:40:17 +1100
Cc: "[email-masked]" <[email-masked]>, Menachem Dodge <[email-masked]>
Subject: Re: [Adslmib] FW:[MIB-DOCTORS]	AD	reviewofdraft-ietf-adslmib-vdsl2-06.txt
Reply-To: [email-masked]

Hi Victor,

I just want to address your comment below :

>> For example I could not figure out how to implement
>> xdsl2LineConfProfModeSpecTable for every possible value of
>> xdsl2LConfProfXdslMode.

The comments in the MIB for this table are :

The manager MAY create an 'optional' row in this table using the
xdsl2aLConfProfModeSpecRowStatus attribute if the parent row
exists.

The comment states that it is not neccessary to to implement a
row in this table for every possible value of xdsl2LConfProfXdslMode.

For example, if your implementation cannot support the values 
ansit1413(2) and etsi(3) the agent could reject an attempt to
create those rows.

Do you think the description is not clear ?

Regards,

Scott.