Subject: [Ianaplan] Constructive redirect -- focusing discussions

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Mon, 15 Sep 2014 12:00:29 -0400

Hi,

Lots of good broad-ranging discussion  of "what-ifs"; I'd like to see if 
we can focus discussion a little bit.

I think John Curran had a good articulation of "what good looks like":

[John Curran wrote:]
 >  It is the combination of the IETF (which brings the registry 
definition and technical IANA
 >    considerations) and the affected user community's support of 
general-purpose registry
 >    policy (developed via an open, transparent, and inclusive 
organization) that results a
 >    useful and "authoritative" registry; [...]

The WG task that several threads have been exploring is whether or not 
we have adequate documentation in place in order to ensure that is and 
remains a valid description of the IANA (protocol parameter) registries.

I further think John's suggestion of working through scenarios is a good 
one, though I don't think the text he offered was a single (or simple) 
scenario

So, leveraging what Seth Johnson wrote, shall we identify some scenarios 
to work through?

[Seth Johnson wrote:]
 >
 > But I also think we should think carefully about whether things will
 > in fact be business as usual in/after the transition, or whether
 > things will break and need rectification as a consequence of the task
 > the NTIA has set, or whether things are being changed and need to be
 > changed in a way that works well, including in ways that may go beyond
 > business as usual, whether those elements are necessary to keep things
 > working as usual or simply ideas that people find desirable.

As scenarios, what do we need to consider in the case of:

1/ Everyday IETF IANA protocol parameter registry activities, 
post-transition.

2/ Non-everyday occurrences:  dissatisfaction with existing operator -- 
making the change, impact afterwards; selection of alternate operator 
for one or more registries;  competitive assignments (squatting) on 
individual registries or registry values.

If we can break "2/" down into 3 or 4 coherent scenarios, we might be 
able to talk them through without ratholing in analysis of behaviour 
prediction ("nice"/"not nice") or contract lawyering (that's for IASA), 
and I think that would be helpful.

Leslie.

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
[email-masked]
-------------------------------------------------------------------

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Sep 2014 18:36:42 +0200

Hi Leslie,

Thank you for your email.  I appreciate you re framing the discussion to
move forward.  Here are some possible answers to your questions:

> 1/ Everyday IETF IANA protocol parameter registry activities,
Let's call this State 1.

Good looks like it does today. That's the good news ;-)  IETF policies
will continue to govern the policies by which codepoints are managed. 
In the case of an operator change, things continue to function in just
this manner.  There is no confusion as to where a developer should go to
get a codepoint assignment or where a developer should go to find the
most current list of assignments.
>
> 2/ Non-everyday occurrences:  dissatisfaction with existing operator
> -- making the change, impact afterwards; selection of alternate
> operator for one or more registries;  competitive assignments
> (squatting) on individual registries or registry values.

How to get back to Good:

In the case where we have reached what earlier called the pair shaped
future, the IAB determines that a new contractor is needed, works with
the IAOC and IASA to establish criteria for selection of a new
contractor, and then informs ICANN so that a notice period begins.  A
transition then takes place where the function moves to the new
contractor, and is no longer performed by ICANN.

OR

In the case where ICANN determines that they can no longer support the
function for one reason or another, they provide us notice, hopefully
unofficially at first, and then we go find a new contractor, as
described above, with the transition occurring, as described above.  In
the end, we return to State (1).

How's that?

Eliot

---

From: John Curran <[email-masked]>
Date: Mon, 15 Sep 2014 14:41:21 -0400

> contractor, and is no longer performed by ICANN.

Eliot -

In the scenario you outline above, could you elaborate on the following 
points?

 1) Would that new IANA operator/contractor publish: a) all of the IANA 
    registries, b) all but the DNS root zone, or c) all but the DNS root 
    zone & IP address space registries?

 2) Would the IETF accept DNS root zone and IP address space registries
    being published by a different "IANA operator" than its other protocol
    registries, or is a single IANA operator required or desirable?

 3) If a single IANA operator is desired, what actions (if any) would be
    expected in this scenario from the related policy development bodies
    (ICANN, RIRs) to provide for their interact with a new IETF-contracted   
    IANA operator?  Would that be covered in the IETF's new IANA operator 
    contract, or require ICANN and/or the RIRs to contract with the new 
    IANA operator independent of the IETF's arrangements?

Hopefully, having some a shared understanding on these points would help 
both the IETF (and the rest of the ecosystem) "get back to Good" in a 
reasonably coordinated fashion...

Thanks!
/John

Disclaimer: my views alone.

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 15 Sep 2014 20:28:24 +0000

> -----Original Message-----

c) is the only answer that is possible in this process. Or rather, it is a response to the only question that is being asked of this WG. 
The fate of the DNS root and IP address space registries are in the hands of different groups. 

--MM

---

From: Russ Housley <[email-masked]>
Date: Mon, 15 Sep 2014 17:05:30 -0400

> The fate of the DNS root and IP address space registries are in the hands of different groups. 

I agree.  The IAB decision would certainly impact the protocol parameters directly.  And, the IAB could ask the names and numbers communities to joint in the transition, but those communities would not be obligated to do so.

Russ

---

From: John Curran <[email-masked]>
Date: Mon, 15 Sep 2014 18:24:22 -0400

> I agree.  The IAB decision would certainly impact the protocol parameters directly.  And, the IAB could ask the names and numbers communities to joint in the transition, but those communities would…

Russ -

If that _is_ the case, then would the IETF(/IAB/IAOC) contract with the new IANA
registry operator include provisions (T&C's or SoW) that the operator work with 
any IANA registry operators selected by other delegated registry authorities
(ICANN, RIRs) so as to insure seamless publication of each IANA registry space?  
Such a requirement may mean the IETF's IANA registry operator putting information 
towards other IANA registry operators or picking up same for its own publication, 
depending on the particularly registry.

This is an example of an IANA documentation requirement resulting from removal 
of the NTIA contract; such are to be identified per this working group's charter
(even if not directly part of the ICG response being developed.)  Obviously, if 
the answer reached by the IETF is something other than option (c) above, very 
different requirements result.

FYI,
/John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Sep 2014 11:24:02 +1200

Eliot,

On 16/09/2014 04:36, Eliot Lear wrote:
> unofficially at first, 

Right, but that doesn't change the 6 months notice.

> and then we go find a new contractor, as

In both cases, the transition will include a transfer of intellectual
property. We've handled that before, for example in the two transitions
of the IETF Secretariat and in the transition of the RFC Editor.
That does require the cooperation of the former operator. In this case,
Steve Crocker made ICANN's cooperation fairly clear on March 12, 2014,
but we could ask for a more formal version, I suppose.

http://www.iab.org/mail-archive/web/internetgovtech/current/msg00223.html

   Brian

> 
> How's that?
> 
> Eliot
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Sep 2014 11:24:07 +1200

On 16/09/2014 10:24, John Curran wrote:
>>>> 1) Would that new IANA operator/contractor publish: a)
>>>> all of the IANA registries, b) all but the DNS root
>>>> zone, or c) all but the DNS root zone & IP address
>>>> space registries?
>>> c) is the only answer that is possible in this process.
>>> Or rather, it is a response to the only question that is
>>> being asked of this WG. The fate of the DNS root and IP
>>> address space registries are in the hands of different
>>> groups.

In terms of who updates those registries, sure. However,
there is no reason why the hypothetical new IETF-IANA
couldn't mirror those registries for the convenience of
the public. Also, a mechanism would be needed to ensure
that the other IANA never infringed the special-purpose
registries, which would of course be maintained by
the hypothetical new IETF-IANA. That slightly extends
the coordination mechanism we have today.

>> I agree.  The IAB decision would certainly impact the
>> protocol parameters directly.  And, the IAB could ask the
>> names and numbers communities to joint in the transition,
>> but those communities would not be obligated to do so.
> 
> Russ -
> 
> If that _is_ the case, then would the IETF(/IAB/IAOC)
> contract with the new IANA registry operator include
> provisions (T&C's or SoW) that the operator work with any
> IANA registry operators selected by other delegated registry
> authorities (ICANN, RIRs) so as to insure seamless
> publication of each IANA registry space? Such a requirement
> may mean the IETF's IANA registry operator putting
> information towards other IANA registry operators or picking
> up same for its own publication, depending on the
> particularly registry.

Yes, but...

> 
> This is an example of an IANA documentation requirement
> resulting from removal of the NTIA contract; such are to be
> identified per this working group's charter (even if not
> directly part of the ICG response being developed.)

For me it's in the category of bridges to be crossed when
we come to them. There are so many alternative futures
that going into detail now seems wasteful.

   Brian

> Obviously, if the answer reached by the IETF is something
> other than option (c) above, very different requirements
> result.
> 
> FYI, /John
> 
> _______________________________________________ Ianaplan
> mailing list [email-masked]

---

From: John Curran <[email-masked]>
Date: Mon, 15 Sep 2014 20:56:05 -0400

On Sep 15, 2014, at 7:24 PM, Brian E Carpenter <[email-masked]> wrote:

> ... Also, a mechanism would be needed to ensure
> ...

There is little doubt that the current NTIA IANA function
contract has historically acted to keep the various IANA
registries together with one IANA operator.  The potential
for these IANA registries being maintained by multiple 
operators looks to me to involve additional agreements 
and/or mechanisms (like the one you noted above) 

Per the IANAplan charter - 

"However, the mechanisms required to address the removal 
 of the overarching NTIA contract may require additional 
 documentation or agreements. The WG will identify, but
 not create, such required agreements."

> ...

To proceed as you suggest implies a change to the WG charter 
so that identification of additional needed documentation is 
no longer in scope.  That doesn't seem prudent in general, and 
particularly when the insights gained from identification may 
help out with the primary task of developing an IANA transition 
plan which addresses the implications of moving the NTIA out 
of its current role for IETF protocol parameters.

FYI,
/John

---

From: Jefsey <[email-masked]>
Date: Tue, 16 Sep 2014 08:27:00 +0200

At 23:05 15/09/2014, Russ Housley wrote:
> > c) is the only answer that is possible in this process. Or 
> rather, it is a response to the only question that is being asked of this WG.
>I agree.  The IAB decision would certainly impact the protocol 
>parameters directly.  And, the IAB could ask the names and numbers 
>communities to joint in the transition, but those communities would 
>not be obligated to do so.

Russ,

Would it not be simpler to respect RFCs, starting with your RFC 6852?

I objected to that RFC in the best interest of the IETF community, 
because, as I told you, it acknowledges the reality but does not 
explain how to deal with it.

I hoped that we could find an "internet community" solution through 
the ISOC escalation layer, i.e. a "people centered" one, with ISOC 
opening its membership to every "ledger" (root registry organization) 
leading for example to an ML-DNS: multi-ledger DNS, incuding other 
semantic addressing systems than domain names as they may develop. 
This could have happened if the ISOC response to my appeal had been 
inclusive and open to every DNS Class administrator, every 
technology, every stakeholder,  every national addressing plan, every 
documentation repository, etc. ICANN and RIRs would have seamlessly 
become leaders of this inter pares ISOC community until it stabilizes 
in its own way.

The NTIA decided otherwise, and to pursue the US industry's 30 year 
old strategy (sorry, I know it quite a lot) opposing the IEN 48 
second objective. ICANN and RIRs had to keep the "Being Unilaterally 
Global" BUG forever (in spite of Dubai). This is to be achieved in 
transferring their accountability from being the US Executive branch 
to being the US Legislative branch - i.e. to no one, instead of to 
people through an enlarged ISOC However, the pressure and money put 
on it (Snowden, NETmundial, Davos, etc.) will not change the natural 
trend of the digital ecosystem reality. It might actually critically 
speed it up?

What is worrying, for all of us, is that in all this no one but me 
has considered a contingency plan. The members of our village Libre 
micro-ISP association do not intend to 100% blindly trust any 
ICANN/RIRs still unknown solution for our VGN operations, nor to 
depend on anyone's IANA repository management. There is no offense, 
no opposition, no anarchy, no troll into this. This is simply because 
we do not trust that a single point of failure can be 100% reliable 
and secure. And we are amazed that so many clever and informed people 
disagree on this point with the simple independent users we are.

jfc

---

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Sep 2014 10:46:02 +0200

Brian,

> that going into detail now seems wasteful.

This is a very important point.  The circumstances of the situation are
going to matter.  Our successors will need to address them in a way that
is appropriate for at the time.  They will decide that.  What they need
from us at this time is what is important now.

Eliot

---

From: JFC Morfin <[email-masked]>
Date: Thu, 18 Sep 2014 08:54:47 +0200

>and/or mechanisms (like the one you noted above)

John,

I know it is boring for me to repeat the same basic thing over and 
over again. We cannot use past rules, concepts, terminology, and 
practices in the future. The past is built on a static contractual 
notion based upon the NTIA sovereign stability. At the end of 
September 2015, this sovereign bedrock will be gone. It is to be 
replaced by a dynamic wildness of mutually networked interests.

Either this will lead to anarchy or to a reinforced tensegrity 
(http://en.wikipedia.org/wiki/Tensegrity for those who would not know 
about this fundamental mechanism). The true and only multi-billion 
party "contract" of the internet is the RFCs. This is because 
everyone depends on their consistency and their consistent use by others.

This consistency is challenged. This was clearly documented in RFC 
6852: the consistency does not primarily aim anymore at a single 
better internet but rather at a better digital economy for various 
global communities. The NTIA has acknowledged this situation and asks 
the operators of the previous consistency to transition toward what 
RFC 6852 implies but does not document.

IMHO, it can architectonically imply only one thing if we want to 
protect stability: to strengthen the internet protocol set 
consistency in extending it to the IANA function itself, i.e. as this 
is starting to be discussed now: to a network mechanism.

This means that rather than continually considering the IANA as an 
IETF/ICANN repository, it must become a protocol for all information 
of reference concerning the tensegrity of the whole digital 
ecosystem. Otherwise, there will be hundreds of partly-IANA-like 
repositories that will not be coordinated.

Either we document the IANA protocol before the mess, or after we 
have permitted it to occur. It may be faster/easier before than further on.

jfc

PS. Please note that I speak here as a stakeholder, as a 
"partly-IANA-like repository" operator. As such, those who do not 
realize that they are fragmenting the internet software compatibility 
call me a troll as they believe I am doing what they have perfectly 
designed (cf. Brian and the Bible: his RFC 1958).

The software is fragmented (this is both by the informal community 
standards [cf. RFC 6852] and through the possibilities offered by 
"software designed networking"). This means that we must keep it 
compatible. This compatibility is simpler to enforce if people 
mentally accept that the internet is not only hardware (catenet) and 
software (internet) but also brainware (our common multi-strata 
intelligent use of the software resources, over a cooperative 
management of the hardware infrastructure).

The problem that we face is a change in the internet intelligent use 
(IUse) paradigm. The referent is no longer the USG, and not the edge 
providers either, but rather the Internet individual Users (IUsers).

---

From: "Lynn St.Amour" <[email-masked]>
Date: Thu, 18 Sep 2014 08:26:36 -0400

> and/or mechanisms (like the one you noted above) 

And keeping them together has historically been "preferred" (even if only mildly) by the technical community, correct?   If it did come to pass that one of the communities wanted to go their own way (and recognizing that this is somewhat outside of the WG charter), does the IAB/should the IAB have a view on "what good looks like" in that situation?   

Lynn

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Sep 2014 07:47:11 -0700

On 9/18/2014 5:26 AM, Lynn St.Amour wrote:
> And keeping them together has historically been "preferred" (even if
> only mildly) by the technical community, correct?   If it did come to
> pass that one of the communities wanted to go their own way (and
> recognizing that this is somewhat outside of the WG charter), does
> the IAB/should the IAB have a view on "what good looks like" in that
> situation?

There is possibly a worthy bit of clarity to be gained by noting the
transition in your note from "the technical community" to "one of the
communities".   I suspect the transition from singular to plural
reflects a point of meaningful distinction.

That is, when is it worth distinguishing between "the IETF" as a single,
integrated community that makes registry definition and delegations
decisions, versus separate technical communities that use the IETF but
want a degree of independent control over delegation and/or operation of
registries associated with their work?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: JFC Morfin <[email-masked]>
Date: Thu, 18 Sep 2014 21:35:02 +0200

Dave,
it seems that Lynn is simply consistent with her RFC 6852. The 
question she rises seems to be collateral to the abdication of IAB in 
that RFC as the internet/digital (?) ultimate technology referent. 
(What I questionned in appeal, but the NTIA questionned differently 
before I could appeal ISOC). The only difference I may have with her 
is who qualifies as a "(global) community", i.e. an NTIA stakeholder. 
I include the IUse community, she probably does not it yet.

Lynn,
1. I do not understand why you consider it is somewhat outside of the 
WG charter? It is up to the WG to consider reasonable situations, and 
this is a fully regular situation in the framework of the technically 
partly/unformally fragmented internet normative paradigm.
2. the IAB certainly remains the IETF and, I hope, the ICANN 
architectural referent for a single internet. Its point of view is to 
be respected (this is an RFC 6852 requirement). This is important 
because, however the IAB is not anymore the overall ultimate 
multi-global-community technological referent, it is the one which 
documents the unifying internet architecture.

What would be worrying would be the case where a community's IANA 
occurence would not only differ from others, but break compatibility. 
This could be for an  engineering divergence (what could be most 
probably sorted out quickly). However they could go rogue for 
political reasons (aka a cyberwar situation).

IMHO what the NTIA wants to know is:
- can a national community use its IANA occurence as a deterrence 
theory/strategy component?
- i.e. is Peter deBlanc's "nuclear arsenal" a real threat?

I personnaly think it is. And this is why we want our VGN users to be 
immune as much as possible from external IANA-occurences. Since this 
is not something you can obtain in a minute (update delays, TTL, 
possible DoS at that time, etc.), the only solution is that VGN users 
only trust their VGNIC as a referent.

In 99.99999 % of the cases this will make no difference. But user 
protection means 100% secure. What makes things 100% secure today is 
that, in "Being Unilaterally Global" (BUG), the US-IANA has no 
foreign altenatives. This will be no more the case for the ICANN-IANA 
post-RFC 6852 context, because communities can support their own 
unformal specific standards they will document through their own 
community-VGN IANA-occurences.

jfc

---

From: JFC Morfin <[email-masked]>
Date: Fri, 19 Sep 2014 23:48:33 +0200

On 21:35 18/09/2014, JFC Morfin said:
>I personnaly think it is. And this is why we want our VGN users to 
>be immune as much as possible from external IANA-occurences. Since 
>this is not something you can obtain in a minute (update delays, 
>TTL, possible DoS at that time, etc.), the only solution is that VGN 
>users only trust their VGNIC as a referent.

If some think I am wrong ... what are they proposing to protect us from:

<http://www.bloomberg.com/news/2014-09-19/russia-seeks-to-safeguard-itself-from-u-s-internet-regulation.html>http://www.bloomberg.com/news/2014-09-19/russia-seeks-to-safeguard-itself-from-u-s-internet-regulation.html
http://www.reuters.com/article/2014/09/19/us-russia-internet-idUSKBN0HE1F320140919
<http://rt.com/news/188960-internet-blackout-russia-counter/>http://rt.com/news/188960-internet-blackout-russia-counter/

a kind of consideration we are definitly not interested in?

jfc

>foreign altenatives. This will be no more the case for the 
>ICANN-IANA post-RFC 6852 context, because communities can support 
>their own unformal specific standards they will document through 
>their own community-VGN IANA-occurences.
>
>jfc