ietf
[Top] [All Lists]

Re: Pointing to IANA registries

2010-04-26 04:59:55


On 2010/04/22 18:46, Mark Nottingham wrote:
That's a GREAT document and it makes me feel much better; thanks!

A bit of feedback:

* Section 2.1: "The registry operator maintains public mailing lists as specified in 
IANA Considerations" -- is this always true? Many of the lists are @ietf.org; do 
they operate these as well?

And some are operated by volunteers, with IANA just providing an alias. An example is ietf-languages(_at_)iana(_dot_)org, which is hosted by Harald.

Regards,   Martin.

* Section 3: "it's" ->  "its"

* Does it make sense for new drafts defining registries to talk in terms of PPROs instead 
of IANA? E.g., should there be a "PPRO Considerations" section?

One other way that I think the IETF needs to improve is in advertising who 
fills defined roles like this, whether it be the PPRO(s) or the expert 
reviewers (AFAIK there isn't anywhere you can determine who the experts for a 
particular registry are). This information needs to be collected in a 
prominent, well-labeled and stable place (probably on the IETF Web site, at a 
minimum); it's very confusing for newcomers.

Cheers,


On 22/04/2010, at 6:16 PM, Olaf Kolkman wrote:


[Replying to Mark, only because he inspired to make the remark]

On Apr 19, 2010, at 5:21 AM, Mark Nottingham wrote:

Couldn't IANA just implement the "search format" as

http://www.iana.org/assignments/Registry-Name

and cut out the middle man?

Regarding the "20 year" argument, it seems to imply that one of the following 
will happen in that time scale:

1) HTTP will be replaced by another protocol in a non-backwards-compatible 
fashion, and support in software is dropped (i.e., obviating all existing HTTP 
URLs), or
2) URIs themselves will be replaced in a non-backwards-compatible way, and 
URI-handling software disappears (obviating all URIs, period), or
3) The domain name system crashes and burns irrevocably, or
4) IANA loses legal control of iana.org, or
5) IANA lacks the organisational ability to guarantee stable identifiers for 
its products, or
6) No Web serving software is available that gives IANA the ability to control 
their own URI path components, and it is illegal for them to write it 
themselves.

If #1 or #2 happens (unlikely), we will have enough warning to revise the RFCs 
as appropriate, or provide a mapping to the new way of doing things. Not fun, 
but a reasonably calculated risk, given the shelf life of most IETF products.

If #3 - #6 happens (likelihood is reader-deterimined), we've got far worse 
problems than some RFCs whose registries can't be easily found -- A STATE THAT 
I WOULD MENTION WE ARE ALREADY IN TODAY.



Slightly orthogonal to how one approaches long-term stability of references in 
RFCs there is the issue of the needs of the IETF. It is not completely 
hypothetical that in a far, far future there will other or even multiple 
'vendors' that offer the service[*]. It that context stability is important 
too. See http://tools.ietf.org/html/draft-iab-iana

The IAB is close to finalizing that document.


--Olaf


[*] In fact there are two organizations today, see Appendix A of draft-iab-iana





________________________________________________________

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140,
http://www.nlnetlabs.nl/               1098 XG Amsterdam



--
Mark Nottingham     http://www.mnot.net/

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf


--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   
mailto:duerst(_at_)it(_dot_)aoyama(_dot_)ac(_dot_)jp
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf