Re: [arch-d] Call for Comment: <draft-ietf-iasa2-rfc6220bis-03> (Defining the Role and Function of IETF Protocol Parameter Registry Operators)

[Benjamin Kaduk <[e-mail]>]

On Wed, Aug 21, 2019 at 11:19:33AM -0700, IAB Executive Administrative Manager wrote:
> This is an announcement of an IETF-wide Call for Comment on 
> draft-ietf-iasa2-rfc6220bis-03.
> 
> The document is being considered for publication as an Informational RFC 
> within the IAB stream, and is available for inspection at:
> <https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc6220bis/>
> 
> The Call for Comment will last until 2019-09-18. Please send comments to
> [e-mail] and [e-mail].

As preface, I note that the IAB is not formally constrained by the charter
of the IASA 2.0 WG, but may choose to act consistently with it (in which
case some of these comments are out of scope for being unrelated to the LLC
transition).

Section 1 references the "IETF Internet Standards Process [RFC2026]", which
might be spelled better as BCP 9.

Section 2 uses DHCP and IPsec as examples; are these sufficiently
well-known that no informative reference to them is needed?

Section 2.1 talks about IANA being direted to register values "as directed
by [...] Proposed, Draft, and full Internet Standards", which is a bit
stale with respect to "Draft" standards (though not strictly inaccurate in
the full context).

In Section 2.1:

   o  Mailing Lists

      *  The Registry Operator maintains public mailing lists as
         specified in IANA Considerations [RFC8126].  Such lists are

It might be worth clarifying whether "public" means archives, subscription,
and/or posting.

  Reporting

      *  The Registry Operator will submit periodic reports to the IAB
         concerning the operational performance of the registry
         function.  As an example of the requirements for such reports,
         the reader is referred to a supplement [MoU_SUPP2018] to the
         "Memorandum of Understanding Concerning the Technical Work of
         the Internet Assigned Numbers Authority" [RFC2860] that
         provides service level agreement (SLA) guidelines under which
         ICANN, the current protocol parameter registry, must operate.

I did not think that ICANN was the current primary protocol parameter
registry operator.

   o  Intellectual Property Rights and the Registry Operator

      *  All assigned values are to be published and made available free
         of any charges.

      *  The assignment values may be redistributed without
         modification.

These clauses seem to be in conflict with the earlier text about "special
circumstances" that might allow for a closed registry.
It's also unclear how this interacts with the Trust's role, as specified in
Section 2.4:

   The IETF Trust may make such regulations as appropriate for the
   redistribution of assignment values and registry publications.

In Section 2.5:

   In addition, the IETF LLC has the responsibility to ensure long-term
   access, stability, and uniqueness across all such registries.  This

Ensuring uniqueness seems rather different from the other two, and on the
face of it would seem to require rather invasive interaction with the
actual registry operator.  Do I misunderstand the sense in which this is
intended?

Section 4 notes that there are no new protocols, and concludes that there
are no new security considerations.  To a large extent this is true, and
even if there are security considerations to operating a public, available
registry and maintaining the integrity of its contents, those concerns are
arguably divorced from the administrative structure of how the registry
operator is selected.

Appendix A notes that the IASA 2.0 update was in 2018, though we're well
into 2019 at this point.

Thanks,

Ben