[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IANA administrative issues with draft-ietf-ipsec-doi-tc-mib-07.txt
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
>