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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]