Subject: Re: [iucg] [Ianaplan] IANAPLAN virtual meeting

From: JFC Morfin <[email-masked]>
Date: Tue, 23 Sep 2014 02:07:37 +0200

At 15:46 22/09/2014, Marc Blanchet wrote:
>The IANAPLAN WG will hold a 2 hour interim virtual meeting October 
>6th, 10h00am Eastern. The main agenda item is the first deliverable 
>of the working group, where an individual draft will be discussed 
>and reviewed to be adopted by the working group.

Marc and Leslie,

Prior to this virtual global meeting, I would like to request an 
IANAPLAN IETF/WG charter update in two directions.

A. This charter states both:

1. "The IANAPLAN working group is chartered to produce an IETF 
consensus document that describes the expected interaction between 
the IETF and the operator of IETF protocol parameters registries." 
This implies (as the context clearly shows it) that a single operator 
is to be considered.

2. The working group will assume that the following documents will 
continue to be in effect: ... RFC 6220 - Defining the Role and 
Function of IETF Protocol Parameter Registry Operators.

Point 1 considers a single operator, something that point 2 formally 
contradicts in considering and pertinently documenting the need for 
multiple operators. This calls for a clarification, not only due to 
the demanded contradiction, but because I am most probably not alone 
among Libre and States R&D organizations (RDOs) in planning:

a. to draft within the coming months the description of a general 
internet model,
- addressing the second motivation of the IEN 48, 1978 Vint Cerf's 
ARPANET internetworking project (better known as the internet project 
embodied by the IETF)
- that would be compliant with the RFC 6220 text and rationale in 
extending its MDRS (metadata registry system) support of the IEN 48 
first motivation documentation (IANA)
- to every "new networking technology to be introduced into the 
existing catenet while remaining functionally compatible with 
existing systems" in order to "allow[] for the phased introduction of 
new and obsolescence of old networks without requiring a global 
simultaneous change".

b. to develop, test, and deploy MDRS tools in order,
- to permit Virtual Glocal Networks (VGNs) (i.e. conforming to the 
IEN 48 "loose sense" of the local meaning "peculiar to the particular 
network" rather than "a network of limited geographic extent.")
- to operate their own Information Centers (VGNICs) for the 
Administration of their Names and Numbers (the MYCANN project in my case),
- at least - outside of any other consideration - in order to have 
available a failsafe plan for their net in case of ICANN failure, 
unaccountable divergence or incapacity to keep coordinated the RFC 
6852 multi-global community landscape.

B. Since 1977, the US (FCC and then NTIA) as a single point of 
network failure was a reliable enough situation that RFC 6852 is 
dissolving and the NTIA is going to terminate on Sept. 30, 2015.

The mission of the IETF is to make sure that the end to end datagram 
exchanges can continue to perform in a the new context "where the 
economics of global markets, fueled by technological advancements, 
drive global deployment of standards regardless of their formal 
status" so its "standards support interoperability [and] foster 
global competition", even in the case they "are [only partly] 
voluntarily adopted globally".

I do not think this is possible if the Milestones are not reviewed in 
order to permit a seamless transition by Sept. 30, 2015. To that end, 
the WG/IANAPLAN RFC(s) should be published by May 31, 2015. This 
implies an IETF general final call by April 30, 2015 and WG final 
call by March 31, 2015.

The charter must not appear as an incitement to the status quo while 
criticality is a possibility, and this way to legitimate 
self-organization that is not concerted.

jfc

.

---

From: Jefsey <[email-masked]>
Date: Tue, 23 Sep 2014 18:19:56 +0200

At 03:58 23/09/2014, Leslie Daigle (TCE) wrote:
>M. Morfin,
>The appropriate time for such substantive suggestions for charter 
>changes would have been during the initial WG chartering process.
>At this time, the status quo is in fact what the WG is chartered to 
>ensure, and what the WG chairs will be pursuing unless or until the 
>IESG directs us otherwise.
>Leslie.

Dear Leslie,

One of my premises is that, at this time, the status quo's 
political/economic/technical strategy deployed by the US industry 
since 1983 is dissolving. I am, therefore, not suggesting substantive 
changes to an inadequate charter, but rather demanding the urgent 
resolution of two double constraints in its text, of which some deem 
the aporia to be a pro-status-quo strategic bias that you seem to 
confirm. Several consider this bias to be of such a magnitude that 
its resolution could only lie in an IETF fork.

Before triggering such a risk in refusing to review the Charter, it 
would seem reasonable for the co-Chairs and the AD, who is also the 
IETF Chair, to consider my request carefully. This request follows 
the RFC 2026 procedure:

1. It is based upon my belief that, in not calling for the 
clarification of internal and contextual contradictions in our 
charter, the AD and the co-Chairs would make "an incorrect technical 
choice which places the quality and/or integrity of the Working 
Group's product(s) in significant jeopardy".

2. as such I "first discuss the matter with the Working Group's 
chair(s)" and "involve other members of the Working Group (or the 
Working Group as a whole) in the discussion."

3. due to the time constraints imposed on this question that you 
refer to, I "bring it to the attention of the Area Director(s) for 
the area in which the Working Group is chartered." in the hope that 
"The Area Director(s) shall attempt to resolve the dispute."

For the information of the non-IETF parties:

1 I quote the RFC 2026:

"If the disagreement cannot be resolved by the Area Director(s) any 
of the parties involved may then appeal to the IESG as a whole.  The 
IESG shall then review the situation and attempt to resolve it in a 
manner of its own choosing. If the disagreement is not resolved to 
the satisfaction of the parties at the IESG level, any of the parties 
involved may appeal the decision to the IAB.  The IAB shall then 
review the situation and attempt to resolve it in a manner of its own 
choosing. The IAB decision is final with respect to the question of 
whether or not the Internet standards procedures have been followed 
and with respect to all questions of technical merit."

2. Due to the political nature of the disagreement, you have clearly 
identified:

"the status quo [political strategy] is in fact what the WG is 
chartered to ensure, and what the WG chairs will be pursuing unless 
or until the IESG directs us otherwise [whatever the WG members may 
contribute]",

3. If the IESG and IAB are unable to reach a compromise that is 
acceptable to the whole Internet community, such a compromise will 
have to be found through an appeal to ISOC. This results from RFC 
2026, which states:

"Further recourse is available only in cases in which the procedures 
themselves (i.e., the procedures described in this document) are 
claimed to be inadequate or insufficient to the protection of the 
rights of all parties in a fair and open Internet Standards Process. 
Claims on this basis may be made to the Internet Society Board of 
Trustees.  The President of the Internet Society shall acknowledge 
such an appeal within two weeks, and shall at the time of 
acknowledgment advise the petitioner of the expected duration of the 
Trustees' review of the appeal. The Trustees shall review the 
situation in a manner of its own choosing and report to the IETF on 
the outcome of its review. The Trustees' decision upon completion of 
their review shall be final with respect to all aspects of the dispute."

4. If ISOC is then unable to work out an acceptable compromise to the 
world, the RFC 6852 (Affirmation of the Modern Paradigm for 
Standards) would provide the framework to find a way to avoid an 
international sovereign involvement in devising the appeal procedure 
that I called for in my appeal to IESG and IAB reaching the ISOC 
level, concerning the RFC 6852 incompleteness on this very point. 
That procedure was interrupted by the NTIA strategic move that was 
called for by the Dubai vote, Snowden saga, RFC 6852, Montevideo 
Statement, and NETmundial and Geneva meetings in that it:

- (1) made the status quo strategy obsolete that you want to slowly 
follow in spite of the NTIA imposed fast calendar;
-.(2) is based upon a quid-pro-quo that is organized by ICANN, that 
many consider to be a self-protection move, confusing the NTIA 
request concerning the punctual transition of the ICANN/NTIA "IN" DNS 
Class registry function with the ICANN management of the whole set of 
IANA functions;
- (3) prompted the need for this WG.

The time frame imposed by the NTIA, ITU, R&DO, Governments, and IUser 
projects is extremely tight and, therefore, I cannot accept to engage 
in any dilatory skirmishes. I, therefore, urge you, and Jari Arrko, 
both as the AD and the IETF Chair, to urgently support a WG/IANALAN 
charter internal and contextual consistency review.

The only alternative in order to prevent an IETF horizontal and/or 
vertical fork, leading to the WCIT already voted on ITU/IGF takeover 
of the internet affairs and governance, would then be for me to 
engage anew in a fastidious, cumbersome, and time consuming peace 
mongering IESG/IAB/ISOC appeal effort. However, due to the tight time 
frame I doubt that the created incertitude would prevent 
uncoordinated but legitimate or the legal duty of precaution projects 
tending to protect many people's interests and harden internet 
operational security, stability, transparency, neutrality, and reliability.

Such projects would most probably durably affect the internet 
architectonics. It is not up to me to decide if they would "make the 
Internet work better" (RFC 3539) nor if their possible conflicts 
would lead to an internet "where the economics of global markets, 
fueled by technological advancements, drive global deployment of 
standards regardless of their formal status." (RFC 6852).

I am only interested in a "paradigm [where] standards support 
interoperability, foster global competition, are developed through an 
open participatory process, and are voluntarily adopted globally" (RFC 6852).

jfc

>On 9/22/14 8:07 PM, JFC Morfin wrote:
>>>6th, 10h00am Eastern. The main agenda item is the first deliverable of
>>>the working group, where an individual draft will be discussed and
>>>reviewed to be adopted by the working group.
>>
>>Marc and Leslie,
>>
>>1. "The IANAPLAN working group is chartered to produce an IETF consensus
>>document that describes the expected interaction between the IETF and
>>the operator of IETF protocol parameters registries." This implies (as
>>the context clearly shows it) that a single operator is to be considered.
>>
>>continue to be in effect: ... RFC 6220 - Defining the Role and Function
>>of IETF Protocol Parameter Registry Operators.
>>
>>multiple operators. This calls for a clarification, not only due to the
>>demanded contradiction, but because I am most probably not alone among
>>Libre and States R&D organizations (RDOs) in planning:
>>
>>- to every "new networking technology to be introduced into the existing
>>catenet while remaining functionally compatible with existing systems"
>>in order to "allow[] for the phased introduction of new and obsolescence
>>of old networks without requiring a global simultaneous change".
>>
>>- to permit Virtual Glocal Networks (VGNs) (i.e. conforming to the IEN
>>48 "loose sense" of the local meaning "peculiar to the particular
>>unaccountable divergence or incapacity to keep coordinated the RFC 6852
>>multi-global community landscape.
>>
>>B. Since 1977, the US (FCC and then NTIA) as a single point of network
>>failure was a reliable enough situation that RFC 6852 is dissolving and
>>the NTIA is going to terminate on Sept. 30, 2015.
>>
>>economics of global markets, fueled by technological advancements, drive
>>global deployment of standards regardless of their formal status" so its
>>"standards support interoperability [and] foster global competition",
>>even in the case they "are [only partly] voluntarily adopted globally".
>>
>>the WG/IANAPLAN RFC(s) should be published by May 31, 2015. This implies
>>an IETF general final call by April 30, 2015 and WG final call by March
>>31, 2015.
>>
>--
>-------------------------------------------------------------------
>Leslie Daigle
>Principal, ThinkingCat Enterprises
>[email-masked]
>-------------------------------------------------------------------

---

From: Pete Resnick <[email-masked]>
Date: Tue, 23 Sep 2014 14:40:22 -0500

On 9/22/14 7:07 PM, JFC Morfin wrote:
> consensus document that describes the expected interaction between the 
> IETF and the operator of IETF protocol parameters registries." This 
> implies (as the context clearly shows it) that a single operator is to 
> be considered.
>
> 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.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: JFC Morfin <[email-masked]>
Date: Wed, 24 Sep 2014 00:59:35 +0200

At 21:40 23/09/2014, Pete Resnick wrote:
>>Point 1 considers a single operator, something that point 2 
>>formally contradicts in considering and pertinently documenting the 
>>need for multiple operators.
>
>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

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Mon, 22 Sep 2014 21:58:24 -0400

M. Morfin,

At this time, the status quo is in fact what the WG is chartered to 
ensure, and what the WG chairs will be pursuing unless or until the IESG 
directs us otherwise.

Leslie.

--