Subject: [newtrk] Comments on draft-klensin-newtrk-std-repurposing-00.txt

From: Margaret Wasserman <[email-masked]>
Date: Mon, 16 Aug 2004 05:47:02 -0400

Hi All,

I have reviewed draft-klensin-newtrk-std-repurposing-00.txt, and I 
have some specific comments regarding this proposal.  While I find 
the concept of "named" standards to be compelling, if only because of 
the benefits to relative newcomers to the IETF document process, I 
believe that this specific proposal has several flaws.

Most importantly, I believe that this proposal drastically under 
estimates the level of work required to produce the STD documents. 
It says:

    "There is a case to be made that creating this sort of document series
    is additional work for the IESG.  In practice, this author doesn't
    believe it, at least to any significant degree.  All of the relevant
    information is created today."

I do not agree with this statement.  IMO, the information that would 
need to go into a STD document, such as which RFCs are (and are not) 
part of the core standard, which portions of which RFCs are required 
and which are optional, current thinking regarding errata, etc.  are 
NOT produced by the IETF in any form for most our standards.  And, 
when we do try to produce this information, it can take several years 
and result in considerable debate.  See, for example, the effort 
required to produce the Host and Router Requirements documents, or 
the considerable effort required to produce the IPv6 Node 
Requirements document.

The proposal is also unclear on several key points:

(1) Must a STD document be produced (or updated) before a document 
can be published as a PS?
(2) Who actually writes (or updates) the STD document?  The 
shepherding AD?  The WG Chair?  The document editor of the new (or 
updated) standards-track document?
(3) What level of community consensus/review is expected for the STD 
document itself?
(4) What is the approval process for a new (or modified) STD 
document?  IETF Last Call?  IESG Approval?  And, what criteria are 
used to decide whether or not to approve a STD document?

I am concerned that this proposal could be interpreted to say that 
the responsible AD will produce (or update) a STD document for each 
standards-track document that is published at PS or advanced on the 
standards track (about two hundred times per year) and that the only 
community involvement would be IETF Last Call...  In addition to 
creating a lot more work for IESG members (and likely delaying the 
approval and publication of standards-track documents), this seems to 
place an enormous degree of power in the hands of the IESG -- 
effectively the power to define compliance to a particular IETF 
standard.  The IETF has steered clear of compliance statements and 
standards profiles for the most part, perhaps for good reason.  And, 
IMO, the few attempts we have made to define the scope of a 
particular standard have been lengthy and contentious.  Do we really 
want to give the power to define the scope of our standards to a 
single AD, at the very end of the standardization process, with 
minimal opportunity for community input and review?

I also believe that this proposal vastly overrates the expertise of 
each IESG member (or at least it overrates my expertise).  Frankly, I 
am not qualified to create the STD document for every standard that 
is produced by the WGs in my area.  While I do struggle to understand 
the basics of the standards being produced each of my WGs, a great 
degree of subtlety would be lost if I were required to summarize and 
categorize what is required for a compliant implementation of every 
technology that is standardized in my area.

Another issue with this proposal, IMO, is that it doesn't explain how 
it will be rolled out...  When this document is passed, would the 
IESG be expected to produce an STD document for every single 
standards-track document that is approved?  For instance, would I 
need to produce the STD document for DHCP in order to approve a small 
extension to the DHCP protocol?  If so, this would create an enormous 
amount of work and result in enormous delays to the standards process 
for at least the first couple of years after it is adopted.  Or are 
older standards grandfathered in some way?  If older standards are 
grandfathered, I think we'd end up with a mess...  older STD 
references would refer only to the contents of the RFC Index while 
newer ones would refer to an STD document.

If proponents of this plan think that I am over-reacting and that 
producing a STD document is a fairly trivial, clerical task that I 
should be able to perform ~30+ times a year without adding to my 
workload, perhaps you could prove it to me...?

I have six PS-candidates in the pre-IESG portion of my document 
queue, all of which should be submitted to the IESG within the next 
4-6 weeks.  If you believe that this is a trivial task that shouldn't 
add substantially to my workload, please send me examples of the STD 
documents that should be written for these documents:

draft-ietf-ipv6-inet-tunnel-mib-02.txt
draft-ietf-ipv6-router-selection-02.txt
draft-holbrook-idmr-igmpv3-ssm-07.txt
draft-ietf-ipv6-rfc2013-update-03.txt
draft-ietf-dhc-server-mib-10.txt
draft-ietf-ipv6-unique-local-addr-05.txt

Personally, if I had to produce a STD for each of these documents, I 
don't even know where I would start.  Some questions:

What level of granularity makes sense?  For example, would 
draft-ietf-ipv6-rfc2013-update require that I write a STD for all of 
IPv6?  Or only for Neighbor Discovery?  Even if it is just for ND, 
would that include IPv6 Auto Configuration?  Any of the recent DAD 
optimization work?  Would I need to include informational documents 
about how DAD relates to MIP, etc?  Would the Router Selection draft 
(draft-ietf-ipv6-router-selection) also be covered under ND (because 
it uses an RA option) or would that be a separate standard?

Would a MIB (like draft-ietf-dhc-server-mib) be a standalone STD?  Or 
part of the STD for the protocol that it can be used to manage?  If 
the latter, would I need to write an STD for all of DHCP to publish 
the DHCP Server MIB?

For a draft that defines interactions between IGMPv3 and SSM, would I 
need to write two STD documents (one for each)?  Having me write the 
initial STD for SSM would be interesting, since SSM is not my area 
(it's in Routing), I haven't been tracking it at all, and I don't 
even pretend to fully understand it...

And what sort of STD document would I need to write for the IPv6 
local addressing draft?

Once a few realistic examples have been produced, we will have a much 
better understanding of what is involved here.  We can get a report 
from the people who wrote the examples regarding how much work was 
involved in producing these documents.  We can run the examples by 
experts in each technology to determine how accurately the STD 
examples reflect the state of those standards.  We can also judge 
what level of contention is involved in producing these lists.

Margaret

.
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: Mon, 16 Aug 2004 06:41:00 -0500

Hi, Margaret,

Your note had two sections - my suggestion is that we focus on the
first section first (if we decide that producing STDs is not the right
things to do, the nits don't matter).

I am extremely sympathetic to the concern that producing STDs isn't
zero work.

I like the way PROTO is headed with WG chairs shepherding documents,
and do see ADs asking their WG chairs to come up with STD text as a
reasonable way to ensure that we have STD text.

My understanding is that the vast majority of our STDs (the vast
majority of our existing PSes) come from WGs, so this seems OK.

Making sure that STD text does exist is still an AD responsibility,
under this view, so an AD who needs to produce text for a specific STD
can still do so.

And WG chairs can also ask for help in generating text for STDs.

My concern here is that by not producing STDs, we ask every user of
existing PSes to do the work we don't have time to do, and in many
cases to do that work with less insight into history and a more narrow
experience base. Loughney has a horror story about implementors who
produced 793 TCP within the past two years, I have a horror story
about implementors who produced 822 STMP within the past two years. If
we don't find some way to provide STD guidance, this is what the
Internet of the future will look like (if the NATs don't kill it dead,
the Old and Crufty PSes, DSes, and ISes will).

Spencer

p.s. Yeah, the STDs could be developed in parallel with the drafts,
and approved as part of the draft approval process, but that's getting
into the second half of your note. Let's stay on "is it physically
possible" for now, OK?

.

---

From: John C Klensin <[email-masked]>
Date: Mon, 16 Aug 2004 11:50:22 -0400

Margaret,

Since Spencer has addressed the first part of your observations,
let me try to address the second, i.e., how much marginal work
this involves.  There are two implicit assumptions in the draft.
I was reluctant to make either explicit although I went partway
down that path at the San Diego meeting.  I suppose it is time
for me to be explicit.  I believe that:

	* Some reasonably accurate information, even if it is
	not complete or precise, is better than leaving the
	reader (or procurement department) completely in the
	dark and guessing.  Picking up Spencer's examples, it
	doesn't take much to say "don't implement to 793 (or
	822) alone". Even though that statement doesn't give the
	reader full details about what should be done, it at
	least provides a strong hint that some questions or
	detective work is needed.  More would certainly be
	helpful, of course, but my goal is improvement, not
	perfection.
	
	* For _any_ of the proposed reforms to work --either
	those in newtrk's scope or others coming out of
	Solutions or Problem Statement discussions-- the IESG is
	going to need to get over the notion that anything it
	emits must represent an example of perfection, polished
	to a high luster.  If we can't get past that --or
	behavior that is indistinguishable from that-- then
	nothing makes any difference.

Now, if one accepts those principles, then the default document
for an existing PS contains just:
      Name (from the title of the PS RFC)
      Abstract (from the abstract)
      Status: Proposed Standard, published YYYY.MM
      Defining RFC: NNNN
That isn't the format the I-D outlines, or what I would suggest,
but it is the information content.  And I suggest it can be done
automagically.

For a newly-approved PS, again involving a single document, the
information would be similar to the above, but
      Name (from the title of the PS RFC)
      Abstract (from the abstract)
      Status: Proposed Standard, approved YYYY.MM
      Protocol action statement: (these exist, independent of
how good they are)
      Defining RFC: NNNN

And, for a newly-approved DS, assuming we keep those, we might
have, ideally:
      Name (from the title of the PS RFC)
      Abstract (from the abstract)
      Status: Draft Standard, published YYYY.NN.dd
      Protocol action statement: (see above)
      Defining RFC: NNNN
      Obsoletes: RFC MMMM
      Related documents: Informational RFC NNN4, "Security
considerations section of RFC NNNN considered bogus" (no IETF
action taken on this document)
		Interoperability statements: (whatever they are, with URIs if
appropriate)
      IPR statements: (probably just a URI or list of them)
      Change History:
         1885.02.30: First relevant internet-draft posted as
draft-ietf-going-around-in-circles-00.txt on 
         YYYY.KK.DD: Status document updated to reflect new
interoperability posting, (URI)
         YYYY.KK.D2: WG mailing list persuaded that section 13
of RFC NNNN was completely bogus and should be dropped, text
removed in RFC MMMM.
         YYYY.KK.D3: Comma missing in third line of section
1.2.3 or RFC NNNN, should read "completely strange, but"
         YYYY.MM.DD: Proposed standard approved, RFC MMMM, with
information (copied from the PS doc if it exists)

Clearly, under the proposal, any of the information I've
suggested for the DS-status document could be incorporated into
the PS one(s) if there were will and inclination.

Now I suggest that the first two of these involve almost zero
extra work, that the change history stuff could be mostly
supplied mechanically or by an alert secretariat and be subject
to either cursory IESG review or review by some group the IESG
delegated the job, subject to appeal or even more cursory
review.  And the real work for the DS document is required
today: we just aren't writing it down in one place and in a
coherent way.  

Now things get more complicated if several new documents are
approved concurrently and intended to become one standard, or if
a new document is added to an existing standard.  But, again, I
suggest that, if the underlying work isn't being done, it is a
major flaw in the system that will sooner or later cause us
significant problems.  But I think it is mostly being done, but
not captured, so the only marginal work is capturing it.

So I don't see the incremental work as being that great.  More
important, I see this as a mechanism for avoiding republishing
RFCs for trivial changes and perhaps even for binding formal
status/ change statements to a PS-level RFC that would permit
advancing the specification to DS without revising and reissuing
the RFC itself.  That would clearly reduce the document-reading
load on the IESG and should be considered in evaluating the
amount of marginal work required here.   Of course, it would
also reduce the editing/ publication load on the RFC Editor,
which might improve standards throughput.

To exaggerate the content and intent of John Loughney's "what
standards" document a bit, if we aren't doing this work somehow,
and doing a reasonable job of documenting it, we better get over
the idea that we are producing standards that anyone can use, or
at least anyone who is not part of the IETF's culture and oral
traditions.

Again, if the IESG doesn't agree with the intent here, and
believes that every single document must be comprehensive,
clear, and reviewed to an extent previously unprecedented, the
idea will fail because it will, indeed, require a huge amount of
additional work.  But we are, IMO, getting closer and closer to
failing with the system we have now, so it may be time to try
something that at least holds out some hope for simultaneous
improvements in quality, clarity about what is intended and
understood, and speed with which things can be done.

     john

--On Monday, 16 August, 2004 05:47 -0400 Margaret Wasserman
<[email-masked]> wrote:

> 
> Hi All,
> 
> I have reviewed draft-klensin-newtrk-std-repurposing-00.txt,
> and I have some specific comments regarding this proposal.
> While I find the concept of "named" standards to be
> compelling, if only because of the benefits to relative
> newcomers to the IETF document process, I believe that this
> specific proposal has several flaws.
> 
> Most importantly, I believe that this proposal drastically
> under estimates the level of work required to produce the STD
> documents. It says:
> 
> I do not agree with this statement.  IMO, the information that
> would need to go into a STD document, such as which RFCs are
> (and are not) part of the core standard, which portions of
> which RFCs are required and which are optional, current
> thinking regarding errata, etc.  are NOT produced by the IETF
> in any form for most our standards.  And, when we do try to
> produce this information, it can take several years and result
> in considerable debate.  See, for example, the effort required
> to produce the Host and Router Requirements documents, or the
> considerable effort required to produce the IPv6 Node
> Requirements document.
> 
> (1) Must a STD document be produced (or updated) before a
> document can be published as a PS?
> shepherding AD?  The WG Chair?  The document editor of the new
> (or updated) standards-track document?
> (3) What level of community consensus/review is expected for
> the STD document itself?
> document?  IETF Last Call?  IESG Approval?  And, what criteria
> are used to decide whether or not to approve a STD document?
> 
> I am concerned that this proposal could be interpreted to say
> that the responsible AD will produce (or update) a STD
> document for each standards-track document that is published
> at PS or advanced on the standards track (about two hundred
> times per year) and that the only community involvement would
> be IETF Last Call...  In addition to creating a lot more work
> for IESG members (and likely delaying the approval and
> publication of standards-track documents), this seems to place
> an enormous degree of power in the hands of the IESG --
> effectively the power to define compliance to a particular
> IETF standard.  The IETF has steered clear of compliance
> statements and standards profiles for the most part, perhaps
> for good reason.  And, IMO, the few attempts we have made to
> define the scope of a particular standard have been lengthy
> and contentious.  Do we really want to give the power to
> define the scope of our standards to a single AD, at the very
> end of the standardization process, with minimal opportunity
> for community input and review?
> 
> I also believe that this proposal vastly overrates the
> expertise of each IESG member (or at least it overrates my
> expertise).  Frankly, I am not qualified to create the STD
> document for every standard that is produced by the WGs in my
> area.  While I do struggle to understand the basics of the
> standards being produced each of my WGs, a great degree of
> subtlety would be lost if I were required to summarize and
> categorize what is required for a compliant implementation of
> every technology that is standardized in my area.
> 
> Another issue with this proposal, IMO, is that it doesn't
> explain how it will be rolled out...  When this document is
> passed, would the IESG be expected to produce an STD document
> for every single standards-track document that is approved?
> For instance, would I need to produce the STD document for
> DHCP in order to approve a small extension to the DHCP
> protocol?  If so, this would create an enormous amount of work
> and result in enormous delays to the standards process for at
> least the first couple of years after it is adopted.  Or are
> older standards grandfathered in some way?  If older standards
> are grandfathered, I think we'd end up with a mess...  older
> STD references would refer only to the contents of the RFC
> Index while newer ones would refer to an STD document.
> 
> If proponents of this plan think that I am over-reacting and
> that producing a STD document is a fairly trivial, clerical
> task that I should be able to perform ~30+ times a year
> without adding to my workload, perhaps you could prove it to
> me...?
> 
> I have six PS-candidates in the pre-IESG portion of my
> document queue, all of which should be submitted to the IESG
> within the next 4-6 weeks.  If you believe that this is a
> trivial task that shouldn't add substantially to my workload,
> please send me examples of the STD documents that should be
> written for these documents:
> 
> Personally, if I had to produce a STD for each of these
> documents, I don't even know where I would start.  Some
> questions:
> 
> draft-ietf-ipv6-rfc2013-update require that I write a STD for
> all of IPv6?  Or only for Neighbor Discovery?  Even if it is
> just for ND, would that include IPv6 Auto Configuration?  Any
> of the recent DAD optimization work?  Would I need to include
> informational documents about how DAD relates to MIP, etc?
> Would the Router Selection draft
> (draft-ietf-ipv6-router-selection) also be covered under ND
> (because it uses an RA option) or would that be a separate
> standard?
> 
> Would a MIB (like draft-ietf-dhc-server-mib) be a standalone
> STD?  Or part of the STD for the protocol that it can be used
> to manage?  If the latter, would I need to write an STD for
> all of DHCP to publish the DHCP Server MIB?
> 
> For a draft that defines interactions between IGMPv3 and SSM,
> would I need to write two STD documents (one for each)?
> Having me write the initial STD for SSM would be interesting,
> since SSM is not my area (it's in Routing), I haven't been
> tracking it at all, and I don't even pretend to fully
> understand it...
> 
> And what sort of STD document would I need to write for the
> IPv6 local addressing draft?
> 
> Once a few realistic examples have been produced, we will have
> a much better understanding of what is involved here.  We can
> get a report from the people who wrote the examples regarding
> how much work was involved in producing these documents.  We
> can run the examples by experts in each technology to
> determine how accurately the STD examples reflect the state of
> those standards.  We can also judge what level of contention
> is involved in producing these lists.
> 
> Margaret
> 
> 
> 
> 
> 
> .
> newtrk
> resources:_____________________________________________________
> web user interface:
> http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive:
> http://darkwing.uoregon.edu/~llynch/newtrk/index.html

.

---

From: John C Klensin <[email-masked]>
Date: Mon, 16 Aug 2004 14:46:38 -0400

Trying to answer a few loose-end questions at the nit, rather
than concept, level...

--On Monday, 16 August, 2004 05:47 -0400 Margaret Wasserman
<[email-masked]> wrote:

>...
> in any form for most our standards.

I consider that a problem.   Don't you?  

But, as suggested at the WG meeting and in my prior note, my
personal criterion for what should be in a given one of these
documents is "whatever the IESG, or various contributors,
consider to be worth the trouble".   In the interest of full
disclosure, I'd rather see, e.g., relationship to other
documents "we didn't think filling this in was worth the
trouble" in a document in preference to "none" if the former is
true.  But, if something isn't worth the energy, then we should
say so and move on.

>  And, when we do try to

Part of the assumption that drove the very first version of this
proposal (many years ago) was the recognition that we are poor
at producing and generating full A/S-type documents.  This
proposal recognizes that reality and has to do with the desire
to reduce the need for them, rather than recreating them in
another form.  I'd be quite happy to see these documents capture
the debates, rather than trying to resolve them.  A statement
like "there continues to be wide debate in the community as to
whether this idea really works at scale" is useful to the
reader, but not the sort of thing we would normally permit in a
standards-track RFC.  If there are references to which such a
statement would point, even if they are URIs into a mailing list
archive, that would be even better.  But it isn't necessary
unless the issue is important enough that someone feels like
doing the work.  If it isn't, then omission or "unknown" are
perfectly good answers.

> The proposal is also unclear on several key points:

I'll try to give my responses.  John Loughney is holding the pen
at the moment; I hope that, if he agrees, these changes will
make it into the -01 draft.  If not, we should probably have a
wider discussion.

> document can be published as a PS?

Yes.  But, as indicated in my previous note, a minimal STD for a
single-document PS is just the title of that document, its
abstract, and the text of the protocol action notice.  That does
not impress me as significant work: it is really a reformatting
of the Protocol Action announcement.  While Spencer's comments
about where the text should come from are, IMO, useful here, the
point is that we are already doing all of the work.  Now, if a
standards-approval process involves some linked set of documents
the STD would need to have its own abstract and a summary of the
relationships.  But we generally do that in the protocol action
notices anyway and a WG or AD recommending such a thing had
better be clear enough on the relationships to be able to
describe them clearly or we have bigger problems than whether
these documents are produced.

> (or updated) standards-track document?

Uh, yes.  Only I would hope it wouldn't be the AD, both because
it is extra work (however minimal) and because the AD should be
acting, on these as on the documents themselves, in a review
function not an author one.

> (3) What level of community consensus/review is expected for

An issue that I would hope the IESG would incrementally work
out, with different sections possibly having different criteria.
For the core title/ abstract/ description of relationships, I'd
assume this would be part of the Last Call on the underlying
document(s).  Yes, that means that the draft protocol action
text gets written up --ideally by the WG and representing its
consensus-- before IETF Last Call.  To the extent to which we
want to avoid late surprises, that would be A Good Thing for
reasons that go well beyond any desire for these documents.

> are used to decide whether or not to approve a STD document?

See (3).  As I said during the San Diego discussion, it really
doesn't make a difference as long as we are absolutely clear
about what we are doing.  This is the advantage of prose over
category names.  I would hope that we could come up with
language that would distinguish between:

	(i) Elmer Fudd thinks that section five is wrong and
	should be...
	
	(ii) Donald Duck thinks that section five is wrong,
	exposed his ideas to the mailing list that used to
	support the WG, and got general agreement...
	
	(iii) The IETF reviewed comments on section six and
	agrees that it should really read...

The first would, I assume, require only agreement/approval from
Elmer and maybe the (former) WG Chair or Editor that Elmer is
credible and the claim is plausible (the latter to provide some
resistance against DoS attacks).  The second would require some
sign of WG consensus using our usual models, e.g., a
determination by the (former) WG Chair and/or AD, but without
any requirement for IETF or IESG review.  And the third would
presumably require a Last Call process, probably involving an
I-D addressed to a change in the STD document rather than toward
a new RFC.

I would hope that this level of fine tuning could be done by
relatively informal processes, rather than trying to nail down
every detail in advance.

> be IETF Last Call...  

It could be interpreted that way.   It should not, IMO, be
interpreted that way.  If the IESG were to insist on using
something like this as a weapon for foot-shooting, I can't
imagine how the community could prevent that.  But I think the
IESG has better judgment.

> In addition to creating a lot more work
> publication of standards-track documents), ...

again, all of the substantive work that this requires is being
done already.  The only thing it really does is to provide a
place to put the comments that are now documented only in
protocol action notices or, worse, in notes to the WG.  

> ...this seems to place

Hmm.   The draft isn't about compliance statements, and it
certainly isn't about profiles.  Everything to which it is
addressed is, IMO, being done today, but done in ways that leave
the intent very much to the reader's imagination and/or with no
reading of the community's intent at all.   For example, we
group standards today, but we do it only at full standard level
(much too late for most purposes) and as an RFC Editor action
(with no community or IESG review).  And we define scope and
applicable relationships by publishing new documents and putting
terms like "updates" or "obsoletes" on them without any language
about the actual relationships or, in general, the reasons.  Can
you possibly consider that situation better?

I'd assume that the only way a real compliance statement would
make it into one of these things would be after there was a
draft and community consensus, determined in the usual fashion.
If we are both correct that such drafts and consensus are
unlikely, then there will be no such statements.  And an AD who
wrote and approved one without such consensus would presumably
be subject to the wrath of the community via the usual appeal
and recall processes.    So I don't see that this creates any
new risks.

> every technology that is standardized in my area.

Make the WGs do it.  If they can't do it, and reach consensus on
what they have done, _and_ do it with minimal marginal effort,
then they can't explain what they are doing with sufficient
clarity that their results should be standardized.    See above
comment about "review" rather than "authorship".   You are being
asked to determine plausibility, and to monitor the results of a
Last Call process, but you need to do that for the standards
themselves.  The big difference is that the Last Call
announcement would come with significantly more of a summary
about what the proposed standards action is about than the
current title, URL, and sometimes abstract.   I think that would
be a net improvement in the process.  It might even get more
Last Call reviews and comments.  But the WG Chair would be
responsible for getting it written, not you, and, if you didn't
think it was clear after minimal review, you should bounce it
just as you should bounce the specification itself.

> protocol?

Your option.  But I would hope that, if the DHC WG produces a
"small extension to the DHCP protocol" they would feel motivated
to explain how that extension relates to other pieces of DHCP
and to explain any interactions with other extensions.   If they
can't, pity the poor implementer and pity even more the person
who is trying to write a procurement spec who wants to require
"DHCP".

>  If so, this would create an enormous amount of work

I thought the I-D was clear on that.  STD documents for
everything, but in skeleton form... Automatically generated for
full standards (which now have STD numbers and groupings,
assumption that all PS and DS documents are independent until/
unless someone considers it important enough to do the work
identify the pieces and draw them together.

>...
>...
>... 
> documents, I don't even know where I would start.

Margaret, let me try to say something a little more strongly and
black-and-white than might actually be appropriate in practice.
In principle I don't believe that an AD should ever write so
much as a line of text that will end up in a standards-track
document.  If you want to suggest text to a WG, that is fine,
but text should original with WGs or document authors, not the
IESG.  When the IESG, or individual ADs, start generating text,
it becomes a source of both delays and process abuse,
substituting your judgment for that of the WG or the community.
I'd suggest that an AD doing _anything_ that could be
delegated/assigned to a WG is also a sign of bad management, but
maybe that is another issue.  So the answer to all of the
questions above, and to the granularity one, is "hand the
problem to the WG, ask them what they consider reasonable and
worth the investment, make them do enough of a writeup to
explain what they are doing, and then accept their judgment (and
text) unless you believe it is incompetent or get strong
pushback from the community to that effect.   

And my response to the rest of the granularity questions is that
the answers don't make much difference.  Taking the first
example and dissecting it.

> all of IPv6?

That would be a pretty foolish conclusion, IMO, especially in
the absence of strong and obvious community consensus about what
had to be implemented in order to claim one has implemented
IPv6.  Now that consensus probably doesn't exist, and seeking it
would probably be a fool's errand, as you suggest.   So, no.

>  Or only for Neighbor Discovery?  Even if it is
> just for ND, would that include IPv6 Auto Configuration?

Whatever you like or, more important, whatever the WG thinks
sensible.   Would it make sense to do it without Auto
Configuration but to include a pointer to the Auto Config work
in the STD document if that pointer doesn't already appear in
the ND docs themselves?  Sure.  Is it a Big Deal if the STD doc
doesn't (either by mistake or by not considering it important).
Nope.

> is involved in producing these lists.

Seems reasonable to have some examples and that is more or less
what the WG seemed to agree on in San Diego.  I'm only concerned
that you seem to have gone on the attack in a major way without
seeing either any of the examples or the amount of flexibility
that is anticipated here.

    john

.

---

From: Larry Masinter <[email-masked]>
Date: Mon, 16 Aug 2004 13:20:01 -0700

I don't want to be disruptive, but I'm wondering if the
next step is to take the proposal a little further, and
eliminate the 'standards track' categories for RFCs themselves
and move the designation entirely to the STD documents.

> > document can be published as a PS?

So this question wouldn't be meaningful. If we kept the
'PS', 'DS', 'S' categories, they would apply only to the
STD documents, and not to the RFCs. The IESG review would
be of the package (STD document and any referenced RFCs).
The criteria for RFC publication would be 'suitable for
use as a reference to a STD document'.

"Not all RFCs are standards" => "No RFC is a standard".

Of course, in some cases, there is a 1-1 'standards track RFC'
to 'RFC with corresponding standards track STD', but we'd
shift the locus of 'what is a standard'.

Larry
-- 
http://larry.masinter.net

.

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Aug 2004 16:38:42 -0400

> and move the designation entirely to the STD documents.

I suspect the notion of "RFC == standard" is too firmly wedged in the
public midset, and that the effect of such a change would be to dilute
even further the distinction between Informational, Experimental,
PS, DS, FS, and BCP RFCs.

Keith
.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 17 Aug 2004 08:19:46 +0300 (EEST)

> Trying to answer a few loose-end questions at the nit, rather

I'm not sure if you addressed one of Margaret's bigger concerns, i.e.,
what do we do with PS's which are part of a larger "category", so let
me try to spell it out more explicitly..

 1) just publish (about) one STD per PS.  This would be very
straightforward, but might not map the standards track documents
together in a way that some seem to want.  The only times you wouldn't
do a new STD number is when you obsolete or update an existing
document that already has a STD number (and you'd just put the
information there).

 2) just publish specific STDs, not necessarily out of every PS.  
I.e., try to figure out some categories where each document fits in,
and if one can't, just put it out as an invididual STD.  For example,
such STDs could be "PIM-SM", "IGMP", "BGP", "OSPF", "TCP", etc. -- 
this gets a bit hairy if you add "IPv4" and "IPv6" there as well, 
because those include such a large number of documents.

Figuring out these categories could take a lot of work, and it might 
not be obvious where to start looking for the place to put a PS-to-be 
document to.  I think this was a big concern on Margaret's part.

 3) Another option could be a combination: push out an STD for each 
PS, and additionally create these "category" STDs.

It's not clear to me what would be the best path, but 3) might be
confusing if these are not labeled from a separate space.  1) is
straightforward to do, but the benefits seem questionable. 2) seems
useful in collecting the information and grouping it more
intelligently, but also requires a LOT of thinking.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Aug 2004 10:29:46 +0200

> me try to spell it out more explicitly..

One of the reasons I am a fan of the "slash and burn" model (a.k.a.
exactly one standards track maturity level) is that it will make much
of this discussion irrelevant. If all standards track RFCs were simply
called Standards, then building the list of RFCs that constitute a
single STD would be much less of a puzzle (and btw the RFC Editor
already does it, but because of our multiple levels, gets most of them,
including TCP and SMTP, wrong).

http://www.rfc-editor.org/rfcxx00.html

    Brian
.

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Aug 2004 05:14:48 -0400

Pragmatically, I favor your #1 unless  there is an obvious
linkage among documents and/or someone is willing to do the work
of generating a document and moving it through the normal
process.  Again, I would expect WGs and individuals to do that,
not ADs, although I can imagine ADs insisting on it in
complicated situations.

In some sense, the proposal is addressed to three separate
issues:

	(i) We have no convenient, efficient, and
	easily-referenced way to locate small updates,
	interoperability statements, errata, comments about
	observed applicability, agreements about what will be in
	future revisions, etc., for particular specification
	documents (RFCs).
	
	(ii) Personally, I strongly disagree with Brian that
	tossing everything and going to single-level would be a
	good idea.  However, it is is fairly clear that the
	"maturity level categories" model of standards isn't
	sufficiently fine-grained to deal effectively and
	without qualification with common situations such as
	"that element of the standard is a lot more mature
	(implemented, interoperable, deployed,...) than this
	other element".
	
	(iii) When we have multiple documents that address
	pieces of the same logical/abstract standard, we lack an
	adequate method to tie them together and explain the
	relationships.

My view is that a significant improvement in any of these three
areas would be a step forward and that two of the three would be
a huge gain.   And my goal is enough improvement in one area or
another to justify the investment, not perfect solutions.  That
leaves me much more relaxed than Margaret seems to be about
whether we get the third exactly right, especially at the first
iteration ("Proposed Standard") level.   Given a choice, I'd
much rather see each PS get its own number, with prose in the
STD document that says, where appropriate, "if you are
implementing this, you might also want to look at XX and YY"
(note that is not a "conformance statement") than to see the
model, or the IETF, bogged down in arguments about whether two
things are close enough in intent or function to be assigned the
same number.

     john

(iii) 

--On Tuesday, 17 August, 2004 08:19 +0300 Pekka Savola
<[email-masked]> wrote:

> I'm not sure if you addressed one of Margaret's bigger
> concerns, i.e., what do we do with PS's which are part of a
> larger "category", so let me try to spell it out more
> explicitly..
> 
> straightforward, but might not map the standards track
> documents together in a way that some seem to want.  The only
> times you wouldn't do a new STD number is when you obsolete or
> update an existing document that already has a STD number (and
> you'd just put the information there).
> 
>  2) just publish specific STDs, not necessarily out of every
> PS.   I.e., try to figure out some categories where each
> document fits in, and if one can't, just put it out as an
> invididual STD.  For example, such STDs could be "PIM-SM",
> "IGMP", "BGP", "OSPF", "TCP", etc. --  this gets a bit hairy
> if you add "IPv4" and "IPv6" there as well,  because those
> include such a large number of documents.
> 
> Figuring out these categories could take a lot of work, and it
> might  not be obvious where to start looking for the place to
> put a PS-to-be  document to.  I think this was a big concern
> on Margaret's part.
> 
>  3) Another option could be a combination: push out an STD for
> each  PS, and additionally create these "category" STDs.
> 
> It's not clear to me what would be the best path, but 3) might
> be confusing if these are not labeled from a separate space.
> 1) is straightforward to do, but the benefits seem
> questionable. 2) seems useful in collecting the information
> and grouping it more intelligently, but also requires a LOT of
> thinking.

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 17 Aug 2004 07:20:44 -0500

Hi, Pekka,

OK, this is where Dave Crocker usually pops up and says "but we don't
have to be this inflexible". This time, he would be right.

I agree with John Klensin that we don't have to get every
multi-document STD right, but we don't have to get every
multi-document STD wrong, either. If a working group spends the time
to actually say "this is SIP", or even "this is SIP conferencing"
(neither of these will be trivial in five years, I'm not sure that
either is trivial now), we would, of course, say "thank you for making
this effort", not "bad monkey, all PSes go into individual STDs, we
won't approve a multi-document STD until we're talking at least one DS
in the STD", or something equally insane.

Your choice (2) seems the most similar to what people who buy
computers and network equipment are actually trying to do. It would be
lovely if we made it easier for people buy computers and networking
equipment, to specify protocols in phones and other consumer devices,
etc...

Spencer

p.s. Dave has been right other times ... :-)

.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Aug 2004 06:24:38 -0700

> including TCP and SMTP, wrong).

Lets see, RFC822 is still officially the IETF mail standard, but RFC 2822
is the one we should be using.

Or at least that was the situation when I last took the time to dig the 
STD document out of the bowels of the IETF web site. 

There are two problems here. First, if an RFC reaches standards status
and nobody notices or for that matter can even find out without putting
serious effort into the problem, has anything happened.

Second, according to RFC 2822 it made RFC 822 obsolete, yet STD 11 is
according to RFC 3000 still RFC 822.

So what is it, is RFC 822 obsolete or is it a standard?

PS yusing the actronym for Sexualy Transmitted Disease for the standards
documents series is more than a minor problem. Nobody who does press work
is ever going to mention the STD series, nobody who has gone to media
school anyway.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 17 Aug 2004 08:21:21 -0700

>including TCP and SMTP, wrong).

Fully agree. Simplicity would be a very helpful thing here.

>is the one we should be using.

The slash-and-burn model codifies what is reality anyway: the market 
decides what to implement when we supercede one RFC with another. 
There has been zero public effort for RFC 2822, although it is 
probably implemented widely (but certainly not universally).

Having protocols with internal version numbering will help get 
implementers to deploy newer versions of standards. The IETF is much 
better about this than it used to be.

Further, this will make the "bundle of RFCs that is the Foo standard" 
even easier to understand. The bundle can have some explanatory text 
that might include a discussion of which earlier RFCs used to be 
considered part of the standard.

>serious effort into the problem, has anything happened.

This is a problem if we don't also make standards bundles. The 
problem goes away with the standards bundles (even if those bundles 
only contain one item).

--Paul Hoffman, Director
--VPN Consortium
.