Subject: [Hubmib] RE: draft-ietf-hubmib-efm-cu-mib-07 LC comments

From: "Edward Beili" <[email-masked]>
Date: Sun, 27 May 2007 19:40:00 +0300

Alfred/Bret,

On the references to G.991.3, T1.424, and TS101 270-1 in EFM-CU-MIB, in efmCuPme10PBandplanPSDMskProfile, efmCuPme10PUPBOReferenceProfile and efmCuPme10PBandNotchProfiles:

1st of all I do agree that the standards in question should be written the same way in all places (already fixed that in the new version of the draft).

What I'm contemplating now is whether to list these standards in the REFERENCE clauses of the relevant objects. I don't think it is necessary and here is my reasoning:

The tables listing these standards in the DESCRIPTION clauses are the exact copies of the relevant IEEE 802.3ah tables. From the EFM-CU-MIB point of view, the only important part of these tables is the profile number, which is an index of a relevant entry in a relevant table. In other words when describing profile(1) the only important thing to say about it is that it is the index of the 1st entry in the relevant 802.3ah table. The meaning of this entry (value of each columnar parameter) is described in the relevant 802.3ah section, already referenced in the REFERENCE clauses of the management objects. The 10Pass-TS PHY/equipment manufacturers would implement these tables, and a management station would use the efmCuPme10P*Profile objects to activate these entries as a single profile.

Regards,
-E.

> -----Original Message-----
> From: Edward Beili 
> Sent: Thursday, May 24, 2007 2:20
> To: 'Alfred H־nes'
> Cc: [email-masked]; [email-masked]
> Subject: RE: draft-ietf-hubmib-efm-cu-mib-07 LC comments
> 
> Alfred,
> Thank you very much for your comments, I fully appreciate the 
> time and effort you put into checking the draft. I agree with 
> almost all of your comments. See my rebuttal inline below.
> 
> Bert,
> How do you want me to proceed - should I issue a new version 
> of the draft?
> 
> Regards,
> -E. 
> 
> > -----Original Message-----
> > From: Alfred H־nes [mailto:[email-masked]]
> > Sent: Wednesday, May 23, 2007 22:39
> > To: Edward Beili
> > Cc: [email-masked]; [email-masked]
> > Subject: draft-ietf-hubmib-efm-cu-mib-07 LC comments
> > 
> > Hello,
> > as recommended by Bert Wijnen yesterday, I've hurried up, 
> and hereby I 
> > submit my notes on the more-than-just-editorial issues I found in 
> > draft-ietf-hubmib-efm-cu-mib-07, plus the issues in Section 7 & up.
> > 
> > A subsequent message will address the remaining textual flaws in 
> > Sections 1..6  I have observed.
> > 
> > All but the last two items below deal with the MIB modules in the 
> > draft.  For brevity, I use the following shorthand notation 
> to locate 
> > the affected part of the text there:
> > 
> >       <object_name> D <n>
> >                    /    \
> >                   /      paragraph number; positive values count
> >     DESCRIPTION clause   top-down, negative values count 
> from the end
> > or:
> >       <object_name> <X>
> > 
> > where the following single capital letters <X> are used:
> >      S ... SYNTAX clause
> >      O ... OBJECTS clause
> >      R ... REFERENCES clause
> > 
> > The items are listed in textual order.
> > Issues spanning more than one object (etc.) will be noted 
> for either 
> > place in the text via cross-references.
> > 
> > 
> > (A)  ====  IF-CAP-STACK-MIB  ====
> > 
> > 
> > (1)  ifCapStackTable D -2
> > 
> > Please reconsider the trailing phrase,
> > 
> >   "... for any existing value of x or y." .
> >            ^^^^^^^^^^^^^^^^^^
> > 
> > This might be misleading, since in the preceding text, the 
> scenario of 
> > EFM-Cu interfaces is only referred to by "e.g.".
> > 
> > The IF-CAP-STACK-MIB obviously has been specified separately with 
> > other areas of applicability in mind, i.e., the 
> ifCapStackTable (and 
> > its inverse) might be applicable for other scenarios of stacked 
> > interfaces too (although not specified yet).
> > Currently these tables should only be applied to EFMCu 
> interfaces; in 
> > all other cases where it would be conceptionally valid, 
> > ifCapStackTable rows should not be instantiated unless and until 
> > specified otherwise.
> >
> > Therefore, I recommend to replace the above phrase by:
> > 
> >   "... for any ifIndex values x or y representing an EFMCu PME
> >    or PCS, respectively."
> > 
> > (or similar).
> 
> EFMCu interfaces with flexible cross-connect are just one 
> example where IF-CAP-STACK-MIB can be used.
> In fact ifCapStackTable (and its inverse) can be implemented 
> for _any_ stacked interface. Of course in some cases it would 
> not add any value, for example for interfaces without 
> flexible cross-connect, the ifCapStackTable would be 
> semantically identical to the ifStackTable - meaning that the 
> sublayers which MAY be connected, as indicated by if 
> CapStackTable, ARE connected, as indicated by ifStackTable.
> 
> The DESCRIPTION text clearly states that ifStackTable 
> describes cross-connect capability of the devices with 
> stacked interfaces. Apart from EFMCu there are G.Bond 
> interfaces (their MIB modules are being drafted) which use 
> this table, so specifying EFMCu here is incorrect. While 
> there is no point in implementing this table for devices 
> without cross-connect capability, it won't do any harm if implemented.
> 
> Therefore, I suggest leaving this text as it is.  
>  
> > (B)  ====  EFM-CU-MIB  ====
> > 
> > 
> > (2)  efmCuLowRateCrossing O
> > 
> > The ASN.1 comment,
> > 
> >   -- ifIndex is not needed here since we are under specific PCS
> >                                       
> > ^^^^^^^^^^^^^^^^^^^^^^^^^ is unclear, and in fact not needed at all:
> > the ifIndex value occurs in the index part of all the OIDs of the 
> > objects included in this NOTIFICATION, anyway!
> > 
> > I recomment to remove that ASN.1 comment entirely, or else 
> to replace 
> > it by:
> > 
> >   -- The ifIndex of the specific PCS is delivered in the index part
> >      of the OIDs of the following objects' instances.
> > 
> > (or similar).
> 
> You are right, I wrote this comment for myself, it should be removed.
> 
> > (3)  efmCuNumPMEs S
> > 
> > The semantics of that object apparently perfectly fit the 
> > specification of the Gauge32 SYNTAX in SMIv2.
> > 
> > Are there specific reasons to *not* specify a subrange of
> > Gauge32 for this object, but using Unsigned32 instead ?
> 
> My understanding of Gauge32 is it should be used for 
> "latched" objects, that is, whose information being modeled 
> can be greater than the maximum or smaller than the minimum.
> Since the number of PMEs can never be negative or more than 
> 32, I concluded that Gauge32 is inappropriate here. Please 
> correct me if I'm wrong here.
> 
> > (4)  efmCuPmeThreshSnrMgn D 2
> > 
> > The draft says:
> > 
> >           This object is writable for the CO subtype PMEs
> > |         (2BaseTL-O/10PassTS-R). It is read-only for the 
> CPE subtype
> >           (2BaseTL-R/10PassTS-R).
> > 
> > It should say:
> > 
> >           This object is writable for the CO subtype PMEs
> > |         (2BaseTL-O/10PassTS-O). It is read-only for the 
> CPE subtype
> >           (2BaseTL-R/10PassTS-R).
> 
> You are right, it should be corrected.
> 
> > (5)  efmCuPmeOperSubType D 2
> > 
> > The draft says:
> > 
> >           The operational sub type of the PME can be configured via
> >           efmCuPmeAdminSubType variable.
> > 
> > This might be confusing.  It should perhaps better say:
> > 
> >              vvvvvvvvv
> > |         The desired operational sub type of the PME can be
> > configured
> > |         via the efmCuPmeAdminSubType variable.
> >              ^^^^^
> 
> Ok.
> 
> > (6)  efmCuPme2BsModeRowStatus D 2
> > 
> > The draft says:
> > 
> >           If an 'active' entry is referenced via 
> efmCuPme2BsMode, the
> >           entry MUST remain 'active' until all references 
> are removed.
> > 
> > This is illogical and confusing.
> > It should perhaps better (and even simpler) say:
> > 
> >           If an 'active' entry is referenced via 
> efmCuPme2BsMode, the
> >           entry MUST remain 'active'.
> 
> I don't see a big difference between the two, but willing to 
> go with your wording. I think though that it is important to 
> remind the implementer that there can be multiple references 
> to the same entry (from multiple PMEs). So I would suggest to say:
> 
>           If an 'active' entry is referenced via efmCuPme2BsMode, the
>           entry MUST remain 'active'. Note that there can be multiple
> 	    references to the same entry.
> 
> > (7)  efmCuPme10PProfileTable D 3
> > 
> > There are a couple of issues with the table of predefined 
> > efmCuPme10PProfileTable entries presented there.
> > 
> > a)  The order of the columns does not exactly match the (OID)
> >     order of the columnar objects specified subsequently.
> >     This might raise some confusion.
> > 
> >     I recommend to exchange the last two columns to achieve
> >     a matching order.  (Changing the columnar object sequence
> >     and the OIDs for efmCuPme10PPayloadURateProfile and
> >     efmCuPme10PPayloadDRateProfile will perhaps not be feasible!)
> 
> I agree. Suggest to swap the order of the 
> efmCuPme10PPayloadURateProfile and 
> efmCuPme10PPayloadDRateProfile, since the IEEE standard 
> defines Downstream rate before the Upstream.
> 
> > b)  In the first table row, the "(default)" is attached to the
> >     value in the last column without any intervening white space.
> > 
> >     I strongly suspect that this tag conceptually is affixed to
> >     the entire row, not to the last columnar valu there.
> >     I that's right, to avoid confusion, I recommend to insert
> >     at least one space character before the "(default)"
> 
> Agree, to further avoid confusion I suggest to add the word 
> 'profile' after the 'default', i.e.
>           1      1      3    2,6,10,11    20    20 (default profile)
> 
> > c)  From the 4th row down to the last row, in the third column
> >     the value '0' (for UPBO p#) is specified.
> > 
> >     But the efmCuPme10PUPBOReferenceProfile SYNTAX does not
> >     admit the enumerated value 0, it only allows (1..9).
> > 
> >     What's wrong there ???
> 
> Right, I added the value of profile(0) to 
> efmCuPme10PUPBOReferenceProfile, with a description - no profile.
> 
> > d)  The last row (profile index 22) in its second row gives a
> >     Bandplan PSDMask# value of '30'.
> > 
> >     But the efmCuPme10PBandplanPSDMskProfile SYNTAX does not
> >     admit the enumerated value 30, it only allows (1..29).
> > 
> >     What's wrong there ???
> 
> Missed that one, I added the value 30 with description.
> 
> > (7')  efmCuPme10PProfileTable D -3 and D -2
> > 
> > Because of item (7) above, I include the following remarks 
> on textual 
> > flaws in the subsequent paragraphs as well:
> >                            vvvv
> > a) Change:  "... be created by during agent initialization ..."
> > 
> >    to say:  "... be created during agent initialization ..."
> 
> Agree.
> 
> > b) Delete the two commas from D -2.
> > 
> > 
> > (8)  efmCuPme10PBandplanPSDMskProfile S
> > 
> > See item (7) d)  above!
> 
> Agree.
> 
> > (9)  efmCuPme10PBandplanPSDMskProfile D 2  and  R
> > 
> > a)
> > The profile table uses short references for the "PSD Mask":
> >    'T1.424/T-U P1', 'TS1 101 270-1', and 'G.993.1 F.1.2.*' .
> > 
> > These should be detailed in the REFERENCE clause of the object.
> 
> Agree.
> 
> > b)
> > The ref. label "TS1 101 270-1" is used here, whereas in the 
> > efmCuPme10PUPBOReferenceProfile D, "ETSI TS 101 270-1", and in the 
> > efmCuPme10PBandNotchProfiles D, "TS101 270-1"
> > is used for what perhaps denotes the same document.
> > 
> > Using a unified notation in all three tables would be appreciated!
> 
> Agree.
> 
> > (10)  efmCuPme10PUPBOReferenceProfile S
> > 
> > See item (7) c)  above!
> 
> Agree.
>  
> > (11)  efmCuPme10PUPBOReferenceProfile D 2  and  R
> > 
> > a)
> > As in item (9) a)  above:
> > 
> > The profile table uses short references for the "PSD Mask":
> >    'T1.424/T-U', and 'ETSI TS 101 270-1' .
> > 
> > These should be detailed in the REFERENCE clause of the object.
> > 
> > b)
> > See item  (9) b)  above !
> > 
> > 
> > (12)  efmCuPme10PBandNotchProfiles D 2  and  R
> > 
> > a)
> > The profile table uses short references for the table heading
> >    'G.991.3',  'T1.424/T-U', and 'TS101 270-1' .
> > 
> > These should be detailed in the REFERENCE clause of the object.
> > 
> > b)
> > See item  (9) b)  above !
> > 
> > 
> > (13)  efmCuPme10PBandNotchProfiles D -2
> 
> Agree
> 
> > The draft says:
> > 
> >           Any combination of profiles can be specified by ORing
> >           individual profiles, for example value of 0x0622 selects
> >           profiles 2,6,10 and 11.
> > 
> > The hex value given does not match the set of profiles listed.
> > [See RFC 3416, Section 2.5, paragraph #2 for the mapping of BITS.]
> > 
> > 0x0622 corresponds to 5,6,10,14 !
> > (The 1st nibble is for BITS 0,1,2,3, the 2nd for BIT 4,5,6,7, ...)
> > 
> > Assuming the set of profiles to be left unchanged, the hex 
> value must 
> > be corrected to 0x2230 .
> > 
> > Hence, the draft should say:
> > 
> >           Any combination of profiles can be specified by ORing
> >           individual profiles, for example value of 0x2230 selects
> >           profiles 2,6,10 and 11.
> 
> You are right. Must be corrected.
> 
> > (14)  efmCuPme10PStatusEntry D + other
> > 
> > The draft is not clear about the instantiation rules for 
> rows in the 
> > efmCuPme10PStatusTable.
> > 
> > From the D's of the columnar objects it can be concluded that such 
> > rows only make sense for 10PASS-TS PMEs, and that therefore the 
> > instantiation of efmCuPme10PStatusTable rows is not intended for 
> > 2-BASE-TL PMEs, and cannot be assumed to be mandatory in that case.
> > 
> > The efmCuCompliance MODULE-COMPLIANCE statement contains the lines:
> > 
> >           GROUP       efmCuPme10PStatusGroup
> >           DESCRIPTION
> >             "Support for this group is OPTIONAL for implementations
> >             supporting 10PASS-TS Phy."
> > 
> > Hence, even for 10PASS-TS PMEs, the instantiation of 
> > efmCuPme10PStatusTable rows is *not* mandatory.
> > 
> > Contrary to that, the efmCuPme10PStatusEntry OBJECT-TYPE 
> declaration 
> > contains the structural specification:
> > 
> >         AUGMENTS { efmCuPmeStatusEntry }
> > 
> > According to the SMIv2 (STD 58, RFC 2578, Section 7.8), this clause 
> > means that the efmCuPme10PStatusTable is a *dense* 
> augmentation of the 
> > efmCuPmeStatusTable, i.e. that the instantiation of any row
> > (efmCuPmeStatusEntry) there immediately enforces the 
> instantiation of 
> > the corresponging efmCuPme10PStatusEntry.
> > 
> > That makes no sense!
> > 
> > IMHO, the above AUGMENTS clause has to be substituted by:
> > 
> >         INDEX { ifIndex }
> 
> Agree.
> 
> > Also, the instantiation rules should be made explicit in the 
> > efmCuPme10PStatusTable D or the efmCuPme10PStatusEntry D .
> 
> Agree.
>  
> > (15)  efmCuNotificationGroup NOTIFICATION-GROUP
> > 
> > The draft says:
> > 
> >         NOTIFICATIONS {
> >           efmCuLowRateCrossing,
> >           efmCuPmeLineAtnCrossing,
> >           efmCuPmeSnrMgnCrossing,
> >           efmCuPmeDeviceFault,
> >           efmCuPmeConfigInitFailure,
> >           efmCuPmeProtocolInitFailure
> > |  --       efmCuPmeDeviceFault,
> > |  --       efmCuPmeLocalPowerLoss
> >         }
> > 
> > It remains unclear what has been intended with the two lines tagged 
> > above, written as ASN.1 comments.
> > 
> > a)
> > 'efmCuPmeDeviceFault' is well defined in the MIB module.
> > 
> > I cannot see any immediate reason why it is getting 
> excluded from the 
> > conformance groups.
> > 
> > Perhaps this line should be re-activated !
> >
> > b)
> > 'efmCuPmeLocalPowerLoss' does not appear anywhere else in the draft.
> > 
> > Perhaps this line should be dropped !
>  
> Both comments should be removed. efmCuPmeDeviceFault already 
> appears in the confirmance group.
>  
> > (16)  Section 7
> > 
> > In the second paragraph below the bulleted list,
> > change   "evasdrop"  -->  "eavesdrop" .
> 
> Right.
> 
> > (17)  Sections 8, 10, and 11
> > 
> > Hint:  To alleviate the job of the RFC-Editor and the IANA,
> >        - RFC 4836 and RFC 4837 should be substituted for the
> >          respective I-Ds;
> >        - the first paragraph of Section 8 apparently is void
> >          in the meantime (and hence should be deleted), by
> >          publication of RFC 4836 and IANA action for that RFC;
> >        - the text in Section 10 can be simplified;
> >        - one Normative and one Informative Ref. can be updated
> >          immediately from I-D to RFC.
> 
> Agree.
> 
> > I apologize for any errors introduced into this memo due to its 
> > hastily preparation.
> > 
> > If you like, please forward (parts of) this note to the 
> hubmib  list 
> > if you think the issues above should be discussed there.
> > 
> > Kind regards,
> >   Alfred H־nes.
> > 
> > --
> > 
> > +------------------------+------------------------------------
> > --------+
> > | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., 
> > Dipl.-Phys.  |
> > | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18 
> >         |
> > | D-71254  Ditzingen     |  E-Mail:  [email-masked]             
> >         |
> > +------------------------+------------------------------------
> > --------+
> > 

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: Alfred Hönes <[email-masked]>
Date: Sun, 27 May 2007 22:01:53 +0200 (MESZ)

Edward,
thanks for your note:
> 
> On the references to G.991.3, T1.424, and TS101 270-1 in EFM-CU-MIB,
> in efmCuPme10PBandplanPSDMskProfile, efmCuPme10PUPBOReferenceProfile
> and efmCuPme10PBandNotchProfiles:
> 
> 1st of all I do agree that the standards in question should be
> written the same way in all places (already fixed that in the new
> version of the draft).
> 
> What I'm contemplating now is whether to list these standards in
> the REFERENCE clauses of the relevant objects. I don't think it is
> necessary and here is my reasoning:
> 
> The tables listing these standards in the DESCRIPTION clauses are the
> exact copies of the relevant IEEE 802.3ah tables. From the EFM-CU-MIB
> point of view, the only important part of these tables is the profile
> number, which is an index of a relevant entry in a relevant table.
> In other words when describing profile(1) the only important thing to
> say about it is that it is the index of the 1st entry in the relevant
> 802.3ah table. The meaning of this entry (value of each columnar
> parameter) is described in the relevant 802.3ah section, already
> referenced in the REFERENCE clauses of the management objects. The
> 10Pass-TS PHY/equipment manufacturers would implement these tables,
> and a management station would use the efmCuPme10P*Profile objects
> to activate these entries as a single profile.

Well; that's an argument.

On the other hand, due to the columnar space restrictions enforcing
abbreviated references, it might anyway be a service for the reader
and the user of a management station to somewhere give the full
references.

If you dislike expanding the REFERENCE clauses of these objects,
an alternative might be to update the DESCRIPTION clause of the
efmCuMIB MODULE-IDENTITY, where [802.3ah] is expanded.
One possibility I envision would be to amend the IEEE 802.3ah
expansion there, without introducing new [...] style reference
tags, by a note like this:

      This document makes normative references to
      -  G.991.3,
      -  T1.424, and
      -  TS101 270-1,
      indirectly quoted as well by DESCRIPTION causes in this
      MIB module.  The full references for these standards are:

      ...
      ...
      ...

Kind regards,
  Alfred.