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

["Spencer Dawkins" <[e-mail]>]

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).

>
> 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
>
>
>
> .
> newtrk 
> resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive: 
> http://darkwing.uoregon.edu/~llynch/newtrk/index.html
> 


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