Subject: [newtrk] Re: WGLC for draft-ietf-newtrk-repurposing-isd-01.txt

From: [email-masked] (Scott Bradner)
Date: Sun, 20 Mar 2005 15:04:41 -0500 (EST)

back on 10 Feb I posted a working group last call for the 
newtrk-repurposing-isd ID with an end date of 3/18.

since then there has been quite a bit of discussion, a face to 
face meeting and a revision of the ID (the current version is now
draft-ietf-newtrk-repurposing-isd-02.txt)

at the face to face meeting and mostly on the mailing list I see
general consensus that the basic idea and the ID are basically 
ready for IESG discussion modulo two things

1/ we need to get an XML schema (list discussion seemed to indicate 
   that a schema might be a better idea than a DTD)

2/ Brian says we need to get 'horsey-ducky" presentation put together for
   the IESG so that they can talk about the concept at their retreat (the
   term comes from an ex-boss who said she needed very simple "horsey-ducky"
   presentations whenever she needed to go talk to university deans
   due to their busy schedules (or limited attention spans))

This is not to say that there have been no voices that run counter
to the above but that such voices have been quite much in the minority.

John K says that he has a volunteer for the XML work and I guess
I can work with the Two Johns to come up with a draft of a presentation
for discussion on the list.

if anyone disagrees with the above please post your comments to the
list.

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

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 21 Mar 2005 11:32:05 -0500

Hi Scott,

>to the above but that such voices have been quite much in the minority.

You didn't include my concerns about the clarity of the document 
and/or the practicality of the transition plan, so I guess that you 
are declaring me to be part of the "rough"?

I did review the new version of the draft -02, and I send my review 
to you and the John's in response to John Klensin's request for more 
specifics.  I'm also including it below, so that the working group 
can see it.

Margaret

The document says "[This document] proposes that ISD documents be
created", but it doesn't include a clear requirement/check for their
existence as part of the standards track at any point.  Is it intended
that, as of a certain date, the IETF would no longer publish standards
track or operational BCP documents without an ISD?

    These documents, and documents authoritatively (normatively)
    referenced from them, will become, essentially, the definitions of
    standards.  Consequently, any changes to them will occur only under
    IESG authority and responsibility.  The IESG may, at its discretion,
    and with appropriate announcements to, and consultation of, the
    community, delegate authority for some sections to groups responsible
    for the ongoing maintenance of the standards, but may not relinquish
    responsibility for the documents themselves.  However, nothing in
    this specification prohibits (or requires) IESG authorization of
    placement of links in the STD documents that point to less formal and
    less authoritative discussions of, or comments on, the relevant
    standards should they deem that appropriate.

I am completely confused by the above paragraph.  Who is responsible
for what?  Does the IESG have the authority to change an ISD on their
own and can therefore delgate that authority to others?  Or is some
sort of community LC and/or WG or community consensus required, as
seems to be indicated quite clearly elsewhere?

How can someone else place "links in the STD document that point to
less formal and less authoritative..."?  Does this imply that someone
can modify IETF standards without IESG approval?  Even if we wanted
that to be possible, I am not sure how it would work, as the RFC
editor doesn't modify standard documents, and they don't publish
updates to standards track documents without instructions from the
IESG.

    By extension from the above, the IESG will need to make
    determinations, ideally after creating guidelines and getting
    community review and assent to them, as to criteria (e.g., length,
    importance, degree of discussion needed) by which authoritative
    comments and qualifications about standards will be incorporated into
    the STDs documents or issued as separate RFCs.  The starting point
    and minimum descriptive and qualifying text for new standards will be
    the text of the Protocol Action Notice.

What are "STDs documents"?  Are you taking about changes to the
standards themselves?  Or changes to the ISDs?

    If
    multiple, related, specifications are approved at the same time, they
    may be assigned the same ISD number and name.  As those documents are
    published as RFCs, the RFC may (and presumably usually will) contain
    the standard number and name since it will constitute a stable
    forward reference.  This assignment of an ISD number and name, and
    assignment of a specification to it, results in a corresponding ISD
    document being created or updated, as described below.

How can assignment of a number and name cause a document to be
created?  If these document contain descriptive prose (as indicated
elsewhere), they can't be created by a perl script, they will need
authors.

Later in the document, you say that ISDs will be submitted to the IESG
by the WG or submitter, but that doesn't seem to match this section.

    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.

Personally, I think that it is a mistake to publish errata in the ISD,
rather than updating the RFCs.  When folks implement RFCs, I don't
think we should count on the fact that they will check for errata
elsewhere.

4.  Publication and Formatting

    ISDs constitute an entirely new document series, to be managed
    directly by the IESG as part of its management of the standards
    process.  ISDs are not to be published as part of the RFC series.
    The basic source format an ISD will be XML, conforming to an
    appropriate and IESG-designated, Document Type Definition (DTD).

 From the list discussion, it appeared that there was agreement that
XSDs would be better.  Either way, I don't see why this level of
detail about how the documents are produced should be included in a
BCP.

    For
    archival and external reference purposes, the formal archival form of
    the ISD will be ASCII text.  However, it is anticipated that web
    pages with embedded links will also be generated from the XML and
    made accessible from the IETF home page.

Has any effort been made to determine the total cost of the paid work
(for the RFC Editor or equivalent and the Secretariat) outlined in
this document, so that we can determine if these documents will, in
the opinion of the community, be worth the cost?

    Draft versions of ISDs or proposals for updating them may be posted
    as Internet-Drafts.  Such posting will generally be required in
    conjunction with Last Calls unless the IESG devises an alternate
    procedure.  Since current Internet-Draft format requirements are
    based on RFC formats and requirements, posting drafts for ISDs as
    Internet-Drafts may require some extensions to the Internet-Draft
    posting rules.

I am not sure what this means.  Would the XML be posted as an I-D?  Or
would the text be posted as an I-D?  Either way, why would this
require changes to the I-D rules?

    ISDs will be identified by a name and the combination of a
    serially-assigned standard number and a date with resolution in days.
    The numbers for ISDs and those for STDs (see [RFC1311]) are not
    expected to be synchronized.

The document later indicates that ISDs for FS documents will be
synchronized with the STD numbers and that no new STDs will be issued.

5.  Content and Organization of an ISD Document

    An ISD document is expected to follow the general layout and
    formatting conventions of an RFC (because the community is familiar
    with them).  The components listed below may appear, or are expected
    to appear (required materials, even if only pro-forma, are identified
    with asterisks).  As with RFCs, additional sections may be included
    as needed and appropriate.  Note that ISDs don't have authors: the
    RFCs have authors, but the "author" of an ISD would always be "IETF"
    (or the historical "Network Working Group") so there is no
    information in providing an author or editor name.

ISDs contain prose text and will, therefore, have authors.  I don't
object to not listing them on the first page of the RFC, but the
authors do need to exist.  What is the motivation for people to do
this work?

    Applicability Remarks about the standard.  Any remarks about
       applicability that seem useful or appropriate, as authorized.
    Security Remarks about the standard.  Any authorized remarks about
       the security implications or considerations of the standard that
       are not completely reflected in the component RFCs.

By whom would these remarks be authorized and using what process?  I
assume that they would be authorized by the IESG?  Would they also
need to be approved through a WG or community consensus process?

6.  Transition

    Obviously, we now have many full Internet Standards, with STD numbers
    assigned and packaging defined by those numbers, that are not
    associated with documents as described here.  We have even more
    documents at Proposed or Draft Standard levels that do not have
    either documents of this type or grouping.  Some of those documents
    should almost certainly be bound to existing packages defined by STD
    numbers.  If this process is not bootstrapped by issuing ISDs for
    those documents, it probably won't work.

I personally agree with this statement, which is I why I do not think we
should publish this document as a BCP unless/until we have a practical
plan to bootstrap the process by issuing ISDs for these documents and
we understand what it will cost (in $$, volunteer time, and impacts on
other IETF work)

    o  For each existing STD number, assign a name or acronym and create
       a prototype ISD document.  Reuse of the STD numbers as ISD numbers
       would save some time and avoid some confusion.  This step and the
       management of titles and abstracts, as discussed below, can be
       done from the existing std-index being maintained by the RFC
       Editor.
    o  Populate that document with the list of RFCs now associated with
       the ISD and identify all of them as Internet Standards.

s/ISD/STD?

Are you picturing a fully automated approach here?  Or are you hoping
that abstracts and other prose will be written for this step?

    o  For each existing Proposed or Draft Standard, generate a template
       document and assign a name and number.  Exceptions should be made
       and documents grouped when it is obvious and uncontroversial that
       several documents belong together and someone can be found to do
       the work.  Initial assignments and drafts should be created on an
       area basis, preferably by directorates or specially-selected
       committees, coordinating with any reclassification efforts to
       avoid duplicate work.

Even assigning acronyms to all of these documents would be a big
task.

I am concerned that we will create a big mess if we create a huge
number of ISDs, one for each of the current PS and DS documents and
don't do the work, up front, to determine which ones should be grouped
together and/or grouped with existing FS documents.

If we produce hundreds of useless ISDs, how will we ever get people to
notice that some of them are actually useful?

    o  Populate the title and abstract with the title and abstract of the
       first RFC in the series.

The first RFC in what series?

7.  Operational Issues

    There is a case to be made that creating this sort of document series
    is additional work for the IESG.  In practice, the authors don't
    believe it, at least to any significant degree.

As an IESG member, I do believe that, as described, ISDs would
represent signficant addtional work for the IESG, the RFC Editor (or
equivalent) and the Secretariat (or whoever manages our web site).

Once the system is established, the creation and/or modification of
ISDs could be done by WGs or independent submitters and the IESG could
consider the ISDs in parallel with considering the document itself.
This would represent a bit more work for the IESG, but it would
probably manageable and useful.

The problem is the transition.  By my count, we have:

66 STDs
77 Draft Standards
Over 600 Proposed Standards (I stopped counting at that point)

So, if you accept the premise of the document that ISDs won't be
useful unless we produce ISDs for many of the existing FS, DS and PS
documents, then we would have a _huge_ and _expensive_ job on our
hands to make this useful.

Before I could reasonably assess whether this is a worthwhile effort
and/or whether undertaking this effort would be damaging to the IETF,
I would need to see a reasonably well-thought-out estimate of the
costs (RFC editor and secretariat time) associated with this effort,
the number of volunteer hours that would be required and a list of
volunteers to do the work, and an estimate of the impact that this
effort would have on the IETF's ability to produce specifications
during the transition period.

    All of the relevant
    information is created today.  It is scattered in meeting minutes and
    secretariat notes, protocol action notices, discussions about whether
    to restart WGs to deal with problems, etc.  Today that information,
    much of it quite useful, gets lost or at least becomes quite
    difficult to find.

Gathering this information together for past documents would be quite
a bit of work.  I agree that it would be useful to have this
information readily available for our standards, but I wonder if there
is a way that we can do that for future standards without requiring a
huge transition effort for the past documents, and/or a huge
impediment to publishing the next modification to each existing
standard.

Think of the impact that this effort will have on the first attempt
to publish a minor performance improvement to TCP after the ISD
requirement is put into force...

    Conversely, these series should reduce workload
    by considerably reducing the pressure to find editors to write or
    rewrite RFCs whose purpose is ultimately "this document is just like
    RFC xxxx, except that section 3.1.3 is removed to permit promoting
    the specification to the next maturity level".

As you indicated earlier in the document, we don't do this very often,
so it doesn't represent a serious amount of work.  In fact, I have
never (as an IESG member) needed to located an editor for any document --
WG chairs do that.

    For a new specification document intended to be processed onto the
    standards track (including non-procedural BCPs), responsibility for
    preparing a draft of a new or revised ISD and advising on whether the
    standards-track document will require a new ISD number or become part
    of an existing ISD lies with the relevant WG or other submitter.  The
    IESG will issue a Last Call that includes the proposed ISD text along
    with the substantive document(s).  They will then modify the ISD text
    as needed based on input during Last Call and internal discussions.
    In general, the new or revised ISD will be issued at the same time as
    (or replacing) the Protocol Action Notice, referencing the approved
    Internet-Draft and containing copies of any RFC Editor instructions.
    That material would then be replaced in the ISD when the relevant
    documents are published.

It would be better, in my opinion, to include this information earlier
in the document.  You could then remove the passive voice from the
sections where you talk about ISDs being "created".

    Regardless of what organizational arrangements are responsible for
    updating and maintaining these documents, and in spite of their
    containing a cumulative change history, they should be treated as
    archival -- at least as archival as the RFC series.

So, old versions of the ISDs (previous dates) will also be maintained
at all times, even after they are superseded by the new version??  I
think that is what "archival" would mean in this context, and I think
that contradicts text elsewhere in the document.

8.  References to ISDs or References to RFCs

    Before this proposal was generated, vendors who wished to specify
    what they support, and potential customers who wished to specify what
    they wanted to purchase, had a choice between referencing specific
    RFCs (to get precision) or, for full standards, a specific STD number
    (to get "the most current version").  Except for providing an "ISD"
    mechanism for referencing documents other than full Internet
    Standards, this proposal does not change either of those options:
    both are still free to use the existing forms.  In the rare case in
    which a vendor is deliberately attempting to confuse its potential
    customers, this mechanism is not likely to help very much either.  It
    does, however, provide a third option, which is to specify the state
    of an STD as of a particular date (even a date in the past or future)

s/STD/ISD?

.