RE: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

So if we do allow this, then why are we so hard on ourselves
when some labels are added in the sense that we then require 
a new MODULE-COMPLIANCE and to make sure that the old one
only lists the labels that existed originally?

Or would we accept the proposal below and then require that
the MODULE-COMPLIANCE (but here they only do TCs, so we
would have to keep an eye on it later) would only REQUIRE
the enumerated values?

Just thinking aloud here

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: dinsdag 8 april 2003 0:18
> To: Mreview (E-mail)
> Subject: FW: Important question about 
> draft-ietf-ipsec-doi-tc-mib-07.txt
> 
> 
> MIB Doctors --
> 
> Here is one I had not encountered before:  folks who want to define
> enumerated INTEGER objects that are allowed to assume values that
> are not in the enumeration list.  Technically this is not legal (cf.
> RFC 2578 Section 7.1.1).  Practically, it does not seem that it
> should cause much harm, since enumerated INTEGERS can be extended by
> having more enumerations added.  In view of this, is the rule
> against assuming values other than the ones specifically enumerated
> just another crummy little rule that should not be enforced?  This
> would amount to treating enumerated INTEGER like ASN.1 does (i.e.,
> the enumerations are just distinguished values, but in no way
> constrain what values may be assumed).
> 
> Opinions?
> 
> //cmh
> 
> ---------- Forwarded message ----------
> Date: Mon, 07 Apr 2003 15:02:01 -0400
> From: John Shriver <jshriver+ietf@sockeye.com>
> To: C. M. Heard <heard@pobox.com>
> Cc: IPsec WG <ipsec@lists.tislabs.com>,
>      "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> Subject: Re: Important question about 
> draft-ietf-ipsec-doi-tc-mib-07.txt
> 
> C. M. Heard wrote:
> > On Sat, 5 Apr 2003, C. M. Heard wrote:
> > % The WG needs to be aware that (according to RFC 2578 
> Section 7.1.1)
> > % the only values allowed for objects defined with these enumerated
> > % INTEGER TCs are the named numbers that are actually present in the
> > % enumeration list.  Thus, managed objects defined with these TCs
> > % cannot represent values in the ranges that are reserved 
> for private
> > % use amongst cooperating systems.  If it is intended that objects
> > % defined using these TCs be able to represent arbitrary 
> values of the
> > % corresponding parameters, including the "private use" 
> values, then a
> > % SYNTAX value other than enumerated INTEGER will be required -- for
> > % instance, Unsigned32 with a subrange, as is used in the definition
> > % of IkePrf.  Of course, in that case there would be no need to have
> > % the IANA maintain these TCs:  they could be defined once, in a
> > % WG-maintained document, with the value list in a conventional
> > % assigned number registry.
> > 
> > On Mon, 7 Apr 2003, John Shriver replied:
> > 
> >>Let me be sure that I understand your intent.  Because RFC 
> 2578 Section
> >>7.1.1 says that the only legal values of an enumeration are 
> those in a
> >>list, and there may be numbers in the list from the 
> user-reserved space
> >>that may not be in the list, we should abandon any effort 
> to provide an
> >>enumeration for any of these number spaces in any MIB for IPsec?
> >>
> >>Instead, they should all be range-limited INTEGERS[?]
> > 
> > 
> > More probably, range-limited Unsigned32 (like IkePrf).  But 
> yes, that's
> > the idea, if the managed objects defined with these TCs are 
> supposed to
> > be able to represent all possible values of the 
> corresponding parameter.
> > 
> > 
> >>[A]nd there is no attempt at having software convert small
> >>positive integers into strings that might make sense to a human,
> >>and instead people have to look it up by hand?
> > 
> > 
> > An enumerated INTEGER TC does not do quite that much.  All 
> that can be
> > done with the parseable information in such a TC is to build a table
> > that converts the values in the enumeration list into the 
> corresponding
> > enumeration labels.  You don't get any of the descriptive 
> text that is
> > present in the ASN.1 comments.
> 
> As a user, I have found the enumeration labels much more 
> useful than a 
> raw number.  Few agents present the ASN.1 comments in a very 
> accessible 
> manner.  (Well, I never used any of the fancy $500,000 SNMP 
> management 
> systems.)
> 
> > 
> > To be weighed against this benefit is the cost to the IANA 
> of having to
> > maintain both a conventional registry and a MIB module for 
> the majority
> > of the IPsec-related assigned numbers.  My past experience 
> with stuff
> > that requires two (or more) versions of the truth to be manually
> > synchronized suggests to me that this cost will be rather 
> high.  Note
> > that some of the TCs (XyzExchangeType and XyzNotifyType) require
> > synchronized updates in more than two places.
> 
> I would hope that the IANA would never try and keep two files 
> synchronized.  As the I-D states, the itent was that the MIB would 
> become THE definitive document.  This is certainly what has happened 
> with the ifType MIB, although that was MIB-centric.
> 
> All programmers know that source-file synchronization is evil.
> 
> > 
> > 
> >>This strikes me as a disservice to the real customers, which are the
> >>users of any IPsec MIBs.  (RFC 2578 is not a customer.)  The entire
> >>purpose of this MIB was to eliminate those manual lookups.
> > 
> > 
> > In retrospect, it might have been better if the SMI had adopted the
> > ASN.1 rule that enumerations only specified distinguished 
> values, and
> > that the underlying type was allowed to have all INTEGER 
> values (well,
> > all in the range -2147483648..2147483647, since the SMI restricts
> > INTEGER to that range).  But that wasn't what was decided, and the
> > current rule is the one we have to live with.
> 
> I think that the current set of MIBs are not absolutely pure in 
> adherence to the standards.
> 
> > 
> > 
> >>I was thinking that a customer using these MIBs who had a 
> product using
> >>a proprietary value would simply EDIT their copy of this 
> MIB to include
> >>the offending value.  There's no "do not edit under penalty 
> of law" tag
> >>on the MIB.
> > 
> > 
> > Although not sanctioned by the SMI, a customer could indeed 
> perform such
> > edits.  However, they would have to be re-applied whenever 
> the "official"
> > version was updated with a new registered value, which is clearly
> > undesirable.  I think such edits should be discouraged.
> 
> So should private use numbers be discouraged.
> 
> > 
> > 
> >>Rather than abandon the enumerations, I would instead 
> propose to reserve
> >>one value in each and every enumeration, which would represent all
> >>values which are "undefined" within the enumeration.  The 
> numeric value
> >>of it would be 65536, which is out of the real protocol 
> range for all
> >>the numbers.
> >>
> >>Then MIB authors who need to reveal the user-reserved 
> values can have a
> >>second variable that reveals the raw INTEGER number.  (What 
> fun!  But
> >>I'm not writing that MIB.)
> > 
> > 
> > That will work, since all of the items that have "private 
> use" ranges
> > don't include 65536 as a legitimate value.  Again, however, 
> the question
> > must be asked whether the automatic generation of 
> integer-to-enum-label
> > tables is worth the cost of using two objects to represent 
> one value.
> 
> This was somewhat of a tongue-in-cheek suggestion.  I doubt that most 
> MIB authors would go to the effort.  We'd just lose the information. 
> (Or vendors would ignore the 65536, and put in the real value.)
> 
> > 
> > 
> >>Or, I can edit the MIB to give every enumeration a tag for every
> >>reserved value.  Like on IpsecDoiSecProtocolId, add 
> privateUse249(249),
> >>privateUse250(250), privateUse251(251), etc.  But I can 
> assure you that
> >>many of the management agents out there would crash in 
> flames if we do
> >>that.  In my experience, they are exceptionally fragile...
> > 
> > 
> > I agree that this would not be a good idea, especially for the ones
> > that have private use ranges of 61440-65535, 65001..65535, or
> > 32768..65535.
> > 
> > Frankly, I think that the benefits from the enum labels are 
> not worth
> > the costs in this application.  The costs include both the burden on
> > the IANA of having to maintain synchronized registries and the need
> > to have extra MIB objects to represent the "private use" values.  I
> > think it would be better to use subranged Unsigned32 TCs in a
> > WG-maintained MIB module, with the DESCRIPTION and REFERENCE clauses
> > of those TCs pointing to the authoritative sources for the number
> > assignments (namely the defining RFCs and the IANA registries).
> > However, my role in this matter strictly advisory, and the decision
> > is ultimately up to the IPsec WG (subject of course to IESG and IANA
> > approval).
> 
> Well, I started this project 4 years ago because I thought that the 
> enumeration values really would make IPsec MIBs easier to use.
> 
> We discussed the "standards fudge" issue of the non-enumerated values 
> back then, and people on the IPsec list weren't offended by 
> the problem. 
>   A common-sense standards bending didn't bother them.  I don't have 
> time to dig the archives...
> 
> > 
> > Regards,
> > 
> > Mike Heard
> 
> 
> 
> 
>