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. It just does not feel right to use it as a normative reference. 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? Daniel
On 27 aug 2014, at 07:03, Daniel Karrenberg <daniel.karrenberg@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
On 27.08.14 8:02 , Patrik Fältström wrote:
On 27 aug 2014, at 07:03, Daniel Karrenberg <daniel.karrenberg@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.
Now how is that for an almost Freudian mistake?? :-) :-) :-) I just cannot type the string SSAC without an R in front of it. Apolgies to all SSAC people who worked on that doc. I will cogitate about the other stuff you said. Daniel
On 27 aug 2014, at 08:10, Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote:
Now how is that for an almost Freudian mistake?? :-) :-) :-)
I just cannot type the string SSAC without an R in front of it.
Apolgies to all SSAC people who worked on that doc.
Maybe RSSAC people are the ones you should send apologies to? ;-) He he he... Patrik
I like this A, B, C; it's clear. The ABCs of IANA, by Patrik Falstrom. But let's not put it in the RFP, please. The point we seem to be missing is that the people who fill out the RFP will have their own working definition of what IANA is to them and what they do or do not want to change about it. So we don't need to get stuck on this. --MM
-----Original Message----- 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
participants (3)
-
Daniel Karrenberg -
Milton L Mueller -
Patrik Fältström