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

[Harald Alvestrand <[e-mail]>]

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