Re: The LTRU initialization document

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



John C Klensin wrote:

> In a situation like this, if the community leaves the IESG to
> make this sort of decision without significant community
> input, then the community deserves whatever the IESG does,
> including coin-tossing.   If people care, they should say so
> clearly enough that the IESG's role is to interpret community
> input, not to make things up because no one (besides some
> soreheads like me) is saying anything.

It's not that nobody but you said anything about it, in fact
it's the only case of a potential "rough consensus" not covered
by a half dozen LTRU tickets.

What Addison said is IMHO correct, 3066bis must replace 3066,
they can't coexist.  One of the main design goals was backwards
compatiility.  Any solution designed to exist in parallel with
3066 would be completely different, because it's not forced to
be backwards compatible.  For starters there won't be a kludge
like "Suppress-Script" in that hypothetical solution.

Most probably we agree so far, and then the question of BCP vs.
standards track is among other things a matter of taste.  It's
apparently a "feature" of 2026 that the IESG decides about the
status - in the usual sense of "your feature is my bug (and
v.v.)", so all we can do is offer some opinions.

If you'd press the WG for some kind of consensus about this I'd
bet that you'd get "BCP with an option for the IESG to say PS",
exactly as Scott (= the AD, the Proto-shepherd avoided that
issue) stated it.  With some more or less convincing reasons.

And finally it's not up to the author / WG / Chair / community
to decide about the status.  Unfortunately in the case of some
individual submissions, this "experimental" loophole to bypass
a proper "IETF last call" as seen for SPF and SID was "wrong"
(a 2234bis "wrong", so that's as bad as 32 ordinary wrongs :-)

But for ltru-registry there was a "last call", and I think the
IESG knows that some (not only you) prefer PS instead of BCP
for 3066bis - under the conditions listed by Addison.

> FWIW, that split in the BCP series is already covered in
> draft-ietf-newtrk-repurposing-isd.

Thanks for info, added to my "I-D collection" - admittedly I'm
lost in this one-step / two-step / add-XML-step netwrk-maze.

> Perhaps my imagination is worse than yours, but I can easily
> imagine "numeric country codes prohibited" or "alpha-2
> country codes prohibited" (note that matching the two
> requires large tables that are not, as far as I know, freely
> available for free and that change).

In that case your imagination is worse tha mine.  The _actual_
lists are freely available, e.g. the alpha-2 country codes:

http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_3166-1_decoding_table.html?printable=true#AA

It's unnecessary to match these lists.  All details about the
registration of region codes are specified in 3066bis.  Forward,
sideward, backward, 3166 screws up, 3166 out of sync with UN,
everything, we discussed this for months.  It was the reason
why I was interested in this WG.

It makes no sense to exclude all numeric country codes, that's
the "escape hatch" if 3166 is forced to reuse an aplha-2 code
(examples: GE, SK, CS), because 3066bis tags are persistent
(unlike 3066 tags).

Maybe you could exclude the UN "macro-regions" (~ continents),
you could as well exclude some languages or scripts, or all
variants.  If you do so, fine, but that doesn't affect the
registry.

There's one thing where getting _free_ lists could be tricky:
old region codes.  OTOH precisely that issue is addressed by
the registry with its persistent subtags, you don't need any
old UN or 3166-lists to determine what 3066bis subtags mean
(unlike 3066 tags).

> I can also imagine "script required" or "region, if present,
> ignored" or a number of other variations and profiles.

Yes, the first case was also in my shorter list.  If you take
language + script + region as three "dimensions", then the
language is required (using the langtag registry in other
contexts could be a bad plan, it's not designed to be a say
region registry, and for a script registry you can also use
the ISO standard).  That leaves two dimensions where you could
say "ignored" or "required".  Better don't consider "variant"
as an independent fourth dimension, it's not, generally it has
a "Prefix".

All in all you'd get about four potential "profiles":  I-I,
I-R, R-I, and R-R (I = ignored. R = required).  The concept of
regions in 3066 and 3066bis is so clumsy that I can't imagine
any serious case of R.  That reduces the profiles to I-I + R-I
(= my "to script or not to script"), or maybe I-I, R-I, I-?,
and R-I (? = region allowed).

>> Maybe we could mention this in a note about the extension
>> registries.  Also as a hint for the future DS^W3066ter.

> "Add later" is much more plausible, at least formally, with
> a Proposed Standard than it is with a BCP.

Add Jefsey and we're three. and that's not much, bye, Frank



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]