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

[Olaf Kolkman <[e-mail]>]

Colleagues,

I’ve just uploaded [version 04](https://tools.ietf.org/html/draft-ietf-iasa2-rfc6220bis-04). Here is a summary of the changes I’ve made and didn’t make. For reference, [here are the diffs](https://tools.ietf.org/rfcdiff?url2=draft-ietf-iasa2-rfc6220bis-04.txt).


I’ve taken up Bob’s suggestion to add a sentence about obsoleting RFC6220 in the abstract and introduction.


Benjamin’s comments are addressed below.

> 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?

I am tempted to err on the side of clarity. I do have a similar question about the repeated references to the IASA model. But punted that to the RFC editor.

>
> 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).
>

I replaced Proposed, Draft, and full Internet Standards with “Standard Track Documents[RFC6410]”



> 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.
>

I would think that the details of what maintenance means are subject to the specifics of a list and can be captured in SOWs. So no change.


>   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.

ICANN is the entity the LLC does its business with .. See the latest version of the MoU - to which the reference has been updated. Besides the reference update, no other changes.

>
>    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.



I think that is right - with some goodwill this can be seen as an editorial change.

Text now reads:

````
   *  Intellectual Property Rights and the Registry Operator

      Unless special circumstances apply (see Section 2.1):

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

      -  The assignment values may be redistributed without
         modification.

      In any case,

      -  any intellectual property rights of the IETF protocol parameter
         assignment information, including the IETF protocol parameter
         registry and its contents, are to be held by the IETF Trust
         [BCP101].
```





> 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?

My understanding is this: the LLC should make sure that uniqueness is guaranteed. For instance in the case that a registry is transferred from one operator to another, the legacy operator should stop registering new values in the registry and track (if the legacy operator chooses to continue publication) the content of the registries as published by the new operator. That can/should(?) the LLC can/should (?) enforce this.

I have made no changes in the text.

>
> 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.
>

No Changes.


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

Removed mention of year.

Thanks for the comments Benjamin and Bob,


-Olaf