[Internal-cg] RFP: IANA Definition

[Patrik Fältström]

On 27 aug 2014, at 07:03, Daniel Karrenberg <daniel.karrenberg at ripe.net> wrote:

> Coming back to the discussion on yesterday's call:
> 
> We should refer to source documents in the RFP and not secondary
> documents. NB: I totally respect the work of RSSAC on RSSAC067 and it is
> a great help.

SSAC and SAC067.

> It just does not feel right to use it as a normative
> reference.

This was my point as well. We can reference it as a source, but not normative.

> So I propose adding a footnote at the first occurrence of "IANA" like this:
> 
> In this RFP "IANA" refers to the functions currently specified in the
> agreement between NTIA and ICANN
> [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well as
> any other functions traditionally performed by the IANA functions
> operator. SSAC067
> [https://www.icann.org/en/system/files/files/sac-067-en.pdf] may be
> useful reading in addition to the documents constituting the agreement
> itself.
> 
> And then replace "IANA" with "IANA functions operator" wherever that
> adds clarity.
> 
> Can I have feedback on this?

Either like what you have done, or have wording like "SAC-067 is one description of the many different meanings the term IANA has" (to say it is one, good enough to reference, but not the only description).

I think the key here is that:

1. We refer to whatever is covered by the contract between NTIA and ICANN

2. IANA can have many meanings

3. We do acknowledge for example that whoever is writing a proposal and is sending it in (for example IETF) must write a proposal for what definition THEY use (because they must write a complete proposal from their point of view). That might imply they will describe slightly different set of definitions, which is ok, as long as they do "solve the issues" with (1) above.

Yes, I have tried to make Venn diagrams over these kind of things, but it is hard and do not always make the situation more clear. But a simple example can be:

A. We have a set of functions and services ICANN in the form of the IANA team is providing under the contract with NTIA

B. The very same group at ICANN also provide other functions and services that are not covered by the same contract, but other agreements

C. Whoever has those other agreements with ICANN might have agreements with other organizations than ICANN to provide other functions and services, and the total set of functions and services (provided by ICANN and others) is what "they" might believe is the same "pool" of functions and services they want to cover under whatever processes they are looking at.

I claim people normally include (A) and (B) in what they call "IANA", and we are interested in (A).

   Patrik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140827/8044a6f6/signature.asc>