Subject: [Internetgovtech] Documents from the ICG Meeting Last Week are Available

From: Russ Housley <[email-masked]>
Date: Sat, 19 Jul 2014 16:58:14 -0400

Documents from the IANA Stewardship Coordination Group (ICG) meeting last week have been posted.

The ICG charter:
https://www.icann.org/en/system/files/files/draft-charter-coordination-group-17jun14-en.pdf

A statement about the meeting that took place in London last week:
https://www.icann.org/en/system/files/files/draft-icg-statement-18jul14-en.pdf

The agenda, transcripts, and so on are available here:
https://www.icann.org/resources/pages/coordination-group-resources-2014-07-18-en

Russ

---

From: Avri Doria <[email-masked]>
Date: Mon, 21 Jul 2014 10:07:06 -0400

Hi,

> https://www.icann.org/en/system/files/files/draft-charter-coordination-group-17jun14-en.pdf

I have a question of the slice and dice methodology for the topics into
3 categories.

Does the IETF, though it includes the protocol work on DNS and the tools
to support the likes of WHOIS functionality and the design on numbering
systems, plan to only contribute 'outputs' on protocol parameters?

Not commenting for now on the orphan issues - things NTIA stewards a
that don't fit into any of the 3 defined operational groups.  that is a
problem for other messages.

I understand why various organization may be the ones to take the first
shot and even the lead on various issues, I am concerned that we
building walls to who can prodice recommendations that need to be
coordinated on which aspects.  I think that silo orientation is a losing
methodology and is one that put too much control in the hands of the IGC.

avri

---

From: Russ Housley <[email-masked]>
Date: Mon, 21 Jul 2014 10:16:42 -0400

> methodology and is one that put too much control in the hands of the IGC.

The IETF community will be responsible for the proposal for protocol parameters. I expect that interested individuals will be working with the name community or the numbers community to make sure that the right things are happening in each of those proposals as well.  Coordination will be needed where there is overlap, such as anycast addresses and special-purpose names.  That said, once the whole proposal is stitched together, it will be reviewed by all three communities and many other interested parties.

Russ

---

From: Avri Doria <[email-masked]>
Date: Mon, 21 Jul 2014 10:26:08 -0400

Hi,

> 
> The IETF community will be responsible for the proposal for protocol
> parameters. I expect that interested individuals will be working with
> the name community or the numbers community to make sure that the
> right things are happening in each of those proposals as well.
> Coordination will be needed where there is overlap, such as anycast
> addresses and special-purpose names.  That said, once the whole
> proposal is stitched together, it will be reviewed by all three
> communities and many other interested parties.
> 
>

Is that what the community as a whole has decided or just what is
decreed by the ICG.

I fund this silo approach very problematic and more likely to produce a
disjointed set of solutions - leaving too much power to the ICG to fit
things as it sees fit. But time will tell and if it has been decided by
the powers-that-be, I guess I will just have to live with it.

avri

---

From: Seun Ojedeji <[email-masked]>
Date: Mon, 21 Jul 2014 15:30:32 +0100

Hello Avri,

On Mon, Jul 21, 2014 at 3:07 PM, Avri Doria <[email-masked]> wrote:

>
>   ....I am concerned that we building walls to who can prodice
> recommendations that need to be coordinated on which aspects.  I think that
> silo orientation is a losing methodology and is one that put too much
> control in the hands of the IGC.
>

This was one the concern i raised within the number community[1]. The thing
is the process is trying to be organisaed however the attempt is making
possibility of getting diverse contribution more complex and less probable.

Regards
1. https://lists.afrinic.net/pipermail/ianaoversight/2014-July/000010.html

>
> avri
>
> _______________________________________________
> Internetgovtech mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/internetgovtech
>

-- 
------------------------------------------------------------------------

*Seun Ojedeji,Federal University Oye-Ekitiweb:      http://www.fuoye.edu.ng
<http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email:
<http://goog_1872880453>[email-masked]
<[email-masked]>*

The key to understanding is humility - my view !

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Jul 2014 10:31:06 -0400

On Mon, Jul 21, 2014 at 10:26:08AM -0400, Avri Doria wrote:
> disjointed set of solutions 

Where would be the joint whereof you speak?  To put this another way,
in my opinion protocol parameters belong squarely in the IETF's
purview, and nobody else's.  Similarly, given the protocols, names
fall squarely into ICANN's purview, no?  What is the "joint" that
wouldn't be better solved (in the case of names) by working within the
ICANN community?  Similarly for number resources, except a different
community.

I don't think there's any handed-down-ness about it.  This is a fully
community-based approach, I think.

A

-- 
Andrew Sullivan
[email-masked]

---

From: John Curran <[email-masked]>
Date: Mon, 21 Jul 2014 10:36:42 -0400

> The IETF community will be responsible for the proposal for protocol parameters. I expect that interested individuals will be working with the name community or the numbers community to make sure t…

This is a reasonable approach, given that there is a dedicated coordinating
group that can facilitate the necessary review and coordination steps to make 
a consistent proposal. It would also be helpful if an IAB/IETF IANA framework 
<http://tools.ietf.org/html/draft-iab-iana-framework-02> for all of the IETF
registries (i.e. technical "protocol parameter" ones, more "general purpose" 
registries of DNS root zone, IP address spaces, ASN spaces, etc.) were to 
be published, as this would help make plain the IETF's generic expectations 
for the registries component of its successful Internet protocol development
efforts.

Thanks!
/John

Disclaimer: My views alone.

---

From: Avri Doria <[email-masked]>
Date: Mon, 21 Jul 2014 10:52:14 -0400

Hi,

I am not necessarily looking for joint efforts - though it might be
nice, just allowing for any of the communities to produce
recommendations on any of the aspects.

There are cross over concerns, for example in ICANN the Advisory
Committees (At Large, Government, Security etc) have purview to advise
on addresses as well as numbers and even parameters when it concerns
tech that will be used to manage those names and numbers.  Why does our
process say that they can't make recommendations on that?

Likewise the IETF has great concerns over the allocations of some names
and may want to make a suggestion of how the allocation of names is done
given the IETF's decision that it is able to assign names for protocol
reasons.  That is a tussle waiting in the wings that needs to come out
into the light for all of this assignment of responsibilities.

Yes, the IETF will naturally choose to mostly produce recommendations on
parameters, but need it be limited to that?  Likewise with the other groups.

I have no problem with the notion of an expectation that mostly
parameters will be covered by IETF and names by GNSO and the ccNSO, and
numbers by the NRO.  What I have problems with is the construction of
silo walls that indicate an expectation that others might not have
standing and ability to contribute to the proposed solutions on
particular subjects.

I do not want there to be a possibility that someone calls an
uncomfortable recommendaton out of scope for the organization making it.

As for this have been handed down, I do not remember there ever being a
community wide discussion on slice and dice, just announcements of this
being the way it would be from various leaders.

avri

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 Jul 2014 10:54:03 -0400

> the powers-that-be, I guess I will just have to live with it.

The alternative is creating more one time processes that are by
definition untested.  We could spend months more doing just that and do
it poorly, rather than actually developing proposals to be knitted
together.  The words in the current charter make clear that the key role
of the ICG is to gain consensus among the different communities, and
specifically *not* to develop the contents.  And so let's just please
manage the corner cases (there are several).

Eliot

---

From: John Curran <[email-masked]>
Date: Mon, 21 Jul 2014 12:08:54 -0400

> standing and ability to contribute to the proposed solutions on

Avri - 

Since the ICG charter specifically states that everyone's input is to be 
welcome across all topics, I'm not certain how anyone's contribution could 
be excluded for a lack of "standing"...  From how I read the process, any
such input will be considered by the ICG, and potentially provided back to 
the appropriate operational community for consideration; this is regardless 
of its origin.  (Of course, that's just my take based on the charter just 
published, I am not in London/Toronto nor part of the ICG.)

Do you read it differently?
/John

Disclaimer:  My views alone - no IANA accountability mechanisms are proposed
             by way of this email.

---

From: Avri Doria <[email-masked]>
Date: Mon, 21 Jul 2014 12:27:00 -0400

Hi

>  Do you read it differently?

Yes.  I read it as saying the while comments can be accepted by all,
outputs/proposals seem to only come from the 3 designated operational
actors, each restricted to their assigned topic.

I.e. first there are proposals from the 3 operational assignees on their
assigned topic

then there is broader input on the transition proposal

avri

---

From: John Curran <[email-masked]>
Date: Mon, 21 Jul 2014 12:37:18 -0400

On Jul 21, 2014, at 10:52 AM, Avri Doria <[email-masked]> wrote:

> tech that will be used to manage those names and numbers.

Could you elaborate some on the above concepts?  I understand how there is 
potential for consultation with such advisory committees if considered 
appropriate by the ICANN Board (and as provided for in the ASO Global Policy 
Development process), but the more typical method of engagement is directly 
in the policy development processes taking place in each RIR region... in 
this way, the input is considered closer to those affected by the outcome.  

Similarly, I am not aware of any ICANN advisory committees providing input 
to the IETF regarding issues in protocol parameter registry administration;
any/all parties with concerns are encouraged to participate in the relevant 
IETF working group and/or last call process to make sure their concerns are 
heard in a timely manner.

I guess I'm trying to understand what "IANA stewardship" responsibilities
the various ICANN advisory groups may feel with respect to the IP registry
and technical protocol parameter spaces?  Do you see it with respect to the
policy development aspect or policy administration/IANA registry operations?

> Why does our process say that they can't make recommendations on that?

I do not believe it does; my reading of the charter indicates that anyone 
can make recommendations regarding IANA stewardship and related transition 
matters.

Thanks!
/John

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 21 Jul 2014 10:13:47 -0700

Andrew,

When applicants (note the plural) sought single Han script character 
(necessarily 5 or more octets) labels in the IANA root, the IETF's 
liaison objected, and when an applicant sought to use only characters in 
the 0-9 range as a label in the IANA root, again, the IETF's liaison 
objected. Other examples of third-party involvement in the policy 
development of the GNSO (the only portion of ICANN with ByLaws 
responsibilities for domain name policy development) exist.

I appreciate that you were expressing your own opinion, and perhaps 
brevity could have been equally well served by "most names" or "names, 
with some exceptions", in your response to Avri.

Also, just to be somewhat formal, since the removal of the Protocol 
Supporting Organization from the ByLaws in 2003, other than the 
persuasive abilities of Liaisons, the "members" of the ICANN community 
-- and recall ICANN is a 501(c)(3) with no members -- however vigorous 
and vocal, are but (a very few) individuals with no particular status, 
commenting on policy developed by a ByLaws body, and so unlikely to 
participate effectively in review/purview/oversight/ghastly-error-avoidance.

Perhaps if you'd written "names fall squarely into the GNSO purview, 
no?" Then the locus of control, and the composition of the controllers 
-- that community -- would be unambiguous, and modulo persuasive 
Liaisons, supra, and the efforts of third-parties such as the GNSO, and 
correct.

Eric

---

From: Seun Ojedeji <[email-masked]>
Date: Mon, 21 Jul 2014 18:33:39 +0100

sent from Google nexus 4
kindly excuse brevity and typos.
On 21 Jul 2014 17:09, "John Curran" <[email-masked]> wrote:

 From how I read the process, any
> of its origin.
If I may ask where is the process that "anyone" will take to provide input
indicated?

Thanks

Cheers!
 (Of course, that's just my take based on the charter just

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Jul 2014 13:47:04 -0400

On Mon, Jul 21, 2014 at 10:13:47AM -0700, Eric Brunner-Williams wrote:

> liaison objected, and when an applicant sought to use only
> characters in the 0-9 range as a label in the IANA root, again, the
> IETF's liaison objected.

Right.  What's wrong with that?  In that case, we've actually created
a formal mechanism for the IETF to deliver its opinions to ICANN -- a
liaison.  Also, because all the relevant communities (IETF, ICANN, all
the RIRs) run open, community-driven processes, people can have a foot
in both worlds: there's nothing that says you have to participate in
only one community.  I think you'd be seeing a very different set of
proposals if some of these communities were closed.  But they're not,
and I don't think it's worth inventing a process for a problem we
don't have.

Anyway, by and large, there are three areas of interest here with
three associated communities _qua_ community.  I'm not sure I see how
trying to mix that up (and invent a complete new process by which we
co-ordinate across these communities in real time) is better than
saying, "Just use the existing processes we have for the three broad
areas."

Now, are there some corner cases?  Of course.  But reasonable
engineering says that, for a one-time event, you can deal with the
small number of corner cases one at a time by hand, rather than create
a process.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Avri Doria <[email-masked]>
Date: Mon, 21 Jul 2014 14:11:52 -0400

Hi,

> this way, the input is considered closer to those affected by the outcome.  

The ASO is part of ICANN.  Anything it does, is open to comment by any
of the Adivisory Committees (AC).  I am assuming that the ASO and the
NRO are not identical as they both got seats on the ICG.  That indicates
that there are ICANN concerns with numbers that may be more
appropriately dealt by ICANN participants.

I understand that the RIRs all have their own regional participants, but
at the global level, there is very little stakeholder participation,
with the ICANN Advisory Committees being the only possible venue for
such concerns.  doea the NRO provide a multistakeholder venue at the
global level or is that the task of the ASO?  Because the ASO is part of
ICANN, the ACs have a voice in their activities and thus have a say in
the accountability methods for those issues.

On a specific example that I pay more attention to than numbers, the
IETF has recently asserted its ability to take names out of the general
pool of labels available for TLDs by declaring them to be protocol
artifacts, i.e. RFC 6761 on Special Use Names.  To assert IETF having
full control of this interface without any accountability to others is
problematic.  While this may just be an edge case from the IETF protocol
perspective, it could could be a huge issue from the ICANN perspective.

It is just not as simple as one group per each issue.   And I am sure
that as we go on, we will find other issues of commonality that need to
be explored.

And I still don't know who submits proposals on the .arpa, or .int issue
and the root server issues.

In a world where the various tech and the various policy issues are so
intertwined and interdependent, I think siloing is risky and should be
avoided.

avri

BTW, i have sent too many messages to this list today and figure i
better stop before someone speaks to me sternly.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 21 Jul 2014 20:20:44 +0200

> then there is broader input on the transition proposal

Avri, let me express it differently.

There are _main_ categories and _main_ holders of processes for each one of them. But there are (as you pointed out yourself) a few IANA "things" that are not so clear where they fit, and there are groups (like SSAC) that is chartered to work with all three.

What the CG have identified already now is that the maturity of the PDP and relationship between the policy development and IANA is different for the various categories, and we found it being good to already now identify that fact, and that it might be that the various categories must be treated slightly differently.

No one like silos, and that is definitely not the intention. Trust me!

It is to not create too many dependencies between various processes that have different maturity.

   Patrik

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 21 Jul 2014 12:40:44 -0700

Andrew,

If I wrote that there was "something wrong with that", you're response 
would be ... responsive.

You've observed that, in your opinion, "names fall squarely into ICANN's 
purview", and I've pointed out that there are examples where the policy 
of the GNSO, the only ICANN ByLaws entity with responsibility for names 
policy, has been altered by third-parties.

See also Avri's note on some restrictions on labels offered by some 
third-parties.

Eric

P.S. Exactly what is wrong with 5 octet labels? With 4 octet labels? 
With 3 octet labels? And finally, with 2 octet labels?

P.P.S. Exactly what is wrong with a terminal label consisting only of 
characters in the 0-9 range, that is not completely cured by a 
requirement that the next subordinate label contain one or more 
characters from the range g-z?

---

From: John Curran <[email-masked]>
Date: Mon, 21 Jul 2014 15:48:38 -0400

On Jul 21, 2014, at 2:11 PM, Avri Doria <[email-masked]> wrote:
> of the Adivisory Committees (AC).

Yes - in accordance with the agreement between ICANN and the NRO including
the Global Policy Development Process contained therein.  I expect that the 
ICANN Board would want to promptly seek such advisory committee comment 
given the timelines involved...

> such concerns.

Given that something does not get to ICANN until it has been fully agreed 
as a result of policy development meetings in all of the regions generally 
over a period of years, it would probably be more productive to engage in 
the regional processes leading to the formation of the global policy (i.e.
rather than at the very end of lengthly consensus building process)  

It might make sense for ICANN to look at that model for its own policy
development efforts; it might help address some of the concerns I heard
expressed at the recent IGF-USA meeting about ICANN advisory committees 
needing to be more involved in the policy development process and hence
more invested in the developed outcomes.

>  doea the NRO provide a multistakeholder venue at the

The ASO does provide for global policy _coordination_ and participates
in ICANN's accountability review processes.  Note that the ASO does not 
do policy development; that takes place closer to the effected parties 
via meetings in each region.

You probably need to look over the agreements between ICANN and the
RIRs/NRO, as the RIRs are accountable (as actual membership orgs) to
their respective communities via elected leaderships and open policy
development processes. The ICANN Board is accountable per agreement
to the collected addressing community for the timely review and 
ratification of proposed global address policies.

> perspective, it could could be a huge issue from the ICANN perspective.

Strange... The IETF created the namespace through definition of the DNS
protocol, just as they did with IPv4 and IPv6 number spaces.  If there 
are technical/specialized reservations that they (the IETF) see fit to 
make, then that portion of the identifier space is no longer part of 
the "general purpose" portion of the affected registry.  

We work these issues fairly routinely on the addressing side, and I 
would say have excellent working relationships.  Ultimately, those who
are actually affected (service providers, equipment makers, researchers)
know to show up in appropriate working groups in the IETF to make their
views heard.  I have ample faith in the openness and accountability 
of the IETF processes to the affected community in these matters, but
would be willing to consider bodies such as the RIRs as equally capable
given their membership structure.  Trying to claim accountability absent 
the ingrained institutional record of the IETF or an actual membership
model does seem more difficult.

> and the root server issues.

If those are technical reservations from the DNS space, then they are backed
by RFCs and will be followed by ICANN per the existing IETF MOU (RFC 2860).
In the event ICANN adopts a policy that prevents it from complying with such
guidance, things would get interesting real fast (see MOU section 4.3...) 

> intertwined and interdependent, I think siloing is risky and should be

It's much simpler if you look at things one parameter space at a time: 
who created it, what technical reservations does it have, is there a 
general purpose portion & if so who is the delegated policy authority, 
what entity administers the resulting policy, and what party performs 
registry operations/publication for the entire parameter space?  The 
general purpose DNS and IP registries are only portions are subsets 
of the entire registry spaces; keeping that in mind may help quite a
bit with clarity of roles.

FYI,
/John

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Jul 2014 16:08:24 -0400

Since you asked on list, I'll reply, but I don't think this is the
right list to pursue this discussion and if we're going to have to do
that I suggest perhaps DNSOP or the dns-operations OARC list or
perhaps [email-masked] (which is still open), depending on whether
you want to talk about protocol or operations.

> With 3 octet labels? And finally, with 2 octet labels?

Nothing, in principle.  In practice, it depends.  You might want to
have a look at RFC 6912.  Even though it was particularly about
Unicode code points for U-labels, the general principles outlined
there are useful in other ways too.

> P.P.S. Exactly what is wrong with a terminal label consisting only
> of characters in the 0-9 range, that is not completely cured by a

Well, the actual terminal label cannot contain any characters at all,
but I think you knew that and meant the second-to-last label
(conventionally called a TLD).  So, first, there's actually no
technical way to require what you're saying, really.  That's what
"delegation" means.  You could do it with contracts, though.  

But what you're really saying is that the heuristic implied in RFC
1123 might break.  That seems like an extremely incautious thing to
do, and therefore a responsible operator of the root zone wouldn't do
it.  Technology is not infinitely plastic: once you have deployed
something, it affects the world.  In the case of the DNS, the way it
has affected the world is partly based in the assumptions people have
about what their software may depend on.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 21 Jul 2014 13:20:31 -0700

Yeah, that was a mistake. If you ever get around to responding to the 
main point that would be ... well, too late at this point.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Jul 2014 16:52:30 -0400

On Mon, Jul 21, 2014 at 12:40:44PM -0700, Eric Brunner-Williams wrote:
> ICANN's purview", and I've pointed out that there are examples where
> the policy of the GNSO, the only ICANN ByLaws entity with
> responsibility for names policy, has been altered by third-parties.

Well, first, for the current discussion, I don't have a theory of how
policy development goes on inside ICANN, which is why I think the
discussions about that ought to live inside the relevant community.
But also, see John's remarks about the scope of all this.  I agree
with what he said, so I won't repeat it.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 21 Jul 2014 14:10:47 -0700

On 7/21/14 1:52 PM, Andrew Sullivan wrote:
> I don't have a theory of how
> policy development goes on inside ICANN,

and, a few hours earlier.

> names
> fall squarely into ICANN's purview, no?

Eric

---

From: Olivier MJ Crepin-Leblond <[email-masked]>
Date: Tue, 22 Jul 2014 00:08:01 +0200

Dear John,

> bit with clarity of roles.

Is there going to also be a study of accountability mechanisms for each
of the parties administering each parameter space?
Kindest regards,

Olivier

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 Jul 2014 18:26:37 -0400

Olivier,

On 7/21/14, 6:08 PM, Olivier MJ Crepin-Leblond wrote:
> Is there going to also be a study of accountability mechanisms for
> each of the parties administering each parameter space?

Certainly the community should review our existing model to decide what
needs to change.  But we should be mindful that we do have a functioning
service, and some principles that were reviewed on this list and
presented in London that do guide us.  I also think the proposed charter
that Andrew put out makes pretty clear what needs to be reviewed.

Eliot

---

From: John Curran <[email-masked]>
Date: Mon, 21 Jul 2014 21:03:20 -0400

> of the parties administering each parameter space?

Olivier - 
 
As I understand it, we have been discussing the charter of the 
"IANA Stewardship Transition Coordination Group (ICG)", which 
is responsible for coordinating in the formation of a plan for 
the transitioning of NTIA’s stewardship of the IANA functions.

The IANA Functions are administrative/clerical registry functions
for all of the parameter spaces, including protocol parameters
in general, and the general purpose portions of the DNS and IP
address spaces.  All of these are administered by the "IANA"
(by a team of folks within ICANN); if the ICG does its job,
the resulting plan will cover (as your state) the "accountability 
mechanisms for each of the parties administering each parameter 
space", but in this case, the administration is being done by 
all the same party, i.e. ICANN in its performance as the IANA.

I believe what you meant to ask is a significantly different 
question regarding study of accountability mechanisms for the 
_policy authority and policy development_ aspects of each of
the parameter spaces.   

I know that ICANN has kicked off an ICANN Accountability effort 
which presumably will encompass such with respect to its DNS policy 
efforts...  With respect to policy authority and relationships 
for the address parameter spaces, the 5 RIRs have stated that 
"we believe than a review is appropriate at this time, prior to 
the expected NTIA transition, along with reviews by each of the 
RIRs of their own accountability mechanisms."  
<https://www.nro.net/wp-content/uploads/NRO-to-ICANN-Accountability-2014066.pdf>

As with regard to accountability mechanisms for the technical 
protocol parameter spaces created by the IETF, I do not know if 
any review is planned or even warranted.  Protocol use is nominally 
a voluntary choice, and to the extent that the IETF predominantly 
sticks to technical criteria and its open & transparent development 
processes, it should be the rightful authority for any registries 
created out of that process.  I guess if the  IETF were to make a
habit of embedding social policy aspects into its protocol design, 
one could argue that its processes and accountability mechanisms 
become a valid item to review, but the IETF hasn't historically 
been embedding public policy values into its protocol designs...
(and any claim that the present day NTIA contract provides a
"accountability mechanism" in this regard is specious.) 

FYI,
/John

---

From: S Moonesamy <[email-masked]>
Date: Tue, 22 Jul 2014 01:20:16 -0700

Hi Seun,
At 07:30 21-07-2014, Seun Ojedeji wrote:
>This was one the concern i raised within the number community[1]. 
>The thing is the process is trying to be organisaed however the 
>attempt is making possibility of getting diverse contribution more 
>complex and less probable.

The concern in that message was about the process for the various 
numbers communities.  It isn't directly related to the protocol 
parameters registry.  I'll mention that I have previously reviewed 
numbers-related requests in IETF drafts.  Several persons who have 
posted on this thread (and another one) have an interest in 
names.  They didn't mention concerns about the names side.

I took a quick look at the proposed charter.  According to that 
document the coordination group will be acting as a clearinghouse for 
proposals about the various IANA Functions.  There is already some 
discussion in the IETF about the process for the protocol parameter 
Function.  As I am already familiar with the IETF process I did not 
consider it as useful to ask questions about that process at this stage.

One thing that I found odd is why this discussion is taking place on 
this IAB mailing list instead of the venues for the relevant 
communities.  This is where I will get blamed for starting the 
(previous) off-topic thread.

Please note that I do not have any concern about the following.  The 
problem [1] is that the proposed (coordination) charter does not 
provide much information about the process.  From that document:

   "The ICG will then put this proposal up for public comment involving
    a reasonable period of time for reviewing the draft proposal, analyzing
    and preparing supportive or critical comments.  The ICG will then
    review these comments and determine whether modifications are required.
    If no modifications are needed, and the coordination group agrees,
    the proposal will be submitted to NTIA."

If I was able to suggest something I would say:

   (a) Please don't use words such as "reasonable period of time".

   (b) Please don't use words such as "supportive or critical comments".

   (c) Please clarify how the comments will be reviewed.

Regards,
S. Moonesamy

1. I picked the first word that came to my mind.

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 22 Jul 2014 06:00:52 -0400

> that Andrew put out makes pretty clear what needs to be reviewed.

Perhaps I can rephrase Eliot's point by referring back to the previous discussion of Andrew's proposed charter for the ianaplan activity.

It seems that the task at hand is limited to assessing and planning what needs to change if the NTIA contract with ICANN for the IANA functions goes away.

NTIA today has nothing to do with "accountability mechanisms for each of the parties administering each parameter space" under IETF policy management, and touches only a very small handful of general purpose parameter spaces associated with IETF protocols (DNS and IP).

Could you explain why "study[ing]…accountability mechanisms" of the rest of the "parties administering each protocol space" is important to move beyond the current ICANN-NTIA IANA functions contract? I guess I don't understand what organizations or processes you're proposing to "study," or to what purpose.

thanks,
Suzanne

---

From: Avri Doria <[email-masked]>
Date: Tue, 22 Jul 2014 07:30:01 -0400

On 22-Jul-14 06:00, Suzanne Woolf wrote:
> NTIA today has nothing to do with "accountability mechanisms for each
> of the parties administering each parameter space" under IETF policy
> management, and touches only a very small handful of general purpose
> parameter spaces associated with IETF protocols (DNS and IP).

I disagree.  NTIA provides a giant accountability function.

Just about everyone goes running to NTIA whenever something they don't
like happens.  And the fine folks at NTIA finesse the situation and get
things back on the right track.  I believe it happens all the time.

NTIA are the adults in the room and we better have adequate
accountability all around when they step out of their role.

avri

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 22 Jul 2014 07:43:40 -0400

> things back on the right track.  I believe it happens all the time.

Just to be clear: the scope of my remarks was intended to be primarily on the IETF, as this is the IAB's list and I'm trying to keep to that focus. 

Is your assertion that "everyone goes running to NTIA" and that "it happens all the time" intended to describe the situation regarding the IETF and the IANA protocol parameter registries?

If so, I'm curious how people directly involved in the IETF's relationship with IANA will respond. As I am not one of those people, I'll simply confess to being deeply surprised by this assertion if it's intended to include the IETF and the protocol parameter registries for which it provides direction to IANA.

thanks,
Suzanne

---

From: John Curran <[email-masked]>
Date: Tue, 22 Jul 2014 07:49:37 -0400

> things back on the right track.  I believe it happens all the time.

That might happen with respect to DNS general-purpose identifiers, but such
is consequential of ICANN being in all of the roles at once when it comes to
DNS (coordination/accountability, policy development, policy administration, 
registry update, and registry publication), whereas the original blueprint 
called DNS policy development to be primarily arms-length to ICANN in an 
independent body.  Mash all of those roles together, and you get lots of 
accountability concerns and opportunities for NTIA involvement.  

Both the RIRs and IETF operate with policy development external to ICANN;
NTIA has not, to my knowledge, ever been involved in "finessing" any issue
in those areas.

> accountability all around when they step out of their role.

It's worth noting that (for IP addresses and protocol parameters) that we've 
had that solid accountability via membership structures, long-established 
use of open/transparent practices, and contractual separation of roles from 
the IANA since day one, so it would indeed be nice to see some of that sort 
of progress in the DNS area.

Please remember that both the IETF and several of teh Regional Internet 
registries predate ICANN and have represented "running code" long before
the IANA functions contract came into being.

Thanks!
/John

---

From: S Moonesamy <[email-masked]>
Date: Tue, 22 Jul 2014 10:48:02 -0700

Hi John,

This comment is unrelated to the transition.

>been embedding public policy values into its protocol designs...

During discussions about protocol design there are instances where 
the line between the technical aspects and the other aspects not that 
clear.  As an example, I posted a review of a BCP at 
http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00454.html 
My personal experience is that it is becoming difficult to determine 
whether I am straying too far away from the technical aspects during 
discussions about surveillance.

There was an IETF discussion yesterday about an IETF technology and 
Africa.  Someone argued [1] that security is not considered as a high 
priority in Africa and that it makes sense to do have intermediaries 
in between the servers and the users.  There are technical benefits 
for having intermediaries.  This is where a person would have to 
decide whether it is appropriate, as part of the design, to allow 
interception in the protocol.

Regards,
S. Moonesamy

1. I did not catch the exact words and I could be misinterpreting 
what was said.

---

From: John Curran <[email-masked]>
Date: Tue, 22 Jul 2014 15:14:00 -0400

On Jul 22, 2014, at 1:48 PM, S Moonesamy <[email-masked]> wrote:

> During discussions about protocol design there are instances where the line between the technical aspects and the other aspects not that clear.  

Indeed - to the extent that the IETF decides to embed specific public
policy positions into protocols being developed, it becomes much easier 
to argue that it should have some responsibility (and accountability) for 
engagement beyond its traditional technical community on such issues.

/John

---

From: Seun Ojedeji <[email-masked]>
Date: Tue, 22 Jul 2014 20:50:34 +0100

Hi SM,
On Tue, Jul 22, 2014 at 9:20 AM, S Moonesamy <[email-masked]> wrote:

>> This was one the concern i raised within the number community[1]. The
>> thing is the process is trying to be organisaed however the attempt is
>> making possibility of getting diverse contribution more complex and less
>> probable.
>>
>
> The concern in that message was about the process for the various numbers
> communities.  It isn't directly related to the protocol parameters
> registry.  I'll mention that I have previously reviewed numbers-related
> requests in IETF drafts.  Several persons who have posted on this thread
> (and another one) have an interest in names.  They didn't mention concerns
> about the names side.
>
> I took a quick look at the proposed charter.  According to that document
> the coordination group will be acting as a clearinghouse for proposals
> about the various IANA Functions.  There is already some discussion in the
> IETF about the process for the protocol parameter Function.  As I am
> already familiar with the IETF process I did not consider it as useful to
> ask questions about that process at this stage.
>
> One thing that I found odd is why this discussion is taking place on this
> IAB mailing list instead of the venues for the relevant communities.

Well you are right about this; i posted here about numbers to qualify the
"names" interest. On whether my concern was discussed in relevant
community, well can i assume you are also subscribed on that AFRINIC IANA
list, as it sure looks like the list is in listening mode ;).[1] The other
reason why i do respond on comments that is of interest on any list is
because right now there is no global space to discuss the transition
process. For instance, the charter which ICG refer to as a draft and say is
up for comment does not have a clear process on how they receive comments
beyond the 3 communities. The charter indicates that its open and at the
same time will receive contribution from the 3 communities; how about those
who like to comment on names for instance but belong to the numbers
community(it seem like a community based restriction to me). I had thought
a global space will be maintained and the ICG will let us know that they
are watching the list for comments.

 This is where I will get blamed for starting the (previous) off-topic
> thread.
> problem [1] is that the proposed (coordination) charter does not provide
> much information about the process.  From that document:
>

This is the summary of what i am trying to communicate.

Cheers!
1. I have posted my view on the list about the numbers process in engaging
its community and Adiel indicated he will check the possibility out with
the other RIRs. Will be good to read your view via that medium also.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 22 Jul 2014 16:58:18 -0700

Hi Seun,
At 12:50 22-07-2014, Seun Ojedeji wrote:
>Well you are right about this; i posted here about numbers to 
>qualify the "names" interest. On whether my concern was discussed in 
>relevant community, well can i assume you are also subscribed on 
>that AFRINIC IANA list, as it sure looks like the list is in 
>listening mode ;).[1] The other reason why i do respond on comments 
>that is of interest

That assumption is correct. :-)

>  on any list is because right now there is no global space to 
> discuss the transition process. For instance, the charter which ICG 
> refer to as a draft and say is up for
>  comment does not have a clear process on how they receive comments 
> beyond the 3 communities. The charter indicates that its open and 
> at the same time will receive contribution from the 3 communities; 
> how about those who like to comment on names for instance but 
> belong to the numbers community(it seem like a community based 
> restriction to me). I had thought a global space will be maintained 
> and the ICG will let us know that they are watching the list for comments.

According to a stewardship transition document there are 13 
communities: ASO, ICC/BASIS, ISOC, NRO, IETF, IAB, SSAC, RSSAC, ALAC, 
GAC, GSNO, gTLD Registries and ccNSO.  The draft charter mentions 
that the Functions are divided into three main categories.  It looks 
like the theory of those who came up with the plan is that a person 
will be able to find a representative in one of those communities to 
represent his or her interests.  The draft charter also mentions that 
there are relevant community processes and it says that the 
coordination group may refer input it receives to the relevant 
community discussion.

Let's assume that you belong to the numbers community and you have an 
interest in names.  I guess that you could contact a representative 
from 
https://www.icann.org/resources/pages/coordination-group-2014-06-17-en 
for advice.

>1. I have posted my view on the list about the numbers process in 
>engaging its community and Adiel indicated he will check the 
>possibility out with the other RIRs. Will be good to read your view 
>via that medium also.

One definition of conflict of interest is "when a person has separate 
duties to act in the best interest of two or more clients in relation 
to the same or related matter, and those duties conflict, or there is 
a significant risk that those duties may conflict".  I would be 
increasing the risk by getting involved in a discussion about the 
numbers process.

Regards,
S. Moonesamy

---

From: John Curran <[email-masked]>
Date: Tue, 22 Jul 2014 21:12:53 -0400

On Jul 22, 2014, at 7:58 PM, S Moonesamy <[email-masked]> wrote:

> According to a stewardship transition document there are 13 communities: ASO, ICC/BASIS, ISOC, NRO, IETF, IAB, SSAC, RSSAC, ALAC, GAC, GSNO, gTLD Registries and ccNSO.  The draft charter mentions that the Functions are divided into three main categories.  
...
> It looks like the theory of those who came up with the plan is that a person will be able to find a representative in one of those communities to represent his or her interests.

I don't see anything to support that theory in any of the materials;
as I understand it, the coordinating group acts as liaisons for the
solicitation of proposals, assembly of a complete proposal, and the 
related communications.  

> The draft charter also mentions that there are relevant community processes and it says that the coordination group may refer input it receives to the relevant community discussion.

Relevant community processes are mentioned in the materials, so I 
imagine that will mean processes in each of the communities to come
up with various proposals.  Contacting a representative makes sense,
but not to carry your views as much as find our the process in that
community for participating and sharing your views therein.

> Let's assume that you belong to the numbers community and you have an interest in names.  I guess that you could contact a representative from https://www.icann.org/resources/pages/coordination-group-2014-06-17-en for advice.

That's probably a fine starting point, but it would be even better if 
there were processes for each of the various communities to work on 
proposals.  You could then get involved in each of the communities that
you felt you had interest in.

> One definition of conflict of interest is "when a person has separate duties to act in the best interest of two or more clients in relation to the same or related matter, and those duties conflict, or there is a significant risk that those duties may conflict".  I would be increasing the risk by getting involved in a discussion about the numbers process.

Strange; many folks that I know are involved in multiple communities,
and I'd expect to see them involved in each of the processes to the 
extent that they are interested in such...  This is no different than
regular participants in IETF working groups; they participate as 
individuals (not representatives of any particular community) and 
their ideas are evaluated on merit rather than origin or imprimatur. 

I can understand a concern in clarity of participation by those on 
the ITG, but I do not know why it would be an issue for anyone else,
(unless they somehow have been given a duty to formally represent 
one of these communities)

/John

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 23 Jul 2014 07:18:59 +0200

> you felt you had interest in.

This is btw also what (we in) the Coordination Group encourage.

From our statement <https://www.icann.org/en/system/files/files/draft-icg-statement-18jul14-en.pdf>:

> We encourage all interested parties to engage early and often in the community discussions now underway.

   Patrik

---

From: S Moonesamy <[email-masked]>
Date: Wed, 23 Jul 2014 00:19:55 -0700

Hi John,
>solicitation of proposals, assembly of a complete proposal, and the

Ok.

>community for participating and sharing your views therein.

Ok.

>you felt you had interest in.

Ok.

I prefer not to be involved in discussions about the transition in 
the other communities as the issues are too controversial.

>their ideas are evaluated on merit rather than origin or imprimatur.

I'll comment about the second sentence (above).  I have participated 
in several IETF working groups in several Areas; I am the only person 
from my region who used to send Last Call comments to 
[email-masked].  My personal experience has been that I was held to a 
higher standard compared to other regular participants.  I don't wish 
that newcomers, irrespective of origin, go through the same 
experience as I did.

>one of these communities)

It is a personal decision.  I'll cite some words from the Supreme 
Court of Texas:

   "The needs of the many outweigh ...
    the needs of the few"

I don't know the right answer for the above.  I do know that there 
are three words missing in the above [1][2].

Regards,
S. Moonesamy

1. http://www.youtube.com/watch?v=MhRmlV0aaDg
2. http://www.youtube.com/watch?v=dhcR-w-56tA

---

From: Olivier MJ Crepin-Leblond <[email-masked]>
Date: Wed, 23 Jul 2014 22:10:30 +0200

I'd just like to register my agreement with Avri on this.

Please be so kind to review the table in this document:
https://www.icann.org/en/system/files/files/iana-transition-scoping-08apr14-en.pdf

I clearly points to new accountability mechanisms needed for *all*
functions.

Kindest regards,

Olivier
(own views)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jul 2014 08:43:23 +1200

Olivier,

> I clearly points to new accountability mechanisms needed for *all*

It would be absurd to define new mechanisms if the existing ones are
fully satisfactory.

    Brian

---

From: John Curran <[email-masked]>
Date: Wed, 23 Jul 2014 16:56:11 -0400

> I clearly points to new accountability mechanisms needed for *all*

The scoping document calls for "defining accountability mechanisms 
that would serve to replace the current stewardship role played by 
NTIA to ensure ICANN’s performance of the IANA functions based on 
the agreements and/or policies provided by the respective bodies 
(IETF, GNSO, RIRs, ASO, ccTLDs, ccNSO)."

In short, before one can meaningfully define any "new accountability 
mechanisms" with respect to protocol parameters or IP addresses that
would "replace the current stewardship role played by NTIA", you'll
first want to confirm that there is an operative NTIA stewardship 
role in these spaces to be replaced, i.e., some NTIA accountability 
mechanisms aside from the referenced agreements with the IAB & RIRs.
Otherwise, you stand to risk replacing the existing, well-functioning
IANA accountability mechanisms to these communities with something 
"new" and hence by definition unproven.

Thanks!
/John

---

From: Avri Doria <[email-masked]>
Date: Wed, 23 Jul 2014 17:15:31 -0400

Hi,

> It would be absurd to define new mechanisms if the existing ones are

ah the old 'if it ain't broke' conundrum.

Thing is, while it is not broken for some, it is broken for others.

For me, as an example at this point, I see breakage on things like the
self established ability of the IETF to unilaterally decide that a
protocol mandates removing labels from the list of available TLD labels.

As a long time participant in the IETF, I see how natural this decision
is for the the IETF and a part of me cheers at the simplicity of this
solution for any number of issues.

As a member of the ICANN GNSO Council I am outraged at the idea because
it is a policy decision that the technical arm of the enterprise has no
business making.

To whom is the IETF accountable in making this decision?  Just itself?

This is breakage.

Likewise if ICANN were to start making technical decisions and deciding
to use protocols designed in places other than the IETF, or where to
just start modifying IETF protocols without any consideration of IETF
perogative of change control, I expect many in this group would be
outraged.

To whom is ICANN accountable in making this decisions?  Just itself?

(yes there are liaisons and that is part of the accountability
structure, but it too exists between the silos being defined by the ICG)

If we have no common accountability mechanisms, each of the groups can
do what it pleases willy nilly without any support or buy in by other
stakeholders.

I am sure others from outside of the IETF and ICANN bubbles can come up
with other scenarios where the policy decision made in the act of
deciding between protocol trades off  do not take sufficient account of
the concerns of users or others.

Though rarely if ever exercised, there is a current point of common
accountability where everyone could run to.  It is needed and I can't
see how this process will get global buy in without one.

If ain't broke ... doesn't work for most of the world, because most of
the world see breakage, even if insiders normally don't.

avri

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jul 2014 09:24:56 +1200

> protocol mandates removing labels from the list of available TLD labels.

Can you be specific, since I really don't what you mean?

> To whom is the IETF accountable in making this decision?  Just itself?

What does that have to do with ICANN or IANA accountability?

    Brian

---

From: Avri Doria <[email-masked]>
Date: Wed, 23 Jul 2014 17:46:59 -0400

Hi,

> Can you be specific, since I really don't what you mean?

RFC 6761 Special Use Domain Names
https://tools.ietf.org/html/rfc6761

Allows for protocol that meet certain conditions to reserve TLDs.

> What does that have to do with ICANN or IANA accountability?

Well this and IETF act with regard to IANA entries in a area where ICANN
might think it get a say.

To whom is IANA accountable in making the reservation? the IETF.

But ICANN is responsible for policy regarding TLDs.  It gets to tell
IANA what to do with TLDs.

It seems to me that it is what could be called a cross-accountabilty
example.

IETF 'quite rightly' says it controls protocol parameters and it can do
what it pleases with them despite any policy implications that may occur
that it may or may not have considered.  It tells IANA to make these
changes.  IANA arrangements with IETF says do what IETF says.  As long
as we stick to a single point of accountability for each function we
have no way out of this problem.  I therefore argue that there has to be
accountability mechanisms that cross the 'jurisdictions'.

And this is but one simple issue.

avri

---

From: JFC Morfin <[email-masked]>
Date: Wed, 23 Jul 2014 23:44:05 +0200

>To whom is the IETF accountable in making this decision?  Just itself?

This is the "BUG": as "Being Unillateraly Global".
If this might be the way global communities (cf. RFC 6852) under 
influence may work, this is not the way the real world does.

The IETF proposes its way to run the digisphere.
ICANN to govern it.

There are billions of others in a "people centered" information society.
Sorry
jfc

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Jul 2014 17:53:54 -0400

Hi Avri,

> protocol mandates removing labels from the list of available TLD labels.

"Unilaterally" implies that somehow the community isn't involved in the
decision.
> To whom is the IETF accountable in making this decision?  Just itself?

The community and through its leadership through the NOMCOM process,
which also takes into account community views.  But to be specific, when
the IETF steps in and reserves a name, it should do so only to avoid
technical breakage.  Can you provide an example where the IETF got
involved where that wasn't the case?  Also, did you appeal any decision
the IESG took in this regard?

> This is breakage.

What would be breakage would be if the IETF entered such a debate
without technical ground or if the IETF *didn't* enter the debate when
there was technical breakage at risk.

But even if the example you cited was broken, we have an appropriate
means to fix it, complete with accountability.
Eliot

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Jul 2014 18:03:39 -0400

> it is a policy decision that the technical arm of the enterprise has no

I cannot imagine such a thing happening without coordination.  There was coordination before ".local" was selected by the technical community.  The coordination turned out to be straightforward because ".local" was on the list that ICANN was not allowed to use.

I'd like to see a process for this coordination written down, but I am not worried about "unilateral" decisions.

Russ

---

From: Avri Doria <[email-masked]>
Date: Wed, 23 Jul 2014 18:16:06 -0400

Hi,

(Please remember I am only discussing this issue as an example)

Yes, there are internal IETF mechanisms.

And no I did not object, though I do remember thinking it was an
entertaining work around to ICANN processes, but that is not the point.
 I happen to be nerdy enough to participate in both organizations and
track the things I am interested in in both of them, more or less.  That
is a rare affliction.  And counting on such individuals is not really an
optimum cross-function accountability mechanism.

Perhaps this was brought to the ICANN Board by the then Liaison as an
issue, though i do not remember it being communicated to the GNSO at the
time.  If it was that is a good thing, but is that is a defined cross
function accountability function.  And even if it so defined, is it
sufficient?

And what about a year later when we all of a sudden notice that you have
reserved a bunch of names for technical reasons we just don't see -
remember, we do not universal agreement on the technical risks of things
like collision (not to start that discussion here - just an example). So
to whom is IANA accountable in terms of placing and removing such names
from various lists?

At this point, we could go running to NTIA and complain.  What would
come out it, who knows, but we could.  And that is the point:  they
represent a common point of accountability for the IANA function.

avri

---

From: John Curran <[email-masked]>
Date: Wed, 23 Jul 2014 18:23:54 -0400

> might think it get a say.

IANA accountability is about whether the IANA operator performs 
in accordance with the supplied policies...  that is it, i.e.
does IANA perform registry updates as specified by the policy
documents.  It's a fairly straightforward question of contractual
performance (or at least in the case of the RIRs and IAB which
perform their policy development separate from ICANN/IANA)

> To whom is IANA accountable in making the reservation? the IETF.

IANA is accountable to the IAB/IETF for technical reservations in
both the IP and DNS spaces (as per the ICANN/IAB/IETF MOU.)  It is 
accountable to the RIRs for adherence to global policy for general 
purpose IP space (per ICANN/NRO MOU) and one presumes that it is 
accountable to ICANN's guidance for following policy for the general 
purpose DNS space (although it is unclear if that's to the ICANN 
DNS policy body or to ICANN's Board)

> IANA what to do with TLDs.

ICANN has the ability to make policy with respect to DNS names, but 
that is still subject to its existing agreements, including the MOU 
between ICANN and the IAB/IETF (RFC 2860)... That MOU is quite clear 
about deference to IETF specifications for technical reservations 
if ICANN wishes to continue serving as the IANA.

> It seems to me that it is what could be called a cross-accountabilty

Not at all - IANA accountability is about operating the registry accordingly 
to the policy authority, whereas you are raising issues about the proper 
policy authority.  The IANA must know the proper policy authority for each
registry it administers, but that is set external to the IANA via agreements
between the parties.

You _never_ want the IANA deciding to insert its own independent judgement
regarding dispute situations; the IANA is a set of interrelated technical 
recording functions, not an oversight or judicial role.

> accountability mechanisms that cross the 'jurisdictions'.

Again, IANA accountability is about the IANA adherence to the supplied 
policy; is it doing it promptly and accurately.  You are asking a more 
general issue about IETF and ICANN accountability for policy development 
to their respective communities, and does not appear to be in scope for 
the transition proposal.  Specifically -

"In discussions to date, a number of topics have arisen that are outside the scope of this transition. To avoid any misunderstanding, there are a range issues that, while important, are not appropriately part of a transition proposal requested by NTIA, including:

	• Policy development related to the IANA functions. As NTIA currently plays no unique role in the development of policies for the coordination of the Internet’s domain name system, the proposal is not about how relevant policies are created, nor the relevant structures in which they are created. The roles of all Internet registry policy bodies (such as the RIRs, IAB, IETF, ASO, NRO, ccNSO, ccTLD Registry Operators, and the GNSO) will stay unchanged. These bodies continue to represent their respective communities and hold policy authority for the protocol parameter, number, and name spaces, including responsibility to ensure the faithful registry implementation by ICANN according to those policies."

<https://www.icann.org/en/system/files/files/iana-transition-scoping-08apr14-en.pdf>

i.e. it is perfectly reasonable to specify how "RIRs, IAB, IETF, ASO, NRO, 
ccNSO, ccTLD Registry Operators, and the GNSO" will know that the IANA is 
performing faithful registry administration of the supplied policies, but
asking how those individual bodies are accountable to their communities in
policy development is out of scope.

Thanks!
/John

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jul 2014 10:36:31 +1200

Hi Avri,

> Allows for protocol that meet certain conditions to reserve TLDs.

Indeed, but this is a more precise instantiation of the
exception to the policy exception in the IETF/ICANN MoU
from 2000 - nothing new here in principle or in practice.
It's been exercised a number of times since then, but
quite rarely:

  "Note that (a) assignments of domain names for technical uses (such as
   domain names for inverse DNS lookup), (b) assignments of specialised
   address blocks (such as multicast or anycast blocks), and (c)
   experimental assignments are not considered to be policy issues, and
   shall remain subject to the provisions of this Section 4."

>>> it is a policy decision that the technical arm of the enterprise has no

Yes it does, because it was explicitly excepted from the agreement. It's
unfortunate if that wasn't well understood when the GNSO Council was created.

> IANA what to do with TLDs.

Except for the exception signed off 14 years ago.

> accountability mechanisms that cross the 'jurisdictions'.

Oh, in the general case I certainly agree that the 3 major
areas should consult with each other when there's an overlap
issue. But I don't quite see how this impacts accountability
as such.

In the instance you mention, was the existence of the draft
and the IETF last call etc. notified in any way to the ICANN TLG
or (maybe indirectly) to the GNSO? If not, that was probably
an omission IMHO, but I still don't see where accountability
comes in.

   Brian

---

From: Avri Doria <[email-masked]>
Date: Wed, 23 Jul 2014 18:36:28 -0400

Hi,

As I say I do not remember coordination, but maybe.  It is just an example.

And it is not really defined.  At the moment it works because we like
and trust each other all around.  But when speaking of
cross-institutional accountability, these are not things we can just
count on.

I am not saying we need big heavy duty cross-accountability mechanisms
that oppress us and keep us from doing the stuff we need to do.

I am saying we need to formally consider the multistakeholder
cross-accountability (or put another way the IANA aggregate function
accountability) issues together with the multistakeholder IST process.

avri

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 23 Jul 2014 18:47:03 -0400

> IANA what to do with TLDs.

I think, actually, that's not precisely correct.  ICANN has
responsibility for the root zone.  The things we put in the root zone
are often called "TLDs", but not every domain name is in fact a name
eligible to be in the DNS.  

The IETF has responsibility for the technical definition and
consequences of protocols, and what RFC 6761 establishes is a way to
reserve certain kinds of names for technical purposes when that is
necessary.  This is not new: RFC 2606, published in 1999, establishes
some similar reservations.

So, ICANN gets to tell IANA when to add an entry to the root zone,
provided that is technically acceptable.  ICANN cannot, for instance,
create a new delegation for com. that is distinct from COM., at least
not without violating STD13.  That's a consequence of the way the
protocols are defined.  ICANN cannot, either, create a new delegation
for zx--foo. without violating IDNA2008.  Note that somewhere around
2000, that latter restriction wasn't the case.  But new protocols come
along, and they have new rules.

RFC 6761 is intended to be used to identify names that need to be
handled specially.  In the case of such names that might be understood
as "top-level domains" (i.e. that are one label plus the null label
long), those are names that by definition should _not_ appear in the
root.  If they should, then part of the standards action or IESG
approval needed to approve the entry in the special-purposes registry
would detect that and likely reject the registration.  RFC 6761
clearly says as much:

   The specification also MUST state, in each of the seven "Domain Name
   Reservation Considerations" categories below, what special treatment,
   if any, is to be applied.  If in all seven categories the answer is
   "none", then possibly no special treatment is required and requesting
   reservation of a Special-Use Domain Name may not be appropriate.

There's no question that the special-use registry for names is a place
of overlap, where a slow and careful job of co-ordination will be
needed.  But we actually have those relationships between the
organizations, and this registry requires a fairly heavyweight
registration procedure precisely _because_ of the potential for conflict.

It just isn't true that RFC 6761 is a unilateral encroaching by IETF
on ICANN's area of responsibility.  ICANN is responsible for the root
zone.  It certainly should have policies itself for things that are
not permitted to be registered.  But I do not buy that ICANN's policy
responsibility extends to all labels that could logically-possibly be
in the root zone, just because of those cases where a protocol
requires a special-use name for technical reasons.  The IETF doesn't
tread on ICANN's responsibilities when it reserves local. any more
than it treads on Verisign's when it reserves example.com.

At the same time, the RFC 6761 example militates in favour of leaving
the different IANA functions together in a single IANA.  It is
logically possible, of course, to separate these functions, but it
would be a bad idea because IANA is about technical co-ordination that
turns out to be useful.  It's not Internet Police, and neither are any
of the policy bodies that feed it.  It's a utility, and making
arrangements that maximise that utility is the right thing to do.

Quite apart from that, it's not like the adoption of RFC 6761 or the
adoption of any future entry (were one to happen) in the special-use
registry is going to happen under a barrel.  One of the things I've
been finding mystifying about this entire discussion is the apparent
assumption that if someone is "in" one community that person can't
also be "in" another one.  We're not arranged with carefully-balanced
powers, or spheres of influence, or things like that.  I thought one
of the supposed advantages of open, bottom-up, transparent, and even
multi-stakeholder processes was supposed to be that cross-participation
is easy.  What have I missed?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: John Curran <[email-masked]>
Date: Wed, 23 Jul 2014 18:47:08 -0400

> accountability) issues together with the multistakeholder IST process.

I also believe that it would be rather timely for all of the registry 
policy development bodies to reexamine their accountability mechanisms 
to the affected communities (and do believe that there will be quite a 
bit of these reviews going on over the next year or so...)

However, at least per the language in the scoping document, accountability
of the policy development bodies is independent to the development of the
requested proposal for transition of NTIA's stewardship of the IANA functions.

FYI,
/John

---

From: S Moonesamy <[email-masked]>
Date: Thu, 24 Jul 2014 03:31:05 -0700

Hi Avri,
>Allows for protocol that meet certain conditions to reserve TLDs.

In my opinion there was, at most, rough consensus on that 
document.  I did not like what the document was proposing as it could 
be argued in future that it was intruding into the policy side.

The following paragraph is a technical opinion.  Should .local be 
delegated to as a gTLD?  My recommendation is no as public 
information collected from various points on the internet shows that 
the .local string is in use.  Some of the computers used by the 
people reading this list contribute to that usage.

What if some company insists on buying .local?  That company will 
come back later and complain that the (purchased) string is not 
working because of technical problems; someone will suggest that the 
IETF has to find a solution to those technical problems.  It is up to 
the policy side to assess this paragraph and the previous one to 
determine whether the .local string should be delegated.

The reason not to have that document is that Person X will come and 
ask for a string as Company Y got a string.  This is where one might 
have to consider whether the decision taken is arbitrary 
[1].  Anyway, the document has been published.  In my opinion there 
is a valid concern.

Regards,
S. Moonesamy

1. Based on random choice or personal whim, rather than any reason or system.

---

From: John Curran <[email-masked]>
Date: Thu, 24 Jul 2014 10:16:17 -0400

On Jul 24, 2014, at 6:31 AM, S Moonesamy <[email-masked]> wrote:

> In my opinion there was, at most, rough consensus on that document.  I did not like what the document was proposing as it could be argued in future that it was intruding into the policy side.

You seem to believe that the IETF does not make "policy" for identifiers, 
but in fact, IANA registries are specifically required to have policies 
(see RFC 5226, "Guidelines for Writing an IANA Considerations Section in
RFCs") so that the IANA knows what exactly to do in administration.

Now it is true that these policies are generally technical in nature and 
tend to avoid "public policy" positions, but that is not a hard requirement 
for either IETF protocols or the associated registries.  For example, it 
is possible for the IETF to define a protocol (e.g. an enhancement to DNS) 
whereby the protocol itself has some embedded rules for certain identifiers 
(e.g. the string "curran" shall always return empty set on any query...)  

Thankfully, the IETF doesn't generally engage in such things, and instead 
usually constrains itself to technical constraints on the protocols and 
associated registries; thus the keeping the IETF protocols very popular 
and enabling the success of the Internet that we've all come to enjoy.

It's worth encouraging the IETF to work on predominantly technical issues,
and to delegate the public policy issues that come with general purpose
registries to bodies which are supported by the affected community, but 
at the end of the day, that is nothing more than a polite suggestion to the
IETF, and may or may not be followed.  If the IETF were to make a serious
misstep, then it runs the risk of parties going elsewhere to work on their
protocol standard needs, and that's likely a reasonable deterrent with a 
natural counterbalance.

/John

Disclaimer: my views alone.

---

From: S Moonesamy <[email-masked]>
Date: Thu, 24 Jul 2014 10:08:33 -0700

Hi John,
>RFCs") so that the IANA knows what exactly to do in administration.

My choice of words was incorrect.  You explained it better in the 
paragraph quoted below.

Ok.

>protocol standard needs, and that's likely a reasonable deterrent with a

Yes.

The problem is that it is not always clear at the time the decision 
was taken whether the misstep is serious.  In addition, there are a 
handful of people who would bother to raise any objection if 
something is considered as a misstep as:

   (a) The person is not making or losing money because of the decision; or

   (b) The person will be labelled as querulous.

   (c) It is bad for the person's career.

Regards,
S. Moonesamy

---

From: John Curran <[email-masked]>
Date: Thu, 24 Jul 2014 16:52:17 -0400

On Jul 24, 2014, at 1:08 PM, S Moonesamy <[email-masked]> wrote:
> My choice of words was incorrect.  You explained it better in the paragraph quoted below.

Coolness.

>> (e.g. the string "curran" shall always return empty set on any query...)

i.e. technical registry policy is part of protocol specification; the IETF
can indeed make a mess of either, but is inclined to try and make it so the 
resulting protocol & registry useful for the Internet.

> The problem is that it is not always clear at the time the decision was taken whether the misstep is serious.

A single misstep is unlikely to cause folks to go to another venue for
their Internet standards development; it would probably take a pattern of 
decisions which impact others without reasonable opportunity for input to
cause such an outcome.  This is very unlikely given the open nature of 
IETF standards development, but does highlight the need for the various
organizations (IETF, ICANN, RIRs) to keep each other apprised of any policy
or standards development that may be of cross interest.  This has worked 
very well between the RIRs and the IETF, okay with the RIRs and ICANN from 
what I can tell (and I do not know how well the IETF/ICANN communication 
in this area has worked.)

>  In addition, there are a handful of people who would bother to raise any objection if something is considered as a misstep as:
> 

And such folks are free to write Internet Drafts which describe the problem 
(as they see it) with a given protocol or registry requirement, and participate 
in the IETF process to get things changed to something more pleasing.  If their 
arguments have merit, they are likely to be picked up and advanced by others 
via the process, and if not, then the asserted misstep is actually a non-issue.

In any case, this is all handled via the existing IETF processes for standards 
and registry policy development; there is no evidence of any need for new or 
additional accountability mechanisms for these IETF processes, particularly to 
the extent that the IETF work predominantly covers technical matters rather than 
"public policy" issues.  That aligns well with the IANA Stewardship transition 
proposal development effort, which is not scoped to include accountability 
mechanisms for "how relevant policies are created, nor the relevant structures 
in which they are created."

FYI,
/John

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 25 Jul 2014 11:46:57 +0900

> resulting protocol & registry useful for the Internet.

I think that in general, IETF caring about the technical stuff, and 
ICANN about the political stuff, should work out fine, even where these 
overlap (i.e. TLDs).

But imagine the following, somewhat imaginary but not totally improbable 
scenario:

The IETF is working on some technology that requires a couple of TLDs to 
be reserved for a special purpose. The technology is already partially 
deployed, but not yet extremely widely, and the IETF is standardizing it 
and fixing some stuff that needs fixing for wider deployment.

ICANN is working on a new round of gTLDs or some such. Of course they 
exclude already reserved TLDs, but not stuff that might be coming up 
(because they don't know it).

Now assume that at some point rather late in the game, it gets 
discovered that some names on both sides clash. ICANN already has 
accepted a (significant) amount of money and made some firm promises. 
The IETF technology is already well deployed, and fixes may be costly 
and time-consuming. Each organization and its constituents thinks that 
they were first and therefore think they have priority, and provide 
ample material to support their claims.

What, if any, provisions are there currently to avoid such a problem? 
What, if any, additional provisions would we need to avoid such a 
problem in the future.

Please note that "we can talk to each other" doesn't work here; the 
example is explicitly constructed that way :-(.

Regards,   Martin.

---

From: John Curran <[email-masked]>
Date: Fri, 25 Jul 2014 00:12:58 -0400

On Jul 24, 2014, at 10:46 PM, Martin J. Dürst <[email-masked]> wrote:
> What, if any, provisions are there currently to avoid such a problem? What, if any, additional provisions would we need to avoid such a problem in the future.
> 
> Please note that "we can talk to each other" doesn't work here; the example is explicitly constructed that way :-(.

Inter-party communication and coordination is the key to avoiding such a problem, 
but avoiding such a conflict isn't an option for a pre-existing condition as you 
have specified.  The short answer I expect is that the language in the MOU between 
ICANN and the IAB/ IETF would likely govern the outcome.

FYI,
/John

---

From: S Moonesamy <[email-masked]>
Date: Thu, 24 Jul 2014 17:58:01 -0700

Hi John,
>in this area has worked.)

I'll say ok to the above as I do not do the coordination.

>via the process, and if not, then the asserted misstep is actually a 

A generally accepted theory or belief was that nothing could be done 
about 2050 as the previous attempts to update the document resulted 
in failure.  I don't think that the move happened based on the merit 
of the arguments.  There is a thread on ietf@ about something more 
pleasing.  Some things are unsurprising.

>in which they are created."

I have followed the non-IETF discussions about the word 
"accountability".  In some ways it is about a clash of cultures and 
other considerations.  The IETF can end up as collateral damage in all that.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Fri, 25 Jul 2014 00:26:58 -0700

Hi Martin,
At 19:46 24-07-2014, Martin J. Dürst wrote:
>I think that in general, IETF caring about the 
>technical stuff, and ICANN about the political 
>stuff, should work out fine, even where these overlap (i.e. TLDs).
>
>But imagine the following, somewhat imaginary 
>but not totally improbable scenario:
>
>The IETF is working on some technology that 
>requires a couple of TLDs to be reserved for a 
>special purpose. The technology is already 
>partially deployed, but not yet extremely 
>widely, and the IETF is standardizing it and 
>fixing some stuff that needs fixing for wider deployment.
>
>ICANN is working on a new round of gTLDs or some 
>such. Of course they exclude already reserved 
>TLDs, but not stuff that might be coming up (because they don't know it).
>
>Now assume that at some point rather late in the 
>game, it gets discovered that some names on both 
>sides clash. ICANN already has accepted a 
>(significant) amount of money and made some firm 
>promises. The IETF technology is already well 
>deployed, and fixes may be costly and 
>time-consuming. Each organization and its 
>constituents thinks that they were first and 
>therefore think they have priority, and provide 
>What, if any, provisions are there currently to 
>avoid such a problem? What, if any, additional 
>provisions would we need to avoid such a problem in the future.
>
>Please note that "we can talk to each other" 
>doesn't work here; the example is explicitly constructed that way :-(.

I find it difficult to provide a honest answer to 
the above on a non-IETF mailing list. :-(

Regards,
S. Moonesamy

---

From: Seun Ojedeji <[email-masked]>
Date: Fri, 25 Jul 2014 08:58:33 +0100

On Fri, Jul 25, 2014 at 8:26 AM, S Moonesamy <[email-masked]> wrote:

> I find it difficult to provide a honest answer to the above on a non-IETF
> mailing list. :-(
>
> What difference does that make ;)

Cheers!

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Jul 2014 23:29:23 +1200

> (because they don't know it).

That's already a failure of coordination.

> Please note that "we can talk to each other" doesn't work here; the example is explicitly constructed that way :-(. 

But that is in fact the only answer in any such situation; it will
work because it has to work.

The saying in English "We'll cross that bridge when we come to it"
applies, in my opinion. We can't plan for every possible case.

Regards
   Brian

On 25/07/2014 14:46, Martin J. Dürst wrote:
> .

---

From: S Moonesamy <[email-masked]>
Date: Fri, 25 Jul 2014 04:31:46 -0700

Hi Seun,
>What difference does that make ;)

It would be an internal IETF discussion.  I am familiar with the 
(IETF) process rules.

Regards,
S. Moonesamy

---

From: Seun Ojedeji <[email-masked]>
Date: Fri, 25 Jul 2014 12:43:36 +0100

On Fri, Jul 25, 2014 at 12:31 PM, S Moonesamy <[email-masked]> wrote:

> It would be an internal IETF discussion.  I am familiar with the (IETF)
> process rules.
>

Didn't know it was a cabal settings ;) Could you perhaps point to that
process url that restrict you as such?

Cheers!

---

From: Steve Crocker <[email-masked]>
Date: Fri, 25 Jul 2014 07:47:20 -0400

> That's already a failure of coordination.

I don’t understand the basis for the above statements.

ICANN has not yet begun formulating the next round of gTLDs.  As part of the process, there will be consultation on what issues arose during the first round.  Consultation with the IETF re current and future reserved names is definitely and obviously part of what needs to be included.

There are multiple avenues of coordination between the IETF and ICANN.  The coordination is broad and deep.  Some of it is structural and some is pragmatic.  It is ongoing and effective.  The last important incident of uncoordinated activity that I’m aware was in another dimension entirely, viz the scheduling of meetings, and that was dealt with quite firmly.

Steve

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Jul 2014 00:36:17 +1200

Steve,

You're quoting from a discussion of a strawman hypothetical case as if
were an assertion about the real world. I meant that if such a situation
were to arise, it would mean that there had been a failure of coordination.

We'd be better off having this conversation in French with correct
use of the conditional subjunctive ;-).

Regards
   Brian

---

From: Steve Crocker <[email-masked]>
Date: Fri, 25 Jul 2014 08:56:53 -0400

:) Thanks.

---

From: Eric Burger <[email-masked]>
Date: Fri, 25 Jul 2014 13:24:55 -0400

I would offer John’s scenario is not totally made up, in that something similar already happened. The real situation provides proof that we can work with ICANN. What I am thinking of is the SLD block list. That was a community effort, recognized reality, and brought ICANN, IETF, manufacturers, ISP, etc. together to work through the problem. So, I am not desirous of formalizing some sort of process that might have worked for the last war (SLD’s, or gTLD collisions) when the next war is something completely different. I am OK with our informal relationship, as ICANN has shown it can work with us, and we have shown we can work with ICANN.

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 27 Jul 2014 19:18:26 -0400

Olivier, Avri,

I'm not sure I agree that "new accountability mechanisms [are] needed for *all* functions." It seems to me entirely possible that in examining needs for the future, and analyzing how things might change in the absence of NTIA, we will find that in some cases, the mechanisms we already have are perfectly adequate. 

I've reviewed the graphic Olivier refers to, and I'm not convinced that whoever wrote it meant to force an assumption that "new accountability mechanisms" are required for all the IANA functions, only that accountability mechanisms need to be documented and understood. Given also how hard ICANN has tried to avoid being prescriptive in this process where it wasn't necessary, and how carefully the ICG is guarding its self-determination so far, I'm not sure I'd regard such a view as the last word on the subject. 

I'm also reminded that ICANN is undertaking a discussion about replacing NTIA's supposed general accountability role ("adults in the room") with an "ICANN Accountability " examination process of some kind, which I'd thought was intended to look at such global accountability concerns separately from specifics of the day-to-day IANA functions. We can hope to see that take more definite shape soon.

best,
Suzanne

---

From: Jari Arkko <[email-masked]>
Date: Sun, 27 Jul 2014 23:10:59 -0400

I have not had time to review this thread or post when the IETF was going on, however, I just wanted to echo the points Suzanne made. I am in full agreement with them.

Jari