Subject: [newtrk] thoughts from the newtrk WG chair

From: [email-masked] (Scott Bradner)
Date: Tue, 2 Aug 2005 07:33:18 -0400 (EDT)

For reasons I'd rather not go into I was forced to cancel my trip to
Paris at the last minute.  As you have seen by now, Harald, the newtrk
AD when newtrk was formed, has agreed to run the Friday morning newtrk
session.  (I will be listening in on the (quite good so far, at least
when people use the mic) audio and be on the jabber room but the
session is Harald's to run as he sees fit.)

For those of you who wondered why we decided to hold the newtrk session
on Friday morning - it was to maximize the possibility of IESG members
attending the session.  In light of the IESG's message to this list
about the ISD proposal after their retreat a few months ago, we (Brian
(the current newtrk AD) and I) felt that the next step for the newtrk
discussion on ISDs needed to involve as many of the IESG as possible if
it was going to be useful at all.

This message is to take the place of the  "introduction and status" that
I would have given were I going to be there.

I said on the mailing list:
   the Paris newtrk session is going to focus on deciding once and
   for ever the fate of the ISD proposal (in this context I'm using
   "ISD proposal" as a placeholder for the concept of a meta document
   that is used to define an IETF "standard" rather than just what is
   in the ID)

It is my opinion that the newtrk WG reached consensus support for the
basic ideas in the ISD proposal after discussing it in sessions and on
the mailing list.  I think the WG felt that there were a few things that
needed tightening up (like the change history, the XML schema etc) but
supported the basic ideas.

In my mind those ideas are:
1/ a meta document that is *the* definition of an IETF standard
   i.e. the document that people in and out of the IETF would point to
   to indicate a particular standard (for example purchasing agents and
   other standards organizations)

2/ the meta document would point to RFCs and other documents but
   would not necessarily be published as a RFC

3/ the meta document would be last-called in the same way that current
   standards track documents are whenever it changed

4/ standards creators or modifiers (usually working groups but
   sometimes individuals) would be responsible for the creation and
   modification of the meta documents for new or revised standards
   and thus there would be little additional work for the IESG - this
   process might even reduce the IESG workload by continuing
   the movement of responsibilities to WG chairs.

5/ meta documents would not be universal - the more complex
    standards  (e.g. TCP) might take more effort than the return would
   warrant and there might not be anyone interested in making meta
   documents for some of the old but not much used standards

6/ the meta document would include some type of maturity
   description for example, a pointer to interoperability reports and
   a statement of significant usage (the things that currently define
   Draft and Internet Standards)

7/ the meta document provides an anchor for authoritative and
   non-authoritative errata and a mechanism for distinguishing
   between them

There is quite a bit else in the ISD proposal but I consider the above
the principal ideas and the ideas that the WG reached some level of
consensus on. (fwiw - I do not think that Doug's lighter weight proposal
covers all these points)

The ISD proposal authors and I asked the new IETF Chair to have the IESG
discuss the ISD proposal during the IESG retreat in Geneva the end of
April.  Brian's message to the newtrk list was the result of that
discussion.
http://darkwing.uoregon.edu/~llynch/newtrk/msg00999.html

I cannot say that I read the IESG message or follow up messages to the
list from some individual IESG members as being at all positive.  I read
it as the IESG saying that they did not care if the working group had
reached consensus the IESG was just going to say "no" for a number of
reasons, most of which I disagreed with.  (There is a side issue of the
IESG's proper role in evaluating changes to IESG responsibilities that
might result in changes to IESG work processes that was brought up on
the list but I'm not sure that this session is the right place to talk
about that issue.)

Brian has tried to convince me that I misread the IESG and AD responses
and his efforts are the reason that there will be a newtrk session in
Paris discussing the ISD proposal - it does seem to be worth the effort
to hold a face to face discussion to see if any of this can be salvaged.

In preparation for this session I asked some questions on the list:
http://darkwing.uoregon.edu/~llynch/newtrk/msg01115.html
http://darkwing.uoregon.edu/~llynch/newtrk/msg01150.html
The responses to these questions reconfirm my general opinion on the WG
consensus in support of the basic ISD principals.

It is my opinion that the ideas I mention above are important for the
future of the IETF and would go a long way to dealing with some of the
problems brought up in the problem working group (including the mismatch
between our written standards track and our reality) and problems I have
seen when others try to understand our technology. Just to be clear - as
the WG chair I decided to put off the newtrk discussion on the shape and
number of steps in the IETF standards track because I felt (and still
feel) that something along the line of ISDs might just render that issue
moot.

I hope I am being too pessimistic and that Harald will be able to guide
this session to a useful conclusion such that newtrk can move forward
productively.

The newtrk session is also supposed to finalize what will happen to the
de-cruft effort - I trust that Harald will masterfully (and without
co-author bias) lead the WG to figure out what to do.

Thanks for reading this ramble and good luck on Friday

Scott

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Aug 2005 14:56:45 +0200

Dear Newtrk,

> feel) that something along the line of ISDs might just render that

Just to respond to what Scott is saying here,

- his assessment of the sense of the WG is very much like mine.

- Since 2003, I have co-authored drafts that proposed a three-stage 
standards track with working group snapshots, a two-stage standards 
track, and a one-stage standards track. At this point, I really don't 
care what we choose as long as (1) we actually choose something, and 
(2) what we choose, as practiced, is closer to reality than 2026 is to 
2026-as-practiced.

When this effort started out, I was expecting relatively minor tuning 
to 2026. The first draft I worked on was almost entirely written as 
specific edits to 2026. I no longer believe that small changes are 
worth doing - they would certainly not be worth the effort we've spent 
to date.

At this point, I happen to like, very much, the concept of the 
out-of-scope standards review panel proposed in 
draft-klensin-stds-review-panel-00.txt. I don't think that it is the
only way forward, but any way forward the IETF chooses needs to be at 
least as good.

We really need to figure out how to make things better without 
requiring two years in a chartered working group. It may take two 
years to design a protocol; it should not take two years to figure out 
a better way to describe one, or a better way to evaluate one.

In My Opinion. Thanks for listening. See you Friday.

Spencer 

.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 2 Aug 2005 15:44:29 +0200

>    Draft and Internet Standards)

Scott,

These two points should not be the case for the SRD version (ISD  
lite).  Complex information is instead placed into an asynchronous  
Status database.  This Status database could highlight various  
outstanding issues.  Any such issues seen valid long term should  
motivate changing the underlying RFC.  This Status database could be  
used by the IESG to invoke feedback as well.  This should be helpful  
at resolving time sensitive issues, which may involve security, for  
example.  This Status database may offer a description of the  
maturity, which could change, just as interoperability may also  
change over time.  By isolating this information in the Status  
database, this information may remain current without revisiting a  
review of the basic SRD document.  The HASH issue could represent  
such an issue where this type of dynamic Status information would be  
useful, and also how nothing is permanently mature.  As an adjunct to  
the Status database, perhaps a moderated developer's wiki using the  
SRD references may also provide timely "in the field" information not  
found in either the RFC or Status database.

>    non-authoritative errata and a mechanism for distinguishing

This is perhaps the most significant point shared by both ISD and  
SRD.  Attempting to place details not related to this goal into an  
over-arching document will increase the work needed to carry these  
documents along with the modified RFC.  Keeping the SRD document "as  
simple as possible" should permit all currently active RFCs to be  
encompassed by this approach.  Over time, the Status information  
would eventually be created asynchronously.  The difference is  
largely how the SRD divides the ISD document to provide anchors  
separated from mutable information related to current use.  If the  
SRD approach is followed, there should be efforts defining a general  
outline for the Status.  This outline could represent a merger of  
various database table elements to facilitate future modifications.

-Doug

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 03 Aug 2005 14:18:19 +0200

Doug,

if the status database is the thing we need to solve our problems, then we 
should focus on developing the status database.....

I happen to believe that we have some problems that ISD/SRD/ISD-Lite would 
solve, without the need for a database; I'd like to focus on those things 
at this meeting, given that we don't have a worked-out description of the 
"database" concept to evaluate.

--On 2. august 2005 15:44 +0200 Douglas Otis <[email-masked]> wrote:

> These two points should not be the case for the SRD version (ISD  lite).
> Complex information is instead placed into an asynchronous  Status
> database.  This Status database could highlight various  outstanding
> issues.

.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Aug 2005 14:38:13 +0200

Front posting, because I'm on an earlier point in Scott's

>    other standards organizations)

I think the SRD proposal is significantly different on this point too.
While an SRD could be "the document that people ... would point to"
it would not in my view be "*the* definition of an IETF standard."
It would be informational/factual in nature rather than normative,
if I understand the proposal, and that is a key difference from
ISDs (and similar to Larry Masinter's suggestion). The normative
documents would be identical to those we have today.

    Brian

Douglas Otis wrote:
> used by the IESG to invoke feedback as well.  This should be helpful  at 
> resolving time sensitive issues, which may involve security, for  
> example.  This Status database may offer a description of the  maturity, 
> which could change, just as interoperability may also  change over 
> time.  By isolating this information in the Status  database, this 
> information may remain current without revisiting a  review of the basic 
> SRD document.  The HASH issue could represent  such an issue where this 
> type of dynamic Status information would be  useful, and also how 
> nothing is permanently mature.  As an adjunct to  the Status database, 
> perhaps a moderated developer's wiki using the  SRD references may also 
> provide timely "in the field" information not  found in either the RFC 
> or Status database.
> 
> 
> This is perhaps the most significant point shared by both ISD and  SRD.  
> Attempting to place details not related to this goal into an  
> encompassed by this approach.  Over time, the Status information  would 
> eventually be created asynchronously.  The difference is  largely how 
> the SRD divides the ISD document to provide anchors  separated from 
> mutable information related to current use.  If the  SRD approach is 
> followed, there should be efforts defining a general  outline for the 
> Status.  This outline could represent a merger of  various database 
> table elements to facilitate future modifications.
> 
> -Doug
> 
> 
> .

.

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Aug 2005 08:55:52 -0400

> documents would be identical to those we have today.

Brian,

In practice, the experience of most (or all) standards bodies of 
which I am aware has been that, if the standards body publishes 
a  summary or commentary or tutorial of any sort on a standard, 
that is treated as normative by just about everyone. 
Disclaimers that it is not normative are potentially very useful 
in dealing with lawyers (“be careful about picking up this 
coffee cup, it may contain hot liquids that will cause damage if 
poured into your lap”) but will have little substantive effect.

So, if there is a non-normative summary series, the IETF should, 
IMO treat it, with regard to review and approval, the same way a 
normative one would be treated.   Having it published and 
circulated as an IETF document without such review could 
actually make things worse.

     john

.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 3 Aug 2005 15:28:14 +0200

On Aug 3, 2005, at 2:18 PM, Harald Tveit Alvestrand wrote:

> Doug,
>
> if the status database is the thing we need to solve our problems,  
> then we should focus on developing the status database.....
>
> I happen to believe that we have some problems that ISD/SRD/ISD- 
> Lite would solve, without the need for a database; I'd like to  
> focus on those things at this meeting, given that we don't have a  
> worked-out description of the "database" concept to evaluate.
>
>> lite).

I will create a separate draft to describe components of the Status  
database.  This will be a rough attempt and will depend upon a fair  
amount of feed-back, as this would serve the needs of the IESG, IETF,  
developers, administrators, and others.  Ideally, this information  
should be partitioned to suit these different perspectives:

  IESG Notes
  IETF Notes
  Security Alerts
  Developer Considerations
  Administrator Considerations
  Interoperation (Versioning and report URIs)
  Forum URI (mailing list)

-Doug
.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Aug 2005 16:59:34 +0200

John C Klensin wrote:
> In practice, the experience of most (or all) standards bodies of which I 
> am aware has been that, if the standards body publishes a  summary or 
> commentary or tutorial of any sort on a standard, that is treated as 
> normative by just about everyone. Disclaimers that it is not normative 
> are potentially very useful in dealing with lawyers (“be careful about 
> picking up this coffee cup, it may contain hot liquids that will cause 
> damage if poured into your lap”) but will have little substantive effect.

Undoubtedly true, exactly like the effect of RFC 1796.

> So, if there is a non-normative summary series, the IETF should, IMO 
> treat it, with regard to review and approval, the same way a normative 
> one would be treated.   Having it published and circulated as an IETF 
> document without such review could actually make things worse.

In the sense that it should be independently reviewed, yes,
but I'm not sure that formal approval would be needed.

    Brian

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 10 Aug 2005 16:52:14 +0200

> but I'm not sure that formal approval would be needed.

I can't quite wrap my head around the idea of an independent review that 
has no conclusion..... either the review concludes that it's good enough, 
or it concludes that it is not good enough.
I can't tell the difference between such a conclusion (documented) and 
formal approval.

I think.

.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Aug 2005 11:37:02 +0200

Harald Tveit Alvestrand wrote:
> has no conclusion..... either the review concludes that it's good 
> enough, or it concludes that it is not good enough.

Well, we already have the rather curious construct that we publish
interop reports uncritically, and then decide to promote a PS formally
to DS as a result. I guess I'm arguing for less discordant, drawing
a distinction between

    The IESG has approved draft-foobar as an IETF Standard (STD 173)

and

    The IESG has reviewed the interoperability report for STD 173.

which doesn't imply judgement. And in this model, the two actions
are completely orthogonal.

     Brian

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 11 Aug 2005 12:21:10 +0200

> are completely orthogonal.

Ah - THAT sense of review. I was thinking about "summary series".

In that sense, I'd make a distinction between:

- Review of material to see if action can be taken on that basis (which we 
certainly do with interoperability reports)
- Review of material to see if the material passes the bars set for a 
certain publication series (RFCs, and, IMHO, overview documents)

The distinction might be between "looking at" and "pushing back on" - for 
the overview documents envisaged here, I think they should definitely be in 
the second category.

                       Harald

.