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?
* 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