Subject: RE: Last Call: 'A Process Experiment in Normative Reference Handl ing' to Experimental RFC (draft-klensin-norm-ref)

From: "Gray, Eric" <[email-masked]>
Date: Thu, 1 Jun 2006 11:47:55 -0400

John,

 	In your "choices" below, choice i and ii are not quite
separable.  In the "do nothing" mode i, eventual advancement
required to de-queue the "would-be Draft Standard" will only
happen if choice ii is in effect.  In other words, choice ii
is effectively the same as choice i except that the duration
of the "do nothing" phase is shorter (by an arbitrary amount).

--
Eric Gray

--- [SNIP] ---

--> (From Eric Rosen) 
--> 
--> > Frankly,  I  think  this   wavier  procedure  is  outrageous,
--> > and  entirely unacceptable.  The fact  The fact that the
--> > referenced  document has not gone through some bureaucratic
--> > process does not  mean that it is any less stable, or that any
--> > more caution is  required in its use.  Inserting this
--> > derogatory language about technology which may  be well-proven
--> > and widely deployed will be extremely misleading to the
--> > industry. 
-->
--> (your response)
--> 
--> If a WG agrees with you about a particular piece of technology,
--> they have three choices:
--> 
--> 	(i) Do nothing, in which case their would-be Draft
--> 	Standard will sit in queue until that well-proven and
--> 	widely -deployed technology is, itself, advanced to
--> 	Draft Standard (or to not try to advance their Proposed
--> 	Standard to Draft Standard at all).
--> 	
--> 	(ii) Pick up the obviously well-documented definition of
--> 	the well-proven and widely deployed technology and
--> 	advance it to Draft Standard.
--> 	
--> 	(iii) Invoke the RFC 3967 procedure for downrefs, which
--> 	is more burdensome in terms of processing than the new
--> 	proposal, but does not involve disclaimers.  You can
--> 	think of the RFC 3967 procedure as requiring a community
--> 	determination that the referenced technology is stable
--> 	enough to be referenced in a document of a given
--> 	maturity level.
--> 
--> So the proposed new rule adds one option to the three that are
--> there already.  It is up to the WG (or individual submitter)
--> which one to use.   This one is intended to be much more
--> lightweight and quick than any of the existing options, but no
--> one is forcing its use.  And I assume that, if it is found too
--> unpleasant or derogatory, then no one will use it and it will
--> disappear after a year.  Personally, that wouldn't bother me one
--> bit -- you will recall that I have proposed and/or backed much
--> more radical and extensive solutions to this type of problem --
--> but that is a rather different discussion.
--> 
--> > I  think that  any rule  which requires  us to  insert false
--> > and misleading statements in the documents should be strongly
--> > opposed. 
--> 
--> But there is no requirement that this procedure be used at all.
--> If I writing a document that needed to reference a specification
--> that was as well-defined, mature, and stable as you posit, I'd
--> first try to get that specification advanced to the right
--> maturity level or, if there was some bar to doing so, I'd invoke
--> the RFC 3697 procedure.  Or I might try to build consensus for
--> some serious discussion and action on
--> draft-ietf-newtrk-promotion-00.txt, which essentially proposes
--> fast-tracking the advancement of such specifications on the
--> basis of their marketplace acceptance (and which is showing
--> signs of vanishing without a trace).
--> 
--> > Even worse: 
--> > 
--> >      "The IESG may, at its discretion, specify the exact text
--> > to be used"
--> > 
--> > Great, not only is the WG  required to denigrate its own
--> > technology, but the IESG is given free rein to insert whatever
--> > derogatory remarks they feel like putting in. 
--> 
--> First, this seemed appropriate for an experiment of the type
--> specified.  In addition, like it or not, current procedures, as
--> practiced, essentially give the IESG free rein to insert
--> whatever remarks (derogatory or otherwise) they feel like
--> inserting in anything.  They are prevented from doing so by some
--> combination of good sense and the presence of the appeals
--> procedure, which is exactly what the paragraph you complain
--> about below says...
--> > 
--> > Of course, we'll be told not to worry, since:
--> > 
--> >       "If members of the community consider either the
--> > downward reference or the annotation text  to be
--> > inappropriate, those issues  can be raised at any time
--> > in the document life cycle, just as  with any other text
--> > in the document."
--> > 
--> > Great.  Another useless thing to argue  about in the WG, and
--> > another useless thing to argue about with the IESG.
--> 
--> But the assertion you are making about a (e.g.) Proposed
--> Standard specification being stable, mature, well-defined,
--> widely-deployed, etc., is one that presumably should get some
--> community review, rather than simply being accepted as the
--> result of the divine rights of the author/editor.  And that
--> brings us back to the three existing choices above, which the WG
--> presumably needs to argue about today.   The WG's only choice
--> without such an argument is to not try to advance any document
--> that would require a downref... and that is an opportunity to
--> argue as well.
--> 
--> > There  are  also   other  reasons  why  I  find   this
--> > proposed  experiment disheartening. 
--> > 
--> > For  one  thing, it  really  misses  the point.   We  need  to
--> > simplify  our processes, not make them more  complicated.
--> > Either we need the downref rule or we  don't.  If we want  to
--> > experiment, let's  experiment with eliminating the rule
--> > entirely, not with fine tuning it.
--> 
--> I don't know how to do that and still get back if there is a
--> conclusion that it wasn't a good idea.  And, remember, I have
--> proposed more radical solutions to the underlying problem here.
--> It is evident at this point that they lack adequate traction
--> (people who care) and consensus, so adding a lightweight option
--> within the current framework seemed to be an idea worth
--> exploring.
--> 
--> > The  real underlying  problem of  course  is the  the
--> > multi-stage  standards process is just a relic from another
--> > time, and makes no sense at all in the current environment.
--> > Experiments in fine tuning the process are nothing but a
--> > distraction.
--> 
--> Well, we disagree about that.  Perhaps more important, there is
--> little evidence of community consensus for that position
--> although it certainly has several loud advocates.  I suppose one
--> can rationally oppose any proposal to make the current system
--> work better on the grounds that it should be made to work worse
--> in order to gain more traction for getting rid of maturity
--> levels.  Maybe, from that point of view, you should support this
--> on your theory that it will create more arguments and bog things
--> down further.  On the other hand...
--> 
-->        john
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Gray, Eric" <[email-masked]>
Date: Thu, 1 Jun 2006 12:07:06 -0400

Eric (Rosen),

	Irrespective of opinions about the nature of the current 
process, if one RFC is advanced significantly ahead of another 
one that it has a normative dependency on, it is possible that
the state of the art will migrate between one advancement, and
the other.

	In the event that this occurs, the documents will be out
of synch - irregardless of the actual state of the art.  It is
simple to fix that - either advance both at the same time, or
allow them to be out of synch based on a speculative assertion
that de-synchronization will not occur.

	In the latter case, it is certainly reasonable to allow
that de-synchronization may occur - and that appears to be the
intent of the note in this draft proposed process experiment.
The risk is that - if the normative reference is advanced, and
this produces a de-synchronization of the documents, then the
referring Draft Standard will have to be updated as well.

	Consequently, I - for one - see nothing either false or
misleading in the proposed note.  I also find that addition of
such a note is substantially less onerous than alternatives we
have now...

--
Eric (Gray)

Your mail included [paraphrased]:
--- [SNIP] ---
--> 
--> Frankly, I think this [waver] procedure is outrageous, and entirely
--> unacceptable. The fact [...] that the referenced document has not 
--> gone through some bureaucratic process does not mean that it is any 
--> less stable, or that any more caution is required in its use. 
-->
--> Inserting this [language] about technology which may be well-proven 
--> and widely deployed will be extremely misleading to the industry. 
--> 
--> I think that any rule which requires us to insert false and misleading
--> statements in the documents should be strongly opposed. 
-->  
--- [SNIP] ---

---

From: "Gray, Eric" <[email-masked]>
Date: Mon, 12 Jun 2006 11:27:50 -0400

Brian,

	I had responded to Eric Rosen's note earlier (see my mail
of Thu 6/1/2006 12:07 PM EDT) - in particular concluding:

"I - for one - see nothing either false or misleading in the 
proposed note.  I also find that addition of such a note is 
substantially less onerous than alternatives we have now..."

	In the event that this was not clear, I support this
experiment.

	I think it is worth adding that we might not know the
outcome of such an experiment for many years - because it may
take that long to determine whether or not this approach is
more or less painful than the current process.

--
Eric

--> -----Original Message-----
--> From: Brian E Carpenter [mailto:[email-masked]] 
--> Sent: Monday, June 12, 2006 6:20 AM
--> To: C. M. Heard
--> Cc: [email-masked]; [email-masked]
--> Subject: Re: Last Call: 'A Process Experiment in Normative 
--> Reference Handling' to Experimental RFC (draft-klensin-norm-ref)
--> 
--> C. M. Heard wrote:
--> > On Thu, 1 Jun 2006, Eric Rosen wrote:
--> > 
--> >>There  are  also   other  reasons  why  I  find   this  
--> proposed  experiment
--> >>disheartening. 
--> >>
--> >>For  one  thing, it  really  misses  the point.   We  
--> need  to simplify  our
--> >>processes, not make them more  complicated.  Either we 
--> need the downref rule
--> >>or we  don't.  If we want  to experiment, let's  
--> experiment with eliminating
--> >>the rule entirely, not with fine tuning it.
--> >>
--> >>The  real underlying  problem of  course  is the  the 
--> multi-stage  standards
--> >>process is just a relic from another  time, and makes no 
--> sense at all in the
--> >>current environment.  Experiments in fine tuning the 
--> process are nothing but
--> >>a distraction.
--> > 
--> > 
--> > For the record, I completely agree with the above 
--> sentiments (and have so
--> > stated on the newtrk mailing list).
--> 
--> I'd like to ask people who *don't* agree with the above sentiments
--> (i.e. who support this experimental process change) to say 
--> so, before
--> the Last Call ends in two days. (Obviously, people who *do* 
--> agree are welcome
--> to say so too, but a problem with Last Calls is that it's 
--> very hard to
--> judge whether silence means consent.)
--> 
-->      Brian
--> 
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/ietf
-->