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

[Brian E Carpenter <[e-mail]>]

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:
> 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.
> 
> 
> 
> [e-mail] wrote:
> 
>> 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.
>>   
> 
> 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.
> 
>> - 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.
>>   
> 
> 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.
> 
>> 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.
>>   
> 
> 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!
> 
>> Thanks,
>> --David
>> ----------------------------------------------------
>> David L. Black, Senior Technologist
>> EMC Corporation, 176 South St., Hopkinton, MA  01748
>> [phone]             FAX: [phone]
>> [e-mail]        Mobile: [phone]
>> ----------------------------------------------------
>>
>>   
> 
> 

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