Message-Id: <6.2.3.4.2.20050827000657.03b10bc0@mail.jefsey.com>
Date: Sat, 27 Aug 2005 01:55:19 +0200
To: Sam Hartman <hartmans-ietf@mit.edu>,
	Brian E Carpenter <brc@zurich.ibm.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <tsl1x4gjs6p.fsf@cz.mit.edu>
References: <6.2.3.4.2.20050826005941.03dcdeb0@mail.jefsey.com>
	<430EF843.3000709@zurich.ibm.com>
	<6.2.3.4.2.20050826142135.049e1a60@mail.jefsey.com>
	<430F33E4.20204@zurich.ibm.com> <tsl1x4gjs6p.fsf@cz.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ietf@ietf.org
Subject: Re: IESG powers - was: Appeal: Publication of
 draft-lyon-senderid-core-01 in conflict with referenced 
 draft-schlitt-spf-classic-02
Precedence: list
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf