Subject: [newtrk] WGLC for draft-ietf-newtrk-repurposing-isd-01.txt

From: [email-masked] (Scott Bradner)
Date: Thu, 10 Feb 2005 08:23:23 -0500 (EST)

This starts an extended working group last call on "Internet Standards
Documentation (ISDs)" (draft-ietf-newtrk-repurposing-isd-01.txt) 

The last call will end March 18 - (the Friday after the IETF meeting)

This WGLC is an attemt to tease out any remaining issues with the ID 
- if issues get found before the ID deadline John may issue
a revision so please take a careful look over the next week and
post any issues you find to the list.

We will talk about this ID during the newtrk session in Minneapolis
but I hope that all of the issues (if any) are resolved by then

Scott
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 10 Feb 2005 15:47:05 +0100

Scott,

just checking: the updates since the previous version are these:

   Version 01.  This version incorporates the changes and clarifications
      discussed in a meeting of the NEWTRK WG at IETF 61 (Washington,
      DC, USA, November 2004) and on the mailing list in the subsequent
      weeks.  While some outstanding issues and possible issues remain,
      the document has been considerably tightened up and a number of
      previous loose ends documented.  In the process, some of the
      conversational text in the previous versions (see above) has been
      edited into a more formal form.  Most of the "why is this
      justified and being done" material has been moved to an appendix
      in order to facilitate eventually turning the Internet-Draft into
      a permanent IETF process specification.

The fact that there are known outstanding issues makes me wonder if this 
should be called a "WG first call" rather than a "WG Last Call".

Is the author able to give us a summary of outstanding issues?

                       Harald

.

---

From: John C Klensin <[email-masked]>
Date: Thu, 10 Feb 2005 14:31:09 -0500

--On Thursday, 10 February, 2005 15:47 +0100 Harald Tveit
Alvestrand <[email-masked]> wrote:

> The fact that there are known outstanding issues makes me
> wonder if this should be called a "WG first call" rather than
> a "WG Last Call".
> 

The first-listed author believes that he has done so: please
search the document looking for "[[ Note in draft".  Those notes
are intended to at least identify the issues and, in some cases,
to suggest possible resolutions to see if they can get
consensus.  I could repeat the list here but, frankly, I'd
rather make people read the document :-(

There is a meta-issue with the document that should probably be
explicit in this thread.  There are a number of little issues
that have the property that it probably doesn't make any real
difference how they are resolved, as long as they are resolved
somehow.  Those that I could identify are identified in those
Notes in draft, but I imagine that there are a number of others
that we haven't unearthed.  I believe that, if we spent another
several months theorizing about and tuning the document, many of
those issues (some unidentified even then) would remain.

If we want to move forward with this, I believe that we should
recognize that situation and take advantage of it.  In
particular:

	(1) We will not be able to agree on the details of the
	"standard" or "correct" form for these documents,
	especially around the edge cases, until a number of
	people have independently constructed documents to cover
	a fairly wide range of situations.  The RFC Editor's
	traditional approach to that sort of situation has been
	to say, essentially, do something sensible and try to be
	guided, to the extent it is reasonable, but what has
	come before".  I think that is a good principle, and
	that we had better be prepared to let the IESG accept
	(or push back on) documents and formats based on their
	subjective judgment about reasonableness, rather than on
	rigid format rules.  I hope that IESG, or
	whomever/whatever it delegates the job to, will be able
	to accept the role in the spirit that the RFC Editor has
	used for many years, rather than trying to build a
	Procrustian Bed and force every situation into it.
	
	(2) We will not be able to design precisely the right
	procedures for handling these things until we've tried
	it.  IESG members might be able to make good guesses,
	but I can't and the large fraction of the WG who have
	never been on the IESG side of document processing are
	in an even worse situation.  If we try to specify
	something in the draft, we will get it wrong (at least
	in the details) and either the IESG will be forced to
	ignore the letter of the document or we will end up
	paralyzed.   If, in feeling things out, the IESG
	concludes that it needs six slightly different
	procedures for the first half-dozen documents it
	handles, I would prefer that be called "incremental
	learning", rather than breaking rules that are
	over-specific given what we can anticipate. So, at some
	point, we need to let things go and rely on IESG
	discretion, with the expectation that we will want to
	come back in a year or so and write down what experience
	has told us is the right way to proceed.

In both of these case, the tough question is figuring out where
to stop.   We can tie up those open issues (or not), advance
this thing, and then leave it to the IESG to figure out how to
handle the details, edge cases, and unexpected small surprises.
Or we can fuss and tune for another few IETF meetings and then
advance the thing and leave it to the IESG to figure out how to
handle the details, edge cases, and unexpected small surprises.
My own view is that we are pretty close to the point of
diminishing returns, should beat on it for the next week, get
another draft out in a week and a half if it is needed, bash it
during IETF and get another draft out thereafter if needed, and
then ship the thing.  Others may, of course, feel that more of
the details need to be filled in.  

And my view of this preliminary WGLC is that it is time that
everyone in the WG take a pass through the document to both help
get the loose ends tied and to permit a serious discussion about
the above and just how many further refinement iterations we
want to invest in.

Just my opinion...
   john

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 11 Feb 2005 00:15:12 -0600

Replying to JohnK/JohnL's notes in this thread, but replying to the 
working group,

I like this draft, and think that JohnK and JohnL have done a good job 
of capturing our discussions on this topic.

After looking at JohnK's notes in the draft, I find ONE "open issue" 
that seems to need closing:

   [[Note in draft: Numbers versus Names.  There are advantages to 
names
   or acronyms (easier to remember as long as there are not too many 
of
   them, more human friendly) and to numbers (very precise and
   language-independent).  The choice between the two does not seem to
   be worth the amount of energy it will take.  Consequently, this
   version of the document recommends assigning both a number and a 
name
   (acronym or other string).]]

I agree with JohnK's take that we're now very close to the point where 
we can't logically perfect the draft without any operational 
experience. I believe this is the only "open issue" that we have to 
resolve, in order to start getting operational experience.

On this open issue, I agree with JohnK that both a number and a name 
would be appropriate.

If this meets with the approval of others in the working group, my 
suggestion is that we

- as the Johns requested, actually READ the document as it stands 
today,

- examining it for suitability for a BCP93 "Process Experiment",

- develop an XML schema (as Harald pointed out, we actually do need 
this to proceed),

- and propose a process experiment under BCP93, setting the IESG 
expectation that we are close enough to "go for it", but we'll 
probably learn things.

This would give us up to a year (the maximum sunset period) to nail 
down the loose ends.

It would also give us one of our chartered milestones.

Spencer

p.s. I'm also wondering how much IESG enthusiasm we actually have 
behind ISD, and that's probably a bigger unknown than any of the known 
unknowns in the current draft. I'd really like to get operational 
experience that includes IESG participation, instead of "fussing and 
tuning for another few IETF meetings" - which seems likely to turn us 
into ICAR Phase II (a well-fussed and tuned process that no one will 
actually sign up to participate in - see 
http://www1.ietf.org/mail-archive/web/icar/current/msg00291.html for 
background).

> newtrk 
> resources:_____________________________________________________
> mhonarc archive: 
> http://darkwing.uoregon.edu/~llynch/newtrk/index.html
> 

.