RE: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.t xt

There should be no impact on the configuration policy model document.

Jamie

> -----Original Message-----
> From: The Purple Streak, Hilarie Orman [mailto:[email protected]] 
> Sent: Wednesday, April 16, 2003 2:50 PM
> To: [email protected]
> Cc: [email protected]
> Subject: FW: Re: Important question about 
> draft-ietf-ipsec-doi-tc-mib-07.txt
> 
> 
> 
> Has this got any impact on the policy config doc?  We need a 
> response on this issue.
> 
> Hilarie
> 
>   ---Forwarded Message Follows---
> From: "C. M. Heard" <[email protected]>
> To: IPsec WG <[email protected]>
> cc: "Wijnen, Bert (Bert)" <[email protected]>
> Subject: Re: Important question about 
> draft-ietf-ipsec-doi-tc-mib-07.txt
> 
> [ authors of draft-ietf-ipsp-ipsec-conf-mib-06.txt bcc'd;  ]
> [ please direct all discussion to [email protected]  ]
> 
> Summary of the discussion so far:  I have pointed out to the 
> WG that all of the enumerated INTEGER TCs in the 
> IPSEC-ISAKMP-IKE-DOI-TC MIB module in 
> <draft-ietf-ipsec-doi-tc-mib-07.txt> (except for
> IsakmpCertificateEncoding) are intended to represent data 
> items that have a certain range of values reserved for 
> "private use amongst cooperating systems."  Since values in 
> these ranges are not subject to standardization, there will 
> be no enumerations for them. However,  SMIv2 rules require 
> (and MIB users/authors expect) that objects defined with an 
> enumerated INTEGER syntax will assume only those values that 
> are named in the enumeration list.  I have therefore advised 
> the WG (in my role as MIB reviewer) that the SYNTAX value of 
> all of the enumerated INTEGER TCs in the 
> IPSEC-ISAKMP-IKE-DOI-TC MIB module be changed to the 
> appropriate Unsigned32 subrange with the usages of the 
> various ranges spelled out in the DESCRIPTION clause (as is 
> done now) and a pointer to the IANA registry included.  This 
> approach, which is the also used in the SnmpSecurityModel TC 
> from the SNMP-FRAMEWORK-MIB in RFC 3411, has the added 
> advantage of not imposing any extra workload on the IANA to 
> supplement or reorganize the existing IPsec and ISAKMP 
> registries.  The disadvantage of this approach is that 
> applications such as MIB browsers that don't have any 
> built-in knowledge of the underlying MIB objects can only 
> display the integer value and not the enumeration label, 
> which makes the MIB modules harder to use.
> 
> This discussion has been dormant for about a week, and I do 
> need to proceed with finalization of my MIB review comments 
> for the ADs.  So unless I hear some very convincing arguments 
> to the contrary before Tuesday, 22 April 2003, my review 
> comments will advise that all the enumerated INTEGER TCs in 
> the IPSEC-ISAKMP-IKE-DOI-TC have the SYNTAX value changed to 
> the appropriate Unsigned32 subrange, and that the MIB module 
> be maintained by the WG, not by IANA.
> 
> I am aware of the following Internet Drafts that contain MIB 
> modules which use one or more of the TCs defined in 
> IPSEC-ISAKMP-IKE-DOI-TC:
> 
> draft-ietf-ipsec-ike-monitor-mib-04.txt
> draft-ietf-ipsec-isakmp-di-mon-mib-05.txt
> draft-ietf-ipsec-monitor-mib-06.txt
> draft-ietf-ipsp-ipsec-conf-mib-06.txt
> 
> Of these, it appears that only the last one would be affected 
> by the changes I intend to recommend.  It would be necessary 
> to change the object definition
> 
> ipspSaPreActActionType OBJECT-TYPE
>     SYNTAX      IpsecDoiEncapsulationMode
>     MAX-ACCESS  read-create
>     STATUS      current
>     DESCRIPTION
>         "This object specifies the encapsulation mode to use for the
>          preconfigured SA: tunnel or transport mode."
>     DEFVAL { tunnel }
>     ::= { ipspSaPreconfiguredActionEntry 9 }
> 
> to
> 
> ipspSaPreActActionType OBJECT-TYPE
>     SYNTAX      IpsecDoiEncapsulationMode
>     MAX-ACCESS  read-create
>     STATUS      current
>     DESCRIPTION
>         "This object specifies the encapsulation mode to use for the
>          preconfigured SA: tunnel or transport mode."
>     DEFVAL { 1 } -- tunnel
>     ::= { ipspSaPreconfiguredActionEntry 9 }
> 
> Regards,
> 
> Mike Heard
>