Subject: [newtrk] My notes from Newtrk

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 10 Mar 2005 17:31:52 -0600

Please send corrections to Scott!

Thanks,

Spencer

New IETF Standards Track Discussion (newtrk) WG

Thursday, March 10 at 1530-1745
===============================

CHAIR: Scott Bradner <[email-masked]> 
SCRIBE: Spencer Dawkins <[email-masked]>

AGENDA

intro & status - chair 

  a.. One week away from end of WGLC on ISD document
  b.. Did not WGLC cruft yet, will discuss moving forward here
  c.. We are not worrying about the number of stages in the standards process, because if we do ISD, we won't care about status of individual RFCs
discussion of ISD proposal  - John Klensin
background reading:
draft-ietf-newtrk-repurposing-isd-01.txt
draft-ietf-newtrk-sample-isd-00.txt
draft-ietf-newtrk-sd-00.txt
draft-ietf-newtrk-sample-isd-stdproc-00.txt

  a.. We went though a number of issues with the ISD document at the last meeting, the current ISD draft captures all the discussion John could capture
  b.. Not getting comments that require document changes - are there questions? Comments? Are we ready to go?
  c.. Don't want ISDs to contain IETF process BCPs, so proposed SD series ("Standing Document") - need to decide what we want to do about this, not obviously within our chartered scope
  d.. We need a DTD for these documents, if we're going to keep them in XML. The IESG needs to wade in here, because they care more than we can care about the details - if this is the plan, we need to start punting to the IESG now
  e.. Brian Carpenter - what are you punting? Not designing DTDs, surely? Defining what they should do? That's basically the problem. What sections, what they should contain, etc. We've gotten individual feedback from IESG members that isn't consistent
  f.. Brian blamed his predecessor
  g.. Eliot Lear - we're supposed to decrease the work of the IESG, not increase it. We need a liaison, and it needs to not be Brian. We need to ask "are we keeping the right information?" Let's get this feedback before doing the detailed work.
  h.. John Klensin - if we need arbitrary IESG decisions, it would be more efficient to let the IESG make them on their own
  i.. Harald Alvestrand - the IESG tends to defer complicated questions. We can probably ask "do you agree that X is true and Y is false?" Be as specific as possible. Don't ask them to think. About what they really want.
  j.. Brian Carpenter - Let's conspire on questions with binary answers, sometime in the next two weeks.
  k.. John Klensin - we don't want to cycle for very many more months without feedback.
  l.. Dan Connally - XML DTD for what sort of document?
  m.. John Klensin, standing on one leg - we've discovered that a small number of categories about unlinked RFCs isn't useful and linking with STDs is too late. We've done a lot of iterations, but that's the waterfront. We're looking for a real document series, not a bunch of RFCs. The ISDs contain prose about the referred-to RFCs. 

  n.. Eliot Lear - did not find serial number in the current draft. What about maturity level of ISD versus maturity level of RFCs referenced?
  o.. Scott Bradner - would like to postpone this discussion.
  p.. Bob Braden - what do we need to do before passing to the IESG? Granularity is a real problem and needs to be addressed in the ISD draft. Taxonomy of the problem space, or some part of the problem space, is needed.
  q.. John Klensin - conclusion of WG is that we can't get a unified theory. We can do examples.
  r.. Bob Braden - I'm asking for running code.
  s.. John Klensin - check the example documents - there's no way to answer this question in general.
  t.. Eliot Lear - Bob is asking for some more specific use cases
  u.. Spencer Dawkins - use cases are not easy - and don't need to be serialized with this discussion. It would be good to figure out how many ISDs SIP is, but don't wait on this - the SIP chairs think this will be hard.

  v.. Scott - Any objections to moving this forward?
  w.. Bob Braden - is this a BCP? Scott believes so. Bob - Experimental? John Klensin - we don't have process experiments except for July14th RFC. This could be a process experiment, but John is concerned about "going back" if we decide NOT to go forward.
  x.. Scott - IESG would be mandating that WG chairs "do the right thing" - going back will be funky.
  y.. Brian Carpenter - using Experimental doesn't feel right - BCP doesn't feel a lot better, there are problems with the labels. Informational? No level of approval, and people don't read Last Calls for Informational carefully. We'll propose BCP and can go to Historic if we have to.
  z.. Eliot Lear - Backing out is difficult because the other label is STD - this won't multiplex well with ISDs. Maturity levels still need help?
  aa.. John Klensin - we cycled with no helpful input last time - we can solve this fast or tell the IESG to figure it out, those are the options.
  ab.. Scott Bradner - we can have "soft" labels - "has been implemented", etc.
  ac.. John Klensin - if ISDs have the lowest maturity level referenced that solves one problem.
  ad.. Scott - but this means all ISDs will be Proposed Standard, and that's the problem we have now. We have running code that maturity levels aren't used anyway.

  ae.. Brian Carpenter - actually like not having mathematical relationships based on maturity levels.
  af.. Harald Alvestrand - ISDs talking about maturity levels makes sense, having maturity levels doesn't.
  ag.. John Klensin - does this document queue up behind decisions about maturity levels? We hope not.
  ah.. Eliot - Maturity statements make more sense than maturity levels.
  ai.. Melinda Shore - this is a boffo idea, totally support it, one caveat - we need relatively uniform descriptions
  aj.. Does anyone think ISDs should wait for maturity levels?
  ak.. Eliot Lear - if the purpose is to ask the IESG if we're doing the right thing, we don't have to wait, but if we're nailing things in stone, we need to have some clue.
  al.. John Klensin - should I just take maturity level of ISD out of the draft?
  am.. Eliot Lear - did we also agree that we would provide descriptive text? But this is about the referred-to RFCs, not about the ISD. Would like to see applicability.
  an.. We will forward request for processing with one change after WGLC finishes. This will be a normal request for publication, but we expect feedback from the IESG. If they say "yes", they say "yes".

  ao.. Harald Alvestrand - will request for processing include a DTD? We don't have one now, so the answer is no.
  ap.. Dan Connally - is the reason there isn't a DTD because it's hard, or no one knows how, or ...
  aq.. John Klensin - we don't need a DTD until the IESG knows what they want, at least not more than a skeleton.
  ar.. John Klensin - we also need to scrub explicit placeholders, including the cruft work. 

  as.. Bob Braden - is it the expectation that when this is adopted, RFCs will no longer have maturity levels? Scott - we'll stay with the current mechanism for pragmatic reasons, until we get a better offer - we'll just say "standards track".
John went through the rest of the placeholders...

  a.. IESG can put anything in an ISD they feel to be helpful, right? Seems to be "yes". We've discovered that we need a place to store accumulated experience, that's what we're trying to accommodate. 

  b.. Bob Braden - we have a lot of experience about our inability to foretell the future - IESG has a freeform field to extend this mechanism, and that's a good thing.
  c.. Eliot Lear - there's a difference between having a freeform field and having a freeform document.
  d.. Harald Alvestrand - I thought it was obvious that the working group was going for a DTD when they chose XML, so I can start writing text when this is approved

report and discussion on the anti-cruft effort - Eliot Lear
background reading: 
draft-ietf-newtrk-cruft-00.txt

  a.. We've been running a cruft experiment since the last IETF
  b.. There is cruft out there - we covered this last time. We created a list of all PSes numbered under 2000 and discussed them on a mailing list, asking for anyone to provide any reason why it wasn't cruft. There was barely even a laugh test. We did outreach to find other people, and we're asking again here.
  c.. We have 57 documents on the current cruft list, out of 119 that we started with.
  d.. Cruft classes - PEM, Whois++. Token Ring, Appletalk, Novell, X.400, X.25, plus MIBs for cruft.
  e.. Pat Thaler - IEEE does five-year reviews, and Token Ring recently passed in IEEE - this is good enough for us.
  f.. Telnet docs were removed from the cruft list.
  g.. Pekka Savola - we don't have a clear idea what "making something Historic" means - some people think if a protocol is even in use somewhere in the universe, we shouldn't declare it cruft.
  h.. Scott Bradner - if the criteria is that "cruft" isn't what we would recommend today, should MIBs be on the list if there's no alternative MIB? Obsoleted isn't the same thing as Historic... There are three reasons things became Historic - replaced, obsolete, or a really bad idea - this doesn't help at all.
  i.. Other positive output - some documents will be revised, etc.
  j.. How to do more outreach?
  k.. Should a draft detailing what is cruft be Informational or a request to the IESG to remove these documents? Or words for ISDs?
  l.. Spencer Dawkins - is 57 a big enough number? I thought we had more cruft than this - others? Also - please don't produce a bunch of ISDs about cruft- that's the last thing we need to move ISDs forward!
  m.. Melinda Shore - 57 isn't that bad - we don't want to throw out too much.
  n.. Pekka Savola - the IETF Announce list would be enough outreach.
  o.. Bob Braden - OSI protocols were on the list, and X.400 probably didn't die...
  p.. Melinda Shore - we can do more outreach, Bob is right, and the question of how to filter stuff out is a hard one - we can get input from others
  q.. John Klensin - ITU is considering bringing back X.400 distinguished names to solve the DNS problem...
  r.. Brian Carpenter - IBM's office I visit has only token ring, we do need to be careful.
  s.. Scott Bradner - a MIB is different from a protocol - the MIB will be in use as long as a device is on the net.
  t.. Pekka Savola - is there any problem with non-cruft referencing cruft? There aren't "normative references" in these older documents. What about Informational? that would get rid of a lot of more...
  u.. Harald Alvestrand - the reason to obsolete X.400 documents in the IETF isn't because no one uses it, it's because no one cares what we said anymore.
  v.. Pekka Savola - criteria could be "no one has energy to revise this document"
  w.. Eliot Lear - we could also go look at Draft Standards, but we are supposed to be thinking about the process of going to Draft Standards anyway. I'm planning to spend another month looking for authors and doing outreach. If you have contacts/e-mail addresses for someone who's interested, please send them to me.
  x.. Plan for going forward?
  y.. Pekka Savola - any assumptions about Informational RFC versus actual request for action? 

  z.. Fun exercise and move on? Publish the list? Request moving documents to Historic? Last two options got about equal support in the room, we'll take this to the list.
  aa.. Brian Carpenter - the second option needs justifying
  ab.. Melinda Shore - eventually this needs to go to the IESG, but it's not ready yet.
  ac.. Doug Otis - we have a massive RFC Index and it's hard to figure out most recent document - can we have a cruft-free index, at least?
  ad.. Bob Braden - I don't think we should just forget about this, but ISD will make this irrelevant, so put your energy there, unless the document is harmful to the Internet.
  ae.. John Klensin - I'm concerned that we do as little as possible to add work to the IESG - ISDs will make these documents irrelevant - I should remove the ISD text pointing to cruft, right? Scott - right, and we can move discussion about alternatives into an opinion.
  af.. Melinda Shore - there's another step that needs to happen before we go to the IESG - we have to do a Last Call to move to Historic anyway. The mechanism to identify cruft can use some refinement.
  ag.. Eliot Lear - I agree that the number of documents that can be crufted being only 57 means the document classification is actually being maintained. We can wait on the ISDs and come back to this if we have to.
  ah.. Pat Thaler - I'd rather have choice 1 than choice 2. Publishing another RFC that calls Proposed Standards cruft will be invisible and people will continue to use them.
  ai.. Harald Alvestrand - if we don't declare these documents Historic, we should abandon the concept of Historic. Declaring something cruft by not issuing an ISD is pretty obscure.
  aj.. Eric Grey - Just making documents Historic doesn't make them go away. The advantage is that this does raise the visibility of the document's status. 

  ak.. Scott Bradner - we've used Historic to tag really bad ideas - don't lose this.
  al.. John Klensin - what path are we going down? I thought we would issue a 57-document ISD and bail all of them out.
  am.. Harald Alvestrand - that would work for me.
  an.. There is no support for abandoning the crufting work, we're still going forward.
wrapup - chair 

  a.. Where to go next? We could have ISD draft and cruft done by Paris.
  b.. Look at the labeling of RFCs? Maturity level, and tagging non-IETF documents. ISDs could make RFC maturity levels irrelevent. 

  c.. Bob Braden - confused - I thought the label on the RFC reflected the standards process - is this changing?
  d.. Scott - RFC maturity levels can wait until we're sure we need to do the work on this at all. We are going to have to revise the standards process eventually, but we can wait to see which way we need to revise it.
  e.. Bob Braden - If you have a standard and want to extend it, is another RFC added to the ISD? Or a new ISD might reference the old one, or... what's the process for deciding what ISD an RFC goes into when a standard changes? RFC Editor needs more guidance here.
  f.. Brian Carpenter - I agree and want to say it differently - this is how we direct someone to the real SMTP specification instead of the full standard one. We can freewheel here for a bit before redoing RFC 2026.
  g.. Clear way to identify non-IETF RFCs? If we have ISDs, and we are extremely clear what a standard is (an ISD), this probably doesn't matter.
  h.. Bob Braden - Not All RFCs Are Standards - actually, "NO RFCs are standards" - correct.
  i.. Defer this work, too? No objection in the room. All our objectives are deferred, and we won't meet in Paris.

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 13 Mar 2005 19:51:26 -0500

I am somewhat confused by the  content or tone of the ISD discussion 
contained in these minutes...

The general content seems to be that the newtrk WG is specifying ISDs 
_for_ the IESG (or to help the IESG in some way?), and that the IESG 
has not provided enough information to write the DTD. The tone seems 
to be some frustration with the IESG for not providing more feedback.

This confuses me because, as far as I know, the IESG did not come up 
with the concept of ISDs.  We originally started this group to 
evaluate, and possibly update,  the IETF standards track, and this WG 
decided that it would be better to do something along the lines of 
ISDs.  In keeping with the usual IETF bottom-up (or is that 
bottoms-up? :-)) approach, the working group was rechartered to do 
the work that the group had consensus to do.

I think that the purpose of ISDs is to make it easier for 
implementers and users to find pertinent/related documents and to 
understand their status.  In fact, I don't think that ISDs will 
decrease the IESG work load, and they might increase the IESG effort 
to process a standards track document -- which may be okay if ISDs 
have a larger benefit to the community than the additional WG 
documents that the IESG could have processed with the same resources.

So, shouldn't we be asking the implementers and users what should be 
in the ISDs?  They are the folks that are expected to benefit from 
them, right?

Am I fundamentally misunderstanding something here?

Margaret

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 14 Mar 2005 12:48:48 +0100

Hi Margaret,

You got the tone wrong.  We just want to know if we're going off the 
rail, and we'd like to know that sooner rather than later.  And if you 
like ISDs, then it makes sense to have a discussion with the IESG (and 
IMHO Secretariat and RFC Editor) about what information, and perhaps 
meta-information, should be codified in an XSD for ISDs.

Jeez... I'm beginning to think I need an acronym glossary for these 
emails...

HTH

Eliot
.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Mar 2005 15:00:31 +0100

I agree with Eliot. The ISD proposal is one where it will
be useful to have a sense of the IESG's opinion before it
gets into formal shepherding.

(Needless to say, that doesn't scale; but this is a draft
that really specifically needs IESG input before the WG
settles the details.)

     Brian

.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Mar 2005 20:05:32 -0500

-----BEGIN PGP SIGNED MESSAGE-----

  {as an occasional reader of newtrk...}

>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:
    Margaret> I think that the purpose of ISDs is to make it easier for
    Margaret> implementers and users to find pertinent/related documents
    Margaret> and to understand their status.  In fact, I don't think

  True.

    Margaret> that ISDs will decrease the IESG work load, and they might
    Margaret> increase the IESG effort to process a standards track
    Margaret> document -- which may be okay if ISDs have a larger
    Margaret> benefit to the community than the additional WG documents
    Margaret> that the IESG could have processed with the same
    Margaret> resources.

  I think that you are mostly right. The IESG work load/RFC published
may go up. I think that the IESG work load/FS published may go down.
  That may in fact result in an absolute increase in IESG work, but in
more FS published for that effort.

  I think that many PS do not advance to DS/FS because of the high
effort.  As a result, the quality bar of a PS has risen because the next
step is so infrequently done. 

  So, the purpose of the ISD is to make it easier for PS->DS->FS to
occur. This is done by having a "weather report" on a document set.

- -- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 14 Mar 2005 17:07:40 -0500

At 12:48 PM +0100 3/14/05, Eliot Lear wrote:
>You got the tone wrong.

Well, I am doing the best I can, given that you insist on holding 
your meetings when I am unavoidably detained elsewhere!  :-)

>We just want to know if we're going off the rail, and we'd like to 
>know that sooner rather than later.  And if you like ISDs, then it 
>makes sense to have a discussion with the IESG (and IMHO Secretariat 
>and RFC Editor) about what information, and perhaps 

I am not sure whether I like ISDs or not.  I do think that it is a 
serious problem with the RFC series (at least as it is currently 
structured)  that it is so difficult to determine important things 
about IETF standards like:  What is their status? Have they been 
updated or obsoleted? What other documents should I read before I 
implement them? etc.  And, I think that ISDs might resolve that issue.

But, I still don't really understand who is expected to produce ISDs, 
how/when they will be produced, whether they are WG or IETF consensus 
documents, etc.  The ISD draft contains so much passive voice and so 
much legalistic obfuscation that I don't understand what it is 
actually saying.  I have raised this issue before, and it hasn't been 
addressed in the most recent version, as far as I can tell.

I would like to understand the answers to the following questions:

- Who is expected to write the ISD text for a document that doesn't 
fit into an existing one?

- When is that text written and who reviews it?

- Who is expected to maintain that text as the standard changes?

- Will the contents of an ISD (or changes to the contents) by 
reviewed by the WG that produces the standards track document?  By 
the IETF community in a LC process?

There are _many_ verbs included in this document (create, publish, 
populate, define, generate, omit), but there are very few subjects 
included anywhere in the document.

For instance, who is expected to do all of the work outlined in 
section 6, "Transition"?  I agree (as it says in the document) that 
ISDs will be useless without this work, but I think that this 
document is equally useless without some understanding of how all of 
that work will get done.

I wonder if we are seriously underestimating how much work it will 
take to produce ISDs and how long it will take before we have enough 
of them that they are a useful source of information for implementers.

Margaret

.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Mar 2005 15:33:35 +0100

Margaret Wasserman wrote:
> Well, I am doing the best I can, given that you insist on holding your 
> meetings when I am unavoidably detained elsewhere!  :-)
> 
>> and RFC Editor) about what information, and perhaps meta-information, 
>> should be codified in an XSD for ISDs.
> 
> 
> structured)  that it is so difficult to determine important things about 
> IETF standards like:  What is their status? Have they been updated or 
> obsoleted? What other documents should I read before I implement them? 
> etc.  And, I think that ISDs might resolve that issue.
> 
> much legalistic obfuscation that I don't understand what it is actually 
> saying.  I have raised this issue before, and it hasn't been addressed 
> in the most recent version, as far as I can tell.
> 
> - Who is expected to write the ISD text for a document that doesn't fit 
> into an existing one?
> 
> - Will the contents of an ISD (or changes to the contents) by reviewed 
> by the WG that produces the standards track document?  By the IETF 
> community in a LC process?
> 
> For instance, who is expected to do all of the work outlined in section 
> 6, "Transition"?  I agree (as it says in the document) that ISDs will be 
> useless without this work, but I think that this document is equally 
> useless without some understanding of how all of that work will get done.
> 
> I wonder if we are seriously underestimating how much work it will take 
> to produce ISDs and how long it will take before we have enough of them 
> that they are a useful source of information for implementers.

These are good questions. For new or newish technologies, I understand
that the idea is that writing & updating the ISD is simply part of the
WG's job. For older technologies, it's not so clear where we can assign
the work.

Personal opinion: successful ISDs will show that the PS->DS->S progression
is makework. And that's where we save effort. But it is *not*, repeat
*not*, on the cards to increase the IESG workload by introducing ISDs. They
need to lead to an increase in delegation, not to more pressure at the
bottleneck. I'd ask the WG to think carefully about Margaret's questions.

     Brian

.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 15 Mar 2005 19:11:54 +0100

Margaret,

> meetings when I am unavoidably detained elsewhere!  :-)

As I wrote to you personally, I apologize if my message sounded gruff. 
It's perfectly understandable not to have picked up the tone.  It's 
often hard to get that right between the writing and the reading of notes.

> etc.  And, I think that ISDs might resolve that issue.

Ok, so- here we at least agree we have a problem.  This is an excellent 
start ;-)

> in the most recent version, as far as I can tell.

I think that's a writing style thing.  Perhaps it would be good if we 
could prevail on an IESG member (cough) to come to our rescue.

> - Who is expected to write the ISD text for a document that doesn't fit 

  It would seem to me that the standard author and the IESG should agree 
on all normative text within the ISD (and I think John says this), but 
that there might be some additional non-normative informational text 
where a looser standard might apply.
> - When is that text written and who reviews it?

Continuing the model that one doesn't need a WG for every standard, this 
should be the call of the IESG, but generally WG output w/LC.  Perhaps 
the ISD changes are included when a component doc is added/deprecated/...?

> - Who is expected to maintain that text as the standard changes?

I think this falls to the RFC Editor.

> community in a LC process?

Certainly the latter for normative text.  I think ADs should decide 
about the former.

> that they are a useful source of information for implementers.

Good question.  How do we answer it?

Eliot
.

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Mar 2005 12:39:25 -0500

> I would like to understand the answers to the following

These are my opinions; the WG may not agree.  But, since I 
haven't seen a point-by-point response to your questions.
>
> - Who is expected to write the ISD text for a document that
> doesn't fit into an existing one?

For new documents, the WG or author of a non-WG document.  Same 
answer for the new ISD text for documents that do fit into 
existing ones.    Old ones remain an interesting problem.

> - When is that text written and who reviews it?

Written before Last Call.  Reviewed as part of Last Call.  The 
intent is that, for standards-track materials, ISDs get Last 
Called and drag whatever they normatively reference along with 
them.

> - Who is expected to maintain that text as the standard

For the normative text (and anything changing the standard is 
necessarily normative), the WG or document author or 
person/entity proposing the change.

> reviewed by the WG that produces the standards track document?
> By the IETF community in a LC process?

Yes to both.  See above.

There is no question that this will increase workload in the 
WGs, at least until we get used to it.  They will actually have 
to explain the status and context of their documents, rather 
than leaving that to guesswork or AD Last Call and Protocol 
Action writeups (since the ISDs, rather than individual I-Ds, 
are what is last called, I'd expect the AD workload to produce 
those writeups to transition from "write it" to "review what the 
WG has written" -- continuing an AD workload reduction model 
that I understand is already in effect in some areas.   For the 
IESG, I expect the workload increases and decreases to balance 
or work out in favor of the ISD path.  As Brian suggests, this 
may change how we view maturity levels.  Even if it does not, it 
should permit more documents to be advanced by ISD changes 
alone, rather than issuing new RFCs.  Either direction reduces 
load on both the IESG and the RFC Editor.

> There are _many_ verbs included in this document (create,
> publish, populate, define, generate, omit), but there are very
> few subjects included anywhere in the document.
>
> For instance, who is expected to do all of the work outlined
> in section 6, "Transition"?  I agree (as it says in the
> document) that ISDs will be useless without this work, but I
> think that this document is equally useless without some
> understanding of how all of that work will get done.

Two answers: (1) The overworked editor has been waiting for 
community feedback and specific suggestions about this.  At 
least understanding of what is going on and what is required has 
been rising.

> I wonder if we are seriously underestimating how much work it
> will take to produce ISDs and how long it will take before we
> have enough of them that they are a useful source of
> information for implementers.

I don't know any way to know other than to try.

The latest I-D went off for posting before your note hit my 
mailbox.  However, if you have specific chunks of text that you 
consider "so much passive voice and so  much legalistic 
obfuscation" as to obscure meaning, please identify it and I'll 
see what can be done.

Margaret, let me be quite explicit about what, in my opinion, is 
going on here.  The ISD story is intended to provide the 
framework for some fundamental changes in how the ISD develops, 
processes, and publishes standards.   It isn't "fussing a bit 
with the standards track" or "reviewing maturity levels".  It 
is, instead, the framework for restructuring how we think about 
a number of issues.  Those issues including maturity levels, 
issues of errata and revisions, implementation reports, and so 
on -- even, to some degree, the "not all RFCs are standards" 
one.   It is as radical, or more so, than the restructuring on 
the administrative side.  As Dave Crocker and others have 
suggested, _this_ is the important stuff, since it fairly 
directly addresses the critical path issues of quality, 
throughput, being clear about what we are doing, and so on.

Some of the bits of this have been explicitly left to the IESG 
to decide -- I hope in dialog with the WG-- because, unless the 
IESG signs up for this, it is dead. For most of those issues, 
IMO, the alternatives of playing "guess which variation the IESG 
might like" is a foolish waste of time.  My own feeling is that, 
for this to actually happen, the IESG has to engage on it at 
least as much as the IESG has engaged on the admin 
restructuring: if the IESG, or individual ADs, set themselves up 
simply to judge whether or not you like the idea, it is pretty 
hopeless.  So the WG is asking for some extraordinary process, 
although a process that is far less extraordinary than that 
followed on the admin restructuring.  If nothing else, I note 
that this is coming out of a regularly-chartered WG, not out of 
some sequence of semi-closed committees, processes, consultants, 
private negotiations, etc.  Those may have been necessary for 
the admin activities but, personally, I derive some comfort from 
the observation that this is following a more regular path.

best,
    john

.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Mar 2005 11:52:00 +0100

I want to focus on this:

 > IESG signs up for this, it is dead.

That is going to require some real-time process re-engineering
to achieve. The IESG doesn't generally look closely at documents
until they are formally ballotted, and that simply won't work
in this case. The IESG will need to look at this, and its deeper
implications, before getting to the ballot stage.

Here's a challenge: deliver a version that has rough WG consensus,
with one of those dreaded powerpoint presentations that sets out
the basics, the implications, and the open questions, by mid-April.
In that case, we can debate it during the IESG Retreat.

    Brian (AD hat on)

.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 15 Mar 2005 10:52:30 -0500

On Tue March 15 2005 09:33, Brian E Carpenter wrote:

> WG's job.

What about individual (i.e. not WG) submissions?

What is the update mechanism?  Do you really want a half-dozen
WGs (chairs? Editors? Secretaries?) simultaneously editing a
master document?   Or do we need an XXXX Considerations section
in RFCs directing XXXX to update the document?

> is makework.

I couldn't disagree more strongly.  The progression through the
Standards Track levels is supposed to ensure that something that
reaches full Standard status really has had the bugs worked out.
The failure in recent times of that process has been that things
advance to Draft without the requisite two *fully* interoperable
implementations, or to full Standard status after significant
substantive changes from Draft (e.g. RFC 2396 to 3986) without a
reset to Proposed.  I.e. the lack of quality of implementation
(of documents and the technologies they represent) and of the
review process are problems.  Possibly *because* progression is
wrongly viewed as makework.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html