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

John C Klensin wrote:

>Dave,
>
>I think one can like, or dislike, this proposal.  My first
>objective was to make sure we were complaining about what was
>there/ intended, rather than what wasn't.  It is not the best
>document I've ever seen wrt specifics and explanation
>(including, I imagine, some of what you describe as "cryptic"),
>but, to some degree, that is part of the point.  Specific
>comments below...
>
>--On Friday, 19 May, 2006 08:40 -0700 Dave Crocker
><dhc2@dcrocker.net> wrote:
>
>  
>
>>...
>>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?
>>    
>>
>
>For #1, it removes the requirements for Last Call and
>demonstration of community consensus that apply to BCPs.   If I
>were advising the IESG, I'd suggest that there were many
>documents that would fall into this category for which the right
>procedure would be to expose a draft, announce intent to
>publish, wait two weeks (or some other short period), and do it.
>I.e., we would shift, for some of these materials, to more of a
>"take action and back away if the community finds problems"
>approach, rather than the BCP pattern.   There are issues in
>knowing which things should be handled that way and which ones
>should still get BCP-equivalent processing (see my other note
>about the issue of specifics and this proposal), but I note
>that, if all policy documents were handled according to this
>outline, it would eliminate the "IESG makes decision, quietly
>puts up a document without telling anyone, then yells 'gotcha'
>when anyone violates one of those rules".   I think the IESG is
>moving away from that approach, which is good; anything that
>reinforces that trend is, IMO, very good.
>  
>
For documents that the community does not see before approval, there 
will obviously be no delay in publication because of public discussion.
Some IONs will be appropriate for such processing. Some will not be.

>For #2, this gives the IESG the ability to figure out when
>something is "good enough", post it, and tune as needed.   That
>is a very different model from the RFC Editor's determination to
>have all documents be of uniform high editorial quality and of
>archival quality and stability.  I think that separation is also
>a benefit... see below.
>  
>
If the published document is identical to the approved document, there 
is no post-approval editing.

>  
>
>># 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.
>>    
>>
>
>Part of the reason for the ASCII focus on RFCs (and RFC
>Editor-published archival documents should we ever invent other
>kinds) is that they need to be archival.  Historically, methods
>for providing  more powerful fonts, graphics, etc., is that they
>get tied to software that doesn't stand the test of time
>(whether we have gotten past that with PDF is the subject of a
>different conversation).   These documents are not archival and
>hence not subject to the same constraints.  That said, if the
>only reason for this was more flexibility about formatting and
>presentation, I'd be violently opposed to it -- just not work
>the marginal effort of doing something different.
>  
>
Today's practice is that several of the documents that could qualify for 
the ION series are published as HTML (web pages) - sometimes as the 
output of the "note" variant of xml2rfc. I did not want to force what 
some people would think of as a step backwards on those documents.

>  
>
>># 4 is the interesting objection, because it appears to have
>># real substance.  However the new series is for operations
>># documents, not "informational" ones.
>>    
>>
>
>But we are publishing tools documents and similar things as
>informational now, if we publish them at all.
>  
>
What I was getting at was that an Info document (like the IESG charter, 
or the RFC Editor's instructions to authors) has no stable identifier 
except its current RFC number. If there is a new version, there is no 
stable identifier that will continue to point to the "current" version.

>  
>
>># 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?  
>>    
>>
>
>For procedural materials, I think "yes".  One example is what it
>takes to figure out what our procedures actually are, given the
>number of things that have updated, modified, or fine-tuned RFC
>2026.
>
>  
>
>>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.
>>    
>>
>
>Interestingly, I'd argue exactly the opposite.  As another
>recent thread points out, the RFC Editor's special expertise is
>in the vetting, editing, and publishing of technical, archival,
>documents.  These documents are neither.  Getting them out of
>the RFC Editor's processing queue could free up resources that
>would be better spent on our primary output materials.  If that
>sped those up, even a little bit, it would be, I think, a net
>gain.  And certainly separating IETF procedural documents from
>the RFC process is not an end run around what other documents
>call the "technical publisher" role associated with the RFC
>Editor.
>  
>
I'll happily leave the discussion of RFCs to Techspec. My intention was 
to get something done about operational notes, not to change the RFC series.

>  
>
>>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???
>>    
>>
>
>I think maybe it is, at least if part of our goal is to have our
>processes described in some coherent and accessible way.
>
>Is this the highest priority I can imagine?  No.  But I find the
>arguments for separating this work from the more technical
>publications that the RFC Editor handles and putting it under
>the more direct control of the IESG and Secretariat seem to me
>to be, on balance, constructive and time-saving steps.
>
IONs are not a very big deal. But unlike some of our other problems that 
need solving, it seems to be possible to make things a little bit better 
in this area.

And after running the experiment for 12 months, we *might* know more 
about how it works.

                           Harald

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