[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: draft-ietf-snmpconf-pm-13.txt (fwd)



Snmpconf folks --

Bert Wijnen asked me to look at the SMICng warnings for
the MIB module in this draft.  Attached below are my
comments, which he has asked me to forward to the WG
mailing list.  The main thrust of these comments is
that I think it would be useful to users of the MIB
module if precise limits on index object sizes were
explicitly spelled out, and text to do that is offerred.
The proposed language also corrects a couple of typos in
the DESCRIPTION clauses of pmTrackingEPElement and
pmDebuggingElement.

A couple of points to note:

- The 128 sub-id limit does not leave much room for
all of the index objects that have been defined for
pmRoleEntry.  The WG _may_ wish to consider a different
indexing scheme to avoid this.  See discussion below.

- My comments  below on the unusual indexing for
pmPolicyEntry were made without having read the
Security Considerations sections.  After having done
so I see the reason why things are done this way and
withdraw that comment.

I hope that these comments are useful.

Mike Heard

---------- Forwarded message ----------
Date: Wed, 28 May 2003 12:36:13 +0200
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: C. M. Heard <heard@pobox.com>, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Subject: RE: draft-ietf-snmpconf-pm-13.txt

W.r.t. the INDEXes being able to exceed 128 subIDs, this
is what I posted to SNMPCONF mailing list:

  - Not sure if the Index entries that can go over 128 subids
    are documented completely in accordance with our
      draft-ietf-ops-mib-review-guidelines-01.txt 
    document. I have asked Mike Heard to check. 

I did discuss it with the authors (they had ntohing about it
in their DESCRIPTION clauses to begin with). So they added
some text. Not sure if we already had the dinfite text in our
guidelines about this stuff when they wrote up the text.

In any event, since I posted to the list that I have asked you
to check it (in the context of being author for the review
guidelines), it seem quite appropriate if you post this to the
WG list. It seems they will need to do one more rev anyway, and
so, it should be easy for them to pick up your proposed text
changes. If your not subscribed to the list, I can also post it
for you and make a statement that I agree.

See further comments inline

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: woensdag 28 mei 2003 1:55
> To: Wijnen, Bert (Bert)
> Subject: Re: draft-ietf-snmpconf-pm-13.txt
> 
> 
> On Mon, 26 May 2003, Wijnen, Bert (Bert) wrote:
> > Mike, could you take a quick look at this doc?
> > 
> > Specifically, I think that these SMICng warningas are OK
> > but want to check with you. I know that maybe the description
> > on the potential more than 128 subIDs is not ideal yet.. but
> > should we hold this doc for that? It does (in each case)
> > at least mention that users should be carefull to not
> > create OIDs with more than 128 subids.
> > 
> > Thanks,
> > Bert
> 
> Personally, I think that some of these warnings warrant discussion
> with the authors if the original MIB reviewer did not already do
> so, but I will let you be the judge of that.  Details inline.
> 
> > ----- SMICng warnings -----
> > C:\bwijnen\smicng\work>smicng pm.inc
> > W: f(pm.mi2), (773,1) Row "pmElementTypeRegEntry" has indexing
> >    that may create variables with more than 128 sub-ids
> 
> Specifically, the index of pmElementTypeRegEntry can exceed the OID
> size limit by 11 sub-ids.  The DESCRIPTION clause for
> pmElementTypeRegOIDPrefix, which is the only index component, does
> say:
> 
>         As this object is used in the index for the
>         pmElementTypeRegTable, users of this table should be careful
>         not to create entries that would result in OIDs with more
>         than 128 subidentifiers.
> 
> A more explicit statement would be:
> 
>         As this object is used in the index for the
>         pmElementTypeRegTable, users of this table should be careful
>         not to create entries that would result in instance names
>         with more than 128 subidentifiers.  That will occur if this
>         object has more than 117 subidentifiers.
> 
> That language serves the same purpose as a SIZE constraint (which
> is not allowed for OBJECT IDENTIFIERs).
> 
> > W: f(pm.mi2), (942,1) Row "pmRoleEntry" has indexing that may
> >    create variables with more than 128 sub-ids
> 
> Specifically, the index of pmRoleEntry can exceed the OID size limit
> by 142 sub-ids.  The DESCRIPTION clause for pmRoleElement does say:
> 
>          As this object is used in the index for the pmRoleTable,
>          users of this table should be careful not to create entries
>          that would result in OIDs with more than 128 subidentifiers.
> 
> In my opinion, this warning is inadequate, because there are other
> variable-length index objects for this table, and no constraint on
> this object could allow the 128 sub-id limit to be met if all of
> those other index objects assume the maximum lengths indicated by
> their SIZE constraints.  So I think (following the advice in section
> 4.6.5 of the guidelines document) that something like the following
> text needs to be present in the DESCRIPTION clause of the row object
> pmRoleEntry:
> 
>          Users of this table should be careful not to create entries
>          that would result in instance names with more than 128
>          subidentifiers.  That will occur if the total number of
>          components in pmRoleElement, pmRoleContextName,
>          pmRoleContextEngineID, and pmRoleString exceeds 114.
> 
> NOTE:  this table _may_ be dangerously close to the edge of
> unusability.  pmRoleContextName and pmRoleContextEngineID have a
> maximum size of 32 octets.  The latter is probably OK since the
> practice in the SNMP-FRAMEWORK-MIB mandates a max size of 32 octets
> for an engine ID;  however, the former may be slim since RFC 3412
> does not (as far as I can tell) mandate a max size for a context
> name.
Mmm... 3412 may not. But 3415 has at least 
   vacmContextName  OBJECT-TYPE
       SYNTAX       SnmpAdminString (SIZE(0..32))
and based on that I made the pmMIB authors do things like:
   pmRoleContextName OBJECT-TYPE
       SYNTAX      SnmpAdminString (SIZE (0..32))

>        pmRoleString has a max size of 64, which may or may not
> be slim, but even if this were chopped down to a maximum of 32
> octets then pmRoleElement could have no more than 18 sub-ids, which
> is definitely rather slim for a RowPointer object.  This point could
> merit discussion with the MIB module authors.
> 
Mmm... I see your point. They first had pmRoleString limited to 32.
So I wondered: "that means that in some langauges it can only be 
4 characters... is that sufficient" and so they raised it to 64.

So it sounds like we might be better off with a complete different
idnexing scheme?

> > W: f(pm.mi2), (1053,1) Row "pmCapabilitiesEntry" has indexing
> >    that may create variables with more than 128 sub-ids
> 
> Specifically, the index of pmCapabilitiesEntry can exceed the OID
> size limit by 11 sub-ids.  The DESCRIPTION clause for
> pmCapabilitiesType, which is the only index component, does say:
> 
>          As this object is used in the index for the
>          pmCapabilitiesTable, users of this table should be careful
>          not to create entries that would result in OIDs with more
>          than 128 subidentifiers.
> 
> A more explicit statement would be:
> 
>          As this object is used in the index for the
>          pmCapabilitiesTable, users of this table should be careful
>          not to create entries that would result in instance names
>          with more than 128 subidentifiers.  That will occur if this
>          object has more than 117 subidentifiers.
> 
> That language serves the same purpose as a SIZE constraint (which
> is not allowed for OBJECT IDENTIFIERs).
> 
> > W: f(pm.mi2), (1181,1) Row "pmCapabilitiesOverrideEntry" has
> >    indexing that may create variables with more than 128 sub-ids
> 
> Specifically, the index of pmCapabilitiesOverrideEntry can exceed
> size limit by 11 sub-ids.  The DESCRIPTION clause for
> pmCapabilitiesOverrideType, which is the only index component, does
> say:
> 
>          As this object is used in the index for the
>          pmCapabilitiesOverrideTable, users of this table should be
>          careful not to create entries that would result in OIDs
>          with more than 128 subidentifiers.
> 
> A more explicit statement would be:
> 
>          As this object is used in the index for the
>          pmCapabilitiesOverrideTable, users of this table should be
>          careful not to create entries that would result in instance
>          names with more than 128 subidentifiers.  That will occur
>          if this object has more than 117 subidentifiers.
> 
> That language serves the same purpose as a SIZE constraint (which
> is not allowed for OBJECT IDENTIFIERs).
> 
> > W: f(pm.mi2), (1620,1) Row "pmTrackingPEEntry" has indexing that
> >    may create variables with more than 128 sub-ids
> 
> Specifically, the index of pmTrackingPEEntry can exceed the OID size
> limit by 78 sub-ids.  The DESCRIPTION clause for pmTrackingPEElement
> does say:
> 
>          As this object is used in the index for the
>          pmTrackingPETable, users of this table should be careful
>          not to create entries that would result in OIDs with more
>          than 128 subidentifiers.
> 
> A more explicit statement would be:
> 
>          As this object is used in the index for the
>          pmTrackingPETable, users of this table should be careful
>          not to create entries that would result in instance names
>          with more than 128 subidentifiers.  That may occur
>          if this object has more than 50 subidentifiers.
> 
> That language serves the same purpose as a SIZE constraint (which
> is not allowed for RowPointer objects, i.e., OBJECT IDENTIFIERs).
> 
> A better solution in this case (because there are multiple
> variable-length index objects) might be to put something like
> the following language into the pmTrackingPEEntry DESCRIPTION
> clause:
> 
>          Users of this table should be careful not to create entries
>          that would result in instance names with more than 128
>          subidentifiers.  That will occur if the total number of
>          components in pmTrackingPEElement, pmTrackingPEContextName,
>          and pmTrackingPEContextEngineID exceeds 114.
> 
> > W: f(pm.mi2), (1730,1) Row "pmTrackingEPEntry" has indexing that
> >    may create variables with more than 128 sub-ids
> 
> Specifically, the index of pmTrackingEPEntry can exceed the OID size
> limit by 78 sub-ids.  The DESCRIPTION clause for pmTrackingEPElement
> does say:
> 
>          As this object is used in the index for the
>          pmElementTypeRegTable, users of this table should be
>          careful not to create entries that would result in OIDs
>          with more than 128 subidentifiers.
> 
> The above should at least s/pmElementTypeRegTable/pmTrackingEPTable/.
> A more explicit statement would be:
> 
>          As this object is used in the index for the
>          pmTrackingEPTable, users of this table should be careful
>          not to create entries that would result in instance names
>          with more than 128 subidentifiers.  That may occur
>          if this object has more than 50 subidentifiers.
> 
> That language serves the same purpose as a SIZE constraint (which
> is not allowed for RowPointer objects, i.e., OBJECT IDENTIFIERs).
> 
> A better solution in this case (because there are multiple
> variable-length index objects) might be to put something like
> the following language into the pmTrackingEPEntry DESCRIPTION
> clause:
> 
>          Users of this table should be careful not to create entries
>          that would result in instance names with more than 128
>          subidentifiers.  That will occur if the total number of
>          components in pmTrackingEPElement, pmTrackingEPContextName,
>          and pmTrackingEPContextEngineID exceeds 114.
> 
> > W: f(pm.mi2), (1841,1) Row "pmDebuggingEntry" has indexing that
> >    may create variables with more than 128 sub-ids
> 
> Specifically, the index of pmDebuggingEntry can exceed the OID size
> limit by 79 sub-ids.  The DESCRIPTION clause for pmDebuggingElement
> does say:
> 
>          As this object is used in the index for the
>          pmElementTypeRegTable, users of this table should be
>          careful not to create entries that would result in OIDs
>          with more than 128 subidentifiers.
> 
> The above should at least s/pmElementTypeRegTable/pmDebuggingTable/.
> A more explicit statement would be:
> 
>          As this object is used in the index for the
>          pmDebuggingTable, users of this table should be careful
>          not to create entries that would result in instance names
>          with more than 128 subidentifiers.  That may occur if
>          this object has more than 49 subidentifiers.
> 
> That language serves the same purpose as a SIZE constraint (which
> is not allowed for RowPointer objects, i.e., OBJECT IDENTIFIERs).
> 
> A better solution in this case (because there are multiple
> variable-length index objects) might be to put something like
> the following language into the pmDebuggingEntry DESCRIPTION
> clause:
> 
>          Users of this table should be careful not to create entries
>          that would result in instance names with more than 128
>          subidentifiers.  That will occur if the total number of
>          components in pmDebuggingElement, pmDebuggingContextName,
>          and pmDebuggingContextEngineID exceeds 113.
> 
> NOTE: for all above the above the OID size limits were derived from
> the smilint warning messages, which are attached.  There were no
> smilint warnings for the stuff that follows.
> 
> > W: f(pm.mi2), (1627,19) Row "pmTrackingPEEntry" does not have a
> >    consistent indexing scheme - index items must be in same order
> >    as used in INDEX clause for "base row" pmPolicyEntry
> 
> This warning may indeed be indicative of a problem, but not in
> this table.  The thing that SMICng is beefing about is the fact
> that the INDEX clause of pmPolicyEntry is
> 
>     INDEX { pmPolicyAdminGroup, pmPolicyIndex }
> 
> and in order for pmTrackingPEEntry to be a proper extension table of
> pmPolicyEntry its index clause should start with the same two items.
> pmTrackingPEEntry uses pmPolicyIndex only.  Now this is OK, because
> pmPolicyIndex is defined to be a _unique_ policy index, i.e.,
> further differentiation by pmPolicyAdminGroup is not needed.  But

I had questioned this qith the authors. And after that they made it
explicit that pmPolicyIndex is indeed to be unique. So I agree that
from that point of view, there now seems to be no issue.

> that brings up the question why pmPolicyAdminGroup is even in the
> index clause of pmPolicyEntry.  Under the circumstances it possibly
> should not be.  Certainly its presence makes it harder than
> it otherwise would be for an application to correlate the contents
> of the pmTrackingPETable, pmTrackingEPTable, and pmPolicyTable.  It
> might be a good idea to ask the authors of the MIB module to explain
> this design decision.
> 
I also kept saying that I find the indexing scheme weird.
The first para of the description clause:
        "An administratively assigned string that can be used to group
        policies for convenience, readability or to simplify
        configuration of access control.
kind of make me think is is OK.
It then hooks up to that in the Security Considerations section, which
puts yet some more justification to it... or so it seems to me.
Did you see that?

> > W: f(pm.mi2), (1742,19) Row "pmTrackingEPEntry" does not have a
> >    consistent indexing scheme - index items from current table
> >    must come after index items from other tables
> 
> This warning comes from the language in RFC 2578 section 7.8.1,
> i.e., SMICng interprets the text of that section to say that if
> there is any relationship between tables other than a 1-for-1
> augmentation or sparse augmentation, then one "must" follow
> 7.8.1(3).  However, RFC 2578 section 7.8.1 only says "should" and
> not "must" or "shall".  If one interprets the the lower-case
> "should" to mean SHOULD as defined in RFC 2119, then I would say
> that it is OK to ignore this warning.  The table DESCRIPTION clause
> says:
> 
>          This table is indexed in order to optimize retrieval of the
>          status of all policies active for a given element.
> 
> which is a valid reason for not having pmPolicyIndex appear first.
> 
I agree. And so I think it is OK.

> > W: f(pm.mi2), (1849,19) Row "pmDebuggingEntry" does not have a
> >    consistent indexing scheme - index items must be in same order
> >    as used in INDEX clause for "base row" pmPolicyEntry
> 
> I think that this warning should be ignored.  See the comments for
> the previous two warnings.
> 
I agree

> > W: f(pm.mi2), (1942,19) Variable "pmCapabilitiesType" in
> >    notification "pmNewCapabilityNotification" is an index for a
> >    table
> 
> It also happens to be the only column in the table.  So this warning
> should be ignored, too.
> 
I agree.

Thanks for your quick review. Let me know if you want to post about
the better text (as proposed by you) to the WG list or if I should do it.
Bert
> //cmh
>