Subject: [Gen-art] GenART review of draft-alvestrand-ipod-01.txt

From: [email-masked]
Date: Fri, 2 Jun 2006 23:04:37 -0400

I am the assigned Gen-ART reviewer for draft-alvestrand-ipod-01.txt.

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other
Last Call comments you may receive.

This draft is on the right track but has open issues,
described in the review.

This reviewer concurs with the rationale in Section 5
of the draft, and agrees that something like IONs are needed.

One should normally give RFC 3933 process experiments a
fair degree of latitude, but this draft is a significant
stretch of what was envisioned in RFC 3933, even if the
general idea and intent are good.  The sheer breadth of
what the ION experiment would allow is impressive:
- The list of ION approvers and the scope of what they
	can approve is unlimited.
- The process by which an ION is approved is unspecified
	- the draft just says that approval is required.  For
	example, there is no discussion of Last Call of any
	form, even for significant process changes.
- The format of IONs is unspecified.
All of the above would doubtless be addressed by IONs, but
that circular dependency is a serious stretch of RFC 3933's
expectation that the IESG approves specific process 
change experiments - approval of this draft would provide
a framework for arbitrary IETF entities to run arbitrary
process experiments.  At least the above three aspects of
IONs should be much more tightly specified.

IONs and ION drafts intend to move from a version numbering
scheme to a date-based versioning scheme.  Particularly for
Draft IONs, this will come as a surprise to the community.
Using a version number in addition to dates would be a
very good idea for Draft and Approved IONs.

The draft name is clever ;-).

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 04 Jun 2006 00:26:55 +0200

David,

thanks for the review.

However, I am going to take the unusual step of declaring that I'm not 
going to address a single one of them as a result of Last Call - because 
in every case, the points you raise are deliberate design choices in the 
way I constructed IONs.

> 	can approve is unlimited.
This is intentional. The reason is that I do not see a rational process 
by which we can arrive at a description of their scope, other than 
"subsidiary to the process BCP documents".
The document's intention is to say that it does NOT ursup the role of 
process BCPs, and does NOT permit the publishing bodies to override an 
existing BCP by means of an ION; on reviewing the draft, I see that this 
can be stated far more clearly than it is now.
> 	form, even for significant process changes.
This is intentional. As noted above, the ION is NOT intended to 
introduce process changes, rather to give a framework for the stuff that 
is needed *other* than the process.
To give one example: I think that the list of organizations that we 
coordinate our meetings with, which the IAD maintains, should be an ION.
If two of these merge, and the IAD notes this change in the list, it 
should be possible to detect when and by who this was done by looking at 
the versions, the dates and the named approver. But a Last Call is 
simply not needed for this level of change.
> - The format of IONs is unspecified.
This is intentional. Among the documents that the ION series is intended 
to replace, there are (at least) text documents, HTML documents and 
documents written using the "note" format of XML2RFC. There are also 
some "semi-permanent internet-drafts" - some of which have expired.
Deciding this up front, and fixing it in concrete for the duration of 
the experiment, would be counterproductive; I think creating a very 
flexible first framework, and modifying it as we learn, is more likely 
to make the experiment useful.
> very good idea for Draft and Approved IONs.
I disagree - if we have a numbering scheme that encompasses both drafts 
and approved IONs, we will either have to work out a 2-level numbering 
scheme or risk serious confusion.

However, this is one that I am far less resistant to changing than the 3 
first aspects you mention - I like dates, but could be convinced 
otherwise if many people told me the same thing.
> The draft name is clever ;-).
Thank you!

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jun 2006 11:50:15 +0200

Let me put it this way.

Under RFC 2026 as it has been interpreted over the years, the IESG
has a lot of latitude to decide on procedures for things that are
(deliberately or not) left vague in the BCPs.

Sometimes, the IESG has documented these procedural decisions,
and sometimes not; but never systematically. Or it has delegated
decisions to others, who have done (or not done) the same.

This experiment doesn't change the IESG's implied authority, but
it creates a systematic way to document procedural decisions.
If the experiment succeeds, I agree that David's points *will*
need to be tied down.

It's actually my opinion that a formal RFC 3933 experiment is
probably not actually needed in this case - we could just do
it. But the experiment should give us a nice framework.

     Brian

Harald Alvestrand wrote:
>> expectation that the IESG approves specific process change experiments 
>> - approval of this draft would provide

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 12 Jun 2006 16:11:29 +0200

> it. But the experiment should give us a nice framework. 
I also agree with Sam that testing whether we CAN run an RFC 3933 
experiment is a Good Thing.