Dear Sam,
thank you for this analysis. This is exactly my concern. There are in
addition a few points:
1. the WG-ltru involves employees of the industry dominant actors. I
feel they will not want to make a costly error for their corporation
and for them. But Layer 8 strategy errors are possible. Today one of
them reported on the ISO yearly meeting on language codes. This
meeting confirmed the root of the open solution I support (ISO 639-6)
and the importance I give (and the Charter implies) to ISO 11179
(registry systems) the WG-ltru consensually decided out of scope.
This shows this area is complex and that we may all be confused,
including over corporate and users best interest.
2. the second Draft is the registry to be loaded by the IANA. The
premature registration of East-Asian languages is included as now
part of the current registry. So, the question is: when is the IANA
supposed to load the registry (with its own delay) and to start
working on its structure. The discussion of the WG-ltru says: as soon
as accepted (+appeals) for a BCP, as soon as published (+appeals) for
a standard track. Hence the importance of being a BCP or not.
The way the IANA will support the registry is a key issue. Planned
RFC 3066 ter and tetra may make the registry more complex, to support
infos we see supported differently (ISO 11179). This might lead to an
XML support. This rises the question of the users utilisation, then
of the load, then of the cost. If each XML/HTML page or computer
reboot, etc. calls on the XML IANA registry, the load will be huge:
we have a new DNS system but centralised (same reason: some ISO or
IANA codes _may_ have changed or been added).
Once started, the solution will have to continue. Who but the
industry could foot its cost if it goes that way? Not me as a small
ccTLD Registry! If the industry takes over the IANA registry for such
a key service, it will make it paid by other services and private
standardisation (read the Charter: CLDR is mentioned but not
discussed, nor its IPRs). The Multilingual Internet will then become
a private venture.
The alternative is the decentralised URI approach. We all consider it
in a way: it is more powerful and free, but more complex and not
ready. I say "this fosters R&D and cooperation", I am opposed "this
fosters competition with you", and that the "best" "win". We all know
that the Internet develops from centralised, to decentralised, to
distributed. The Draft centralises with a commercial decentralisation
as a response to development - no other possibility. My proposition,
to make the Draft a default instead of an exclusive, decentralises
and prepares an open network distribution. I was privately asked if
"I realise what I cost to the industry". I do not think what benefit
to the users, costs to the industry.
3. the IANA's delay will be used for actions outside of the IETF. No
one will really feel concerned before it becomes clear the Draft
would be a standardised BCP, or an Internet future standard approved
by the IESG. Then Governments, Academics, international entities,
atlarge, politics, people will start reacting. A precise timing is
important to know. It is certain such a reaction will damage the
image of the IETF. As Brian mentions it, the importance of the IETF
results from the adherence to its propositions. Triggering an
international opposition should therefore be done very carefully,
only if forced. After every possibility has been explored. But it
must also be done in proper time for having a positive result.
All the more than it only calls for one additional line saying: "the
URI Tags format is supported through the reserved singleton "0"".
At 23:37 26/08/2005, Sam Hartman wrote:
One response to Jefsey is that whether a protocol action (approval of
a BCP or standards document) is suspended during an appeal is
something the IESG decides. In many ways, suspending the effects of
an IANA BCP or a process BCP during an appeal has more of an effect
than suspending a standards protocol.
OK. I understand there is no rule. That a BCP suspension as more
impact (hence may be less chances to be obtained?).
however in all cases the IETF community needs to take into account
deployed implementations and their behavior.
You are correct that implementers can attempt to do things to make it
harder for you to successfully appeal. That may not be nice or fair,
but to the extent that it is outside the IETF process, there is little
we can do about it.
I understand that. Please see my reasons above: to get a result at
least damaging cost for the IETF image. For that clear rules would help.
IANA registrations take long enough that I think you will have time to
file an appeal before the IANA website is updated. However there is
little anyone in the IETF can do to stop vendors shipping code.
This is why I propose to use the Draft as a default: there is no
change in the delivered code, but additions. This is a easy new release.
That's true whether we approve the draft, whether we act on an appeal,
whether we suspend an action, etc. Ultimately, the only reason our
documents have any power or influence at all is because the vendors
choose to give them that influence. Some (hopefully many) vendors
believe that waiting for issues to be resolved has value because it
improves interoperability.
In this case I suppose that a "IANA inside" label would commercially
help: here is the true power of the IETF. The proposed Draft solution
potentially costs a lot. If the industry finances a loser, it will
also be poor for them.
But I must stress that the IETF has no power besides that which people
choose to give it. Nothing stops someone from adding a byte to the
IPV6 header in their implementation. In fact, their ability to do so,
their ability to take the IPV6 standard (or any other IETF standard)
and go off and change it to meet their needs serves as an important
control and check on the process. Now, in the case of adding a byte
to the IPV6 header, a vendor might very well not want to do so because
doing so would cause their implementation to fail to work with every
other implementation. Fundamentally, though, it is their desire to
have interoperability that drives them to work with the IETF. That is
the only power we have.
I feel you may underestimate the commercial image of a IANA central
reference center.
Deep thank you for your analysis and comments.
jfc
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf