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

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 26 Aug 2005 02:03:35 +0200

On 21:25 25/08/2005, Stephane Bortzmeyer said:
>If the IESG were to refuse to publish the Sender-ID document as it is,
>it would not "police" everything: anyone can still do what he wants on
>the Internet.
>
>The only thing than the IETF can do is to "bless" or not the document,

Stephane,
just a remark here. In the RFC 3066bis Last Call case the IETF has 
the capacity not only to "police" but to "impose" and "force". This 
is the case when a memo documents a IANA registry. In the case of a 
standard track memo, there can be an appeal before it is imposed. It 
seems not in the case of a BCP.
jfc  

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Aug 2005 13:08:51 +0200

JFC (Jefsey) Morfin wrote:
> just a remark here. In the RFC 3066bis Last Call case the IETF has the 
> capacity not only to "police" but to "impose" and "force". This is the 
> case when a memo documents a IANA registry. In the case of a standard 
> track memo, there can be an appeal before it is imposed. It seems not in 
> the case of a BCP.

Wrong. IESG approvals of a standards track draft or of a BCP are equally
subject to appeal within two months.

    Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 26 Aug 2005 14:58:20 +0200

At 13:08 26/08/2005, Brian E Carpenter wrote:
>>standard track memo, there can be an appeal before it is imposed. 
>>It seems not in the case of a BCP.
>

Dear Brian,
I do not say that BCP are not subject to appeal, but that in the case 
of a standard track an appeal delays the enforcement and that in the 
case of BCP it does not. My sources are quoted below.

Entries have been made _months_ago_ on East Asian languages in the 
_current_ registry in using the Draft registry format, however 
initially opposed by the reviewer. Should the Draft be accepted, the 
registry update will be requested immediately and products will ship 
on the faith of the accepted drafts. This will impose the Draft 
through usage, rising objections to a "change" resulting from an appeal.

If you warranty that this is not the case and that this Draft can 
only be result in a reload of the IANA registry after the appeals 
(IESG and possibly IAB) are exhausted, this will help everyone 
getting more serene as the complexity of the issue calls for. This 
will permit more Members of the IETF community to become familiar 
with the architectural aspects at stake, and to people from the 
cultural world and from more languages to assess the involved issues.

My "Draft as a default, not as an exclusive" proposition gives that 
time, but over the years to come and without delaying the deployment. 
Should it be refused, appeals would block the implementation for a 
few months. This would be the only delay left to avoid balkanisation 
and an e-cultural world war. Experience from French/European cultural 
exception policy, European response to Google scannerisation project, 
Chinese Names, UNESCO positions and funding for a multilingual 
Cyberspace, NICSO equal linguistic opportunity declaration, MINC 
positions, Eurolinc's Louis Pouzin WSIS contributions, WGIG 
multilingual priorities, etc. show that - even if most of the IETF 
Members are unaware - this technical, political and societal issue, 
is not only commercial.
jfc

At 18:50 24/08/2005, Harald Tveit Alvestrand wrote:
>--On 24. august 2005 12:19 -0400 "John.Cowan" 
><[email-masked]> wrote:
>A process question: does a BCP go into effect when it is passed for
>>publication as an RFC, or when it is actually published as an RFC,
>>months or years later?
>
>When it is passed (see tradition with BCP 101). Setting up the 
>administrative details to actually act like the BCP says can take a 
>little time, of course.
>Harald

At 20:20 24/08/2005, Randy Presuhn wrote:
> > From: "Frank Ellermann" <[email-masked]>
> > On average four months, not years.  For an RfC the "effect"
> > (as far as IANA is concerned) is apparently very fast, one
> > experimental RfC approved less than two months ago with two
> > IANA "effects" is ready for at least three weeks now, IIRC.
>...
>Before a document is even approved for hand-off to the RFC editor,
>IANA will take a look at in in conjunction with the IESG review.  In my
>experience, they go through the IANA considerations sections *very*
>carefully, and are not shy about asking questions or requesting clarification.
>Consequently, by the time the RFC appears, IANA has already known
>for some time what would need to be done to implement a registry,
>so it should not come as a surprise that they are able to activate them
>quickly.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Aug 2005 17:23:16 +0200

JFC (Jefsey) Morfin wrote:
> I do not say that BCP are not subject to appeal, but that in the case of 
> a standard track an appeal delays the enforcement and that in the case 
> of BCP it does not. My sources are quoted below.

I have no idea what you mean. Neither IETF standards nor BCPs are enforced
by anybody - they are what the standards community calls voluntary standards.

(I am not referring to our own process BCPs in this statement.)

    Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 26 Aug 2005 17:49:07 +0200

On 17:23 26/08/2005, Brian E Carpenter said:
>>>>just a remark here. In the RFC 3066bis Last Call case the IETF 
>>>>has the capacity not only to "police" but to "impose" and 
>>>>"force". This is the case when a memo documents a IANA registry. 
>>>>In the case of a standard track memo, there can be an appeal 
>>>>before it is imposed. It seems not in the case of a BCP.
>>>
>>I do not say that BCP are not subject to appeal, but that in the 
>>case of a standard track an appeal delays the enforcement and that 
>>in the case of BCP it does not. My sources are quoted below.
>
>I have no idea what you mean. Neither IETF standards nor BCPs are 
>enforced by anybody - they are what the standards community calls 
>voluntary standards.

Brian,
??? we talk of the enforcement of the IANA considerations. When 
appealed (to IESG and then IAB) when is the IANA to apply the IANA 
considerations:
- of a BCP?
- of a standard track RFC?
jfc

---

From: Sam Hartman <[email-masked]>
Date: Fri, 26 Aug 2005 17:37:18 -0400

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:

    Brian> JFC (Jefsey) Morfin wrote:
    >>>> just a remark here. In the RFC 3066bis Last Call case the
    >>>> IETF has the capacity not only to "police" but to "impose"
    >>>> and "force". This is the case when a memo documents a IANA
    >>>> registry. In the case of a standard track memo, there can be
    >>>> an appeal before it is imposed. It seems not in the case of a
    >>>> BCP.
    >>> 
    >>> 
    >>> Wrong. IESG approvals of a standards track draft or of a BCP
    >>> are equally subject to appeal within two months.
    >> Dear Brian, I do not say that BCP are not subject to appeal,
    >> but that in the case of a standard track an appeal delays the
    >> enforcement and that in the case of BCP it does not. My sources
    >> are quoted below.

    Brian> I have no idea what you mean. Neither IETF standards nor
    Brian> BCPs are enforced by anybody - they are what the standards
    Brian> community calls voluntary standards.

Let me try and interpret here.

As I understand Jefsey's message, he is concerned about whatever
happens when the 3066bis registry is approved.  He believes that
shortly thereafter that products will used registry tags based on
3066bis and there will be an effort to register enough tags and
scripts under the new format that our ability to reverse things in an
appeal would be limited by deployed usage of the new format registry.

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.

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.

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.
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.

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.

--Sam

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 27 Aug 2005 01:55:19 +0200

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"".

>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?).

>but to the extent that it is outside the IETF process, there is little

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.

>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.

>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.

>have interoperability that drives them to work with the IETF.  That is

I feel you may underestimate the commercial image of a IANA central 
reference center.

Deep thank you for your analysis and comments.
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 27 Aug 2005 08:38:50 +0200

> (I am not referring to our own process BCPs in this

Please consider to split BCP vs. "meta / admin" documents.

Both are important, but the audience is different, mixing
rules how to write RfCs or how to manage IETF lists with
charset and langtag registries in the same BCP series is
confusing.
                    Bye, Frank

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 26 Aug 2005 23:50:03 -0700 (PDT)

> Please consider to split BCP vs. "meta / admin" documents.

I agree. There needs to be new track for IETF standardization 
work & procedures.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 27 Aug 2005 11:01:36 +0200

>charset and langtag registries in the same BCP series is

Full support of this. The RFC 3066 bis Draft includes standard track 
issues (ABNF) and IANA/Multilingual Internet management issues which 
should belong to a framework (due to the importance and the novelty 
of it, most probably written by IAB or IESG).
jfc

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Aug 2005 14:02:58 +0200

JFC (Jefsey) Morfin wrote:
> ??? we talk of the enforcement of the IANA considerations. When appealed 
> (to IESG and then IAB) when is the IANA to apply the IANA considerations:
> - of a BCP?

Again, I see no difference (despite Sam's message). A BCP or a PS are both
approved in the same way, both announced in the same way, and both published as
RFCs in the same way. They can both be appealed in the same way, and IANA will
set up registries in the same way. I'm not aware that we have written anywhere
*when* IANA sets up a registry - usually people are impatient, however, and want
it done as quickly as possible.

     Brian