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

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

Your proposed resolution to the comments looks satisfactory to me. 

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

Thanks and Regards,

Dan

> -----Original Message-----
> From: Moti Morgenstern [mailto:[email-masked]] 
> Sent: Sunday, November 09, 2008 4:53 PM
> To: Romascanu, Dan (Dan); David B Harrington
> Cc: MIB Doctors (E-mail); [email-masked]; Menachem Dodge; 
> [email-masked]; [email-masked]
> Subject: RE: AD review of draft-ietf-adslmib-vdsl2-06.txt
> 
> Hi Dan and David,
> 
> Thank you for the comments regarding to 
> draft-ietf-adslmib-vdsl2-06.txt.
> We, the editors, reviewed the comments and here is our 
> response to each (Dan's comments and then David's):
> 
> Comment T1
> --------------
> Comment suggests writing specifically in the MIB module, in 
> the DESCRIPTION clauses of the MIB tables, what is the 
> persistence policy relative to the objects in the table.
> Response: We have a section in the document called "2.5.  
> Persistence" which lists all persistent objects. If you 
> search for each of these objects in the MIB, not all of the 
> objects mention persistence in the DESCRIPTION clause. This 
> is when the persistency is relevant to ALL objects and, when 
> that happens, the DESCRIPTION clause of the containing table 
> mentions: "Entries in this table MUST be maintained in a 
> persistent manner." So we believe the current situation is 
> satisfactory.
> 
> Comment T2
> --------------
> Comment claims that indexation by name is very resource consuming.
> Response: The observation is basically correct. Despite that, 
> we chose name indexes on purpose for ease of use by the 
> operator and consistency with all other xDSL MIBs. 
> 
> Comment T3
> --------------
> Comment refers to rate-limiting notifications mentioned in 
> the document.
> Response: We will remove the rate limiting comment altogether 
> because no other xDSL MIB mentions this.
> 
> Comment T4
> --------------
> Comment is a request to explain the Reserved bits in 
> Xdsl2TransmissionModeType.
> Response: We used reserved bits because we want the VDSL2 MIB 
> to closely match the source document G.997.1.
> 
> Comment T5
> --------------
> Comment about the Textual Conventions with enumerated INTEGER 
> syntax in which the list of values starts from zero.
> Response: Similar to T4 above this was done on purpose. We 
> want the MIB to closely match the source document G.997.1 
> which already defines the range of enumerated values for many 
> attributes. Since the syntax allows that we don't see it 
> necessary to explain such considerations in the MIB. 
> 
> Comment T6
> --------------
> Comment about the Boolean objects with new TCs instead of 
> using TruthValue
> Response: We use TruthValue for 10 objects in the MIB, so, 
> it's not that we are not familiar with that TC. The real 
> reason, again, is that G.997.1 specifically defines the range 
> of values and meaning for many attributes and our MIB follows 
> it as much as we could. 
> 
> Taking the Textual Conventions mentioned in this comment as examples:
> Xdsl2LineLdsf- G.997.1 uses the value 0 to inhibit LDSF and 1 
> for forcing LDSF. We preferred explicitly using those values. 
> Xdsl2LineCeFlag- CEFLAG is defined by G.997.1 as a bitmap 
> with a single bit. So, the values range is 0 and 1.
> Xdsl2LineSnrMode-TruthValue uses the value 1 for true and 2 
> for false, while G.997.1 uses 1 for disable and 2 for enable.
> 
> There is still one TC (Xdsl2LineForceInp) that could be 
> replaced by the TruthValue. This will be performed.  
> 
> Comment T7
> --------------
> Comment regarding to using RowStatus only to delete rows
> Response: We'll add text in the relevant DESCRIPTION clauses 
> to explain that the agent rejects any SET operation which 
> sets row status to a value other than delete(6)
> 
> Comment T8
> --------------
> Comment: why not replace inventory information in 
> Xdsl2LineInventoryEntry with entPhysicalTable in RFC4133
> Response: There are several arguments against the idea. 
> However, the most important one is that we need to provide 
> the inventory for both near-end and far-end units and that 
> means two rows per each ifIndex. So, we cannot use RFC4133 
> for inventory because the indexing scheme is inappropriate.
> 
> Comment T9
> --------------
> Comment: what happens when row is validated, etc.
> Response: We agree that there's a need to perform several 
> changes in the DESCRIPTION clause of row-status objects. This 
> will include removing the text about validating the row 
> content (i.e., as we cannot explain how we expect the 
> implementation to perform that) as well as giving more 
> information regarding to deleting a "referenced" row. 
> 
> Comment T10
> --------------
> Comment requests explanation about how the thresholds in the 
> xdsl2ChAlarmConfProfileTable are being applied
> Response: First of all, RFC3705 includes TCs and we use one 
> of them in the referred table. Second, we suggest to add a 
> text in the top part of the document explaining that only one 
> threshold trap per interval will be issued once the 
> individual counter exceeds the threshold defined for it. Is 
> that acceptable?
> 
> Comment T11
> --------------
> Comment suggests that the compliance should be function of 
> the flavor(s) of xDSL an agent implements. 
> Response: The MODULE-COMPLIANCE section applies to all 
> technology types: VDSL2/ADSL/ADSL2 and ADSL2+. The assumption 
> of G.997.1 is that a typical implementation supports a 
> mixture of technologies and transmission modes, not a single 
> selected one, and that's why the abstract attribute was 
> originally defined as a bit map rather than an enumeration of 
> modes. The idea is that a typical operator wishes to serve 
> all transmission modes supported by the remote units so he 
> prepares, for each service package, a setup that can satisfy 
> multiple use cases. 
> Theoretically, Most of the MIB attributes are relevant for 
> all or at least multiple xDSL technologies. There are still 
> several which are relevant for a specific technology. We 
> didn't want to complicate the compliance section because 
> otherwise we would also need to handle attributes that are 
> sometimes mandatory and sometimes optional (and what happens 
> when you have a mixed scenario..?). So, we believe an agent 
> implementation should conform to the compliance clause but 
> also consult with ITU-T G.997.1 to see exactly what is 
> required depending on the mixture of the various transmission 
> modes relevant for the specific operator.  
> 
> Comment E1
> --------------
> Comment: s/ a more comprehensive/a complementary/
> Response: The ADSL2 MIB is recommended for implementations 
> that do not implement VDSL2 and do not want to be affected by 
> it at all. The NG-xDSL MIB (this draft) has a wider scope of 
> technologies and is recommended for implementations of VDSL2 
> (only VDSL2 or together with older DSL technologies) and are 
> ready to pay the "price". The "price" is expressed in various 
> ways, e.g., the need to implement the "subcarrier group" 
> related attributes for DELT also for ADSL/2/2+, although 
> those attributes are meaningful only in VDSL2.
> So the new MIB is not a complementary one but a solution for 
> the same problem space, only with a wider set of DSL technologies.
> 
> Comment E2
> --------------
> Comment: list of abbreviations
> Response: OK
> 
> Comment E3
> --------------
> Comment: Section 2.3.2 duplicates text from the TC-MIB module itself
> Response: OK. We'll delete it.
> 
> Comment E4
> --------------
> Comment: page 28 - s/This MIB allows supporting/This MIB 
> module allows supporting
> Response: OK.
> 
> Comment E5
> --------------
> Comment: page 31 - s/ Network Elements may /Network Elements 
> MAY/ and s/The xTU-C should / The xTU-C SHOULD/
> Response: OK.
> 
> Comment E6
> --------------
> Comment: In SMIv2 we do not usually speak about attributes 
> but about objects
> Response: We'll correct the relevant text.
> 
> Comment E7
> --------------
> Comment: DESCRIPTION clause of the MIB module duplicates text 
> in the Overview section
> Response: We'll use a short summary in the overview section 
> and a full description in the MIB module.
> 
> Comment E8
> --------------
> Comment: 'an ifType of vdsl(xxx)'. It is good to add at least 
> at the first occurrence a note to the RFC Editor
> Response: OK.
> 
> Comment E9
> --------------
> Comment: The DESCRIPTION clauses of Valid Intervals and 
> Invalid Intervals are almost void
> Response: We'll fill the DESCRIPTION clauses for these objects
> 
> Comment E10
> --------------
> Comment: Section 4 would benefit from one or two examples of 
> configuration templates
> Response: We prefer not to add any additional tutorial 
> material into the VDSL2 draft MIB. 
> 
> 
> Comments from David B Harrington
> --------------------------------
> 
> Comment: "One suggestion would be to put the 
> VDSL2-LINE-TC-MIB in a separate document."
> Response: This would require 2 RFC numbers for VDSL2 and we 
> don't like it. We also have an experience from RFC4706 and 
> the draft ANCP AN MIB (draft-ietf-ancp-mib-an-03) that have 
> the same structure as this draft.
> 
> Comment:"I strongly support Dan's request to eliminate some 
> of the redundancy in this document, and I recommend starting 
> with the textual convention triplication. You can probably 
> save 30% of the document length getting rid of unnecessary 
> textual convention definitions."
> Response: We have no real objection to removing the TCs that 
> are referenced only once and placing the definition in the 
> object definition. Is that also agreed by Dan? Any comment 
> from the WG members?
> 
> Comment: "It might be good to have a manageability 
> considerations section that discusses using short strings and 
> internal choices to minimize the resource impact."
> Response: We don't think this is necessary.
> 
> Dan and David, Thanks again for your time and your comments.
> 
> On behalf of the co-editors,
> Moti Morgenstern
> 
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "David Harrington" <[email-masked]>
Date: Thu, 22 Jan 2009 13:00:35 -0500

Wow! You need to take a closer look at this module.
In the past I just looked at your comments and made some suggestions.
(I was surprised to see a response to comments I forgot I made.)
I have not reviewed this module in depth. But their responses made me
look a little closer to understand what they were doing.

Here are a few of my favorites:

1) 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
   }
I love the abrreviations everywhere.
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.

2) I especially like the "you're screwed" counter - the
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."

I thought we discouraged resetting counters in IETF MIB modules?
Has this MIB been seriously reviewed by a MIB technical advisor?
Has this MIB module been reviewed by any management application
designers?

3) note the naming conventions for counters are not being followed -
xdsl2LineCmndConfBpscReqCount should probably be
xdsl2LineCmndConfBpscRequests.

4) xdsl2LineCmndConfBpscReqCount - note that this counter is not a
Counter32, but an Unsigned32.

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

6) from security consdierations "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.

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

8) Per section 4, you need to go read G.997.1 to understand the
conformance requirements for this MIB module. G.997.1 appears to not
be a free document.

--
I am NOT volunteering to be the MIB Doctor for this document. I have
dealt with huge MIB modules before, especially ones designed by people
from another SDO (e.g., Printer MIB). They are just way too painful to
work though, with people resistant to changes, and ADSL/VDSL is
totally unrelated to my day job.

But I think you need to have this MIB reviewed thoroughly, because it
looks to me like the designers do not have a good understanding of how
MIB modules should be designed for
interoperability with multiple simultaneous management apps, and for
usebaility by operators.

dbh

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, 
> Dan (Dan)
> Sent: Thursday, January 22, 2009 9:38 AM
> To: Moti Morgenstern; David B Harrington
> Subject: Re: [MIB-DOCTORS] AD review of 
> draft-ietf-adslmib-vdsl2-06.txt
> 
> Hi Moti,
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 22 Jan 2009 19:24:51 +0100

Well - at least I succeeded to trigger some more comments from you :-) 

If this is OK with you I will slightly edit and forward them to the
authors and WG. 

I will not hold the document further however. We have little bandwidth
and enthusiasm nowadays in reviewing MIBs. Several calls for volunteers
for a number of documents went unanswered. Everybody is doing work that
is more interesting and more important for their employers, and this is
fine, but we cannot hold documents forever in place waiting for MIB
advisors or for management application writers to review them. 

More opinions are welcome and more MIB reviews are especially welcome. 

Dan

> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, January 22, 2009 8:01 PM
> To: Romascanu, Dan (Dan); 'MIB Doctors (E-mail)'
> Subject: RE: [MIB-DOCTORS] AD review of 
> Hi Dan,
> (I was surprised to see a response to comments I forgot I 
> made.) I have not reviewed this module in depth. But their 
> responses made me look a little closer to understand what 
> they were doing.
> 
> xdsl2LineConfTemplateTable. (cnfg and conf both mean 
> configuration) I note that RFC2662 uses "conf" consistently.
> 
> 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. 
> Has this MIB module been reviewed by any management 
> application designers?
> 
> 3) note the naming conventions for counters are not being 
> followed - xdsl2LineCmndConfBpscReqCount should probably be 
> 4) xdsl2LineCmndConfBpscReqCount - note that this counter is 
> not a Counter32, but an Unsigned32.
> 
> 5) I am a bit concerned about the table that actually 
> contains the measurement - the xdsl2LineSegmentTable  The 
> actual measurement is in xdsl2LineSegmentBitsAlloc. It 
> appears the value is overloaded to provide subcarrier 
> allocation status, as well as the result of a line diagnostic test. 
> 
> xdsl2LineCmndConfBpsc could cause an unscheduled bits per 
> subcarrier measurement to be carried out on the line.", and 
> "Unauthorized changes to xdsl2LineCmndConfLdsf could cause an 
> unscheduled line test to be carried out on the line." Since 
> these two measurements report using the same object, and 
> since one measurement can interfere with the validity of the 
> measurement requested by a different manager, this seems to 
> have serious issues of information reliability.
> 
> **competing** standard to RFC2662. This does not complement, 
> or update, or obsolete RFC2662.
> 
> 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 
> manageent 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.
> 
> 8) Per section 4, you need to go read G.997.1 to understand 
> the conformance requirements for this MIB module. G.997.1 
> appears to not be a free document.
> 
> --
> I am NOT volunteering to be the MIB Doctor for this document. 
> I have dealt with huge MIB modules before, especially ones 
> designed by people from another SDO (e.g., Printer MIB). They 
> are just way too painful to work though, with people 
> resistant to changes, and ADSL/VDSL is totally unrelated to 
> my day job.
> 
> But I think you need to have this MIB reviewed thoroughly, 
> because it looks to me like the designers do not have a good 
> understanding of how MIB modules should be designed for 
> interoperability with multiple simultaneous management apps, 
> and for usebaility by operators.
> 
> dbh
> 
> 
> > [mailto:[email-masked]] On Behalf Of Romascanu, Dan 
> > (Dan)
> > > Comment suggests writing specifically in the MIB module, in the 
> > > DESCRIPTION clauses of the MIB tables, what is the persistence 
> > > policy relative to the objects in the table.
> search for 
> > > each of these objects in the MIB, not all of the objects mention 
> > > persistence in the DESCRIPTION clause. This is when the 
> persistency 
> > > is relevant to ALL objects and, when that happens, the 
> DESCRIPTION 
> > > clause of the containing table
> persistent 
> > > manner." So we believe the current situation is satisfactory.
> > > 
> > > Comment T2
> > > --------------
> > > Response: The observation is basically correct. Despite that, we 
> > > chose name indexes on purpose for ease of use by the operator and 
> > > consistency with all other xDSL MIBs.
> > > 
> > > Comment T3
> > > --------------
> > > Comment refers to rate-limiting notifications mentioned in the 
> > > document.
> > > Response: We used reserved bits because we want the VDSL2 MIB to 
> > > closely match the source document G.997.1.
> > > 
> > > Comment T5
> > > --------------
> > > Comment about the Textual Conventions with enumerated 
> INTEGER syntax 
> > > in which the list of values starts from zero.
> > > Response: Similar to T4 above this was done on purpose. 
> We want the 
> > > MIB to closely match the source document G.997.1 which already 
> > > defines the range of enumerated values for many attributes. Since 
> > > the syntax allows that we don't see it necessary to explain such 
> > > considerations in the MIB.
> > > 
> > > Comment T6
> > > --------------
> > > Comment about the Boolean objects with new TCs instead of using 
> > > TruthValue
> > > Response: We use TruthValue for 10 objects in the MIB, 
> so, it's not 
> > > that we are not familiar with that TC. The real reason, again, is 
> > > that G.997.1 specifically defines the range of values and meaning 
> > > for many attributes and our MIB follows it as much as we could.
> > > 
> > > Xdsl2LineLdsf- G.997.1 uses the value 0 to inhibit LDSF and 1 for 
> > > forcing LDSF. We preferred explicitly using those values.
> > > Xdsl2LineCeFlag- CEFLAG is defined by G.997.1 as a bitmap with a 
> > > single bit. So, the values range is 0 and 1.
> > > Xdsl2LineSnrMode-TruthValue uses the value 1 for true and 2 for 
> > > false, while G.997.1 uses 1 for disable and 2 for enable.
> > > 
> > > Response: We'll add text in the relevant DESCRIPTION clauses to 
> > > explain that the agent rejects any SET operation which sets row 
> > > status to a value other than delete(6)
> > > 
> > > Comment T8
> > > --------------
> > > However, the most important one is that we need to provide the 
> > > inventory for both near-end and far-end units and that means two 
> > > rows per each ifIndex. So, we cannot use RFC4133 for inventory 
> > > because the indexing scheme is inappropriate.
> > > 
> > > Comment T9
> > > --------------
> changes in 
> > > the DESCRIPTION clause of row-status objects. This will include 
> > > removing the text about validating the row content (i.e., as we 
> > > cannot explain how we expect the implementation to 
> perform that) as 
> > > well as giving more information regarding to deleting a 
> "referenced" 
> > > row.
> > > 
> > > Comment T10
> > > --------------
> > > Response: First of all, RFC3705 includes TCs and we use 
> one of them 
> > > in the referred table. Second, we suggest to add a text 
> in the top 
> > > part of the document explaining that only one threshold trap per 
> > > interval will be issued once the individual counter exceeds the 
> > > threshold defined for it. Is that acceptable?
> > > 
> > > Comment T11
> > > --------------
> > > Comment suggests that the compliance should be function of the 
> > > flavor(s) of xDSL an agent implements.
> > > Response: The MODULE-COMPLIANCE section applies to all technology 
> > > types: VDSL2/ADSL/ADSL2 and ADSL2+. The assumption of G.997.1 is 
> > > that a typical implementation supports a mixture of 
> technologies and 
> > > transmission modes, not a single selected one, and that's why the 
> > > abstract attribute was originally defined as a bit map 
> rather than 
> > > an enumeration of modes. The idea is that a typical 
> operator wishes 
> > > to serve all transmission modes supported by the remote 
> units so he 
> > > Theoretically, Most of the MIB attributes are relevant 
> for all or at 
> > > least multiple xDSL technologies. There are still several 
> which are 
> > > relevant for a specific technology. We didn't want to 
> complicate the 
> > > compliance section because otherwise we would also need to handle 
> > > attributes that are sometimes mandatory and sometimes 
> optional (and 
> > > what happens when you have a mixed scenario..?). So, we 
> believe an 
> > > agent implementation should conform to the compliance clause but 
> > > also consult with ITU-T G.997.1 to see exactly what is required 
> > > depending on the mixture of the various transmission 
> modes relevant 
> > > Response: The ADSL2 MIB is recommended for 
> implementations that do 
> > > not implement VDSL2 and do not want to be affected by it 
> at all. The 
> > > NG-xDSL MIB (this draft) has a wider scope of technologies and is 
> > > recommended for implementations of VDSL2 (only VDSL2 or together 
> > > with older DSL technologies) and are ready to pay the 
> "price". The 
> > > "price" is expressed in various ways, e.g., the need to implement 
> > > the "subcarrier group"
> > > related attributes for DELT also for ADSL/2/2+, although those 
> > > attributes are meaningful only in VDSL2.
> > > So the new MIB is not a complementary one but a solution for the 
> > > same problem space, only with a wider set of DSL technologies.
> > > 
> > > Comment E2
> > > --------------
> > > Comment: page 28 - s/This MIB allows supporting/This MIB module 
> > > allows supporting
> > > Response: OK.
> > > 
> > > Comment E5
> > > --------------
> > > Comment: page 31 - s/ Network Elements may /Network Elements MAY/ 
> > > and s/The xTU-C should / The xTU-C SHOULD/
> > > Response: OK.
> > > 
> > > Comment E6
> > > --------------
> > > Comment: In SMIv2 we do not usually speak about 
> attributes but about 
> > > objects
> > > Comment: DESCRIPTION clause of the MIB module duplicates 
> text in the 
> > > Overview section
> > > Response: We'll use a short summary in the overview section and a 
> > > full description in the MIB module.
> > > 
> > > Comment E8
> > > --------------
> > > Comment: 'an ifType of vdsl(xxx)'. It is good to add at 
> least at the 
> > > first occurrence a note to the RFC Editor
> > > Response: OK.
> > > 
> > > Comment E9
> > > --------------
> > > Comment: The DESCRIPTION clauses of Valid Intervals and Invalid 
> > > Intervals are almost void
> > > Response: This would require 2 RFC numbers for VDSL2 and we don't 
> > > like it. We also have an experience from RFC4706 and the 
> draft ANCP 
> > > AN MIB (draft-ietf-ancp-mib-an-03) that have the same 
> structure as 
> > > this draft.
> > > 
> > > Comment:"I strongly support Dan's request to eliminate 
> some of the 
> > > redundancy in this document, and I recommend starting with the 
> > > textual convention triplication. You can probably save 30% of the 
> > > document length getting rid of unnecessary textual convention 
> > > definitions."
> > > Response: We have no real objection to removing the TCs that are 
> > > referenced only once and placing the definition in the object 
> > > definition. Is that also agreed by Dan? Any comment from the WG 
> > > members?
> > > 
> > > Comment: "It might be good to have a manageability considerations 
> > > section that discusses using short strings and internal 
> choices to 
> > > minimize the resource impact."

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Jan 2009 20:19:05 +0100

> and enthusiasm nowadays in reviewing MIBs.

So we are done with serious MIB reviewing at the IETF?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 22 Jan 2009 20:25:12 +0100

MIB doctors to do the serious reviews. Are you willing to commit to
contribute?  Are the other MIB Doctors willing to help? At the current
pace it won't probably mean more than one document an year on average. 

Dan

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Thursday, January 22, 2009 9:19 PM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; MIB Doctors (E-mail)
> On Thu, Jan 22, 2009 at 07:24:51PM +0100, Romascanu, Dan (Dan) wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Jan 2009 20:38:47 +0100

> I hope not. But in order not to be done with serious reviews we need the

The reality is that I am processing much more documents for the
security directorate than I am doing MIB modules these days. And I am
doing this because I ended up chairing a Security Area WG doing
security for SNMP (and security area wg chairs are part of the
security directorate and participate in the document reviewing
efforts).

One difference is that the security directorate assigns documents
(actually on pretty short schedules) and the assignments plus the
reviews are all visible to everyone. That said, I acknowledge that
sometimes reviewing MIB modules for some unknown technology can be
quite time consuming, especially if the modeling is somehow screwed
up. I am not sure whether assignments work here, but why not try?

My experience with MIB reviews has actually been that the initial
review is not the time sink. What follows afterwards (checking that
the comments were understood, changes applied correctly, iterating
this several times) is usually taking much more time and can stretch
over months. I have not experienced this with security directorate
reviews...

/js

---

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

reviews in earlier phases. This worked in a majority of cases when
volunteers were available but not always. In this case we did not have a
volunteer, but then the document did not reach yet Last Call. We can try
assignments ... again actually.  It still depends on the availability
and responsiveness of the MIB Doctors. 

Just curious - Why do you believe that MIB reviews (especially the
follow-up and implementing comments phases) end by being more time
consuming than security reviews? Is this just the nature of the beast? 

Dan

> Sent: Thursday, January 22, 2009 9:39 PM
> To: Romascanu, Dan (Dan)
> On Thu, Jan 22, 2009 at 08:25:12PM +0100, Romascanu, Dan (Dan) wrote:
> 
> > I hope not. But in order not to be done with serious 
> reviews we need 
> > the MIB doctors to do the serious reviews. Are you willing 
> to commit 
> > to contribute?  Are the other MIB Doctors willing to help? At the 
> > current pace it won't probably mean more than one document 
> an year on average.
> 
> The reality is that I am processing much more documents for 
> the security directorate than I am doing MIB modules these 
> days. And I am doing this because I ended up chairing a 
> Security Area WG doing security for SNMP (and security area 
> wg chairs are part of the security directorate and 
> participate in the document reviewing efforts).
> 
> One difference is that the security directorate assigns 
> documents (actually on pretty short schedules) and the 
> assignments plus the reviews are all visible to everyone. 
> That said, I acknowledge that sometimes reviewing MIB modules 
> for some unknown technology can be quite time consuming, 
> especially if the modeling is somehow screwed up. I am not 
> sure whether assignments work here, but why not try?
> 
> My experience with MIB reviews has actually been that the 
> initial review is not the time sink. What follows afterwards 
> (checking that the comments were understood, changes applied 
> correctly, iterating this several times) is usually taking 
> much more time and can stretch over months. I have not 
> experienced this with security directorate reviews...
> 
> /js
> 
> --

---

From: "David Harrington" <[email-masked]>
Date: Thu, 22 Jan 2009 15:13:06 -0500

Part of the problem is the sheer size of this mib. 
The Printer MIB - a huge mib - was done in a document of 171 pages.
This document is 227 pages.
The MIB Definitions spans 180 pages!!!
The Security Considerations alone requires eight pages.

Part of the problem is the attitude.
When you made comments to improve the quality of the MIB, the authors
blew most of them off. When I suggested they break the document down
into multiple RFCs, (separated TCs) they blew that off too. Who wants
to go do expert review of a document where the authors fight you on
most changes? 

Especially if the ADs and IESG won't push back on them to make the
changes ("we don't want to hold up the document")? I have run into
this multiple times with documents I have reviewed as a MIB Doctor.
Why should we bother doing expert reviews at all? 

I guess this sends a definite signal - if you want a MIB document
approved just make it really huge so it is too expensive time-wise for
MIB Doctor review, and resist any suggested changes to make sure the
review process is even more expensive for MIB Doctors. And if the
authors are unresponsive enough to drag out the time, the IESG won't
want to hold up the document. 

And I guess the previous advice - follow the guidelines of RFC4181 -
no longer matters:

1) 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) they do not follow the RECOMMENDED OID assignment scheme for
notifications

3) I already mentioned some other points that I think conflict with
RFC4181.

dbh

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Thursday, January 22, 2009 2:25 PM
> To: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Jan 2009 21:16:51 +0100

> consuming than security reviews? Is this just the nature of the

I don't really know - I can only speculate. Perhaps this is also just
my personal not very objective perception. Contributing factors might
be:

a) Long response times. After a few weeks of silence, I often feel
   like starting from scratch.

b) Dealing with people who do not understand SNMP well; you sometimes
   end up explaining real software engineering basics (such as why
   overloading semantics is a bad idea) or how to break a model into
   multiple tables using suitable indexing schemes or the difference
   between basic data types or how SNMPv3 works since all the authors
   know are community strings or ...

c) MIB modules dealing with technology and its specific terminology
   which is simply not accessible. Even if you manage to get the
   documents in question, this does not guarantee that you can figure
   out from reading what the technology really does.

d) Then there are special situations like MIB modules coming from
   other organizations where communication between the IETF and the
   other organization is difficult.

Security reviews are just concerned with IETF protocols/documents and
often it is possible to consult some other (readable) RFC for the
background reading. And if that does not work, it is usually easy to
find a competent person to talk to who speaks a familiar language (in
terms of the terminology used during the conversation).

But perhaps I was just more lucky with my security directorate
assignments so far. Don't tell them. ;-)

/js

---

From: "David Harrington" <[email-masked]>
Date: Thu, 22 Jan 2009 15:22:33 -0500

beast because the work is simply more detailed. 

MIB reviews of 180-page mibs takes way more work.

If you want volunteers, how about setting a rule that says MIBs should
not exceed 50 pages, or something? I know that is an artificial CLR,
but I just have great difficulty justifying committing my company's
resources to the time that will be required to volunteer to expert
review a MIB this size, especially with uncooperative authors.

dbh

> Sent: Thursday, January 22, 2009 2:50 PM
> I tried to make life easier to MIB Doctors by allocating MIB 
> doctors for

---

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

believe is appropriate for their needs. 

Actually this document has 230 pages!

Yes, committing our employers time is a challenge for all of us. So is
managing a team of volunteers :-) 

Dan

> Sent: Thursday, January 22, 2009 10:23 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Cc: 'MIB Doctors (E-mail)'
> MIB reviews do take a lot more work. It is partially the 
> nature of the beast because the work is simply more detailed. 
> 
> If you want volunteers, how about setting a rule that says 
> MIBs should not exceed 50 pages, or something? I know that is 
> an artificial CLR, but I just have great difficulty 
> justifying committing my company's resources to the time that 
> will be required to volunteer to expert review a MIB this 
> size, especially with uncooperative authors.
> 
> dbh
> 
> > I tried to make life easier to MIB Doctors by allocating 
> MIB doctors 
> > for reviews in earlier phases. This worked in a majority of 
> cases when 
> > volunteers were available but not always. In this case we 
> did not have 
> > a volunteer, but then the document did not reach yet Last Call.
> > We can try
> > > security directorate than I am doing MIB modules these 
> days. And I 
> > > am doing this because I ended up chairing a Security Area 
> WG doing 
> > > reviews are all visible to everyone.
> > > That said, I acknowledge that sometimes reviewing MIB modules for 
> > > some unknown technology can be quite time consuming, 
> especially if 
> > > the modeling is somehow screwed up. I am not sure whether 
> > > assignments work here, but why not try?
> > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Jan 2009 21:28:29 +0100

> The MIB Definitions spans 180 pages!!!

Wow.

The SMIv2 has lots of (sometimes surprising) constraints; obviously we
forgot to put a constraint on the maximum number of macro invocations
per MIB module in place to force authors to write short modules. :)

/js

---

From: "David Harrington" <[email-masked]>
Date: Thu, 22 Jan 2009 15:31:34 -0500

There are far fewer things you need to be concerned about than in a
MIB.
Security is being stressed much more, so more people are learning
about it.
How much stress are we putting on training people how to write MIBs?

The attitude towards MIBs from the IESG seems to be "well, that's old
hat now; we don't really care much about it, so quality isn't really
important anymore. Let's just let the document go through". 

It's too bad that seems to be the attitude of the IESG. Because other
SDOs (IEEE, ITU, SNIA, DOCSIS) are increasingly recognizing the
importance of MIB management for their technologies, and are coming to
the IETF for our expert assistance and review.

dbh

> Sent: Thursday, January 22, 2009 3:17 PM
> To: Romascanu, Dan (Dan)
> On Thu, Jan 22, 2009 at 08:50:21PM +0100, Romascanu, Dan (Dan)

---

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

There are some more comments from David Harrington listed below. 

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

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

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

3) Xdsl2LineEntry  ::=
   SEQUENCE {

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?

Thanks and Regards,

Dan

---

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

be split in a number of smaller documents, beyond separating the TCs? I
have made a comment on these lines in my AD review, also asking for the
elimination of the redundant TC definitions, but I did not formulate it
as a show stopper.

I would certainly support as an AD all MIB Doctors reviews and would not
let documents with critical flaws get approved. 

Dan

> Sent: Thursday, January 22, 2009 10:13 PM
> Hi,
> When you made comments to improve the quality of the MIB, the 
> authors blew most of them off. When I suggested they break 
> the document down into multiple RFCs, (separated TCs) they 
> blew that off too. Who wants to go do expert review of a 
> document where the authors fight you on most changes? 
> 
> Especially if the ADs and IESG won't push back on them to 
> make the changes ("we don't want to hold up the document")? I 
> have run into this multiple times with documents I have 
> reviewed as a MIB Doctor.
> I guess this sends a definite signal - if you want a MIB 
> document approved just make it really huge so it is too 
> expensive time-wise for MIB Doctor review, and resist any 
> suggested changes to make sure the review process is even 
> more expensive for MIB Doctors. And if the authors are 
> unresponsive enough to drag out the time, the IESG won't want 
> to hold up the document. 
> 
> And I guess the previous advice - follow the guidelines of 
> RFC4181 - no longer matters:
> 
> 1) The TruthValue TC SHOULD be used in the SYNTAX clause of 
> object definitions
> 2) they do not follow the RECOMMENDED OID assignment scheme 
> for notifications
> 
> 3) I already mentioned some other points that I think 
> conflict with RFC4181.
> 
> 
> dbh
> 
> current

---

From: "David Harrington" <[email-masked]>
Date: Thu, 22 Jan 2009 16:20:11 -0500

original message, so I cannot tell what I said in my original review.
I made the suggestion to split out the TCs as a way to reduce the size
of the document, and the response was:

> don't like it. 

I am not the MIB Doctor for this document, or I might have been more
forceful.
And there were other ways to reduce the size, such as eliminating
triplicate text, that could be done first.

Unfortunately, RFC4181 can cut both ways - size would not be
considered a critical flaw.
But it is enough of a flaw to discourage MIB Doctors from
volunteering.

dbh

> Sent: Thursday, January 22, 2009 3:50 PM
> To: David Harrington; [email-masked]
> Cc: MIB Doctors (E-mail)
> Did you make a clear comment in the past requesting that this
document

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 23 Jan 2009 09:42:10 +0100

Dan

> Sent: Thursday, January 22, 2009 11:20 PM
> Since I am not the MIB Doctor for this document, I did not 
> save my original message, so I cannot tell what I said in my 
> original review.
> I made the suggestion to split out the TCs as a way to reduce 
> the size of the document, and the response was:
> 
> > Comment: "One suggestion would be to put the VDSL2-LINE-TC-MIB in a 
> > separate document."
> don't like 
> > it.
> I am not the MIB Doctor for this document, or I might have 
> been more forceful.
> And there were other ways to reduce the size, such as 
> eliminating triplicate text, that could be done first.

I made the same comment in my review and I expect this to be fixed in
the revised I-D. 

> But it is enough of a flaw to discourage MIB Doctors from 

I agree with the last, but on the other hand there is an overhead in
creating separate documents which need to be advanced in parallel to
make sense, and even from the reviewers perspective reviewing two or
more mid-size documents instead of a large one is not much more
appealing. 

Dan