Re: [iucg] [Ianaplan] IANAPLAN virtual meeting

[JFC Morfin <[e-mail]>]

At 21:40 23/09/2014, Pete Resnick wrote:
>On 9/22/14 7:07 PM, JFC Morfin wrote:
>>Point 1 considers a single operator, something that point 2 
>>formally contradicts in considering and pertinently documenting the 
>>need for multiple operators.
>
>This is a mis-reading of the title of RFC 6220. It does not say, 
>"Defining the Role and Function of *the* IETF Protocol Parameter 
>Registry Operators". If you read the document, you will realize that 
>it is referring to the role and function of *present or future* 
>operators, but always takes as given that there will be a single 
>operator at any one time.
>
>There is no contradiction or ambiguity here. On this you simply made 
>an error in reading.

Dear Pete,

I certainly accept your point as a possibility. However my re-reading 
of RFC 6220 definitely differs from yours. This is the essence of 
every debate. Yet, in this case I do not think it makes a real 
difference for two reasons. :

1. The RFC 6229 introduction states: "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."

The text says "to a nominated entity" not "to the same/a unique 
nominated entity". When it says "these delegated functions" it does 
not imply they are delegated to the ***same*** entity (because there 
would be a good reason for it to be the same).

My point is not that there MUST be several operators at the same 
time, but that there MAY be several operators, and that the RFC 6220 
does not want to preclude such a possibility. I therefore credit the 
IETF for its RFC 6220 to be consistent with the joint OpenStand 
paradigm (RFC 6852) which does not pay a particular attention to the 
"formal status" of the global communities standards (what implies 
several possible parameter tables).

Please note that if I was not correct, what could be the case but 
what I do not genuinely believe,.this would only mean the RFC 6220 is 
not consistent with the RFC 6852 paradigm for standards. This would 
only call for an RFC 6220bis to adjust to the RFC 6852 paradigm.

I therefore thank you for rising the point. Should I have to appeal 
the IESG against a Chairs' refusal to work first on the clarification 
of the Charter, I would have to add this additional consistency preoccupation.


2. The existing situation is that there already are several 
concurrent Norms, Names and Numbers information centers for IETF and 
non-IETF protocols used on the Internet by the Internet users (please 
remember that my lead concern is the Internet use). If RFC 6220 is 
unable to provide help in this area, this would mean that this WG is 
the one to provide guidance to the community on the concerned points. 
In such a case, I wish this WG to ask first IAB guidance on this 
situation, according to a least confusion precaution.

In both cases striving to protect the past status-quo, as Leslie has 
formally stated it, would IMHO not only be inadequate, put the 
network in jeopardy, but also oppose the Charter.

This is certainly only my opinion; concerning the IETF/WG/IANAPLAN 
responsibilities and the opinion of those I share the concerns.

jfc