Subject: RE: [newtrk] Meeting discussion of ISDs- part 1 - apparent agreem ent

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 16 Nov 2004 11:31:12 +0100

Actually, I think 3GPP is a very bad example to follow, for various reasons.
They specify systems, we don't!
 
We have to allow updates of ISD's, so we will get versions. However, I do
not think we should have several levels in this version handling, that would
bring us nothing but only create problems.
 
/L-E

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: den 16 november 2004 10:57
To: Brian E Carpenter
Cc: [email-masked]
Subject: Re: [newtrk] Meeting discussion of ISDs- part 1 - apparent agreement

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

Pekka Savola wrote:
> On Mon, 15 Nov 2004, John C Klensin wrote:
> 
>>> On Mon, 15 Nov 2004, John C Klensin wrote:
>>>
>>>> * RFCs will no longer have maturity-level status.  RFC numbers
>>>>  become identifiers of documents.  ISDs carry status
>>>>  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...?
>>
>>
>> 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).
> 
> 
> 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?
> 

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
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html