Subject: [newtrk] Meeting discussion of ISDs- part 1 - apparent agreement

From: John C Klensin <[email-masked]>
Date: Mon, 15 Nov 2004 14:38:56 -0500

Hi.

This is the first of several summaries of my notes from last
week's discussion of ISDs.  Sorry for the delay in getting it
out; I needed to recover a bit.   This note covers things that
we discussed and, I believe, reached agreement on.  The next one
will cover areas where I think we have basic agreement (although
more refinement may be needed), and the others will cover areas
that are still very much under discussion (or where
disagreements are known to exist).  My current intention is to
update the I-D in about a week, reflecting whatever we know by
then.

Topics that I'm going to assume are settled unless the WG Chair
contradicts me or new issues are raised...

* ISDs themselves do not have maturity levels.  Depending on
  other decisions to be made by newtrk, documents referenced
  from an ISD, especially to define a standard, may continue to
  have maturity levels, but the ISD will not.

* ISDs apply at all standards maturity levels, and are not
   just limited to full Standard.  Standards track
   component(s) of an ISD may have PS, DS, or Standard
   maturity level (see subsequent notes for BCP status).
   When appropriate, the maturity level of a given
   RFC-documented specification may be changed by updating
   the ISD, without any change to the RFC text itself.

* RFCs will no longer have maturity-level status.  RFC numbers
  become identifiers of documents.  ISDs carry status
  information for those documents as required.

* ISDs are expected to contain a mixture of normative
  (i.e., defining or making up the standard) and
  non-normative (more informational and commentary)
  materials.  If and when an ISD contains non-normative
  material, it will explicitly identify what is normative
  and what is not. 

* ISDs, and changes to normative elements of ISD text, are
  always Last Called.  

* Going forward, when a standards-track document is Last
  Called, the ISD or ISD update is Last Called with it.

* Confirmed technical changes (i.e., those that have gone
  through an IETF Last Call process) should be included in
  the text of the ISD or might be accessed, in some cases,
  by a pointer/reference, but are normative and treated as
  such.    These technical changes may include errata or
  other document corrections that seem substantive enough
  to become explicitly part of the standard. 

* Unconfirmed errata (e.g., those that have been
  reported to the RFC Editor and verified with the
  author/editor or not at all) are non-normative and may
  be incorporated if labeled as such or may be referenced
  with a stable URI.

* For normative references, the traditional rules about
  stability of targets apply.  Some local explanation may
  appear along with the reference

* It is permitted to supply or include non-normative
  materials by incorporating a URL into the ISD text.  In
  particular, while the ISD may contain (and should
  contain if the targets exist) URI-type links to
  interoperability  reports, unconfirmed errata, and IPR
  statements, those links should be designed so that the
  pointers themselves are stable even though the targets
  may change. 

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Nov 2004 23:12:12 +0200 (EET)

>  information for those documents as required.

I think this gets back to the point of what the RFC documents can 
refer normatively and what not.  If RFCs no longer had maturity levels 
themselves, one would have to refer normatively to ISD as of such and 
such date, or...?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: John C Klensin <[email-masked]>
Date: Mon, 15 Nov 2004 17:19:39 -0500

--On Monday, 15 November, 2004 23:12 +0200 Pekka Savola
<[email-masked]> wrote:

> I think this gets back to the point of what the RFC documents
> can refer normatively and what not.  If RFCs no longer had
> maturity levels themselves, one would have to refer
> normatively to ISD as of such and such date, or...?

Nothing changes (unless Newtrk does something else).   I think
RFCs can reference RFCs (as documents), or ISDs as of a
particular date or version (as standards), or ISDs without a
date/version (as a particular technology).

Does that seem sensible to others?  If so, I'll stop trying to
formulate it into a separate question.

   john

.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Nov 2004 01:13:58 +0200 (EET)

> date/version (as a particular technology).

Umm.. Not sure if this answered my concern.  RFCs can of course 
reference pretty much what they want, but the question is about the 
RFC2026 requirement that certain documents (standards track) must not 
normatively refer to documents of a lower maturity level.

If there is no maturity level attached to an RFC, that would mean that 
for those documents, the only way to do it would be to refer to the 
ISD.  And that in turn might require putting in an "as of" date for 
the ISD, because ISD Z of date x might be completely different than 
ISD Z of date y.

Does this clarity my normative references + maturity levels concern?

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 15 Nov 2004 21:11:47 -0600

John,

I think I agree with everything on your part 1 list. Just to make sure 
I understand what I'm agreeing with...

Spencer

>  Called, the ISD or ISD update is Last Called with it.

On these two - and maybe this is getting ahead of ourselves - I had 
imagined one Last Call, of an ISD, and if the ISD passed, documents 
that the ISD points to are approved for publication with the ISD.

But that's not really the point. You and Scott are better at the 
mechanics than I am; I'm just trying to avoid the "ISD workload for 
IESG = current workload * 2" math, so we don't ADD ISD Last Calls to 
the current process, with no other changes.

>  be incorporated if labeled as such or may be referenced

On these two - "confirmed/unconfirmed" doesn't quite seem right to me 
(I think if I ask John about SMTP or Scott about process, I'm 
"confirming" something). Maybe "consensus/non-consensus" errata? 

.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Nov 2004 09:51:40 +0100

Pekka Savola wrote:
> ISD.  And that in turn might require putting in an "as of" date for the 
> ISD, because ISD Z of date x might be completely different than ISD Z of 
> date y.
> 

I think this is a valid concern, which is a problem today in getting
documents published; ISD simply surfaces the problem. To avoid
publication deadlocks, I think we have to either
1) abolish the rule in 2026 that forbids down-level normative references
or
2) abolish the levels.

Since the key reference in the ISD regime will be something like
"ISD 1002 - 2005.04.01", i.e. version-based rather than level-based,
these two solutions are roughly equivalent anyway; we always want to
refer to the latest approved version of a spec,or to a specific older
one.

I think this can be decoupled from ISDs though - it's a bug in our
reference rules, not in the ISD definition.

     Brian
.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Nov 2004 11:46:20 +0200 (EET)

Hi,

On Tue, 16 Nov 2004, Brian E Carpenter wrote:
>> Umm.. Not sure if this answered my concern.  RFCs can of course reference 
>> pretty much what they want, but the question is about the RFC2026 
>> requirement that certain documents (standards track) must not normatively 
>> refer to documents of a lower maturity level.
>> 
>> If there is no maturity level attached to an RFC, that would mean that for 
>> those documents, the only way to do it would be to refer to the ISD.  And 
>> that in turn might require putting in an "as of" date for the ISD, because 
>> ISD Z of date x might be completely different than ISD Z of date y.
>> 

That's certainly an approach, but I'd guess the RFC2026 requirements 
exist for a reason...

It's certainly questionable in some sense to publish standards track 
documents which are dependent on e.g. implementing an informational or 
experimental document?  Do we really want to go there..?

There may be less need for that for inter-standards track referencing. 
This is certainly something that is felt pretty often: it's actually 
typically pretty difficult to move stuff to Draft Standard because 
specs typically need to (normatively) reference proposed standards. 
This is certainly one reason why a lot of stuff stays at proposed 
standard (and the reason, why it's actually often difficult to move 
some others, even if willing, beyond PS).

But in any case, any deliberation on what to do with the standards 
track needs to take this into account.

---

From: [email-masked]
Date: Tue, 16 Nov 2004 10:57:26 +0100

Brian,
Please remember though that many other standards and specification 
developing organisations (ITU, IEEE, ETSI, 3GPP, etc. plus lots of fora) 
also need to have a solution to this referencing problem of IETF outputs 
(to use the general term).  The nice thing about ISDs, with the OPTIONAL 
use of a date suffix is that other IETF WGs and other SDOs can choose 
which degree of "specificity" is in their reference.

For example, when another IETF WG or other standards body simply wants to 
declare "use the latest version of IETF protocol XXX" than their reference 
would be to ISD xxxx.  If on the other hand a specific version of required 
(essential when the interaction if the protocol in question is more 
explicit) then their reference should be to ISD xxxx yyyy-mm-dd.  We 
therefore need both to be valid references and hence need both to be 
available as URLs.

One other potential aspect to consider is whether or not we also need to 
support the concept of "releases" that are independent of their revision. 
For example, if we had the ISD process in place 15 years old and had ISD 
0012 for YYYv4 would we have created a new ISD number of YYYv6 or would 
this have become ISD 0012 v6? 

Each release may then require updates and/or revisions and so the complete 
ISD reference would be:
        ISD xxxx vy YYYY-MM-DD 
with less specific references such as:
        ISD xxxx vy (undated reference to specific release)
        ISD xxxx (undated reference to any release)
also considered valid.

- Alistair URIE

P.S. Have a look at http://www.3gpp.org/specs/numbering.htm to see how 
3GPP handles this issue of document numbering, releases and revisions. 

Brian E Carpenter <[email-masked]>
Sent by: [email-masked]
16/11/2004 09:51
Please respond to Brian E Carpenter
 
        To:     Pekka Savola <[email-masked]>
        cc:     John C Klensin <[email-masked]>, 
[email-masked]
        Subject:        Re: [newtrk] Meeting discussion of ISDs- part 1 - 
apparent agreement

     Brian
.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 16 Nov 2004 11:19:35 +0100

--On mandag, november 15, 2004 23:12:12 +0200 Pekka Savola 
<[email-masked]> wrote:

> I think this gets back to the point of what the RFC documents can refer
> normatively and what not.  If RFCs no longer had maturity levels

Hmmmm.... in the post-ISD world:

ISDs do not have maturity levels.
RFCs do not have maturity levels on them.
RFCs get their maturity level by being mentioned as such in ISDs.

Seems to me that:

1) an RFC will refer normatively to what it needs to refer to in order to 
get the technology fully specified. Period, end of discussion.

2) An ISD that wishes to confer a maturity level on an RFC (beyond 
Proposed?) is obliged to state (by omission?) that all normatively 
referenced technology is at the same or higher maturity level, or explain 
why it doesn't matter in this case that they aren't.

Seems to me that this is conceptually the same as the "waivers must be 
explicitly mentioned in Last Calls" that was Last Called and approved as 
draft-ymbk-downref-03 in July of this year (not yet published).

To misquote: "Never let your respect for process prevent you from doing 
what's right!"

                        Harald

.