Subject: Re: IESG response and questions to the normative reference experiment (draft-klensin-norm-ref-01.txt)

From: Jefsey_Morfin <[email-masked]>
Date: Fri, 01 Sep 2006 13:19:14 +0200

At 11:35 01/09/2006, Brian Carpenter wrote:
>So, in conclusion, the IESG seeks comments on whether there is
>community interest in turning the first part of this experiment into a
>BCP.  The IESG also seeks comments from interested document editors
>and working group chairs pointing to instances where the second part
>of the experiment would be useful.  In particular, please let the IESG
>know about upcoming work where being able to reference approved
>Internet Drafts from RFCs would be useful; please explain how it would
>be useful.  Unless the IESG finds significant cases where the second
>part of this experiment will be useful, the IESG plans to decline to
>run that part of the experiment.

Brian,
you have recently documented a case where referencing current BCP 47 
I-D instead of BCP 47 itself was a need. I oppose your idea to 
consider that expediting their publication as RFC is a solution (and 
I will therefore oppose your decision to expedite this publication 
should my appeal be turned down on this point).

We exactly are in the case you decribed. I asked the IESG to expedite 
that publication months ago. I was turned down. Unicode asks again 
and you want consider it is an emergency case. This means that if an 
IETF participant asks for something he is turned down, but if an non 
IETF participant asks for the same thing IESG will rush to satisfy 
the same request. This is prejudiciable juridprudence. In this case, 
what is absurd is that you simultaneously publish a rechartering LC 
review to obsolete the same documents by the same date: this shows 
that this solution is probably not good in some cases.

You turned my appeal down on false grounds (and I forwarded it to the 
IAB). What I oppose is the idea that expediting the publication of an 
RFC under appeal is a possible solution to the need you describe.

1. It MUST not be.
2. another solution MUST be found.

John Klensin's proposition seems to be a realistic, acceptable one. Because:
- it does not register an RFC which would have to be obsoleted should 
a few points have to be mended.
- in the process it does not influence the appeal under consideration.
- an appeal puts the focus on a document, and an expedited 
publication looks like a special sponsoring of the IESG.

IRT experimentation.
I think the IANA linguistic registries are an important issue and an 
area of experimentation. There already are experimentations carried 
by WG-LTRU members. They show the need to have some QA on the langtag 
libraries. The RFC 3066 Bis format turns out to need further 
constraints to be fool proof: this is reflected by experimentation.

Under appeal is the affirmation by a co-Chair that RFC 3066 Bis 
langtag verification calls for too much load on the IANA to be used 
in the matching process. Only practical testing can show if this is 
true or not, if there are some alternatives or not. The Internet was 
built on experimentation, not on commercial interests. This is 
exactly the rationale of IAB's RFC 3869.

I am certainly willing to share a serious testing experimentation 
protocol over the IETF langtag usage and interoperability.
jfc

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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 01 Sep 2006 17:11:17 +0200

Brian Carpenter wrote:

> one way of looking at this is that it relaxes the
> requirements for normative downreferences in RFC 3967

That's apparently "explicitly mention it in the last call" 
for some time, after that the downref can be considered as
known and accepted, and it doesn't need to be mentioned in
further last calls.

That's apparently as simple as possible.  The experiment
would replace the warning in the last call by a warning in
the references.  I probably miss the point.

> there is sufficient support for this part of the experiment
> that simply writing a BCP is a better approach than running
> an experiment.

Please keep the warning in the last call.  Putting a warning
also in the references is a good idea.  I don't see why...

| The IESG may, at its discretion, specify the exact text to be
| used

...that's necessary.  3967bis could copy bullet 2 in 3.1 of
the draft as is.

Frank

---

From: Thomas Narten <[email-masked]>
Date: Fri, 01 Sep 2006 12:53:38 -0400

> The IESG also seeks comments from interested document editors and
> working group chairs pointing to instances where the second part of
> the experiment would be useful.

In the past, it was rather common for there to be a not insignificant
number of documents in the RFC editor queue, whose publication was
blocked waiting on some other document not yet in the RFC editor
queue. The actual dependency chain wasn't always apparent either (you
could have a transitive relationship going through 3-4 documents
before finding the actual document that was the source of the
blockage). Some of these documents could take more than a year before
they became approved by the IESG for publication.

My guess is that many of the documents awaiting publication would be
viewed as candidates for allowing a downreference to an ID
(especially, when publication is/has been delayed for 6+ months). The
longer publication has been blocked, the greater the pressure to
invoke this aspect of the experiment.

Personally, I don't think RFCs should allow normative references to
IDs, but that is a different question than how often there will be a
tempatation to invoke it.

Looking at the current RFC editor queue, I count 25 IETF documents in
MISSREF*R state. A good number of been waiting for roughly a year, one
document for nearly 3.

Thomas

---

From: Pekka Savola <[email-masked]>
Date: Fri, 1 Sep 2006 22:41:45 +0300 (EEST)

On Fri, 1 Sep 2006, Brian Carpenter wrote:
> The experiment is composed of two parts.  The first part allows
> approved Internet Drafts to reference RFCs at a lower level of
> maturity, provided that a note explaining the reference is added.  One
> way of looking at this is that it relaxes the requirements for
> normative downreferences in RFC 3967.  The IESG believes that there is
> sufficient support for this part of the experiment that simply writing
> a BCP is a better approach than running an experiment.
...
> BCP.

I do not agree with the assessment that there is community consensus 
to turn this to BCP right out.

While some community members expressed their opinion that downref 
rules should be abolished completely, that was not the subject of 
draft-klensin-norm-ref Last Call. I would personally be opposed to 
creating such a BCP (instead of building experience through experiment 
first).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Sep 2006 17:12:47 -0400

>>>>> "Pekka" == Pekka Savola <[email-masked]> writes:

    Pekka> I do not agree with the assessment that there is community
    Pekka> consensus to turn this to BCP right out.

Thanks for the input.
That's why we asked:-)

Would you be sufficiently interested in the experiment to write text
if necessary?

Do people agree or disagree with Pekka?

---

From: "todd glassey" <[email-masked]>
Date: Fri, 1 Sep 2006 15:32:44 -0700

Pekka - the problem with experimenting is that this is not design of a
protocol. Its an organizational workflow and event process and its
constrained in the world by laws. Its also required to be fair and open -
not some of the time but all of it.

Unfortunately this is one of those times when Technology is not the answer -
but rather a reliable and complete organizational process model is.

Todd Glassey
----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: <[email-masked]>
Sent: Friday, September 01, 2006 12:41 PM
Subject: Re: IESG response and questions to the normative reference
experiment (draft-klensin-norm-ref-01.txt)

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Sep 2006 12:10:04 +0200

> MISSREF*R state. A good number of been waiting for roughly a year, one

Let's be clear that the experiment wouldn't automatically release
all of those 25 documents.  It would only allow ones to be released
that refer (normatively) to
   "o  Internet-Drafts of Standards Track documents for which IESG review
       has been completed and Protocol Action or Document Action notices
       have been issued."

The second question we're asking addresses this case. "In particular,
please let the IESG know about upcoming work where being able to reference
approved Internet Drafts from RFCs would be useful; please explain how it
would be useful."

     Brian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 4 Sep 2006 13:32:54 +0300 (EEST)

> Would you be sufficiently interested in the experiment to write text

I assume you refer to guidance on how to indicate the status of a 
reference when down-ref'ed.  Sure, I could craft some text if that's 
the way to go and that would help.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 05 Sep 2006 07:56:59 -0400

>>  Would you be sufficiently interested in the experiment to
    >> write text if necessary?

    Pekka> I assume you refer to guidance on how to indicate the
    Pekka> status of a reference when down-ref'ed.  Sure, I could
    Pekka> craft some text if that's the way to go and that would

No.  John made it fairly clear that he wasn't really all that
interested in only part one of the experiment.  If he steps down as
editor, would you step up?

---

From: Brian Carpenter <[email-masked]>
Date: Fri, 01 Sep 2006 05:35:27 -0400

[Discussion invited on [email-masked]]

The IESG received a request under RFC 3933 to run
draft-klensin-norm-ref-01.txt as an experiment in loosening the IETF's
requirements for normative references in RFCs.

The second part of the experiment proposes that RFCs be allowed to
contain normative down references to approved Internet Drafts that
have not yet been published as RFCs.

According to RFC 3933, the IESG must make a determination of whether
an experiment is plausibly useful before it is approved.
   "The IESG
   can institute whatever procedures it wishes to make this determination
   and to avoid denial of service attacks from large numbers of spurious
   or unimportant proposals.  In particular, they might institute a
   procedure requiring a number of endorsements, or endorsements of a
   particular type, before the IESG considers the proposal.  The IESG is,
   however, expected to understand that procedures or review processes
   that act as a mechanism for significant delays do not fall within the
   intent of this specification."

The IESG is new to RFC 3933 experiments and like the rest of the
community is still trying to figure out how to evaluate these
experiments.  In this instance, the IESG issued a last call and the
discussion focused around the question of whether it would be a good
idea if the IETF tried this experiment.  The consensus was by no means
clear-cut.  The IESG believes it is likely that after more
definition, we could eventually get to an experiment for which there
is community consensus.

However the question of "plausibly useful" includes aspects that were
not adequately considered during the last call.  In particular, while
discussing how to move forward, the IESG realized it had never
actually considered who would use the second part of the experiment.
When queried, no area director indicated a specific desire to use the
experiment to reference an approved Internet Draft from an RFC.

The IESG believes the second part of this experiment is unlikely to be
useful unless there are IESG members that find it sufficiently
compelling to invest time in trying to use the experiment.

In the future, it may be desirable to ask for specific intentions of IESG
members for experiments that would only be successful with the active
participation of some IESG members.  The question is: are there IESG
members who have a specific need for the proposed experiment and are
going to use this proposal in real life?  This should not be used to block
efforts for change with very strong community support.  However it is
appropriate to use such endorsements to focus our efforts especially
when consensus is mixed or when there are a lot of efforts on the
table.  The IESG realizes that it needs to be responsive to the
community.  The IESG also trusts that we all realize that change where
there is active, eager support will be more successful than change with
inadequate support.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 05 Sep 2006 09:57:58 -0400

>        has been completed and Protocol Action or Document Action notices

With this restriction, I suspect that this part of the proposal solves
no real or compelling problem. In those cases where an approved
document needs to become an RFC urgently, it seems like requesting
expedited RFC publication has proven to be an adequate solution.

Leaving it in the proposal would seem to do little except invite
potential mischief.

Thomas

---

From: Eliot Lear <[email-masked]>
Date: Tue, 05 Sep 2006 16:30:03 +0200

Brian Carpenter wrote:
> [...]
In general I am not in favor of 3933 experiments regarding permanent
document series, and so I believe the IESG is right to suggest that a
BCP is appropriate in this case.  While I am in favor of moving ahead
with a BCP to remove the restriction on normative references, I believe
this really to be a half measure.  There are many more reasons why
documents do not progress through the standards track, such as having to
matrix out each feature.  Very few people want to do that work.  And so
I ask that as we move forward with the BCP you propose above, once
approved we monitor its progress to see if *anything* changes.  If after
18 months we see no changes I would ask for further action.

Eliot

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Sep 2006 10:16:32 +0300 (EEST)

> editor, would you step up?

If folks agree that this the way to go, I can pick up the pen if 
necessary.