--On Friday, 09 September, 2005 22:38 -0700 Randy Presuhn <randy_presuhn@xxxxxxxxxxxxxx> wrote: >... >> > (2) The document is passed to the RFC Editor for >> > publication, >> >> It's not clear to me what the point of publishing it as an >> RFC is, and in fact if an explicit decision to that effect >> has been made, it went past me entirely. >> >> IMHO after initial-registry has served its purpose, it should >> be allowed to time out and die. > ... > > (As ltru co-chair) > > Those who follow the ltru WG mailing list closely will recall > that there were two distinct issues recorded in the issue > tracker: (at https://rt.psg.com/ user and password are "ietf") > #875 should initial registry contents be made into an > internet-draft? #878 should the initial registry contents i-d > be published as an RFC? > > There was a rough consensus in support of #875, but the > discussion of #878 was inconclusive. We asked our AD whether > he had any preference with respect to #878, and he indicated a > preference for publication as an (informational) RFC. > > That is how we got to where we are today. > > The decision on #875 (initial registry as i-d) has in > retrospect proven to be a good one, in my personal opinion. > > Regarding issue #878, I think we've all looked at it as just a > matter of how to work the process to get the right stuff into > the registry. The working group has been quite clear in > wanting to ensure that the initial registry is not mistaken > for the registry itself, and was never enthusiastic about > publishing it as an RFC. > > Consequently, I do not think that it would be a big problem if > the IESG were to tell the ltru WG that we don't need to > publish the initial registry i-d as an RFC, or if the WG, > reconsidering issue #878 as a result of the IETF last call > comments were to reach a consensus to withdraw the publication > request, as long as we have some assurance that the registry > will be end up with the right stuff. > > Sure, we would have wasted a lot of energy getting the initial > registry i-d RFC-ready, but the important thing is to > initialize the registry. Process is a tool, not an end in > itself, and the result we are interested in is getting the > updated registry going, not publishing a history of its > initialization, as interesting as that might be. Extremely violent agreement. > The only problem I see is that the registry draft, > http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-1 > 2.txt, currently references the initial registry i-d in > multiple places; we'd need someone to provide the correct > incantation to make the right thing happen. I can hardly > imagine that a document (whether BCP or some kind of > Standard-to-be) would be permitted to reference (even > informatively) an i-d never intended for publication. Please > send suggested text. > > Although my personal preference would be to publish the i-d > http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-04 > .txt as an Informational RFC, ideally marked "Historic" from > the first day it appears, I do not object to non-RFC > alternatives that let us accomplish the initialization, as > long as we keep the initialization data out of any container > that would cause it to be mistaken for the registry itself. Well, that pair of issues is exactly what I was concerned about and suggesting fixing, despite Doug's strong reaction to a suggestion I didn't intend to make. Specifically: If a document is published in the RFC series that lists elements of a registry, it will, inevitably, be used as a reference instead of the registry. Disclaimers in the document (as now exist) will help with that a bit. The word "historic" in the RFC Index will help with that a bit. But it will still be referenced by someone, somewhere, as an "official" RFC and an easy-to-obtain list. At the same time, there is useful, albeit mostly-historical, information in the initialization document that I would personally prefer not get lost. And that referencing issue is a pain in the neck, although not a huge one. So, very specific suggestion: (1) Get the registry created and initialized, exactly as specified in the "initial" document at -02. I think that is a no-brainer and we all seem to be agreeing about it. (2) Issue, and send to the RFC Editor for Informational publication, a version of draft-ietf-ltru-initial that replaces the contents of Section 3 ("Initial Registry Contents") with a pointer to the registry itself and, if desired, a hint as to how the initial elements can be identified, for historical purposes, in the registry. Leave the rest of it alone. It contains useful text and some information that should not be lost (such as the omitted code element list). Just to be orderly, remove the "don't pretend this is the registry" statements/warnings from the abstract and the end of Section 1. This prevents anyone from referencing the RFC form of the initialization document as the registry far more effectively than any warnings or labels -- there will be nothing there to reference. It saves time patching references to the initialization document because the initialization document will exist as an RFC and even have the same section numbering. It saves worrying about whether there is important historical information in the initialization document that would need to be moved somewhere else if that document were dropped, and where to move it. The WG and IESG should do what they think best, but this really seems pretty obvious to me. Of course, none of the above has anything to do, one way or the other, with my concerns about BCP versus Standards Track, replacement of 3066 without doing something specific about the matching rule question, applications-specific profiles, and so on. Whatever the right answers to those concerns are, they are not as obvious, at least to me. john _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf