Subject: RE: IANA administrative issues with draft-ietf-ipsec-doi-tc-mib-0 7.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 26 Apr 2003 18:24:02 +0200

Let me express that I think that the proposed solution by Mike
seems to make a lot of sense to me. That is the answer from Mike
to John, as in the folloing extract from a recent email posting:

>   is Mike
> > is John

> > I can fully see either of two alternatives:
> > 
> > 1. IANA refactors the IPsec registries to eliminate overlap with the 
> > TC-MIB, and the TC-MIB is authoritative on what it covers.
> > 
> > 2. IANA maintains the TC-MIB separately, keeping it in sync with the 
> > registries.
> 
> Those alternatives can indeed be made to work.  Both impose some
> extra administrative burden on the IANA.  #1 does so once up front,
> #2 does so on an ongoing basis.
> 
> > I do not see the alternative of maintaining the TC-MIB under the
> > RFC process as useful, since that will prevent anything using it
> > as a normative reference from ever reaching Full Standard.
> 
> Again, I don't agree with that.  Using IpsecDoiSecProtocolId
> as an example, here is how one could re-write the TCs in the
> IPSEC-ISAKMP-IKE-DOI-TC module so as to avoid the need to
> track updates to the registry.  This is modelled after the
> SnmpSecurityModel TC in RFC 3411, but incorporates the
> suggestion from Dave Perkins to include a pointer to the
> registry where assignments can be found.  It also incorporates
> the suggestion from Wes Hardaker to recommend that "private
> use" values be documented in an AGENT-CAPABILITIES statement
> if they are used.
> 
> IpsecDoiSecProtocolId ::= TEXTUAL-CONVENTION
>     STATUS      current
>     DESCRIPTION "Objects of this type represent IPsec DOI values
>                 for the IP Security Protocol Identifier (Protocol
>                 ID) field in an ISAKMP Proposal Payload, and in
>                 all Notification Payloads.  They may also represent
>                 values of the Protocol ID field in the Notification
>                 Payload and the Delete Payload.
> 
>                 The value zero does not identify any particular
>                 security protocol.  It MAY be used in MIB objects
>                 to indicate that the security protocol is unknown
>                 or that none applies.  Any such use MUST be
>                 documented in the MIB object's DESCRIPTION clause.
> 
>                 Values between 1 and 248, inclusive, are managed by
>                 the Internet Assigned Numbers Authority (IANA).
>                 Assigned values are recorded in the IPSEC Security
>                 Protocol Identifiers section of the IANA Internet
>                 Security Association and Key Management Protocol
>                 (ISAKMP) Identifiers registry (a URL for which is
>                 http://www.iana.org/assignments/isakmp-registry).
> 
>                 The values 249-255 are reserved for private use
>                 amongst cooperating systems.  It is RECOMMENDED
>                 that implementations document the usage of such
>                 values in an AGENT-CAPABILITIES statement."
>     REFERENCE   "RFC 2407 sections 4.4.1 and 6.2"
>     SYNTAX      Unsigned32 (0..255)
> 
> Some wordsmithing may of course be necessary or desirable.
> 
> Changes (if any) as the MIB module advances on the standards track
> could include updates to the STATUS clause (a TC might be deprecated
> if it became obsolete, or if it was not used in defining objects
> contained in two implementations), to the DESCRIPTION clause (e.g.,
> if the URL of the registry changes -- one hopes not, those things
> need to be stable), or the REFERENCE clause (if new documents are
> issued).  But new number assignments would not have any effect, and
> so would not hinder advancement on the standards track.
> 
> The disadvantage of this approach (as we all know by now) is the
> loss of some machine readable information.  The advantages are that
> it does not conflict with the formal requirements of the SMI and
> that it does not impose any administrative burden on the IANA.
> 
> Does anyone else (other than John Shriver, Wes Hardaker, or
> myself) care to express an opinion on these matters?
> 
> //cmh
>