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

From: Bob Hinden <[email-masked]>
Date: Thu, 22 Aug 2019 11:00:17 -0700

Hi,

Overall this looks good.   Here is a link to a diff between the RFC and current draft:

https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/rfc/rfc6220.txt&url2=https://tools.ietf.org/id/draft-ietf-iasa2-rfc6220bis-03.txt

A few comments:

This draft says it obsoletes RFC6220, but that is not mentioned in the abstract or in the Introduction.  It should be.  This was called out in Idnits.  Idnits also mentions some old references.

After the abstract there is a [Cover Note]:

   [The IASA2 WG asks the IAB to publish this replacement for RFC 6220.
    This document is changed for alignment with the new structure for the
    IETF Administrative Support Activity (IASA). ]

Later in the document it asks the RFC Editor to remove this.

I think the Abstract needs to include text that says this draft makes changes relating to the IASA 2.0 model.  For example something like this:

   This document obsoletes RFC 6220 to replace all references to the IASA and
   related structures with those defined by the IASA 2.0 Model.

The something similar in the Introduction.  This was done in the other IASA 2.0 bis documents.

Thanks
Bob

> On Aug 21, 2019, at 11:19 AM, IAB Executive Administrative Manager <[email-masked]> 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
> [email-masked] and [email-masked].
> 
> Abstract
> 
>   Many Internet Engineering Task Force (IETF) protocols make use of
>   commonly defined values that are passed in messages or packets.  To
>   ensure consistent interpretation of these values between independent
>   implementations, there is a need to ensure that the values and
>   associated semantic intent are uniquely defined.  The IETF uses
>   registry functions to record assigned protocol parameter values and
>   their associated semantic intentions.  For each IETF protocol
>   parameter, it is current practice for the IETF to delegate the role
>   of Protocol Parameter Registry Operator to a nominated entity.  This
>   document provides a description of, and the requirements for, these
>   delegated functions.
> 
> [Cover Note]
> 
>   [The IASA2 WG asks the IAB to publish this replacement for RFC 6220.
>   This document is changed for alignment with the new structure for the
>   IETF Administrative Support Activity (IASA). ]
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 24 Aug 2019 15:01:25 -0500

> [email-masked] and [email-masked].

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