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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf