Re: [Ianaplan] A draft for your review

[Eric Burger <[e-mail]>]

On Aug 31, 2014, at 10:35 PM, S Moonesamy <[e-mail]> wrote:

> Hi Eric,
> At 11:42 31-08-2014, Eric Burger wrote:
>> I think the disconnect is /direction/ for the IANA protocol parameters function comes from the IETF, which is an embodiment of the Internet technical community. The /input/ for the function is capably provided, not the /function/ itself. The language needs fixing.
>> 
>> How about:
>> The Internet technical community, through the IETF, has in the past and for the foreseeable future will provide direction to the IANA protocol parameter registry.
> 
> The stated position is:
> 
>  "The IETF Protocol Parameter Registry function is undertaken under the
>   auspices of the Internet Architecture Board."
> 
> The above basically says that the IETF considers that function as an IETF matter.  If you (used in the general sense) call it "IANA protocol parameters function" it is no longer an IETF matter.
> 
> One of the questions I asked was about the "Internet technical community".  The problem with using the term is that it is ill-defined.  I'll step back; there was a discussion about "global multistakeholder community" on this mailing list around the beginning of this month.  It was concluded that it is better to use the term "Internet community".
> 
> My reading of the question is that it is about the IETF Community's use of the IANA functions.  The less difficult way to answer that is to build from RFC 6220 (and the relevant BCPs if that is necessary).  I am taking into account the arguments that the IETF or the IAB has made previously.  It make sense to be consistent or have an explanation for a change in direction or else there will be a loss of credibility.

I think the disconnect is we talk about ICANN so much we think anything that starts with an ‘I’ means ICANN. IANA is the Internet Assigned Numbers Authority. IANA has /nothing/ to do with ICANN, except for the fact that ICANN /happens/ to perform the IANA function. They are a contractor for the IETF. IANA is /not/ ICANN.

The IANA function is separable from domain names and IP addresses, although there are economies of scale and management from keeping them together. Since the IANA function is created by fiat from the IETF contract, I see no problem using the terms “IETF Protocol Parameters Registry” and the “IANA function.” The IANA function is the /embodiment/ of the IETF Protocol Parameters Registry.

However, I agree with your next comment, and I have some proposed text.

>> It is not that it is not aligned with the stated position of the IETF, it is tht it is the IETF community, including implementers, "the IETF's primary users of the IETF
>> standards and other documents," that use the IANA protocol parameter registries. How about:
>> 
>> Many IETF protocols make use of commonly defined protocol parameters. Implementers use these parameters. Implementers are the IETF's primary users of the IETF standards and other documents.  A globally available registry contains the parameter values and a pointer to documentation of the associated semantic intent. This registry, the IANA protocol parameter registry, provides this service to ensure consistent interpretation of these parameter values by independent implementations.
> 
> The above looks better.  It uses the term IANA protocol parameter registry though.  Please see my previous comment about that.

I agree with you here: the use of the term IANA protocol parameter registry is sloppy. Let’s go with:
Many IETF protocols make use of commonly defined protocol parameters. Implementers use these parameters. Implementers are the IETF's primary users of the IETF standards and other documents.  A globally available registry contains the parameter values and a pointer to documentation of the associated semantic intent. This registry, the IETF Protocol Parameters Registry, provides this service to ensure consistent interpretation of these parameter values by independent implementations.  Historically, the Internet Assigned Numbers Authority has, under contract, operated the IETF Protocol Parameters Registry.

>> RIR and ICANN people regularly come to IETF meetings, which means they participate. As we say, in-person attendance is not required for participation. Likewise, email discussions are also not required for participation. Thus, there is no inconsistency. Moreover, participation does not require posting. I will bet there are a lot of ICANN and RIR people subscribed (i.e., participating) to IETF email lists.
> 
> The point was that:
> 
>  (i)  It is possible to argue either way, i.e. people participate
>       or people do not participate.
> 
>  (ii) It does not add anything substantive to the response.
> 
> What you (used in the general sense) could do here is to explain that there is coordination and how it is being done when there is an overlap.

Eliot addressed this issue better than I did. The substantive issue is that we have an open process that already has all of the major players (and lots of minor players like me) involved.

[snip]
>> How? Any text for what you think it is / should be?
> 
> It's an IAB matter.  The term "IETF process" may or may not cover that.  There is already the following as part of the response:
> 
>  "RFC 6220 specifies the role and function of the protocol parameters
>   registry, which is critical to IETF standards processes and IETF
>   protocols.  The IAB, on behalf of the IETF, has the responsibility to
>   define and manage the relationship with the protocol registry
>   operator role.  This responsibility includes the selection and
>   management of the protocol parameter registry operator, as well as
>   management of the parameter registration process and the guidelines
>   for parameter allocation."
> 
> In my opinion it is a matter of fitting that into the response.

The IAB operates on behalf of the IETF. I don’t see the issue.

> As a general comment, there is the following under "required proposal elements":  "associated references to source documents of specific policies/practices".  A plausible response would be one which could be substantiated with references.  Otherwise (in my opinion), it will look like the IETF is not comfortable with what it has written.

On the one hand, we have a lot of references to IETF documents. On the other hand, if a casual reader thinks we do not have enough references, we can have more.