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

[John Shriver <jshriver+ietf@sockeye.com>]

C. M. Heard wrote:
> John Shriver wrote:
> 
>>C. M. Heard wrote:
>>John Shriver wrote:
>>
>>>>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[?]
>>>
> [ ... ]
> 
>>>>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.
>>
> [ ... ]
> 
>>We discussed the "standards fudge" issue of the non-enumerated values
>>back [when this project was started], and people on the IPsec list
>>weren't offended by the problem.  A common-sense standards bending
>>didn't bother them.
> 
> 
> The problem with bending the rules in this way is that it is
> confounds expectations that people have (based on what is in
> the standard) regarding what enumerated INTEGERs mean.  I put
> this question to the other MIB Doctors and got these answers:
> 
> On Mon, 7 Apr 2003, Randy Presuhn wrote:
> % What bothers me about this proposal is not so much the notion of
> % extending enumerations without adjusting the documentation, but
> % rather the semantic ambigiuities that will result due to the lack
> % of coordination of the enumeration assignments.  For this kind of
> % un-coordinated private use, OBJECT IDENTIFIERs are really the way
> % to go.  Otherwise, one has no way of knowing whether agent A's 42
> % means the same thing as agent (or manager) B's.

This applies EQUALLY to the ISAKMP/IKE protocol definitions. 
Implementation A's 64411 is indistinguishable from Implementation B's 
64411.  Even if they mean totally different things.  (Most are used in 
cases where Implementation A can tell if it is talking to one of it's 
own species.)

We are trying to design MIBs, and TCs, that can document the actual 
behavior of the protocol.  If the protocol is a bit screwy, that's life. 
  (Let's just say that ISAKMP/IKE does not comform to RFC 2578, at least 
in spirit.)

> 
> On Mon, 7 Apr 2003, Andy Bierman wrote:
> % I agree with Randy.  If they are leaving enum values unspecified
> % so vendors can assign their own value, then this is a misuse of
> % enumerated INTEGER.  If enums are really the appropriate data type,
> % and they know now that they want specific values defined, then
> % all enum values should be listed and documented.

The vendors are not assigning the numbers for the purpose of the MIB, as 
noted above, they are assigning it for the purpose of the protocol.  I 
would never have proposed this approach if these TCs were not VERY 
tightly coupled to the protocol.

(There was a place in the real MIBs that were once part of this effort 
where I did use Object Identifiers for cross referencing.  See 
saOakleyGroup in the long-expired draft-ietf-ipsec-ike-monitor-mib-02.txt.)

> 
> What the Randy's and Andy's comments are saying is that enumerated
> INTEGERs are the wrong data type for this application not because of
> an obscure technical violation of RFC 2578 but because this usage
> violates the semantics that are expected of enumerated INTEGERs.  I
> tend to agree with that, and that's why I have suggested subranged
> Unsigned32 would be a more appropriate choice.

A more straightforward description is that I tried to forge a compromise 
between multiple design goals:

1. Easy to impelement on the product without pain.  (This is why I 
export exactly what the protocol negotiated, no remapping to any other 
space).

2. Easy to use, in that the normally used values are displayed as an 
enumeration, even on commonly available free SNMP implementations.

3. Avoid the never reaches full standard problem by having the TC MIB 
managed by the IANA.


I will warn that the IPsec implementors in this working group are VERY 
harsh about any MIB proposals that intrude deeply into performance. 
There have been very contentious discussions.  They really aren't very 
interested in SNMP in the first place, which is obvious by the very 
minimal feedback all discussions of the MIBs have produced.  They won't 
bend very far to implement a MIB.

An approach that doesn't meet goal 1 won't get implemented.

If strict RFC 2578 conformance is the only way that IPsec MIBs can be 
published, I can assure you that goal 2 will be dropped in favor of goal 
1.  Having to map every sort of protocol number into a Object Identifier 
(Andy's approach) is going to be quite unpopular, even if approved by 
the working group, I doubt it would get the "implement it" vote.

> Thanks,
> 
> Mike Heard