Subject: [newtrk] I-D ACTION:draft-ietf-newtrk-interop-reports-00.txt

From: [email-masked]
Date: Wed, 12 Oct 2005 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the New IETF Standards Track Discussion Working Group of the IETF.

	Title		: Formalizing IETF Interoperability Reporting
	Author(s)	: L. Masinter
	Filename	: draft-ietf-newtrk-interop-reports-00.txt
	Pages		: 8
	Date		: 2005-10-12
	
   This document suggests another way of reforming IETF standards
   process by formalizing the mechanism for interoperability reporting,
   as a way of facilitating standards development.  It establishes two
   kinds of reports: a 'Protocol Feature Set', which lays out the set of
   features from IETF specifications that constitute a protocol, and a
   'Protocol Implementation Report', which is submitted by an individual
   or group to report on implementation and interoperability testing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-newtrk-interop-reports-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-newtrk-interop-reports-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-newtrk-interop-reports-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 12 Oct 2005 13:46:35 -0700

Regarding the comparison with ISD and SRD in section 10, the levels  
of efforts required for an SRD would be minimal when compared to  
either an ISD or Interop report.  An SRD process would not greatly  
overlap an Interop report, and may reduce efforts needed to  
consolidate related RFCs within these types of documents.  By  
separating efforts expended consolidating RFCs with a stable  
reference, from that of Interop reporting, these documents will be  
better maintained.  An Interop report could capture a snapshot of  
related RFCs by including the SRD serial number when referencing the  
related SRD(s).  It would also be possible to reference the Interop  
report within the SRD as well.  This could be done by sharing a  
common reference name, or publishing the interop report as an RFC.

While an SRD process should not make an Interop report redundant, an  
ISD may.

-Doug

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

---

From: Larry Masinter <[email-masked]>
Date: Thu, 13 Oct 2005 22:06:44 -0700

> While an SRD process should not make an Interop report redundant, an  

I'm not sure I understand the reasoning here. If you look at the draft,
you see that it proposes two kinds of documents, not a single
"Interop report". In fact, as written, there isn't really a single
document -- except what can be automatically constructed -- that
would correspond to what we have today with summary "Interop reports".

A simple Protocol Feature Set is a list of RFCs -- each RFC is a
'feature'. If that's sufficient granularity for everyone, then you
have something that's easy to write.  So a Protocol Feature Set
*could* be as easy to write as a SRD, and would be about as
useful.

The Protocol Implementation Reports contain information that
isn't contained in SRDs or ISDs, so I don't see how a ISD
might make "inteorperability reporting" redundant, if that's
what you meant.

Larry

.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 13 Oct 2005 23:12:58 -0700

> *could* be as easy to write as a SRD, and would be about as

I expect SRDs would have a different granularity than that of a  
feature list for an application.  Such a feature list would likely  
include a larger number of RFCs than that of an SRD.  A Interop  
report could reference a list of SRDs while describing the underlying  
features.

> might make "inteorperability reporting" redundant, if that's

The ISD, as I understood the intent, would comprise similar  
information.  However, SRDs could be components for establishing  
stable definitions for an Interop report.  SRDs could also apply when  
not related to a feature an application.

-Doug 
.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Oct 2005 15:44:24 +0200

My thoughts on this draft (AD hat off).

1. I think the notion of defining what an interop report
looks like is excellent. The implementation reports at
http://www.ietf.org/IESG/implementation.html
are a very mixed bag.

2. You don't tackle one of the thorny problems - how to
handle "single ended" specifications such as MIBs, which don't
in themselves define protocol exchanges. There is some case law
on this (Bert Wijnen can advise from MIB experience). A PFS
will look different in this case.

3. I like the idea of publishing the Protocol Feature Set
orthogonally to the interop reports. This would make it much
easier to interpret the second paragraph of section 4.1.2
or RFC 2026, or whatever eventually replaces it.

4. Note the 2026 has been interpreted as requiring a single
implementation report. This proposal would require a set
(minimum two) of individual implementation reports to make
sense. That's OK; but it needs to be noted.

5. I think you should say in section 6 that the secretariat
will post implementation reports without any evaluation
(in contrast to PFS documents which require approval).

    Brian

.

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 18 Oct 2005 21:52:18 -0700 (PDT)

> My thoughts on this draft (AD hat off).
...
> will look different in this case.

It seems to me that the compliance statement(s) associated with
a MIB module (or a set of MIB modules) already provide(s) the
information required for a PFS.  Typical MIB module implementation
reports are structured around the objects groups (and in some
cases individual objects) mentioned in a compliance statement.

See also RFC 2438.

//cmh

.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Oct 2005 10:37:00 +0200

> cases individual objects) mentioned in a compliance statement.

Yes, indeed, and the PFS proposal needs to cater for this and any
other specifications with a similar nature.
> See also RFC 2438.

Thanks. I knew it was written up somewhere.

     Brian

.

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Oct 2005 09:42:39 -0400

--On Thursday, 13 October, 2005 23:12 -0700 Douglas Otis
<[email-masked]> wrote:

> information.  However, SRDs could be components for
> establishing  stable definitions for an Interop report.  SRDs
> could also apply when  not related to a feature an application.

Doug,

I have to agree with Larry.  There is nothing inherent in the
ISD proposal that requires that it contain either more or less
information, or a different granularity, etc., from SRDs.
Indeed, since ISDs are intended to be the normative definition
of what a particular standard constitutes, it would be as, or
more, natural for them to specify "stable definitions for an
Interop report" or components thereof, than for an SRD.

As I understand things, there were, when you proposed SRDs, only
two key differences between the ISD concept and the SRD one:

	(i) As mentioned above, ISDs are explicitly normative,
	to the point that they become the formal definition of
	the standard, are the real subject of IETF Last Calls
	with RFCs being included in the last call as normatively
	cited supporting documents.  SRDs, as I understand them,
	do not have that property.
	
	(ii) Largely because they have that normative property,
	ISDs must contain at least some text, and normative text
	at that, explaining what they are about.  They cannot be
	just list of things that go together, providing
	informative cross-references among those things.  When
	the SRD concept was first floated, I understood SRDs as
	potentially being links-only, with no local substantive
	text.  As of the time the WG meeting in Paris ended, I
	understood that SRDs had evolved to potentially contain
	some local text and possibly even to require some.  So
	there may be little substantive difference between the
	two proposals along that text versus no-text dimension
	any more.

While I fear the risk that formalizing implementation reports
may plunge us into either more bureaucracy or a situation in
which we try to remove the judgment from standards approvals and
turn it into an entirely mechanical process, a good and workable
implementation report model would, I believe, complement SRDs or
ISDs equally.

      john

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 19 Oct 2005 09:31:28 -0500

> two proposals along that text versus no-text dimension

FWIW, this is what I remember from the Paris timeframe discussions as well.

> implementation report model would, I believe, complement SRDs or

<the hole before you is full of rats, enter at own risk>

I share John's concern that we need a lot of things, but more bureaucracy 
isn't any of those things. It seems to me that the level of approval/vetting 
that we choose will have a lot to do with the amount of bureaucracy we 
create, so let me point to a current topic of interest, at least to me:

As Gen-ART reviewer, I reviewed two documents recently, the PIM-SM protocol 
specification 
(http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-11.txt), and a 
draft describing the level of interop testing (since interop testing is 
required for routing protocols under RFC 1264, which says (in Section 3.0),

 5) There must be evidence that all features of the protocol have
    been tested, running between at least two implementations.  This
    must include that all of the security features have been
    demonstrated to operate, and that the mechanisms defined in the
    protocol actually provide the intended protection.

The interop testing summary is in draft-ietf-pim-proposed-req-01.txt, which 
names three implementations in
section 2.5 (Evidence of testing), and the statements for Cisco and Procket 
say

 Cisco

    The Cisco implementation has undergone extensive laboratory
    testing as well as testing in production deployments. It is found
    to interoperate with implementations of earlier versions of the
    PIM Sparse-Mode protocol specification.

 Procket Networks

    The Procket Networks implementation was deployed in many research
    and service provider networks and showed interoperability with new
    and old Cisco Systems implementations as well as Juniper Networks
    implementations.

I have a question into the ADs about whether this is sufficient to satisfy 
RFC 1264, but if we decide that it is sufficient, I believe that our level 
of vetting/approval can be fairly low, and still be very useful.

My Gen-ART review is available at 
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-pim-proposed-req-01-dawkins.txt

Thanks,

Spencer 

.

---

From: John Leslie <[email-masked]>
Date: Wed, 19 Oct 2005 11:56:12 -0400

> information, or a different granularity, etc., from SRDs.

   I hesitate to comment on ISDs -- I'm not sure we're all talking
about the same thing.

   However, I'm happy to talk about SRDs.

>     do not have that property.

   SRDs are not normative, IMHO. They describe sets of RFCs, of
which each RFC may or may not be normative. If this is not clear
in the draft

http://www.ietf.org/internet-drafts/draft-otis-newtrk-rfc-set-02.txt

feel free to propose text to make it clearer.

>      some local text and possibly even to require some. 

   Admittedly, I was not _in_ Paris, but I was following the audio.
I do not recall anything about requiring text, least of all any
normative text, in SRDs.

   The current I-D makes it clear that <srdref> is an empty element,
which _cannot_ contain text. I suppose it could be argued that the
<core>, <extensions>, <guidance>, <replaces>, <experimental>, and 
<companion> sections could contain text, although that is not the
intent.

   The only free-format sections are intended to be <title> and 
<description>. <title> is intended for searching, and <description>
is intended merely to describe the set, not its members.

> So there may be little substantive difference between the two
> proposals along that text versus no-text dimension any more.

   IMHO, SRDs do not contain any normative text. I accept John 
Klensin's opinion that ISDs _must_ contain normative text. I think
this difference remains unchanged.

--
John Leslie <[email-masked]>
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Oct 2005 12:17:39 -0700

> information, or a different granularity, etc., from SRDs.

ISDs will accumulate a fair amount of luggage per the proposal:
---
The documents proposed here will allow more flexibility by permitting  
the IESG to attach appropriate qualifying notes as needed. ...  These  
(ISD) documents, and documents authoritatively (normatively)  
referenced from them, will become, essentially, the definitions of  
standards. ...  Advancement of a document on the standards track,  
publication of _applicability_ statements, notes on errata or _other_  
issues of sufficient and substantive importance to require alerting  
implementers or the community will also result in modifications to  
the relevant ISD document. ... Because the ISD document is expected  
to contain prose, it will be possible to deal with the long-standing  
issues of what "updates" means by identifying the relevant sections  
or concepts. ... While RFCs are permanent, ISD documents are expected  
to evolve and incorporate changes over time.  However, they are also  
expected to include explicit change histories in order to make it  
possible for a reader to examine a current ISD document and determine  
the status of the relevant standard at any particular previous time. ...
---

ISDs are not limited to just defining the RFCs related to an  
endeavour.  The ISD over-ride normative information contained within  
an RFC.  Why bother to update the RFC _and_ the ISD.  Just updating  
the ISD would be easier.  I see ISDs eroding motivation and oversight  
given RFCs.  Just as with the lag experienced with RFC designations,  
ISDs may suffer from the same type of delay, as a complex document  
will take time and a fair amount of energy to process.  An ISD is not  
simple and is sure to grow in complexity.  An SRD is extremely  
limited in comparison.

> Interop report" or components thereof, than for an SRD.

ISDs may supplant RFCs rather than enhance a categorization process.   
An SRD only offers the set of RFC as anything that I consider  
normative. The SRD can not over-ride content within an RFC, nor is it  
required that the RFC be within any category.  For example, SRDs can  
also track Internet-Drafts as well.  It would be rather trivial to  
require that a WIP-SRD be included with any Internet-Draft submitted  
to the IESG, which should keep RFCs and SRDs fully synchronized.   
SRDs could be generated in minutes using a simple web-page entry  
form.  I do not think ISD synchronization is practical.  ISDs are  
just as likely to create instability when RFCs and ISDs diverge.

>     do not have that property.

Rather than using the Internet-draft process as used when submitting  
an ISD, the SRD is intended to represent a minimalist effort at  
describing RFCs related to some endeavour.  There are two versions of  
the SRD.  One version represents "work-in-progress" where associated  
I-Ds may be included.  The SRD & the I-D would be submitted together  
to ensure synchronization and where the SRD would also assist the  
IESG and the RFC editor to understand the impact created by the I-D.   
I would expect the approved SRD and I-D last-call process would be  
merged as well.  Think of the SRD as a cover-page for an I-D.

>     two proposals along that text versus no-text dimension

No, SRDs do not contain normative text related to the endeavour.  The  
only text, as John pointed out, would be the title and a simple  
description of the set.

With respect to offering topical information, I envision the SRD  
reference would serve as a link into a database maintained in some  
fashion by the IESG as a repository for security alerts and the  
like.  An Interop report could be linked within the SRD, or be  
referenced by way of the SRD reference itself.  Either way,  there  
would be NO normative text included within the SRD.  The only thing  
normative about the SRD would be which documents are within the set.

> implementation report model would, I believe, complement SRDs or

Any stable reference for reports and status would be desirable.  I  
see SRDs as being a safer and more comprehensive approach toward  
achieving that goal without adding to the workload.  SRDs should help  
reduce the workload with respect to the efforts required of the  
"bureaucracy."  I think it would also reduce my workload when  
attempting to keep track of the changes being made.  : )

For examples of an SRD see:
http://www.sonic.net/~dougotis/newtrk/

-Doug

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2005 11:19:36 +0200

--On 19. oktober 2005 11:56 -0400 John Leslie <[email-masked]> wrote:

> which each RFC may or may not be normative.

I think this illustrates a point nicely.... the word "normative" alone is 
not meaningful (although its meaning can often be inferred from context).

>From the SRD draft:

>    The intent of this document is
>    to provide an optimal means for locating relevant information made
>    increasingly difficult by a growing number or RFCs, updates, and
>    corrections.

Now, if the SRD is approved by the IESG and published by the IETF, it is 
normative in the sense that "this is what the IETF says about what the 
relevant information is on this particular topic".

IETF stuff doesn't *get* more normative than that.

On the text question.... I continue to argue that if we do not allow text 
tied to the individual elements, we'll regret it. I'm fine with (for at 
least the first, experimental round) saying that the normal case is "text 
not expected".

My opinion.

                 Harald

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Oct 2005 07:01:43 -0700

> least the first, experimental round) saying that the normal case is "text 

I would rather have in the HTML output, the SRD name being a link into a
database similar to an errata, or an HTML page published in a defined
directory.  For example, the link could be to: 

http://www.ietf.org/srd-notes/notes-posting.0.html

Keeping the SRD as clean as possible ensures there is less effort needed
to maintain and update these documents.  The name itself can serve as an
entry point into more elaborate material.

-Doug

.

---

From: John Leslie <[email-masked]>
Date: Thu, 20 Oct 2005 12:56:03 -0400

Harald Tveit Alvestrand <[email-masked]> wrote:
> I think this illustrates a point nicely.... the word "normative" alone
> is not meaningful (although its meaning can often be inferred from
> context).

   I quite agree: "normative" is a dreadful word; and I'd rather avoid
it.

> Now, if the SRD is approved by the IESG and published by the IETF, it
> is normative in the sense that "this is what the IETF says about what
> the relevant information is on this particular topic".

   But that doesn't mean nearly as much as you suggest it means.

   Firstly, at most it's a statement of opinion on a particular date.
Secondly, it conveys no intent that other RFCs are _not_ relevant.

> IETF stuff doesn't *get* more normative than that.

   Again, "normative" is a dreadful word.

   But I must disagree with Harald: standards track documents can get
quite a bit "more normative" than that.

   (Perhaps we'd be better off dropping the use of "normative"?

> On the text question.... I continue to argue that if we do not allow
> text tied to the individual elements, we'll regret it.

   Could you give some examples of where we'd need text?

> I'm fine with (for at least the first, experimental round) saying that
> the normal case is "text not expected".

   Clearly, whatever the initial proposal may say, we can later extend
SRDs to include structured text.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2005 19:35:41 +0200

>    Could you give some examples of where we'd need text?

I have on my TODO list to redo my MIXER sample ISD as an SRD.
RFC 2163, distributing MIXER mappings using the DNS, is a Proposed 
Standard, and it's strongly related to MIXER. But as far as I know, it's 
been ignored even by most of the small community that cared about MIXER; 
I'd like to list it under "extensions", but say "not worth doing".

               Harald

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Oct 2005 12:17:11 -0700

On Oct 20, 2005, at 10:35 AM, Harald Tveit Alvestrand wrote:

> Standard, and it's strongly related to MIXER. But as far as I know,  
> it's been ignored even by most of the small community that cared  
> about MIXER; I'd like to list it under "extensions", but say "not  
> worth doing".

I agree that there is a need for this type of information, however an  
opinion or correction with respect to a specific RFC should not be  
placed directly within the SRD.  I would rather see the SRD title  
become a link to a specific wiki page referenced using the SRD name  
where vetted opinion's are expressed.  The intent was to allow the  
author of the SRD to remain nameless as no information is expressed  
other than an organization of documents.  It should be easier to  
reach consensus on the categorization of RFCs related to an endeavour  
and still provide significant value without burdening the process by  
adding opinions or various stipulations.

The introduction of opinions, various stipulations, or corrections  
drastically changes the nature of such a document that was intended  
to remain lightweight in order to establish the inclusion of SRDs as  
part of an I-D submittal requiring IESG review.  Even when an opinion  
is dropped in a subsequent version, this could cause great  
consternation and slow the process.  Just as there should be opinions  
that state that an experimental draft demonstrated below  
expectations, or which options are used in various applications,  
there should also be topical notes that indicate when various related  
applications have a discovered security flaw.

It may be appropriate that this information be reflected in  
subsequent versions of RFCs, but attempting to carry that information  
in the SRD will greatly reduce the document's utility at assisting  
IESG in the review process.  Instead, it would add to their burden.   
I would rather that you assume that you will have your say on linked  
wiki page, where you also date this opinion and provide your contact  
information.  Would that be enough?

There is also a citation library that is not part of the SRD, but  
used by the xslt script.

The part of the rfc2629 dtd used for the reference elements is as  
follows:

<!ELEMENT reference   (front,seriesInfo*,format*,annotation*)>
<!ATTLIST reference
           anchor      ID                 #IMPLIED
           target      %URI;              #IMPLIED>

IETF could consider administering that citation library related to I- 
Ds and RFCs and perhaps SRDs, where items could be added as elements  
within these xml citations.  Perhaps a link could be added as a  
target attribute within the reference element when there is errata  
pending (reference/@target).  I do not think this attribute is  
currently used.  There is also an annotation element that could be  
used to store notes related to the document, independent of the  
endeavour of course. From that perspective, this information is not  
included within the SRD, but is within the citation library.  The  
IETF should control this library as it is extensively used today  
creating I-D and RFC citations.  The examples created by the SRD xslt  
uses a small portion of the information contained within these  
citation elements.

-Doug
.

---

From: John C Klensin <[email-masked]>
Date: Thu, 20 Oct 2005 15:46:09 -0400

I continue to have trouble figuring out any other inherent
difference between ISDs and SRDs besides an issue that now
hinges around a word that no one seem to like.  Because of that,
let me restate things without that word.   Then I'm going to go
back to lurking because I believe that the IESG (via comments on
this list and in Paris and Minneapolis) and the IETF Chair (via
the creation of the PESCI effort) have told us that real
proposals for standards-track changes via the Newtrk WG are
irrelevant.

The ISD proposal was, and is, intended to make a fundamental
change to way in which we consider, review, and publish
standards, or if one prefers, standards-track documents.  Under
that model, Last Calls occur on ISDs, IETF publication is of
ISDs, and the ISDs are the standards.  RFCs become nothing more
or less than technical specifications that are referenced from
ISDs to define the specific details of those standards.  In
principle, ISDs can also reference non-RFC documents as part of
the definition of standards.  ISDs change, RFCs do not.   In
that respect, the ISD proposal was intended to respond to the
very fundamental set of questions that John Loughney wrote up,
and that he and many others have raised, about what is and is
not a standard, what is or is not required to implement a
standard, and how one refers compactly and precisely to
standards. 

As part of that change, ISDs are intended to provide an
optional/ alternative mechanism to deal with the portions of the
"Applicability Statement" and "recommendation level" mechanisms
that we have used very little, probably too little, in recent
years.  As one example, they would provide an easy way to record
and state an IETF consensus position that, to use Harald's
recent example, one just shouldn't bother with some component of
what would otherwise be an element of a standard.

That fundamental change permits evolving the existing
three-stage --really three-category-- standards track with a
model that permits much finer and more adaptable system of
descriptions than the simplistic ordinal set of categories and
to do so without generating more RFCs as an end in themselves.
It is precisely that change which, IMO, puts it on-topic for
newtrk.  It is not clear to me that any proposal to generate new
supplemental documents with no direct standards effect are on
topic for newtrk, but I'll leave most of that argument to others.

One can agree or not with that model of how to "fix" the
standards track.   I find it remarkable that we have had very
little discussion on the model itself, especially recently.
What discussion we have had seems to have been, at least in my
impression, largely supportive.

In addition, there have been lots of discussions about details
that, whether they appear in various documents as examples or
not, are mostly irrelevant to that fundamental model and
decision.  As I have said many times, I (and John L.) put a
number of details into the ISD documents, and Harald, Scott, and
I put a number of details into examples, just to provide a
foundation for discussion.  In particular, none of the following
are important to the ISD concept:

	* The formats of those example details
	
	* Whether representation is in XML, HTML, plain text,
	ISO Standard PDL, or something else is not important
	(except insofar as having the documents be the
	fundamental representation/definition of what is
	standardized requires a level of stability that might
	not be consistent with some formats or representations.
	
	* Whether errata are included, referenced, or not
	touched at all
	
	* Whether a distinction is made between errata that are
	formally approved within an IETF consensus process and
	errata that are not and, if so, what the consensus
	process for the approval might be.
	
	* Whether particular types of text are best included in
	the ISD or referenced to some other repository.

	* Whether is is appropriate to reference documents that
	are not part of the standard (whatever that means) as
	useful ancillary information and, hence, whether it is
	appropriate to reference the same document in more than
	one ISD.  I personally consider this one a no-brainer,
	but others may disagree.
	
	* Whether ISDs have titles, numbers, abstracts, formal
	authors, or a number of other structural arrangements.

	* How the sections of ISDs are ordered

	* Whether we try to produce ISD skeletons for existing
	standards or just leave those standards alone until
	someone gets motivated on a case by case basis.  If we
	do try to produce those skeletons, whether we try to do
	it automatically and accept whatever the automatic
	process produces or, at the other extreme, whether we
	try to organize teams to do protocol archeology,
	describe what they find, and subject their results to
	IETF Last Call.
	
	* And so on, for a fairly long list.

Now, to me, Newtrk has one critical question here if, indeed, it
has any further utility as a WG at all (other than approval of
the decruft stuff).  That critical question is whether we want
to see a new document or metadocument series that has the
"defining what is a standard" property.  Once that question is
answered, I think we (and the relevant AD) need to sort out
whether we have any real agenda left and, if so, a way to answer
the sorts of format and organizational questions identified
above and about whatever other superficial differences exist
between SRDs and ISDs.  

Speaking personally, if we embark on that effort, I don't care
what the critters are called nor do I care which documents are
used as a base/ starting point.  Actually, I have a slight
preference for starting from the SRD documents (again,
independent of what things are called), since Doug seems to have
more time and patience for this enterprise than I do right now.

regards,
    john

.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Oct 2005 14:02:52 -0700

> more time and patience for this enterprise than I do right now.

In the previous message I may have spoken too strongly when saying  
what should _not_ be within an SRD. The goal of establishing a stable  
reference for various endeavours would be the same for both the ISD  
and SRD.  In that sense, there is no difference between ISD and SRD.   
The term SRD was really to allow a distinction between two very  
similar approaches.  I may have stated my opinion with respect to how  
an SRD is different from an ISD rather emphatically, where of course  
the group must make these decisions.  Nevertheless, I still feel  
strongly about it.

Currently there are no provisions within the SRD that supports text  
to permit the inclusions of opinions or stipulations regarding RFCs  
and I-Ds.  This aspect represents a _significant_ departure from the  
ISD.  It is not just a matter of permitting the insertion of a text  
field, in my view.  Allowing opinions or stipulations would require  
the names of those involved who expressed the opinions or  
stipulations as is found within the ISD.

Not having a name associated with an SRD document removes any  
hesitation when modifying an existing SRD in order to document where  
a new I-D fits within the endeavour.  As currently defined, any SRD  
should be able to easily fit onto a single page, and could act as a  
simple cover page for a submitted I-D.  Adding opinions and  
stipulations along with associated names to the document will greatly  
increase the review process aimed at achieving essentially a stable  
references.  Once a stable reference is achieved, adding topical  
information can be consolidated into one location.  If a gap emerges  
between the maintenance of ISDs, which could easily become rather  
large and complex, with respect to new RFCs, an ISD references will  
offer much less value.  Allowing modifications to RFCs by way of the  
ISD will cause reticence when making subsequent changes, especially  
when new changes are included or perhaps deleted.  In my view, the  
SRD would have a very low profile to ensure establishing the RFC  
relationships will not burden the process.  However, this has not  
been a decision made by the WG.

There was a discussion about the idea of adding text to the SRD at  
the last meeting where a few expressed the desire to no allow such  
text.  Adding such text would significantly add to the information  
that would also need to be incorporated within the SRD as a means to  
substantiate the text.  I still see the SRD as a cover page for I-Ds,  
that become approved when the I-D is accepted.  The end result is  
simply a stable reference.  Let the stable reference act as a means  
to consolidate where ancillary information is located.

-Doug 
.

---

From: John C Klensin <[email-masked]>
Date: Thu, 20 Oct 2005 18:45:26 -0400

Doug,

Thanks for engaging on what I consider to be the substantive
questions.  Whether we end up agreeing or not, or convincing
anyone else or not, it seems to me that this is how to move
forward.

Comments below...

--On Thursday, 20 October, 2005 14:02 -0700 Douglas Otis
<[email-masked]> wrote:

>> independent of what things are called), since Doug seems to
>> have more time and patience for this enterprise than I do
>> right now.
>...
> Currently there are no provisions within the SRD that supports
> text  to permit the inclusions of opinions or stipulations
> regarding RFCs  and I-Ds.  This aspect represents a
> _significant_ departure from the  ISD.  It is not just a
> matter of permitting the insertion of a text  field, in my
> view.  Allowing opinions or stipulations would require  the
> names of those involved who expressed the opinions or

We probably agree on this, although I'd not certain that
individual names are critical.  Again, the key feature of ISDs
is that they represent IETF consensus documents -- the standards
themselves.  We agree that is a significant departure from SRDs.
Whether the name given is that of an author of specific text,
the editor of that text, the IESG, or the IETF as a whole is, I
believe, of much less importance.

Whether, in addition to that formal definition-of-the-standard
text, the ISDs also contains "opinions" is on my list of things
that don't make any real difference, even though I understand (I
think) your motivations for keeping them out of SRDs.
> hesitation when modifying an existing SRD in order to document
> where  a new I-D fits within the endeavour.  As currently
> defined, any SRD  should be able to easily fit onto a single
> page, and could act as a  simple cover page for a submitted
> I-D.  Adding opinions and  stipulations along with associated
> names to the document will greatly  increase the review
> process aimed at achieving essentially a stable  references.
> Once a stable reference is achieved, adding topical
> information can be consolidated into one location.  If a gap
> emerges  between the maintenance of ISDs, which could easily
> become rather  large and complex, with respect to new RFCs, an
> ISD references will  offer much less value.

To the extent to which, for new or updated documents at least,
the ISDs _are_ the standard and modifications to the standard
cannot be last-called without it, there is no plausible way for
such a gap to develop.   Of course, imposition of  that
requirement could either slow down or speed up document
processing: there are plausible opinions on both sides of that
issue.

>  Allowing
> modifications to RFCs by way of the  ISD will cause reticence
> when making subsequent changes, especially  when new changes
> are included or perhaps deleted.  

Here, we disagree, perhaps based on different experiences
getting documents through the IETF, attempting to manage WGs,
and seeing how the IESG functions from both the inside and
outside.  I would contend that there is already "reticence" to
initiate revisions of RFCs for other than major issues: there is
a large amount of work involved, a very-high-threshold approval
process, and so on.  

> In my view, the  SRD would
> have a very low profile to ensure establishing the RFC
> relationships will not burden the process.  However, this has
> not  been a decision made by the WG.

Just my opinion but the difficulty that arises, and the point at
which that nasty word "normative" applies, is that the mere
decision about what documents go together and which ones do not
is either a substantive action of some importance or it is a
personal opinion of some author or group of authors.   If is is
a substantive action, then it needs, IMO, IESG review and Last
Call about the decision itself, whether there is non-link text
in the SRD or not and we are well out onto the slippery slope
toward ISDs.  If it is a personal opinion, then your
observations above about named authors would seem to apply.  It
may be my lack of imagination, but I don't see how one can have
it both ways.
 
> There was a discussion about the idea of adding text to the
> SRD at  the last meeting where a few expressed the desire to
> no allow such  text.  Adding such text would significantly add
> to the information  that would also need to be incorporated
> within the SRD as a means to  substantiate the text.

I agree, although my impression is consistent with Spencer's
that there was considerable support to that idea in Paris.

>  I still
> see the SRD as a cover page for I-Ds,  that become approved
> when the I-D is accepted.  The end result is  simply a stable
> reference.  Let the stable reference act as a means  to
> consolidate where ancillary information is located.

If it were really a "cover page of I-Ds", then why not
incorporate it into the I-D and be done with it?  That would
require no procedural changes at all.   If a group of I-Ds went
together, why not produce an extra one that was just a
collection of pointers to the others, plus the usual
boilerplate, then ask the IESG to process the lot together.
That, it would seem to me, would make an easy experiment to gain
experience with that particular view of things, again requiring
no WG action or procedural changes.

And, if all we need is a stable reference with no standards
status, then perhaps we should be eating our own dogfood and
inventing an appropriate URN namespace.

      john

.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 20 Oct 2005 17:51:01 -0700

I didn't intend the proposal for Protocol Feature Sets
to be a complement to ISDs or SRDs, but rather 
an alternative. Please consider this possibility.

A Protocol Feature Set could serve as a stable reference
for describing what was or wasn't implemented, and what
documents go together in order to be an "implementation".
Not only that, but it has additional information that
is not currently in the ISD or SRD proposals but important
for claiming compliance; specifically the "roles".

Since the criteria for progression along standards track
seems to be a matter of implementation, interoperability
and deployment, we could best change standards track
by being clearer about the judgments being made.

Merely changing the nature of the documents (approving
ISDs instead of RFCs) without any additional or different
substance doesn't help enough in making "standards track"
more useful.

Larry

.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Oct 2005 18:00:53 -0700

> processing: there are plausible opinions on both sides of that

Increasing the number of steps in front of those making changes will  
not improve upon the state of the documentation.  Avenues may be used  
that impose fewer steps.  It would be a poor outcome for RFCs to  
devolve into disembodied documents to avoid an onerous association  
with an ISD.  Conversely would the depreciated WG RFC draft process  
be avoided for the ISD draft process?  Ending up with many  
disassociated documents or massive all encompassing documents will  
not make change easier, nor will it make the review process easier.   
This is a problem we all face, and not just the IESG.  It seems  
better to breakdown the effort into smaller pieces, as it exists  
today.  The component that is missing is the cover page that ties  
them together.

> a large amount of work involved, a very-high-threshold approval

I agree.  Something that looks more like wiki page for the various  
endeavours would be helpful.  Think of this as a community appraisal  
mechanism that offers lower thresholds for participation than that of  
an RFC.  When people get frustrated looking at too many corrections  
and stipulations, this may provide both motivation and guidance to  
those that are likely not the originator of the initial documents.   
Lowering the thresholds in general will introduce a greater amount of  
documentation.  The goal would then be to clarify what documents  
offer value.  I suspect that the community could offer such opinions,  
if there was an available mechanism.  The SRD offers a way to  
consolidate this information with stable references.  In my view, the  
SRD should not carry the information, as this information could be  
ephemeral.  The SRD should simply serve as a reference for where to  
find such added information.

There is the annotation element within the reference element that  
could allow information to be posted with the SRD.  The information  
accumulated within the annotation element would be a separate process  
from that of the SRD itself.

> personal opinion of some author or group of authors.

It could be either way.  I see a large number of SRDs only used to  
keep track of ongoing work by various WGs.  Every member of the WG  
could publish their own view of how things go together.

> If is is a substantive action, then it needs, IMO, IESG review and  
> Last Call about the decision itself, whether there is non-link text  
> toward ISDs.

I think that the Last Call of the related I-D should include the SRD  
as the "cover-page."  This "cover page" could reference several  
outstanding I-Ds and more than one SRD could reference the I-D.  When  
an I-D becomes approved along with its "cover-page(s)", then the base  
SRD is updated where the RFC reference replaces the I-D reference.   
Any outstanding I-Ds would remain in the WIP-SRD that would have a  
zeroed iteration-number, but an increased base SRD serial-number.

>   If it is a personal opinion, then your observations above about  
> named authors would seem to apply.  It may be my lack of  
> imagination, but I don't see how one can have it both ways.

Retaining a minimalistic approach where I-D synchronicity can be  
assured, the event of the I-D approval serves as this reference.   
Previous SRDs should remain and made available to allow an  
investigation of the history of the document and to indicate who was  
involved when questions arise.  A simple log of the I-D/SRD process  
provides all the needed information.

>> I still see the SRD as a cover page for I-Ds,  that become  
>> approved when the I-D is accepted.  The end result is  simply a  
>> stable reference.  Let the stable reference act as a means to  
> If it were really a "cover page of I-Ds", then why not incorporate  
> it into the I-D and be done with it? That would require no  
> procedural changes at all.

I put together a more complex WIP-SRD example of the ongoing effort  
related to SCTP.  From this example, it should be more obvious why a  
separate document is simpler.  There are already citations within  
each I-D at the time of its approval.  The desire is to _not_ revisit  
information contained in each separate RFC, but to provide a more  
dynamic linking document requiring little effort to maintain.

> If a group of I-Ds went together, why not produce an extra one that  
> was just a collection of pointers to the others, plus the usual  

Again, the goal was to achieve a stable reference that locates  
documents currently associated with a specific endeavour. Your  
suggestion does not seem to achieve that goal.

> no WG action or procedural changes.

The introduction of WIP-SRD would not require any WG or IESG action,  
where each person could provide their own namespace for that matter.   
Organize them with links and make them available and see what people  
think.  Over time, as a greater number of RFCs are incorporated  
within SRDs, then the IESG could decide whether they want to see  
these documents together with submitted I-Ds.

-Doug

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 21 Oct 2005 09:05:59 +0200

--On torsdag, oktober 20, 2005 14:02:52 -0700 Douglas Otis 
<[email-masked]> wrote:

> There was a discussion about the idea of adding text to the SRD at  the
> last meeting where a few expressed the desire to no allow such  text.

And quite a few expressed the opposite desire....

>From the minutes:

3 - future of ISD proposal

-  SHOULD A TYPE OF GROUPING DOCUMENT EXIST? 25 out of 40 yes, 4 no

- SHOULD THEY BE MANDATORY? <in some cases?> run an experiment? room sense 
is "no" - use the PROTOS model?

- SHOULD GROUPING DOCS BE APPROVED? depends on the text they contain? - 
approved by the working group? - show the IESG a couple of examples? About 
half the room was willing to say "yes, approve them", but this also 
includes question of normative text in these documents, and what "approval" 
means.

- SHOULD THEY BE ABLE TO CONTAIN NON-AUTO-EXTRACTED/AUTO-GENERATED TEXT? 
Sense of room is that a lot of people think "yes"

- SHOULD THEY NORMALLY CONTAIN TEXT? No sense of the room. Get a concrete 
proposal and discuss on the list.

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 21 Oct 2005 08:59:11 -0500

If I may express an opinion ..

> a large amount of work involved, a very-high-threshold approval

Keeping in mind that there's a reasonable chance that the working group that 
MIGHT have revised an RFC has already concluded, I think "reticience" is an 
understatement... if step one of the approval process is "charter a working 
group"!

Spencer 

.