Subject: [Ianaplan] ietf91 ianaplan agenda and slides posted

From: Marc Blanchet <[email-masked]>
Date: Mon, 10 Nov 2014 08:03:21 -1000

on the meeting materials site: https://datatracker.ietf.org/meeting/91/materials.html

Regards, Marc.

---

From: Jefsey <[email-masked]>
Date: Mon, 10 Nov 2014 19:47:13 +0100

Dear Chairs,

I do not know the time of the WG meeting. Therefore I have posted the 
draft of my strict IETF Charter perspective I_D at 
http://iuwg.net/index.php/Intlnet_Draft_on_IANA_transition.

1. It is still to be reviewed for its final form and English by our 
local group (NB. Most of the text comes from the horses mouth: NTIA, 
IAB, IETF, ICANN, Charter).
2. it will be registered after this review as an I_D now the cut-off 
period is finished. However it will still be during the last-call 
period, this may be after your meeting. Moreover if I have formating issues.

This I_D concludes to NO change, one domain name registration agreed 
15 years ago by all the parties, a few hints to IAB and IAOC. It 
addresses the ICANN accountability issue and takes the IUWG input into account.

jfc

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 10 Nov 2014 08:56:48 -1000

> Le 2014-11-10 à 08:47, Jefsey <[email-masked]> a écrit :
> 
> Dear Chairs,
> 
> I do not know the time of the WG meeting.

Monday November 10th, 13h00 Honolulu time.

> Therefore I have posted the draft of my strict IETF Charter perspective I_D at http://iuwg.net/index.php/Intlnet_Draft_on_IANA_transition.

To be considered, you should submit your draft in the internet-drafts directory. The window is now reopened:
https://datatracker.ietf.org/submit/

Regards, Marc.

> 
> 1. It is still to be reviewed for its final form and English by our local group (NB. Most of the text comes from the horses mouth: NTIA, IAB, IETF, ICANN, Charter).
> 2. it will be registered after this review as an I_D now the cut-off period is finished. However it will still be during the last-call period, this may be after your meeting. Moreover if I have formating issues.
> 
> This I_D concludes to NO change, one domain name registration agreed 15 years ago by all the parties, a few hints to IAB and IAOC. It addresses the ICANN accountability issue and takes the IUWG input into account.
> 
> jfc

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 11 Nov 2014 10:28:00 +0100

I refer to the slides at:

  http://www.ietf.org/proceedings/91/slides/slides-91-ianaplan-1.pdf

The proposed text on slide 18 is:

  "(2) requires that the owner of any associated marks and identifiers
ensure continuity and resilience of the location of the protocol parameters
registries, so that there exists no confusion that a subsequent operator is
performing the service on behalf of the IETF."

I don't object to the principle, but I find the text above to be
insufficiently precise.  I would prefer something like:

"(2) requires that the owner of any associated marks and identifiers (in
particular the mark IANA and the domain name IANA.ORG) ensure continuity and
resilience of the location of the protocol parameters registries at no
additional cost, so that there exists no confusion that a subsequent
operator is performing the service on behalf of the IETF and so that a
subsequent operator would not be required to pay to use the marks and
identifiers in question."

Best,
Richard

> -----Original Message-----
> From: Ianaplan [mailto:[email-masked]]On Behalf Of Marc
> Blanchet
> Sent: lundi, 10. novembre 2014 19:03
> To: [email-masked]
> Subject: [Ianaplan] ietf91 ianaplan agenda and slides posted
>
>
> on the meeting materials site:
> https://datatracker.ietf.org/meeting/91/materials.html
>
> Regards, Marc.
> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan
>

---

From: Seun Ojedeji <[email-masked]>
Date: Tue, 11 Nov 2014 11:05:04 +0100

Hi Richard,

I think the goal of putting that text is not just for the domain iana.org
but more to any other unforeseen element that may affect protocol
parameters. Whether that is a well written and encompassing statement for
protocol parameters, I think it is. The text you proposed assume only the
domain element while the former seem to address the unforeseen. No?

Cheers!

sent from Google nexus 4
kindly excuse brevity and typos.

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 11 Nov 2014 11:07:46 +0100

No, my text does not exclude anything, it just makes it clear that the mark and the domain name are specifically included.

Best,
Richard
  -----Original Message-----
  From: Seun Ojedeji [mailto:[email-masked]]
  Sent: mardi, 11. novembre 2014 11:05
  To: Richard Hill
  Cc: [email-masked]; Marc Blanchet
  Subject: Re: [Ianaplan] ietf91 ianaplan agenda and slides posted

  Hi Richard,

  I think the goal of putting that text is not just for the domain iana.org but more to any other unforeseen element that may affect protocol parameters. Whether that is a well written and encompassing statement for protocol parameters, I think it is. The text you proposed assume only the domain element while the former seem to address the unforeseen. No?

  Cheers! 

  sent from Google nexus 4

    Best,
    Richard

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 Nov 2014 05:27:46 -0500

--On Tuesday, November 11, 2014 10:28 +0100 Richard Hill
<[email-masked]> wrote:

> I don't object to the principle, but I find the text above to
> be insufficiently precise.  I would prefer something like:
> 
> "(2) requires that the owner of any associated marks and
> identifiers (in particular the mark IANA and the domain name
> IANA.ORG) ensure continuity and resilience of the location of
> the protocol parameters registries at no additional cost, so
> that there exists no confusion that a subsequent operator is
> performing the service on behalf of the IETF and so that a
> subsequent operator would not be required to pay to use the
> marks and identifiers in question."

Richard,

It seems to me that, in this and several other notes, you are
trying to turn this "transition NTIA out of the oversight role"
exercise into a narrow and very specific contract-writing
exercise.  In addition to being of questionable appropriateness,
writing very specific language based on speculation about what
might happen carries its own set of traps with it.  That is
especially true when the speculations don't cover all of the
cases.  

For example, your proposed text above would be useful if the
IANA function transferred away from ICANN to an organization
that would somehow be hostile to the stability needs of the IETF
and relevant registries.  Some of us think that is either very
unlikely or that, if circumstances were to come together so that
it would occur, the questions of what the registry operator is
called or what domain names it would use would be rather far
down on the list of problems we (and the Internet) would face.
Remember in that context that the people who are the most
sensitive to the location of a particular registry don't need
just a top-level domain name; they need a URL or equivalent that
points to the actual information.   We've changed those several
times in the last 20 or 30 years as the various registries have
been reorganized for better access and changing technology.  It
has been painful, but the Internet has not melted down.

By contrast, suppose that some sequence of events resulted in
the IANA function being broken up into pieces and assigned to
separate bodies.  Those pieces might correspond to the current
address-protocol-domain registry split, but one can imagine
other structures at well.  Were we to found ourselves in that
situation, it seems to me that the language you propose might
actually be an impediment, tangling up the subsequent operator
with some mostly-irrelevant issues and requiring sorting out the
meaning of "continuity and resilience of the location" in ways
that might actually impede accessibility and performance.

If we were convinced that the potential for a problem were
great, it would be likely that the IETF community should take
steps now, presumably in conjunction with ICANN, to change the
naming structure in a way that would provide robustness at the
naming level rather than, e.g., depending on maintaining of a
particular web page structure and linking or redirecting from
it.   Whether such actions are need or not, desirable or not,
they are decisions that lie completely outside the scope of this
discussion and WG... other than perhaps to make the point that
was made several times during the meeting discussion which is
that, if such mechanisms are deemed necessary, it is much better
to design an implement them in times or relative peace and
stability rather than trying to put things together in an
emergency.

best.
   john