Re: [Ips] FW: Initial review of http://www.ietf.org/internet-draf

[Keith McCloghrie <[e-mail]>]

> First, I still see:
> 
>     ::= { mib-2 999999 }             -- to be assigned by IANA
> 
> Keith, you know VERY WELL I think that we do NOT want that.
> The strongly recommended notation is:
> 
>     ::= { mib-2 xxx }             -- to be assigned by IANA
 
Sorry.  I hadn't noticed it; presumably, it's been 999999 for at least
the last 2+ years.  I've changed it, and I'm hopeful it will change again
in the near future.

> > > I think the warning is cause by the fact that there is no 
> > > DISPLAY-HINT.  Can you add those?
> > 
> > I can't because, as far as I know, there is no standard format for
> > displaying these.  Anyway, RFC 2579 says that DISPLAY-HINT is 
> > optional.
> > So, this is another bug in that compiler.  Why is the IETF's 
> > MIB review process relying upon a buggy compiler ??
> 
> OK, I asked "can you add those?" I did not say "you MUST add those".
> AS you note, they are optional. However the set of current MIB doctors
> have composed a set of guidelines for review, and document
>     draft-ietf-ops-mib-review-guidelines-02.txt
> represents the current guidelines and sect 4.6.3 recommends to add
> a DISPLAY HINT:
> 
>    4.6.3.  DISPLAY-HINT Clause
> 
>    The DISPLAY-HINT clause is used in a TC to provide a non-binding hint
>    to a management application as to how the value of an instance of an
>    object defined with the syntax in the TC might be displayed.  Its
>    presence is optional.
> 
>    Although management applications typically default to decimal format
>    ("d") for integer TCs which are not enumerations and to a hexadecimal
>    format ("1x:" or "1x " or "1x_") for octet string TCs when the
>    DISPLAY-HINT clause is absent, it should be noted that SMIv2 does not
>    actually specify any defaults.  MIB authors should be aware that a
>    clear hint is provided to applications only when the DISPLAY-HINT
>    clause is present.
> 
> So... Can you add one please.

I already answered: no because I don't know what the correct hint is.

> If nothing else, then use "d"

Why, if it might be wrong ??

Note that DISPLAY-HINT has always been a compromise between being
simple versus being powerful.  That is, DISPLAY-HINT was intentionally
kept simple even though its simplicity prevents it from being able to
represent complicated display formats.  Specifically, it's not possible
to express all display formats with DISPLAY-HINT, and thus, it makes
no sense for it to be required.  That's also why it's a "hint".

> If you disagree with the mib-review guideline. pls speak up on
> [e-mail] list, so we can re-evaluate. This guidelines doc
> is on its way to become a BCP.

But I don't disagree, because as your quote says, with no ambiguity
possible:

    Its presence is optional. 
 
> The compiler by the way only generates a warning, not an error!
 
I'm confused.  Why do you even get a warning for omitting something which
is optional ?

> > > > >    4. PhysicalIndexOrZero, HrSWInstalledIndexOrZero are 
> > > > >       very useful and generally applicable to many mib modules.
> > > > >       They look strangly wrong being defined here and 
> > > > >       should be defined in another TC, like Entity-MIB, or some 
> > > > >       common TC-MIB.
> > > > 
> > > > But they aren't, and thus, the best that this MIB module 
> > > > can do is to define the TC's itself.
> > > 
> > > Could you rename them to RcPhysicalIndexOrZero and 
> > > FcHrSWInstalledIndexOrZero
> > > so that they will not conflict if Entity MIB does define them later.
> > 
> > There will be no conflict.  First, the possibility of a descriptor
> > clash is ever-present in practically every deployment because of
> > Enterprise MIBs.  Second, MIB compilers have to cope with it, and they
> > do for the most part, although HP OpenView's compiler has had the same
> > bug for the last ~10 years, and most often shows up because of
> > OwnerString being defined as an OCTET STRING in IF-MIB and as a
> > DisplayString in RMON-MIB; if you delete one of the two definitions or
> > change them to both have the same syntax, OpenView stops complaining.
> >
> In principle we try to NOT get name clashes in STDs track MIB modules.
> Of course we have goofed up a few times, and we want to try to avoid so
> in the future, that is why I am asking (pretty serious) to consider the 
> name change and add the prefix. PLEASE!
> 
> > > But... SURPRISE (maybe), pls take a look at
> > > 
> > >    draft-ietf-entmib-v3-04.txt
> > > 
> > > and is on my AD plate for review!! So at least that one can be
> > > imported from ENTITY-MIB.
> > 
> > First, we don't want to risk any further delays.  (In the update that I've
> > just done, I changed the date from February 2003 to March 2004.  In other
> > words, we have waited 13 months for the benefit of the minor changes that
> > I'm making now :-(.)  So, let's not import from 
> > draft-ietf-entmib-v3-04.txt.
> > 
> If you do not want to IMPORT from entmibv3, I can accept that. I may want
> to re-open that if that entmib docs ends up as RFC earlier than yours.
> 
> But it DOES again show that you better add the requested prefix to the
> TC names.
> 
> > Second, as you may have noticed all(*) the FC-specific TC's in this MIB
> > are already prefixed with "Fc", and none of the generic TC's are
> > prefixed with "Fc".  I want to keep it that way, and since neither of
> > PhysicalIndexOrZero or HrSWInstalledIndexOrZero are FC-specific, I've
> > just deleted them.  (* -- actually, all but one because I made a
> > mistake with DomainIdOrZero.)
> > 
> So you have removed them I see.

Right, and therefore they won't conflict, which was your concern.

> And you have instead used Integer32.
> Although this is perfectly legal SMIv2, I think you understand VERY WELL
> that this is against the spirit of what we are trying to do with TCs.

I used Integer32 because that is the correct syntax in this case.
Specifically, it would be an error to define them with Unsigned32
because both values are constrained by the syntax of the index objects
which they reference, as defined in RFCs 2737 and 2790 respectively.

> If that is the way you want to go... fine, I guess we should make the docs
> informational or experimental and then you can do whatever you want
> as long as the SMIv2 use is legal to the letter instead of to teh spirit.
>
> > > > >    5. MicroSeconds, MilliSeconds should also be in some 
> > > > generic tc-mib...
> > > > 
> > > > But they aren't, and thus, the best that this MIB module 
> > > > can do is to define the TC's itself.
> >  > 
> > > Well, the SSPM-MIB (draft-ietf-rmonmib-sspm-mib-11.txt) which is in
> > > IETF Last Call DOES have a SspmMicroSeconds TC.
> > > I made them prefix with Sspm.. because I do foresee a future generic
> > > TC MIB for these things. So if you want to keep them in this MIB
> > > module I strongly recommend to name it FcMicroSeconds and FcMilliSeconds.
> > 
> > Again, naming them FcMilliseconds and FcMicroseconds would give the
> > reader the wromng impression.  These are NOT Fibre Channel units; they are
> > generic units. Fibre Channel's milliseconds/microseconds are NO different
> > from any other technology's milliseconds/microseconds.  Nevertheless,
> > because of the comment, I've deleted the two TC's.
> 
> And again use a plain Integer32 instead. OK... you win
 
You're right that Integer32 would be a mistake for these.  So, I went
to change them, but I found that I had previously changed all six of
them to Unsigned32.  However, in searching for other Integer32's, I
found FcDataFieldSize, FcBbCredit and FcDomainIdOrZero are defined as
Integer32's.  I think I inherited these when I started on this MIB
nearly 3 years ago.  Nevertheless, while they seem to be in the "it's
acceptable" category in draft-ietf-ops-mib-review-guidelines, I'd be
happy to change these three TC's to Unsigned32's if you want ??

> > > > >    6. fcmInstanceIndex DESCRIPTION is problematic for me. 
> > > > Either it stays static or it doesn't. 
> > > > >       Having something "desireable" is worthless to those 
> > > > writing mangement applications, they have to assume worst 
> > > > case always.
> > > > 
> > > > Not worthless, because if agent implementors heed the advice, 
> > > > then mgmt
> > > > apps can coded to check whether the index values have 
> > > > been retained
> > > > over the last restart, and only if not, do they need to 
> > > > re-synchronize
> > > > their database.  That is, it is an optimization for the 
> > > > common case of
> > > > index values being retained, but the fallback still works 
> > > > in the case 
> > > > (hopefully less common) when all knowledge of index 
> > > > values is lost.
> > > 
> > > So would it make sense to phrase it with a SHOULD ??
> >  
> > It wouldn't make sense to say a system SHOULD retain the 
> > values if all of
> > its non-volatile memory is replaced, i.e., to say that it 
> > should when we
> > know there are circumstances when it can't !!
> > 
> Would it be better then to just say instead of "desirable" to add
> a sentence that says somethink aka
>   "This should no tbe taken as an easy excuse to ignore the desire
>    for keeping the value constant across restarts"
> We did a similar thing for commitFailed and undoFailed.

I've reworded it to:

  It is mandatory to keep this value constant between restarts of the
  agent, and to make every possible effort to keep it constant across
  restarts (but note, it is unrealistic to expect it to remain constant
  across all re-configurations of the local system, e.g., across the
  replacement of all non-volatile storage).

> >             "The administratively desired type of this port.  
> > Each port
> >             will typically only be able to support a subset 
> > of these types."
> > 
> > Is it really necessary for me to remove the second sentence ??
> > 
> Mike... you raised it?

I've removed it anyway.

> > > > >             DESCRIPTION
> > > > >             "A list of Counter32-based statistics which are 
> > > > a shadow of
> > > > >             the Counter64 statistics in the 
> > fcmPortStatsTable, for
> > > > >             systems which do not support Counter64."
> > > > >       I suggest the text mention it should "shadow" the 
> > > > lower 32 bits?
> > > >  
> > > > If that isn't what "shadow" means, then I don't know what it 
> > > > does mean, and we shouldn't use the term at all.
> > > > 
> > > I prefer if you spell out they contain the low order 32 bits.
> > 
> > I removed the phrase containing "shadow".
> 
> I do not think that addresses our concerns.
> For an SNMPv1 manager which obtains those. I bet they are the lower32 bits
> of the Counter64. What is so darn difficult to spell it out?

It would be easy to "spell it out" (easier than arguing about it :-),
but that doesn't make it right.  While it's a likely and reasonable
implementation strategy, there's no advantage in requiring it.
Specifically, who cares whether they are the lower 32 bits??   An
SNMPv1 manager reading them isn't going to care (because it can't read
the Counter64's), and neither will an SNMPv2c/SNMPv3 manager because
the Counter32's are redundant as far as it's concerned.

[Aside: this reminds me of the old story about conformance testing
with X.25.  Even though most of the original X.25 implementations
passed the conformance test, none of them interoperated with each
other.  In other words, any tests of these Counters should check that
their values accurately reflect their semantics, and we should not
provide fuel for a worthless conformance test which would compare the
low32 bits of the Counter64 with the Counter32's value.]

> > > So in that case it can be stored with InetAddressType "unknown" and
> > > the value that you received in the InetAddress, no?
> > 
> > No.  The GS-3 spec gives, as an example, the use of a URL in this
> > string, with the URL being for an SNMP, or HTTP or XML agent. 
> > I've added some words to the DESCRIPTION stating this.
> > 
> Look much better already.
> How can I get access to the GS-3 spec?
 
I'll send you a URL in another message.

> > > So I do not see a reason to NOT use InetAddress(Type) combo.
> > > > >    21. 
> > > > >                       
> > > > > End of Report
> > > > > 
> > > 
> > > An additional remark from me:
> > > 
> > > I strongly recommend to rename DomainIdOrZero to FcDomainIdOrZero.
> > > The current definition of the TC is certainly not a generic DomainId
> > > definition is it?
> > 
> > Agreed.  DomainIdOrZero is FC-specific, and so it was my mistake to
> > call it DomainIdOrZero.
> > 
> Peace.
> 
> When I do SMICng, I get:
> 
>    W: f(fcmgmt.mi2), (2211,1) OBJECT-GROUP "fcmLinkBasicGroup" is not
>       used in a MODULE-COMPLIANCE in current module
> 
> That probably means that this is an optional GROUP. We recommend in mib
> review guidelines to include it in a MODULE_COMPLIANCE and spell out that
> it is optional. This to make it clear that it is intentional instead
> of accidental.
 
I had added it at the end, after the OBJECT statements, but I've now moved it
to be next to the other GROUP statements.  Does that stop SMICng from
complaining ??

The updated version is in the same place:

    ftp://ftpeng.cisco.com/ftp/kzm/pub/draft-ietf-ips-fcmgmt-mib-05.txt

Keith.

_______________________________________________
Ips mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ips