ietf
[Top] [All Lists]

Re: [Ltru] Re: Last call comments on LTRU registry and initialization documents (issue #878)

2005-09-10 00:44:50
Hi -

From: "John.Cowan" <jcowan(_at_)reutershealth(_dot_)com>
To: "John C Klensin" <john-ietf(_at_)jck(_dot_)com>
Cc: <ltru(_at_)ietf(_dot_)org>; <iesg(_at_)ietf(_dot_)org>; 
<ietf(_at_)ietf(_dot_)org>
Sent: Friday, September 09, 2005 7:16 PM
Subject: Re: [Ltru] Re: Last call comments on LTRU registry and 
initializationdocuments

John C Klensin scripsit:

So, all I was suggesting wrt the text of the "initial" document
is that, when the IESG concluded that it had reached community
consensus, two things should happen:

(1) The IESG instructs IANA to create the registry,
populating it with the elements as instructed in the
Internet-Draft  and using the formats specified there
and in the "registry" I-D.

I think that's what we had in mind.

(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.

The only problem I see is that the registry draft,
http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.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.

Randy, ltru co-chair




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

<Prev in Thread] Current Thread [Next in Thread>