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

From: Michael Richardson <[email-masked]>
Date: Sun, 14 Aug 2005 17:08:03 -0400

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:
    Brian> Firstly let me say that my personal opinion is that SRDs have a
    Brian> better chance of getting off the ground than ISDs, largely because
    Brian> they are simpler and more straightforward (all we need is
    Brian> xml2srd).

    Brian> Now, can SRDs be used in RFPs?

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

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

  This might be a problem in that it might not actually solve the problem.

  (US,Canada,Mexican) government bureaucrats are constrained by NAFTA Chapter
10, article 1007.
    http://www.dfait-maeci.gc.ca/nafta-alena/chap10-en.asp

  which I attach below. (I know that other trade/procurement agreements say
similar things).

  The IETF is a recognized internaional standards body (I don't know where
that list is). However, not all of our documents are standards, and this
already causes the government people lots of problems.  If the xRD document
is declared not to be a standard, then I guess the RFP will have to read the
xRD document, and copy it by value (rather than reference) into the RFP.
  That's better than #include "rfc-index.txt", but it might not be simple
enough.

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

  That's a major issue.
  I don't have an answer for it, but I don't really see why it an issue for
ISDs and not for SRDs, (and what about for RFC2026 process!). Isn't this the
very problem that we were trying to deal with: reducing the amount of work
required for maintenance of standards?

====

Article 1007: Technical Specifications

1. Each Party shall ensure that its entities do not prepare, adopt or apply
   any technical specification with the purpose or the effect of creating
   unnecessary obstacles to trade.

2. Each Party shall ensure that any technical specification prescribed by its
   entities is, where appropriate:

** (a) specified in terms of performance criteria rather than design or
**    descriptive characteristics; and

** (b) based on international standards, national technical regulations,
**     recognized national standards, or building codes.

3. Each Party shall ensure that the technical specifications prescribed by
   its entities do not require or refer to a particular trademark or name,
   patent, design or type, specific origin or producer or supplier unless there
   is no sufficiently precise or intelligible way of otherwise describing the
   procurement requirements and provided that, in such cases, words such as "or
   equivalent" are included in the tender documentation.

4. Each Party shall ensure that its entities do not seek or accept, in a
   manner that would have the effect of precluding competition, advice that may
   be used in the preparation or adoption of any technical specification for a
   specific procurement from a person that may have a commercial interest in
   that procurement.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 15 Aug 2005 09:41:11 -0700

>   That's better than #include "rfc-index.txt", but it might not be  

Per the draft, an SRD document is established initially as a "work-in- 
progress" document, that upon eventual review by the IESG, may become  
the final SRD.  Perhaps in the initial stages, there will only be the  
"wip" SRD documents until time allows for review.  The current SRD  
draft allows for both an informative document as well as a normative  
document.

> required for maintenance of standards?

There is a fair amount of time spent attempting to understand what  
documents and endeavours are affected by an I-D submitted for IESG  
action.  The "wip" SRD attempts to answer that question as input into  
this review process. (The SRD piggy-backs the I-D within the review  
process.)  Once a comprehensive overlay of SRD documents have been  
established, follow-on efforts needed to introduce new I-Ds would be  
greatly facilitated by these SRDs, where the "wip" SRD would likely  
be just a minor alteration of an existing SRD.

When an endeavour is in need of modification, the SRDs would provide  
insight into related RFCs that need to be examined and perhaps  
changed.  When the author of the I-D already knows which RFC they  
wish to change, conversely the various SRDs would indicate which  
various endeavours such change may affect.  When there is an RFC in  
multiple SRDs, then each SRD may need to evolve separately, to  
preserve a prior method, dependent upon the overarching endeavour.   
The SRD would ensure such details are not overlooked.  Today, this  
would be like saying- Updated by xxxx when used for yyyy.

The SRD should provider greater stability, especially when an RFC is  
used by multiple endeavours.  This stability would benefit those who  
are attempting to document what is needed to satisfy the design of  
the endeavour.

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