Comments on draft-ietf-ltru-registry and
draft-ietf-ltru-initial and, secondarily, on
draft-ietf-ltru-matching...
Summary: These documents represent good work, and the community
should be grateful to have them. However, I believe they, and
the still-incomplete "matching" one, have conclusively
demonstrated that the expectations of the WG Charter were
unreasonable and inappropriate. When the documents are
examined as an IETF product, rather than on the assumption that
the charter represents perfect foresight, it is clear that the
documents should not be handled as BCPs but as Proposed
Standards, with an applicability statement and/or profile to
follow. The reasoning behind this conclusion is explained
below.
---------------
These specifications are a nice piece of work and the model
specified is quite elegant. It appears to me to meet the goals
of permitting a high degree of specificity when needed while
providing a plausible mechanism for preserving stability across
changes in underlying documents. Having tried, mostly
unsuccessfully, to track the WG's work, I believe that the IETF
community owes those who have actively participated and
contributed great thanks. However, the documents that they
have produced should not be approved as one or more BCPs, nor,
in their present form, as replacements for RFC 3066 / BCP 47.
An alternate suggestion that does not require significant work
beyond that specified in the charter is outlined below.
(1) BCPs or Proposed Standards
The WG Charter calls for the production of BCPs. Like all
provisions of WG Charters, the requirements that the community
specifies and agrees to must be treated as tentative: if the
best work the WG can produce, consistent with the general goals
of the charter, are not acceptable as the charter specifies,
the community must have the ability to change categories or, in
the worst cases, refer the WG products back to the WG for
further work under a new set of charter specifications.
Fortunately, I do not believe that worst case applies here: the
documents that were last-called appear to be quite appropriate;
it is only how they are classified and applied that appears to
be at issue.
RFC 3066 (and 1766) were arguably just a mechanism for tying a
few existing (and tested) specs together, using a review and
registration procedure. As such, they were at least marginally
inside the category and usage for which BCPs are appropriate.
LTRU-registration, by contrast, is designed to operate without
registration of full tags: the role of the reviewer, and of
IANA, is to register subtag entitites from which tags can be
constructed. It also provides for a highly distributed
registry, with different maintainers for different subtags or
groups of subtags. Neither the IETF community, nor the IANA,
has any experience with doing things that way. Given the
importance of this registry, and the dependencies upon the
preceeding 3066 registry, that combination of conditions -- a
more complex architecture, registration of components rather
than full tags, and lack of community experience with the
approach -- adds up to an extremely strong argument for
treating these documents as Proposed Standards, and then
letting them advance along the standards track as experience
accumulates, rather than approving them as a single-stage BCP.
(2) Matching rules and the replacement of RFC3066/ BCP47
RFC 3066 essentially specifies its own set of matching rules:
for matching purposes, tags are treated as atomic and two tags
match or they do not. Both the "registry" document and some of
the discussion leading up to it pointed out the flaws in that
approach, particularly tags that are equivalent but do not
match because extra information is supplied. However, the
material in Sections 4.1 and 4.2 of the LTRU specification does
not provide an adequate replaceent for Section 2.3 of RFC 3066.
The latter is considerably more normative and specific (even if
naive in retrospect). By contrast, the material in the LTRU
registry document gives much more general guidance, but not the
level of specific instructions needed to promote
interoperability. Hence, a _replacement_ for RFC 3066 as BCP
47 requires not only the registry specification but a set of
matching rules (perhaps those to be specified in
draft-ietf-ltru-matching, but see below).
(3) Interoperability issues
Until and unless a protocol or specification is tested in
practice, interoperability is no better than an hypothesis.
That is one reason, perhaps the major reason, why we have a
multiple-stage standards process. It is also much of the
reason why the IETF has traditionally tried to avoid complex
protocols with many options. As Marshall Rose elegantly wrote
in RFC 1425,
Experience with many protocols has shown that:
protocols with few options tend towards ubiquity, whilst
protocols with many options tend towards obscurity.
Viewed as a protocol the LTRU model is option-laden. Much as I
dislike going down the path of profiles, it appears to me that,
if we are going to keep interoperability paramount, the general
guidance about choices of tags in Section 4 of the registry
document must be supplemented by application-specific profiles,
developed from use cases, that include both tagging and
matching rules if we are going to support interoperability and
avoid many of the operational problems with 3066 that
stimulated the LTRU work.
(4) What should be done.
I have become convinced that, rather than approving these
documents as a BCP, we should...
(i) put the registry document on the standards track, as
a proposed standard. While this step, and the next one,
should not be done without agreement from the WG, they do
not require any additional work on the WG's part. While
changes from would-be standards track to informational or
experimental are more common, such changes of designation
after Last Call are clearly within the IESG's scope.
(ii) either put the initialization draft on the
standards track with it or publish it as informational and
use the downref procedure,
(iii) define a profiling mechanism for what should
actually be done to effectively and interoperably use this
registry. This step, and the one that follows, is an
additional task for the WG. But the WG's work is, IMO, not
complete until it is done: mechanisms for how to put
something into a registry are always much easier than
determinations of how entities, once registered, are to be
used in an effective and interoperable way. For the IETF,
the latter has always been key... to the point that it is
implicit in every WG charter.
(iv) acknowledge that only a profile, and not the
registry doc, can replace 3066, and that such a profile
must combine rules for registry use and specific matching
rules. Such a profile is inherently dependent on the
matching rules and only a document (or set of documents)
that specifies both registration and matching can
appropriately become a new version of BCP 47.
(v) put the matching doc on the standards track when it
is considered ready, with only the profiles (if that)
showing up as BCPs. As with (i) and (ii), this does not
intrinsically require more work from the WG.
--------------------------
Some nit-picking (easily fixed):
The documents make reference to the "record-jar" format. I
believe the text in ltru-registry is sufficient to define the
portion of that spec that is relevant, justifying the editor's
choice to list [record-jar] an an information reference. If
that is correct, the fact that the format specification is
self-contained in this spec should be made _very_ explicit in
both the "registry" and the "initial" document. Indeed, the
"record-jar" reference might best be eliminated from the latter
document as a distraction. If it were not, I believe that we
should obtain permission from Eric Raymond and if necessary
Addison-Wesley, to reproduce the relevant material in an RFC: a
dependency on a moderately expensive book that could go out of
print as part of the definition for an IANA registry should be
acceptable to neither the IETF nor to the IANA. And,
incidentally, the reference given is incomplete.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf