Re: [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 protected]] 
> Sent: Monday, February 16, 2009 4:56 PM
> To: Romascanu, Dan (Dan); 'Moti Morgenstern'
> Cc: 'MIB Doctors (E-mail)'; [email protected]; 'Menachem 
> Dodge'; [email protected]; [email protected]
> 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 protected]]
> > Sent: Monday, February 16, 2009 7:29 AM
> > To: Moti Morgenstern; David B Harrington
> > Cc: MIB Doctors (E-mail); [email protected]; Menachem Dodge; 
> > [email protected]; [email protected]
> > 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 protected]]
> > > Sent: Friday, January 30, 2009 12:40 PM
> > > To: Romascanu, Dan (Dan); David B Harrington
> > > Cc: MIB Doctors (E-mail); [email protected]; Menachem Dodge; 
> > > [email protected]; [email protected]
> > > 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 protected]]
> > > Sent: Thursday, January 22, 2009 10:42 PM
> > > To: Romascanu, Dan (Dan); Moti Morgenstern; David B Harrington
> > > Cc: MIB Doctors (E-mail); [email protected]; Menachem Dodge; 
> > > [email protected]; [email protected]
> > > 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 protected]
> > > 
> > 
> 
>