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

["C. M. Heard" <heard@pobox.com>]

On Tue, 8 Apr 2003, John Shriver wrote:
> A more straightforward description is that I tried to forge a compromise 
> between multiple design goals:
> 
> 1. Easy to [implement] on the product without pain.  (This is why I 
> export exactly what the protocol negotiated, no remapping to any other 
> space).

Subranged INTEGER/Integer32/Unsigned32 can accomplish this.

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

Subranged INTEGER/Integer32/Unsigned32 cannot accomplish this.

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

Subranged INTEGER/Integer32/Unsigned32 can accomplish this.

> 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.

Fair enough.

> 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.

Well, here is the advice from another MIB Doctor:

On Tue, 8 Apr 2003, David T. Perkins wrote:
% Sometimes it is not appropriate or worth the cost of putting things
% in a MIB module that work better as information that augments the
% MIB module. In this case, I would define the object type with
% data type "Unsigned32", and specify in the DESCRIPTION clause
% the semantics of the ranges. In the REFERENCE clause, I would
% put the information (and if available, a URL) so that some one
% could track down the current assignments.
% 
% That's my $.02 worth of advice.
% 
% PS Hint: See the definition of TC SnmpSecurityModel.

That is essentially what I suggested earlier.  If you care to look,
SnmpSecurityModel is defined in the SNMP-FRAMEWORK-MIB, which in
turn is part of RFC 3411 (ftp://ftp.isi.edu/in-notes/rfc3411.txt).
It's the model I had in mind.

I don't think that a shift to this approach would have much (if any)
impact on the MIB modules that use the TCs defined in
<draft-ietf-ipsec-doi-tc-mib-07.txt>.  It would comply with the SMI,
and it would avoid the need to supplement/change the IPsec-related
IANA registries.  And you could include the titles and URLs of those
registries in the relevant TC DESCRIPTION clauses.

As I said before, I don't have the power (nor do I wish) to force
you to do anything ... I only give advice.  But, that's my advice.

Thanks,

Mike

P.S.  I can certainly sympathize with your being unhappy at having
this suggestion arrive so late in the process ... your first I-D,
if I correctly understood what I saw in the IPsec mailing list
archives, appeared in February 1999.  I can only apologize and
say that you have a legitimate complaint about that.  -- cmh