[CRISP-TEAM] Interim version, not yet checked visually in Word...

Andrei Robachevsky robachevsky at isoc.org
Thu Jan 15 07:26:58 CET 2015

Hash: SHA1

Bill, the rationale is when we refer to the IANA operator of all
functions we say "IANA Functions Operator". When talking specifically
about the numbering service - the IANA Numbering Service Operator.
These were conflated in the paragraph.

e.g. communities will have independent arrangements with the IANA
Functions Operator, not the IANA Numbering Service Operator.


Bill Woodcock wrote on 15/01/15 07:08:
>> There are two changes that go beyond simple edits (I include a
>> redline version with the proposed changes):
>> 1) "Provision of reverse DNS services in the IN-ADDR.ARPA and
>> IP6.ARPA domains may also require interaction with the .ARPA
>> registry. " - I think it belongs in I.D.  A description of any
>> overlaps.
> Agreed, I’ve just moved it.
>> 2) Section III.A. In the para, describing the assumption the
>> IANA Numbering Service Operator and IANA Functions Operator. It
>> should read:
>> NEW:
>> This proposal assumes that specific IANA customers (i.e., the
>> numbers community, the protocol parameters community, and the
>> names community) will have independent arrangements with the IANA
>> Functions Operator related to maintenance of the specific
>> registries for which they are responsible. At the same time, the
>> Internet Number Community wishes to emphasize the importance of
>> communication and coordination between these communities to
>> ensure the stability of the IANA services. Such communication and
>> coordination would be especially vital should the three
>> communities reach different decisions regarding the identity of 
>> the IANA Functions Operator going forward. Efforts to facilitate
>> this communication and coordination should be undertaken by the
>> affected communities via processes distinct from this stewardship
>> transition process.
> Basically, this would be rolling back the harmonized use of the
> term “IANA Numbering Service Operator” for this one paragraph, but
> not elsewhere.  I’m happy to do whatever there’s consensus on, but
> can you explain the rationale, and let me know if anyone else is
> supporting this change?
> -Bill
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org


More information about the CRISP mailing list