John C Klensin wrote:
>> I'm not sure what the last paragraph in 2026 4.2.3 means.
> Independent of what that paragraph means, it is common for
> anything that is presented by the WG to IESG for comment to
> get a last call within the WG; I can't imagine a WG chair
> doing otherwise.
Yes, we've done this. The problem with the initial registry
is that it's easy to miss something - it's derived from six
different sources, among others the "old" 3066 registry. For
some details it's possible to fix potential bugs later (using
the registration / review procedure of the main document).
But generally it's intentionally impossible to get rid of a
registered tag, they are persistent: "deprecate" is allowed,
but not "removal". Therefore it's important to find any bug
now in the "IETF last call", later would be too late.
> Whether WG informational documents are then Last Called to
> the IETF is up to the IESG and relevant ADs. There is no
> requirement that it be done, but it generally is done
Okay, that's the desired effect in this case, the status (PS,
informational, or other ways to send it to IANA) is secondary.
[...]
> that the specification provide for some way of distinguishing
> between initial registry entries and subsequent ones by
> examining the registry
That's possible, there are "Added" / "Deprecated" timestamps.
> an instruction to the RFC Editor could be included in the
> I-D asking that they not publish the initialization document
> until the entries have been made in the IANA registry
That should be also clear, there are "IANA considerations" in
both documents, and it makes no sense to publish them as RfC
without first creating the actual registry (as defined by the
initialization document).
In other words, we artificially squeezed the initial registry
into an I-D to get the desired "IETF last call", and IANA has
to remove these artifacts (intro, boilerplate, page headers)
again resulting in the proper registry.
> For draft-ietf-ltru-initial, that would mean retention of
> sections 1, 2, and 4-7 into the RFC but the replacement of
> section three
1, 2, and 4..7 are only a "content-transfer-encoding" for the
purpose of getting 3 via "IETF last call" to IANA. And as a
side-effect there will be also a RfC documenting "the making of
the initial registry" - in theory it could be also archived as
"historic RfC" after IANA created the real registry.
> Then you are done. Presto, clearly informational document,
> historical information retained in the registry (which is
> where, IMO, it belongs), no chance of anyone ignoring the
> instructions in the third paragraph of Section 1 that the
> initialization list in the RFC is not the registry, and an
> RFC that runs around ten pages rather than 118.
Splitting it is IMHO less convincing - your idea assumes that
chapter 3 already exists as new IANA registry, but that's not
yet the case. Some hen and egg situation, and if there's an
informal way to create IANA registries on probation (subject
to a future "IETF last call") the WG didn't know it.
The chapters 1, 2, 4..7 are also interesting without 3, but
OTOH the same info is also available in the LTRU list archive,
it's not strictly necessary to keep it as separate RfC apart
from chapter 3 (= the beef, about 100 pages).
[record-jar]
> For example, the beginning of the second paragraph of 3.1
> might read
> 'The registry will be in a text file format that is
> fully specified below. This format was inspired by the
> "record-jar" format [record-jar].'
> But, again, this is purely an editorial matter as far as I'm
> concerned.
It's fine, I like it, then fix the [record-jar] reference, and
it should be clear that <registry> is fully specified in the
main document, with the book only "for info" and as "credits".
Bye, Frank
P.S. for Randy: Can we get a ticket for this editorial issue ?
It's about 1 - no [record-jar] in "initial", 2 - "inspired by"
in "registry", and 3 - add ISBN + publisher to the reference.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf