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

[Seun Ojedeji <[e-mail]>]

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. ;)

Cheers!
sent from Google nexus 4
kindly excuse brevity and typos.
On 8 Nov 2014 01:24, "Miles Fidelman" <[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>. In particular Section 5.
>> Cheers.
>> jfc
>>
>> (1) 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 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 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" <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>>     David Conrad wrote:
>>>
>>>         Miles,
>>>
>>>         On Nov 6, 2014, at 6:19 AM, Miles Fidelman
>>>         <[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 IANA.ORG
>>>         <http://IANA.ORG> domain?
>>>
>>>
>>>
>>>     Kind of depends on the degree to which various developers depend
>>>     on the various registries published under 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>
>>>
>>>     I expect other operating systems do similar things.  A lot of
>>>     systems could break, rather precipitously, if 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
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/ianaplan
>>>     <https://www.ietf.org/mailman/listinfo/ianaplan>
>>>
>>> _______________________________________________
>>> Ianaplan mailing list
>>> [e-mail]
>>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ianaplan
>