RE: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification....

["Bound, Jim" <jim.bound@hp.com>]

Good response and good for me.  Thank You.
(I am working with others on ent analysis very very tricky :---))
/jim 

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi] 
> Sent: Tuesday, August 17, 2004 3:34 PM
> To: Bound, Jim
> Cc: Alex Conta; Erik Nordmark; v6ops@ops.ietf.org; 
> gilligan@intransa.com; david.kessens@nokia.com; 
> jonne.Soininen@nokia.com
> Subject: RE: 12 Problems with 
> "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: 
> clarification....
> 
> On Tue, 17 Aug 2004, Bound, Jim wrote:
> > I see your points but if we are to use your model as editor then we 
> > need to be consistent in all specs at what level of detail 
> we go into 
> > for the technical protocol specs (as opposed to operational 
> technical 
> > ones).  I think it comes down to what detail and health warnings we 
> > put in documents and I think that is AD and Chairs decision. But 
> > whatever it is lets keep it for all documents.  I have seen Alex's 
> > issues in other docs and other members presented on other 
> specs.  Be 
> > good to know the rules of engagement for v6ops at this 
> juncture with 
> > this spec.
> 
> <co-chair hat on>
> 
> The stage at which the document is *does* make a difference.
> 
> If an argument is made that such and such health warning, 
> operational guideline, or whatever should be put in the 
> document, and it seems reasonable, it should probably be 
> seriously considered for inclusion
> -- *if* this happens prior to WG last call, at WG last call, 
> or maybe even at IETF last call (if appropriate).
> 
> At some point in the process -- when the documents are beyond 
> last calls and forwarded to the IESG for publication, past 
> IESG evaluation, etc. -- we just *have* to stop tweaking the 
> document unless there are strong reasons to do so.
> 
> If WG participants believe that there are very strong reasons 
> why the current proposals in this particular case need to go 
> in, and are fine with accepting the delays etc. which would 
> be incurred (redoing IESG evaluation at least), please 
> provide input.  It has been solicited...
> 
> I don't think this directly addresses your question at its 
> widest interpretation, but should clarify the issue at hand.
> 
> <co-chair hat off>
> 
> (I personally think it's good to have operational guidance in 
> as well, as long as it's sufficiently clear what is protocol 
> specification and what is operations or other warnings.. -- 
> along with other issues in the proposals, these have been 
> partially mixed up.)
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
>