Subject: RE: [newtrk] Re: implementation / interoperability reports vs. ISDs

From: <[email-masked]>
Date: Mon, 25 Jul 2005 07:05:08 +0300

>     John> The key difference, IMO, is the one Doug noted in 
> his response:
> 
>   thanks.
> 
>   So I think that SRDs wouldn't be formal enough to be useful 
> for RFPs.
> 
>   The most serious difficulty in getting Canadian Government procurement
> process for computing equipement to adhere to the NAFTA treaty, is that few
> government departments have any idea how to specify anything that they need
> in terms of RFCs.
>   It's a hard problem for them --- ISDs would solve this.

My general feeling is that SRDs would be acceptable for internal consumption,
for IETFers are people who at least know what the IETF is; while ISDs would
go beyond that and could be used for RFPs and use by other SDOs.

John L.

.
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: Mon, 25 Jul 2005 09:33:36 -0700

> go beyond that and could be used for RFPs and use by other SDOs.

There should be little difference between specifying either an SRD or  
ISD reference in some contract.  The scrutiny given by the IESG  
should be comparable.  The SRD is far easier to evaluate, and  
therefore less prone to error.  With the added reference stability  
offered by SRD or ISD, literature providing guidance to those making  
procurements will remain current.  The information added in the SRD  
Status database will be less formal, but more timely and better able  
to deal with deployment dynamics.  If there is information contained  
within the SRD Status database which is considered essential for the  
long term, then this information should be transfered to an RFC and  
included within the SRD set.

I see the SRD Status database useful for consumption by developers or  
administrators, and helpful to reviewers, but frankly I don't think  
this information should be considered authoritative.  Authoritative  
information should go through the RFC process.  With the SRD being  
typically less than half of page of text, by including it within the  
RFC IESG review, it serves to facility such a review process rather  
than burdening it.  With the ISD, adding an RFC would involve  
modifying two large documents simultaneously, or introduce the type  
of disparity caused by a flagging RFC category system.  To demand  
these two documents be updated together would impose a process burden  
owing to the complexity allowed the ISD.  It may occur to some, that  
just changing the ISD would be easier and cause a loss of maintenance  
of the RFCs.  In effect, ISDs lump more information together making  
it far more difficult to review proposed amendments.

-Doug 
  
.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Jul 2005 11:45:29 +0200

Firstly let me say that my personal opinion is that SRDs have a
better chance of getting off the ground than ISDs, largely because
they are simpler and more straightforward (all we need is xml2srd).

Now, can SRDs be used in RFPs?

1. They would be maintained on the IETF web site and would presumably
be subject to some form of open review process.

2. They wouldn't purport to be standards. They would be a useful summary
list of standards.

3. Anyone, such as a government bureaucrat, could use them to generate
a formal list of specifications.  People who need to use proprietary
document formats can easily convert them (see attached).
(I could even imagine an xml2rfp tool.)

4. I'd be interested to see a list of things that ISDs provide that SRDs
don't.

5. My remaining concern, as for ISDs, is creation and maintenance of
these documents in the absence of a WG.

     Brian

Douglas Otis wrote:
> ISD reference in some contract.  The scrutiny given by the IESG  should 
> be comparable.  The SRD is far easier to evaluate, and  therefore less 
> prone to error.  With the added reference stability  offered by SRD or 
> ISD, literature providing guidance to those making  procurements will 
> remain current.  The information added in the SRD  Status database will 
> be less formal, but more timely and better able  to deal with deployment 
> dynamics.  If there is information contained  within the SRD Status 
> database which is considered essential for the  long term, then this 
> information should be transfered to an RFC and  included within the SRD 
> set.
> 
> than burdening it.  With the ISD, adding an RFC would involve  modifying 
> two large documents simultaneously, or introduce the type  of disparity 
> caused by a flagging RFC category system.  To demand  these two 
> documents be updated together would impose a process burden  owing to 
> the complexity allowed the ISD.  It may occur to some, that  just 
> changing the ISD would be easier and cause a loss of maintenance  of the 
> RFCs.  In effect, ISDs lump more information together making  it far 
> more difficult to review proposed amendments.
> 
> -Doug  
> .

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 26 Jul 2005 07:54:16 -0400

> document formats can easily convert them (see attached).

The attachment contained:

Set of RFC Descriptors
Simple Mail Transfer Protocol:xxxx, SMTP, STD10; Status
RFC2821 Simple Mail Transfer Protocol, SMTP Errata 

Extensions 
RFC3463 Enhanced Mail System Status Codes 
RFC3848 ESMTP and LMTP Transmission Types Registration 
RFC1652 SMTP Service Extension for 8bit-MIME transport 
RFC1870 SMTP Service Extension for Message Size Declaration 
RFC2920 SMTP Service Extension for Command Pipelining 
RFC2034 SMTP Service Extension for Returning Enhanced Error Codes 
RFC2554 SMTP Service Extension for Authentication 
RFC3207 SMTP Service Extension for Secure SMTP over Transport Layer Security 
RFC3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages Errata

Experimental
RFC1830 SMTP Service Extensions for Transmission of Large and Binary MIME Messages 
RFC1845 SMTP Service Extension for Checkpoint/Restart

Related SRD
SRD-SMTP-DSN SMTP Delivery Status Notifications (DSN) 
SRD-SMTP-SPAM SMTP and SPAM (SMTP-SPAM) 
On-demand relay, delivery, and alternatives to TURN 

o What!? DNS and the Internet Message Format aren't related to SMTP?
o Strange format; KWord shows a lot of underlining, OpenOffice shows
  embedded links, but I don't understand why there's an embedded encoded
  CRLF in http://www.ietf.org/srd/srd-status.html?%0D%0Asrd=smtp
o RFC 3030 obsoletes RFC 1830 (3030 is at PS)
o DSN mentioned, but not MDN or MTSN
o All of the above notifications use MIME, but there's no mention of the
  MIME RFCs (note also casual references in titles)
o No mention of message submission (RFC 2476) or LMTP (RFC 2033) (other
  than the IANA type registration for the latter) ?!?
o No mention of the mailto URI (RFC 2368) which accesses mail transfer!?
o no mention of the SMTP BCP (BCP 30, a.k.a. RFC 2505)?
o No mention of gateways (RFCs 976, 2156)?
o no means of distinguishing PS, DS, full Standard, and BCP; also it's
  unclear why some experimental RFCs are listed but not others (e.g. 1845
  but not 1846)
o some PSs listed but not others (e.g. 3030 but not 1985, 2645, 2852,...)
o Peculiar order of RFCs, not chronological, not by RFC number, not
  alphabetical by title...
o etc.; compare to and contrast with http://www.imc.org/rfcs.html#hosttohost

Why was 1830 (obsoleted by included 3030) included?
Why were the RFCs which were excluded left out?
Why no "related SRD" items for DNS, Internet Message Format, MIME, POP,
  IMAP, perhaps even technologies layered on top of SMTP such as
  Internet fax, VPIM, and EDI?

I think this illustrates the difficulties in partitioning RFCs into logical
related groups.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Jul 2005 14:01:33 +0200

> The attachment contained:

<snip>

>   Internet fax, VPIM, and EDI?

Well, this was a first cut example, so it isn't really fair to blame it for
being imperfect.

> I think this illustrates the difficulties in partitioning RFCs into logical

Indeed. Nobody said it was easy, and there are definitely overlapping
groups and "dotted line" linkages.

     Brian

.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 26 Jul 2005 08:31:11 -0400

> groups and "dotted line" linkages.

I think some serious thought needs to go into whether it's practical, and
that is intimately related to the "other" question, viz. who is going to
generate *and maintain* ISDs/SRDs.
.
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: Tue, 26 Jul 2005 11:37:58 -0700

> generate *and maintain* ISDs/SRDs.

You have raised good points.  This SRD draft needs a fair amount of  
work to improve its accuracy.  These were lifted examples from the  
initial ISD.  I may have made some errors in this process.  Perhaps  
non-existent RFCs should be used as examples in the draft, although  
getting this right would not be a wasted effort.  The HTML output was  
included as an illustrative example of a possible output, but was not  
intended to be normative.  I'll make an effort to simplify this HTML  
example.  Please note that there is a fair amount of information in  
reference structures that could be included in HTML presentations.   
There could be both simple and more complete HTML presentations as  
well.  The difficulty creating these relationships is proportional to  
the benefit that can be derived, in my view.

Getting started, there will be an initial effort that relies upon  
scripts to discover much of the RFC relationships.  This will include  
some manual work to resolve issues where the script or the draft fail  
to note the relationships.  There is also a need to classify these  
relationships into the few categories currently defined.  The output  
of that work could be converted into HTML form, where individuals and  
workgroups could provide feedback.  This feedback should be  
consolidated into a (Status) database that uses references based upon  
the SRD names and linked within the HTML presentation.  There could  
be some task assignments made to appropriate working groups, or  
perhaps a working group tasked to resolve these issues.

Once these SRDs have been completed (assuming this is possible), then  
any I-D destine for IESG action must accompany a revision of the  
affected SRD(s), or a new SRD, prefixed as defined in the SRD draft  
for WIP.  Once a comprehensive set of SRDs have been created,  
modifications to this set should be much less contentious.  By  
submitting the modified SRD together with I-D allows those reviewing  
the I-D with the SRD to appreciate the full impact, and permit the  
SRDs and the generated RFCs to stay synchronized.

Change notifications could utilize RSS feeds based upon the SRD names  
as well.

-Doug

.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 26 Jul 2005 16:28:29 -0400

On Tue July 26 2005 14:37, Douglas Otis wrote:
 
> Please note that there is a fair amount of information in  
[...]
> relationships into the few categories currently defined.

I think the primary category would be normative references.  Unfortunately,
many RFCs do not separate normative and informative references.  Continuing
with Brian's example, 2821 is one such RFC (indeed, "reference" [5] is
nowhere referenced in the document text).

Given the varied presentation styles (idnits has needed some tweaks to
detect normative vs. informative references in some cases) and the fact
that many RFCs simply do not categorize references, I suspect that scripts
will yield few results and that most of the work will have to be manual.

> for WIP.

Given the objections over the (existing) requirement for a text IANA
Considerations section in drafts (more than a month of discussion on the
IETF discussion list), I doubt that a requirement to rewrite one (or more?)
SRDs with each draft will be welcome.  Particularly from individual (non-WG)
submitters and especially if there is a requirement for a particular format
(XML).  And it's not clear how references would work at draft stage, where
no RFC number has been assigned to the document.
.
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: Tue, 26 Jul 2005 15:24:16 -0700

> will yield few results and that most of the work will have to be  

I think the term 'core' is more succinct with respect to  
relationships referring to just those RFCs which belong to the  
central endeavour.  Extensions can also be 'normative', for example.   
Normative references may assist initial classifications as to what  
belongs to 'core' however.

The relationship classifications as currently defined are:

   core
   extensions
   guidance
   obsoletes
   experimental
   companion (other SRDs)

I envision guidance including specific BCPs.  It may be better to  
include normative generalized definitions within a companion SRD, so  
when these usual references are changed, they do not impact a large  
number of SRDs.

> no RFC number has been assigned to the document.

In the draft, you will find a general outline regarding this issue.

excerpt from draft-otis-newtrk-rfc-set-00.txt:
------
SRD Identification and References
...
The WIP SRD is identified by a prefix added. The prefix used for an  
RFC-Set, while it is being modified, would be {'X'&lt;iteration- 
number&gt;'-'&lt;group-identifier&gt;'-'}. If this document was  
modifying {foobar.2} by the working group 'newtrk', the first  
iteration would be {X0-newtrk-foobar.2}. When the document becomes  
accepted at some point, it would become {foobar.3}. The 'newtrk'  
represents a group identifier or possibly the name of an individual.  
This group identifier permits simultaneous WIP SRD documents to be  
pending for approval. Normally, an SRD is not allowed to reference an  
Internet-Draft, but there would be an exception made for a WIP SRD.  
The WIP SRD can not receive approval until all referenced Internet- 
Drafts have also been accepted and replaced as RFCs.
-------

For the most part, there will be existing SRDs available to act as  
templates.  The amount of XML specifics is minimal.  There are also  
many open source editing tools which make working with these types of  
documents rather painless, although vi or notepad could be used.  I  
will also note that neither the wg or individual name reference can  
include the '-'.  For example here is srd-xml.1 being initially  
modified by the newtrk wg:

  <?xml version='1.0' encoding="UTF-8" ?>
  <!DOCTYPE srd SYSTEM "rfcxxxx.dtd" >
  <?xml-stylesheet type='text/xsl' href='rfcxxxx.xslt' ?>
  <?srd sortrefs="yes" ?>
  <?srd strict="yes" ?>
  <srd set='srd-xml.1' wip='0.newtrk' >
  <title>XML SRD</title>
  <description>XML structure for SRDs.</description>
  <srdDate>2005-07-16T19:20:30+01:00</srdDate>
  <docs>http://www.ietf.org/</docs>
  <core>
    <?srd include="reference.I-D.newtrk-classifications" ?>
    <?srd include="reference.RFC.9875" ?>
  </core>
  <extensions>
    <?srd include="reference.RFC.9912" ?>
  </extensions>
  <guidance>
    <?srd include="reference.RFC.9915" ?>
  </guidance>
  <obsoletes>
    <?srd include="reference.RFC.9811" ?">
  </obsoletes>
  <experimental>
    <?srd include="reference.RFC.9837" ?">
  </experimental>
  <companion>
    <?srd include="reference.I-D.srd-example.1" ?>
  </companion>
  </srd>

The goal is to facilitate automatically generated outputs to present  
the relationships in various formats, and XML offers a good basis for  
this.  Once benefits can be seen personally, eliciting cooperation  
should be less difficult.  Helping IANA would be for more abstract  
reasons, but I will add an IANA section.  Please forgive this initial  
effort.

When the I-D and SRD are both accepted, the rfc editor would change  
the following lines to:

  <srd set='srd-xml.2' >
...
  <srdDate>2005-08-26T13:10:35Z</srdDate>
...
  <core>
    <?srd include="reference.RFC.9940" ?>

-Doug
.