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

[John C Klensin <[e-mail]>]

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
<[e-mail]> 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:
> 
>     "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




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