Re: IESG powers - was: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

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

 



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

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