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

[Margaret Wasserman <[e-mail]>]

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