Re: I-D ACTION:draft-alvestrand-ipod-01.txt

I can't promise that the best is always the enemy of the good, but I think 
that ION is at least good, and worry that making it much better will not 
help us any time soon.

To pick one example - one might hope that working group chairs and document 
authors would be aware of current IESG practices on DISCUSSes ("why would 
this be wrong?"). The IESG (past and present members) have graciously 
written down what those practices are. Starting now, can you find them? and 
how long did it take?

When *I* was looking for them last week, I checked the IESG web page, where 
they are NOT listed (duh), and then did the I-D database search for "iesg 
DISCUSS". That works (sort of), and I can make the simplifying assumption 
that the current practices are reflected in the current draft (note that 
this is a stretch, because there are long-lived "drafts" that haven't been 
submitted as I-Ds for a while, so maybe I even found the current ones).

It is slightly more challenging to tell someone (in, say, the Working Group 
Leadership tutorial) where to find them in six months.

(Just FYI, the DISCUSS criteria ARE currently llisted on the IETF Chair web 
page, but that's not the first place I might look for the *IESG* criteria, 
and they don't have any author or date listed, so it's something of a pain 
to figure out if this IS the same version of the criteria that's in the 
draft.)

So, I'm worried that we are going to glue up ION in every discussion we've 
(sort of) had in Newtrk before anyone can find anything. Versioning and "who 
approves" were great time sinks for ISD/SRD discussions. Let's not have them 
again while discussing ION.

What I liked about Dave's note below is that it does point out that there 
are concerns about ION that are also more general concerns. My suggestion is 
that we focus on the ION-specific concerns (like, who approves them, and 
whether the IESG has time to flesh the idea out or not), and punt version 
tracking and updates/obsoletes back to Newtrk, where these concerns belong 
because, once again, I have found a working group draft that refers to TCP 
as "RFC 793", so I would really like to solve these concerns more generally, 
so that we stop standing oun our own shoelaces.

And, just to follow up on John's note - it is not necessary for the current 
ADs to figure out every detail of the experiment in order to run the 
experiment. We have a large number of recently-serving ADs, and the process 
hasn't changed THAT much since March, in addition to other people who could 
help flesh out the details. I agree that the IESG has to be OK with the 
details of the experiment at some point, but this doesn't have to be the 
sinkhole that it could be, if the current IESG are looking at each other in 
a room with no outside assistance. AD time and attention are precious.

Thanks,

Spencer

> John C Klensin wrote:
>> I wonder if we are reading the same document.
>
> We are.  But you read it rather carefully than I...
>
>> While the
>> comments below highlight the differences from BCPs that seem
>> most important to me, it appears to me that these differences,
>> and others, appear fairly clearly in section 5 of the I-D.
>>
>
> What I noted in section 5 was that the first part listed existing choices 
> and the second part listed reasons not to use them, notably missing 
> reference to BCPs.  what I missed was that the first part included some 
> cryptic dismissals of existing mechanisms, too.
>
> The reasons the document offers for not using BCP status are:
>
>      1.  usually a great deal of debate and effort to change
>      2.  bind up editing resources in the final edit stage
>      3.  as well as being limited (in practice) to ASCII
>      4.  not available for Info documents
>      5. "updates/obsoletes" ...can also be quite confusing to follow
>
> Does anyone think that the new mechanism will not suffer #1 and #2?
>
> #3 is a universal issue; if anything, IETF process documents need more 
> powerful font and graphics capabilities less than our more interesting 
> technical specifications, so it is difficult to guess why this new 
> mechanisms warrants a new formatting convention.
>
> #4 is the interesting objection, because it appears to have real 
> substance.  However the new series is for operations documents, not 
> "informational" ones.
>
> #5 implies that the updates/obsolets mechanism is generally problematic, 
> but I do not recall hearing about this before.  Is there some undercurrent 
> of community dissatisfaction with it?
>
> On reflection, the proposal could easily be taken as intended to begin an 
> end-run around the RFC editor process. If indeed the RFC Editor process is 
> problematic for IETF documents, then we
> need to worry about it more for our primary output than our internal 
> process documents.
>
> And, by the way, the premise of the proposal is that we need to be more 
> agile in being able to produce process documents.
> As if producing new and different process documents is somehow a current 
> problem in the IETF??? 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf