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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 8 Apr 2003 23:05:20 +0200

John,....
pls calm down. I think Mike is trying to do due dilligence and try
to explain what the issues are that he sees. He then also tries to
understand the issues from your side. Next step is to come up with
a good solution.

The way you respond, it sounds as if the securty folk think
"shoot the MIB doctors, we know what we want and how we want it done".

What if we NM protocol developers would say: "shoot the Security Geeks,
we know what we want and we know how we want it done".

Thanks,
Bert 

> -----Original Message-----
> From: John Shriver [mailto:[email-masked]]
> Sent: dinsdag 8 april 2003 22:56
> To: C. M. Heard
> Cc: IPsec WG; Wijnen, Bert (Bert)
> Subject: Re: Important question about 
> draft-ietf-ipsec-doi-tc-mib-07.txt
> 
> 
> 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
> 
> 
>

---

From: John Shriver <[email-masked]>
Date: Tue, 08 Apr 2003 17:33:00 -0400

> we know what we want and we know how we want it done".

Understood.  I'm trying to be calm, if pragmatic.

The point I'm making in the last response is that some of the MIB 
Doctors are missing the context of how and why these TC's are done this 
way.  If the MIBs that Tim and I wrote were progressing along with the 
TC MIB, this would be clearer.  But we've had to abandon that effort for 
a variety of reasons, so the TC MIB is proceeding without any local 
context, to meet the needs of other MIB projects that need these TCs. 
This makes it harder to understand them.

There was no intent to produce something ugly.  Just something practical.

I'm NOT very up on the MIB projects that are planning to use the TC MIB. 
   Perhaps the new MIBs don't need to document "on the wire" protocol 
values.  If that's the case, we can simply strike all mention of the 
private use values.  Are any of those MIB authors out there reading this 
conversation?  Could you speak up on that topic?