Subject: [Fwd: I-D Action:draft-carpenter-rfc2026-changes-02.txt]

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Jan 2008 15:23:00 +1300

Hi folks,

I produced this update at the request of Russ Housley. It's
considerably tightened up from the previous versions - now the
question is whether people are interested enough to comment...

    Brian

-------- Original Message --------
Subject: I-D Action:draft-carpenter-rfc2026-changes-02.txt
Date: Wed, 16 Jan 2008 21:10:01 -0500
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Changes to the Internet Standards Process defined by RFC 2026
	Author(s)       : B. Carpenter
	Filename        : draft-carpenter-rfc2026-changes-02.txt
	Pages           : 28
	Date            : 2008-01-16

This document defines a number of changes to RFC 2026, the basic
definition of the IETF standards process.  While some of them are
definite changes to the rules, the intention is to preserve the main
intent of the original rules, while adapting them to experience and
current practice.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-rfc2026-changes-02.txt

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

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 16 Jan 2008 18:51:04 -0800

Brian -

Section 3.17 - is a good clarity tool for better clarifying the scope of 
these processes. But that same need for clarity also applies to 3.18 -

Section 3.18 - the Retention and Records Keeping section needs considerable 
rewording. There are three key issues to address in the operations of a 
mailing list and since these are not uniformly implemented the IETF is again 
liable IMHO for its relying on any IP through a mailing list based service.

The three issues are the 'integrity of the content that is managed' by the 
list operator. That means keeping the content in a reliable and provable set 
of submissions. It also as the second constraint is tagged with a retention 
period as well, i.e. a statement of how long the list operator commits to 
operate and maintain that list for. The reasoning is simple - all the 
participants in the WG have the right to recover that IP for some time from 
those sources, so there is an implied expectation that the list content is 
going to continue to be available. The third goochie is that the list 
particpants also have the right to identify the other 'legal participants' 
in the WG so the IP issues in the mailing list can be resolved.

So ... the wording needs to be amended to address the retention and 
integrity in operations requirements as well as any IPR or other 
declarations of 'representation' in the WG participation rules. This also 
makes some changes to the definitions for NoteWell too I think.

Todd Glassey

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 18 Jan 2008 11:20:02 +0100

Brian E Carpenter wrote:

> the question is whether people are interested enough to comment...

...and maybe also how interested the author is to answer comments:
<http://article.gmane.org/gmane.ietf.general/27581/match=2026>

[RFC 3700]
You still propose to kill STD 1 claiming that everybody is online
today.  What with CDs containing all RFCs, or similar collections
for offline use ?

[standards action]
Removing the right to initiate a "standards actions" from the
community is a bad idea.  That's not "aligning with reality", I
tested it, it works like a charme, the RFC in question meanwhile
got its number.

[Draft Standard]
"Deployable Standard" for DS is nice.  

[conflicts]
Does "persons appointed to IETF roles" include document editors
and expert reviewers ?  I think Chairs can act as buffer between
angry folks and editors, and so hope it does NOT include editors.

Have you integrated your conflict draft into this draft ?  It could
be better to keep them apart.  While you are at it you could adopt
John's proposal to replace "two months" by "six weeks" for appeals.

 Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Jan 2008 15:55:16 +1300

> today.  What with CDs containing all RFCs, or similar collections

Well, mosts CDs seem to have index pages of some kind -
something like http://www.rfc-editor.org/rfcxx00.html would
do it (and that is always up to date, whereas STD1 is normally
out of date).

> tested it, it works like a charme, the RFC in question meanwhile

I didn't intend that at all. Where do you find that?

> angry folks and editors, and so hope it does NOT include editors.

We can debate the details I guess - but don't you think there should
be an appeal path if an IANA-considerations expert reviewer makes
a dubious decision? Document editors aren't appointed by the IESG,
so wouldn't be covered by my language.

> 
> Have you integrated your conflict draft into this draft ? 

No. There was insignificant community interest in that so
I've dropped it.

> It could

That would be a real change rather than an alignment with current
practice.

   Brian

---

From: Robert Sayre <[email-masked]>
Date: Fri, 18 Jan 2008 22:03:57 -0500

> That would be a real change rather than an alignment with current

However, it would be a documented change proposal. I find the  
euphemism "alignment with current practice" just a touch Orwellian.

- Rob

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 19 Jan 2008 09:58:11 +0100

Brian E Carpenter wrote:
 
> mosts CDs seem to have index pages of some kind - something like
> http://www.rfc-editor.org/rfcxx00.html would do it (and that is
> always up to date, whereas STD1 is normally out of date).

IMO they should resume to publish ??00 RFCs as STD 1 at least when
there is a new or updated STD.  If they really hate it there should
be a "last" STD 1 deprecating itself.  Some tools (not only offline
collections with an old snapshot) and users still expect that STD 1
exists, whatever 2026bis says, a last STD 1 also needs to be clear.

> I didn't intend that at all. Where do you find that?

3.14 == old ==
| or, in the case of a specification not associated with a Working
| Group, a recommendation by an individual to the IESG.
3.14 == new ==
| or, in the case of a specification not associated with a Working
| Group, an agreement by an Area Director to recommend a
| specification to the IESG. 

You move the "action" right from the community to IESG members.

I also hated it when you (or Jari ?) did in essence the same with
the right to create a "Pubreq" for non-WG documents.

> don't you think there should be an appeal path if an IANA-
> considerations expert reviewer makes a dubious decision?

Yes, my two examples were for both sides, there's no WG Chair who
could "protect" expert reviewers...

> Document editors aren't appointed by the IESG, so wouldn't be
> covered by my language.

...good, I missed "by the IESG" after "appointed to IETF roles".

 Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Jan 2008 09:25:51 +1300

Frank,

Thanks for the comments.

> exists, whatever 2026bis says, a last STD 1 also needs to be clear.

Yes, I agree that *either* we should cleanly terminate the STD 1
mechanism *or* we should implement it as originally documented.
The current situation (where STD 1 was last updated in July 2004)
is clearly misleading for outsiders. My personal preference is
clean termination, but obviously that should be a consensus question.

> You move the "action" right from the community to IESG members.

Oh, OK, I need to put in more words to say something like
"a recommendation by an individual to an Area Director willing
to sponsor the specification..."

I didin't mean to remove the individual from the process.

> the right to create a "Pubreq" for non-WG documents.

http://www.ietf.org/IESG/content/ions/ion-ad-sponsoring.html
is intended to make it *easier* for individuals by actually
clarifying the procedure - we had lots of experience that
just sending a draft to the IESG collectively really didn't work.
It's only when an AD is willing to actively push a document
that it will get the IESG's attention.

(And BTW this does work - just look at the number of non-WG
drafts that make it onto the IESG agenda.)

    Brian

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 21 Jan 2008 10:50:29 +0100

Brian E Carpenter wrote:
 
> is clearly misleading for outsiders.

Yes, for some time I thought that it's caused by what also caused
the "pending errata" congestion, or that they use another trigger 
for a new STD 1 - a fresh RFC ??00 with no changes is pointless.

> My personal preference is clean termination, but obviously that
> should be a consensus question.

Anything that's more obvious than "align with reality", if there
was an info about what they intend I missed it (back in 2004).

 
> to sponsor the specification..."

Strike "willing".  The "unwilling" scenario has to be a "decision":

E.g. if the proponent didn't submit a draft "writeup" questionnaire,
or if the recommendation is nonsense.   Otherwise, if it's just the
AD "unwilling" to accept a recommendation or forward it to the IESG,
this has to be an appealable decision.  Proponents forced to find a
"willing" AD is horrible.

> just sending a draft to the IESG collectively really didn't work.

If that boils down to "proponents either need to find a 'willing' AD
or submit a (draft) 'writeup' for their recommendation" it is okay 
for drafts and RFCs written by somebody else.  If proponents prepare
a 'writeup' normal cases of unwillingness (no time to read the memo,
and no idea what it's about) shouldn't enter the picture.

> It's only when an AD is willing to actively push a document that
> it will get the IESG's attention.

When a "Pubreq" token exists something will happen, tools like the
"tracker exceptions" help.  With the RFC 2026 rules "an individual"
can trigger the standards action, with your rules this could depend
on a "willing" AD.

If "an individual" is "the author" there would a potential conflict
of interests, an author trying to draft a 'writeup' is biased.  In
that case "an individual" (not limited to a "willing AD") is needed,
authors can't sponsor their own documents, the IETF is no Wiki... :-)

> BTW this does work

When I tested it I hit an AD who wasn't convinced that what the I-D
talks about still exists.  The "find a willing AD" procedure is very
embarrassing.  It's okay if they don't like an I-D, or are unwilling
to be forced to vote "YES" later, but that shouldn't be the problem
of the author.  The "an individual" (neither author nor willing AD)
loophole in RFC 2026 is a good compromise, please don't close it. 

 Frank