Murray Kucherawy via Datatracker writes:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 7.1 creates an IANA registry with "Expert Review" rules.  Of such a
> registry, Section 4.5 of RFC 8126 says, among other things:
> 
>    The required documentation and review criteria, giving clear guidance
>    to the designated expert, should be provided when defining the
>    registry.
> 
> This document doesn't do so.  Is that guidance available somewhere else, or
> should some be added here?

This is common in the IPsec documents. The working group has assumed
that experts are experts and they know what to do without being
explictly instructed to do so....

As an IANA Expert for most of the IPsec related registries, I hope
that I have been able to do that job in a such way that other people
have found that good enough (at least I have not heard complains about
that).

For example the IKEv2 registries created in RFC4306
(https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml)
are all expert review and the RFC4306 gave following instructions:

----------------------------------------------------------------------
6.  IANA Considerations

   This document defines a number of new field types and values where
   future assignments will be managed by the IANA.

   The following registries have been created by the IANA:

      IKEv2 Exchange Types (section 3.1)
      IKEv2 Payload Types (section 3.2)
      IKEv2 Transform Types (section 3.3.2)
          IKEv2 Transform Attribute Types (section 3.3.2)
          IKEv2 Encryption Transform IDs (section 3.3.2)
          IKEv2 Pseudo-random Function Transform IDs (section 3.3.2)
          IKEv2 Integrity Algorithm Transform IDs (section 3.3.2)
          IKEv2 Diffie-Hellman Transform IDs (section 3.3.2)
      IKEv2 Identification Payload ID Types (section 3.5)
      IKEv2 Certificate Encodings (section 3.6)
      IKEv2 Authentication Method (section 3.8)
      IKEv2 Notify Message Types (section 3.10.1)
          IKEv2 Notification IPCOMP Transform IDs (section 3.10.1)
      IKEv2 Security Protocol Identifiers (section 3.3.1)
      IKEv2 Traffic Selector Types (section 3.13.1)
      IKEv2 Configuration Payload CFG Types (section 3.15)
      IKEv2 Configuration Payload Attribute Types (section 3.15.1)

   Note: When creating a new Transform Type, a new registry for it must
   be created.

   Changes and additions to any of those registries are by expert
   review.
----------------------------------------------------------------------
(i.e., that is full IANA considerations section).
-- 
kivi...@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to