FW: draft-ietf-hubmib-efm-cu-mib-07 LC comments

Continuation of the previous mail on the subject, below my second reply.
Regards,
-E.=20

> -----Original Message-----
> From: Edward Beili=20
> Sent: Thursday, May 24, 2007 11:58
> To: 'Alfred H=CEnes'
> Cc: [email protected]; Dan Romascanu ([email protected])
> Subject: RE: draft-ietf-hubmib-efm-cu-mib-07 LC comments
>=20
> Alfred,
> Thanks again. See my reply inline below.
>=20
> Regards,
> -E.
>=20
> > -----Original Message-----
> > From: Alfred H=CEnes [mailto:[email protected]]
> > Sent: Thursday, May 24, 2007 10:48
> > To: Edward Beili
> > Cc: [email protected]
> > Subject: Re: draft-ietf-hubmib-efm-cu-mib-07 LC comments
> >=20
> > Edward,
> > thanks for your very quick and detailed response.
> > Please find inline below a few comments on selected open topics.
> >=20
> > > Alfred,
> > > Thank you very much for your comments, I fully appreciate
> > the time and
> > > effort you put into checking the draft. I agree with=20
> almost all of=20
> > > your comments. See my rebuttal inline below.
> > >=20
> > > Bert,
> > > How do you want me to proceed - should I issue a new=20
> version of the=20
> > > draft?
> > >
> > > ...
> > >
> > >> A subsequent message will address the remaining textual flaws in=20
> > >> Sections 1..6  I have observed.
> >=20
> > 'Strategic' consideration for the next steps:
> >=20
> > I have myriads of textual issues, in particular=20
> missing/wrong articles=20
> > etc. to report.
>=20
> BTW, last night when I was looking at the draft I realized=20
> that some of the references, in particular various 10P=20
> related profiles in Clause 30 are wrong, I was using an old=20
> version of the draft at the time of writing and since then=20
> didn't check it. My bad:(
>=20
> > Taking altogether, that IMHO will deserve a new draft, for=20
> clarity and=20
> > for the ease of all parties involved.
> >=20
> > From previous messages I conclude that you start from an XML source.
> > Perhaps it would be much more efficient if you could provide me the=20
> > source, and I could make the proposed changes in a copy thereof
> > (-- this will not happen before Friday evening).  This=20
> would save me a=20
> > lot of time and decrease the amount of text to be produced,=20
> and with=20
> > that version at hand you could certainly derive an accepted version=20
> > more efficiently -- thus speeding up the entire process.
> >=20
> > If you agree, I propose to start from the version after the edits=20
> > already discussed, and perhaps further changes as a result=20
> from other=20
> > comments.  For best timing, your then current intermediate source=20
> > version on Friday evening (in your time zone) would be the best=20
> > starting point.
> >=20
> > Otherwise, if I do not obtain an updated version, I will start from=20
> > the published -07.txt version, for my additional comments.
>=20
> I agree, I'll try to implement all the changes and send you=20
> the final xml file by Saturday night, I'm China now, flying=20
> back home tonight, not sure I'll be able to do this by Friday=20
> night. Since I'm going to check all the references again, I=20
> might as well do it against 802.3-2005 instead of=20
> 802.3ah-2004. That was a comment some time ago from Yakov=20
> Stein, which we decided to decline.=20
>=20
> > >> (A)  =3D=3D=3D=3D  IF-CAP-STACK-MIB  =3D=3D=3D=3D
> > >>
> > >>
> > >> (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=20
> separately with=20
> > >> other areas of applicability in mind, i.e., the
> > ifCapStackTable (and
> > >> its inverse) might be applicable for other scenarios of stacked=20
> > >> 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,=20
> > >> ifCapStackTable rows should not be instantiated unless and until=20
> > >> 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).
> > >=20
> > > EFMCu interfaces with flexible cross-connect are just one example=20
> > > 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=20
> > > 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.
> > >=20
> > > The DESCRIPTION text clearly states that ifStackTable describes=20
> > > cross-connect capability of the devices with stacked
> > interfaces. Apart
> > > from EFMCu there are G.Bond interfaces (their MIB modules=20
> 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.
> > >=20
> > > Therefore, I suggest leaving this text as it is.
> >=20
> > I fully agree with almost all of your explanation.
> > That's what I reasonably had expected, and what the major=20
> part of the=20
> > DESCRIPTION clause says.
> >=20
> > The ultimate reason for my note was that "any existing"=20
> might well be=20
> > misunderstood to extending the scope of the last sentence=20
> there beyond=20
> > whay is specified in this MIB module.
> >=20
> > To propose a 'least impact' change:
> > What about  "... any such existing value ..."   ?
> >                     ^^^^^^
>=20
> Agree.
>=20
> > >> (3)  efmCuNumPMEs S
> > >>
> > >> The semantics of that object apparently perfectly fit the=20
> > >> 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 ?
> > >=20
> > > 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=20
> > > concluded that Gauge32 is inappropriate here.
> > > Please correct me if I'm wrong here.
> >=20
> > The statement,
> >   "the number of PMEs can never be negative or more than 32"
> > IMHO perfectly represent the expected behavior of an object of
> > Gauge32 (0..32) type.  On page 23, RFC 2578 says:
> >=20
> >  7.1.7.  Gauge32
> >=20
> >    The Gauge32 type represents a non-negative integer, which may
> >    increase or decrease, but shall never exceed a maximum value, nor
> >    fall below a minimum value.  The maximum value can not be greater
> >    than 2^32-1 (4294967295 decimal), and the minimum value=20
> can not be
> >    smaller than 0.
> >=20
> > IMHO, this is a perfect match to the semantics intended for=20
> > efmCuNumPMEs.
>=20
> I'm still not convinced (I've read the Gague32 description,=20
> it just sounds wrong to me to represent a number of apples as=20
> a gauge; speed/throughput/attenuation/acceleration would be=20
> perfect candidates for a gauge), but willing to go with your=20
> suggestion. (Bert/Dan, your advice would be appreciated?)=20
>=20
> > >> (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'.
> > >=20
> > > 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=20
> > > implementer that there can be multiple references to the
> > same entry (from multiple PMEs).
> > > So I would suggest to say:
> > >=20
> > >           If an 'active' entry is referenced via
> > efmCuPme2BsMode, the
> > >           entry MUST remain 'active'. Note that there can
> > be multiple
> > >           references to the same entry.
> >=20
> > A shorter variant might be:
> >=20
> >             If an 'active' entry is referenced via some=20
> > efmCuPme2BsMode
> >             instance(s), the entry MUST remain 'active'.
>=20
> Agree.
> =20
> > >> (7)  efmCuPme10PProfileTable D 3
> > >>
> > >> There are a couple of issues with the table of predefined=20
> > >> 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!)
> > >=20
> > > I agree.
> > > Suggest to swap the order of the=20
> efmCuPme10PPayloadURateProfile and=20
> > > efmCuPme10PPayloadDRateProfile, since the IEEE standard defines=20
> > > Downstream rate before the Upstream.
> >=20
> > I do not know the state of initial implementation(s) and=20
> whether such=20
> > change would already negatively effect these; therefore I=20
> had proposed=20
> > the other way.
> > But if you do not see any obstacles, swapping the entries in the=20
> > efmCuPme10PProfileEntry syntax (SEQUENCE statement), the order of=20
> > description and the assigned OIDs, is clearly the better choice!
>=20
> Yes, initial draft implementations do exist and I had a=20
> similar concern a while ago on another change, but Bert=20
> assured me that the existence of such implementations is not=20
> a good excuse at all.
> =20
> > >> 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)"
> > >=20
> > > Agree, to further avoid confusion I suggest to add the word
> > 'profile'
> > > after the 'default', i.e.
> > >=20
> > >           1      1      3    2,6,10,11    20    20=20
> (default profile)
> >=20
> > Even better!  I fully agree.
> > (But please verify that the 72 colunm margin really does=20
> admit this!)
>=20
> I verified, it's ok.
>=20
> > >> (15)  efmCuNotificationGroup NOTIFICATION-GROUP
> > >>
> > >> The draft says:
> > >>
> > >>         NOTIFICATIONS {
> > >>           efmCuLowRateCrossing,
> > >>           efmCuPmeLineAtnCrossing,
> > >>           efmCuPmeSnrMgnCrossing,
> > >>           efmCuPmeDeviceFault,
> > >>           efmCuPmeConfigInitFailure,
> > >>           efmCuPmeProtocolInitFailure
> > >> |  --       efmCuPmeDeviceFault,
> > >> |  --       efmCuPmeLocalPowerLoss
> > >>         }
> > >>
> > >> ...
> > >=20
> > > Both comments should be removed.
> >=20
> > O.k.
> >=20
> > > efmCuPmeDeviceFault already appears in the conformance group.
> >=20
> > Oooops, now that you say that ...  I really have overlooked that!
> > =20
> > =20
> > Kind regards, again,
> >    Alfred.
> >=20
> > --
> >=20
> > +------------------------+------------------------------------
> > --------+
> > | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math.,=20
> > Dipl.-Phys.  |
> > | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18=20
> >         |
> > | D-71254  Ditzingen     |  E-Mail:  [email protected]            =20
> >         |
> > +------------------------+------------------------------------
> > --------+
>=20