Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)

[JFC Morfin <[e-mail]>]

At 18:12 08/11/2014, Seun Ojedeji wrote:
>I have not gone through the document but I have a similar thought 
>about Jefsey's writeup. I feared it would attempt to address a lot 
>beyond scope; reading it and reconfirming my fears would be a great 
>deal for me. ;)

?
There are two topics.

1. the respect of the Charter, as per the reading of the Chairs.

2. the support of the internet users' technical needs as a result of 
the NTIA announcement, NETmundial meetings, ICANN strategy, resulting 
IGF, ITU and SCO ongoing debates and the MYCANN Plug-ins consequent 
projects and expected announcements.

As a member of this WG, and the Non-WG IUCG@IETF facilitator, my plan 
was to do two things after having carefully followed and participated 
to the WG debate:

1. to introduce an I_D as a community proposals the Chairs have 
committed to consider as per the Charter.
2. to introduce an appeal to the IESG for this WG to really consider 
what the IETF is to do in order to adjust to the transition.

The cut-off period has not permitted my Draft to be introduced as an 
I_D in due time. I, therefore, had to create a crash IUWG site where 
I published and continue to maintain the draft with a forming Libre 
small group of IUsers. The mails of Andrew, Miles, and you are clear 
enough; in spite of the Chair's commitment, and the NTIA demand for a 
multistakeholder approach, the intent does not seem to discuss it as 
a Libre IUser community contribution.

As a result,

1. my Draft 
http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.02.pdf 
no longer only focuse on what the IETF should do but what the IUWG 
will do to allow IUsers to match the US transition in an unstable 
situation of contested dominance - during a multistakeholder, 
multitechnology, multilinguistic, multirepository, and multilateral 
evolution of the World Digital Ecosystem. This includes the 
introduction of a separate IETF Draft on Monday responding to the 
WG/IANAPLAN Charter: how the IETF can protect the status quo and 
adequately respond to RFPs such as the one received from the IGC.

2. the young IUWG is forming and, therefore, still uncertain about my 
appeal, due to the lack of a joint appeal process in the RFC 6852 
context (the reason for my NTIA interrupted appeal to ISOC). It might 
be built as an appeal copied as a joint RFP to the other SDOs and 
affected WGs and coalitions.

jfc



>Cheers!
>sent from Google nexus 4
>kindly excuse brevity and typos.
>On 8 Nov 2014 01:24, "Miles Fidelman" 
><<mailto:[e-mail]>[e-mail]> wrote:
>Jefsey,
>Sorry to be blunt, but it's been a long day....
>Actually, I HAVE read your draft.  The thing is, it is not, in any 
>way, shape, manner, or form, a response to the ICG RFP.  As someone 
>who spends most of may day job, writing proposals, my basic reaction 
>is to ignore a document that is unresponsive to the RFP.
>Beyond that, as a matter of general "style" - and a problem I 
>continue to have with the WG draft - is that documents that rely 
>heavily on cross references to other documents are incredibly 
>difficult to follow.
>Miles Fidelman
>Jefsey wrote:
>Seun, Richard, Miles, John,
>This WG calls for a few "iana.cool" brains. If you do not want to 
>read my draft (1) please at least read the IAB/ICANN/NTIA RFC 3172 
>(BCP 52) 
><https://tools.ietf.org/rfc/rfc3172.txt>https://tools.ietf.org/rfc/rfc3172.txt 
><https://tools.ietf.org/rfc/rfc3172.txt>. In particular Section 5.
>Cheers.
>jfc
>(1) 
><http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf>http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf 
>
>Â  Â  Â IMHO this is the one which will prevail as it is not NTIA, 
>nor SCO, nor EU, nor ICANN, nor ITU, nor NETmundial, etc. oriented. 
>Just interested in intelligent internet use capability.
>At 23:06 07/11/2014, Seun Ojedeji wrote:
>Miles, it think you are referencing that url as if the operating 
>systems services are syncing off the <http://iana.org>iana.org 
><http://iana.org> site.
>If that domain changes today, it does not take anything other than a 
>update to reflect the new reference url does it?
>What would be disastrous is if there happens to be 2 authoritative 
>parameter source with different entries; as an example http 
>referenced as port 80 and as another port on the other site.
>How to avoid that is not just by locking up the name 
><http://iana.org>iana.org <http://iana.org> but by locking up to a 
>single source of authority.
>Cheers!
>sent from Google nexus 4
>kindly excuse brevity and typos.
>On 7 Nov 2014 22:42, "Miles Fidelman" 
><<mailto:[e-mail]>[e-mail] 
><mailto:[e-mail]>> wrote:
>Â  Â  David Conrad wrote:
>Â  Â  Â  Â  Miles,
>Â  Â  Â  Â  On Nov 6, 2014, at 6:19 AM, Miles Fidelman
>Â  Â  Â  Â  <<mailto:[e-mail]>[e-mail]
>Â  Â  Â  Â  <mailto:[e-mail]>> wrote:
>Â  Â  Â  Â  Â  Â  More specifically, I'm concerned with avoiding any
>Â  Â  Â  Â  Â  Â  confusion or operational disruption in the event of
>Â  Â  Â  Â  Â  Â  future conflicts among the parties involved in oversight,
>Â  Â  Â  Â  Â  Â  management, and/or performance of the IANA functions -
>Â  Â  Â  Â  Â  Â  particularly in the case where a transition of contractor
>Â  Â  Â  Â  Â  Â  might occur on less then friendly terms.
>Â  Â  Â  Â  Â  Â  Under such situations, it seems at least possible, if not
>Â  Â  Â  Â  Â  Â  likely, that litigation might ensue and/or that parties
>Â  Â  Â  Â  Â  Â  might operate competing registries - causing operational
>Â  Â  Â  Â  Â  Â  confusion at a minimum, and possibly more serious
>Â  Â  Â  Â  Â  Â  disruptions to smooth operation of the net.
>Â  Â  Â  Â  We're talking about the protocol parameter registries, right?
>Â  Â  Â  Â  I'm honestly curious: could you describe the "serious
>Â  Â  Â  Â  disruptions to smooth operation of the net" or "operational
>Â  Â  Â  Â  confusion" that would occur in the event of future conflicts
>Â  Â  Â  Â  relating to the IANA trademark and/or <http://IANA.ORG>IANA.ORG
>Â  Â  Â  Â  <http://IANA.ORG> domain?
>
>Â  Â  Kind of depends on the degree to which various developers depend
>Â  Â  on the various registries published under <http://iana.org>iana.org
>Â  Â  <http://iana.org>, and perhaps on the degree to which anybody
>Â  Â  relies on automatic download of registry contents.
>Â  Â  For example, the /etc/services file in Debian includes this
>Â  Â  statement:
>Â  Â  #Updated from 
><http://www.iana.org/assignments/port-numbers>http://www.iana.org/assignments/port-numbers 
>
>Â  Â  <http://www.iana.org/assignments/port-numbers>
>    I expect other operating systems do similar things.  A lot of
>Â  Â  systems could break, rather precipitously, if <http://iana.org>iana.org
>Â  Â  <http://iana.org> went offline, or the file were moved somewhere
>Â  Â  else, or the file were corrupted - particularly if it happened
>Â  Â  just before a major release cycle.
>Â  Â  To me, that would be a "serious disruption" or at the very least
>Â  Â  "operational confusion"
>Â  Â  Miles Fidelman
>Â  Â  --Â  Â  Â In theory, there is no difference between theory and 
>practice.
>    In practice, there is.   .... Yogi Berra
>Â  Â  _______________________________________________
>Â  Â  Ianaplan mailing list
>Â  Â  <mailto:[e-mail]>[e-mail] <mailto:[e-mail]>
>Â  Â 
><https://www.ietf.org/mailman/listinfo/ianaplan>https://www.ietf.org/mailman/listinfo/ianaplan 
>
>Â  Â  <https://www.ietf.org/mailman/listinfo/ianaplan>
>_______________________________________________
>Ianaplan mailing list
><mailto:[e-mail]>[e-mail]
>https://www.ietf.org/mailman/listinfo/ianaplan 
><<https://www.ietf.org/mailman/listinfo/ianaplan>https://www.ietf.org/mailman/listinfo/ianaplan>
>
>
>
>--
>In theory, there is no difference between theory and practice.
>In practice, there is.   .... Yogi Berra
>_______________________________________________
>Ianaplan mailing list
><mailto:[e-mail]>[e-mail]
>https://www.ietf.org/mailman/listinfo/ianaplan
>
>_______________________________________________
>Ianaplan mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ianaplan