Subject: [newtrk] RE: comments on "What Standards"

From: <[email-masked]>
Date: Mon, 1 Mar 2004 09:13:33 +0200

Hi Pekka,

> Thanks for the concise draft.  I think it presents some good ideas. 
> However, I don't think they are mature quite yet -- there seem to be some
> "dragons" John Klensin warned about... :-)

I definately agree.  I would like some discussion and some input on
what ideas should be developed further, thanks.
 
> That is:
> 
>  1) maintenance is good, but simplifying the documentation and the "IETF
> official seal" to a few Yes/No -like questions is likely to be rather
> difficult and subjective as well.
> 
> It would be simple to maintain a list of the current status of the work,
> alongside with the commentary if needed, without any kind of "official"
> seal, but I'm not sure whether that would fulfill your requirements.  And
> what if such documentation would have trouble being kept in sync (just look
> at the charters :).

Well, we could talk about how this is done, one idea that has been bubbling in
the back of my mind would be that new RFCs should specify their relationship
to existing RFCs.  Do the update, modify, obsolete entire or parts of existing
RFCs?  Could the list be updated 'automatically' once an RFC is issued?
Already the RFC Editor maintains an eratta list, this could be thought of as
a related activity.
 
>  2) defining "protocol labels" or such may actually prove to be quite a bit
> of a burden, especially if you want to combine more more specifications to
> one.  It may not necessarily be clear what a "protocol" means.  For example,
> if there was an Ethernet MIB and an Ethernet-2 MIB, would they be treated as
> one?  I.e., are you trying to come up with some kind of  "loosely related"
> categories?

This, is clearly an area that needs more input.  If a label would be an
acceptable proposal, we should discuss who creates the label - the AD,
the WG, or ?  Anyhow, I should make an example of this, and maybe this would
make more sense.
 
> Editorial comments:
> -------------------
> 
>     This document is an Internet-Draft and is in full conformance with
>     all provisions of Section 10 of RFC2026 [1].
> 
> ==> no numbered references in the header.

Will fix.
 
>     This document proposes a split between the RFC number of a
>     specification and the label for a protocol or protocol set. The
> 
> ==> I don't recall this memo documenting a split of RFC numbers :-). 

Yup, I backed off of that because I need some more input on that subject ;)

> Moreover, what is "specification" or "protocol"?  Where do BCP or
> Informational documents (for example) fit in here?  I'm not sure if they
> necessarily _specify_ anything so using "specification" to refer to them
> might not be appropriate.

My feeling is that AS documents, BCP documents, requirements, etc. should
be included, where applicable.
 
>     Additionally, as the standards with the IETF produces see wider
>     deployment by parties outside of the IETF, the system of
>     documentation and updating within the IETF may cause some amount of
>     confusion.
> 
> ==> s/with//
> ==> "documentation and updating" of what?  it's not 100% obvious.

Will fix.

>     There may be different expectations of what IETF standards may
>     mean.
> 
> ==> I'd remove the second "may".

OK.
 
>     This section looks in greater detail the affects of the problems
>     listed in section 1.
> 
> ==> s/affects/effects/
> 
>     Bugs in a specification can be found at any point. There have been
>     bugs found in even in Full Standards.
> 
> ==> s/found in/found/
> 
>     In order to populate the label system work, there would need to be
>     a web location for this registry.
> 
> ==> s/to populate/for/ or some other rewording?
> 
>    Information References: 
> 
> ==> s/tion/tional/
> 
>  References
> 
> ==> rename to Normative References or remove altogether (the 
> reference to
> 2026 appears to be redundant)?
> 
>    author wants to thank John Klensen for warning that there may be
> 
> ==> s/Klensen/Klensin/ :)

Will update the rest.

Thanks for you comments,
John

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

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Mon, 1 Mar 2004 16:30:33 +0100

It would indeed make sense to consider these aspects when defining the new standards track.

/L-E

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Spencer Dawkins
> Sent: den 1 mars 2004 15:24
> To: [email-masked]
> Subject: Re: [newtrk] RE: comments on "What Standards"
> 
> 
> Hi, Lars-Erik,
> 
> One major difference is that the mechanism you refer to is only used
> for full Internet Standards, while John is referring describing a
> mechanism that would refer to Proposed and Draft Standards, too.
> 
> I think John would like to see more flexibility, too - I know I would.
> 
> Spencer
> 
> ----- Original Message ----- 
> From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> Sent: Monday, March 01, 2004 9:50 PM
> Subject: RE: [newtrk] RE: comments on "What Standards"
> 
> 
> > John,
> >
> > > Well, we could talk about how this is done, one idea that has
> > > been bubbling in the back of my mind would be that new RFCs
> > > should specify their relationship to existing RFCs.  Do the
> > > update, modify, obsolete entire or parts of existing RFCs?
> > > Could the list be updated 'automatically' once an RFC
> > > is issued? Already the RFC Editor maintains an errata list,
> > > this could be thought of as a related activity.
> >
> > In what way would that differ from what is already done by
> > the RFC editor? As an example, if you use the RFC editor
> > search to find RFC 791, the search results will indicate that
> > the RFC has STANDARD status, obsoletes RFC 760, and has been
> > updated by RFC 1349. At the moment I do not remember where
> > these status values are defined, but I know they are. "Updates"
> > means updates parts of, while "Replaces" means updates entire,
> > etc.
> >
> > Rgds,
> > /L-E
> >
> > This communication is confidential and intended solely for the
> addressee(s). Any unauthorized review, use, disclosure or distribution
> is prohibited. If you believe this message has been sent to you in
> error, please notify the sender by replying to this transmission and
> delete the message without disclosing it. Thank you.
> >
> > E-mail including attachments is susceptible to data corruption,
> interruption, unauthorized amendment, tampering and viruses, and we
> only send and receive e-mails on the basis that we are not liable for
> any such corruption, interception, amendment, tampering or viruses or
> any consequences thereof.
> >
> > .
> > newtrk
> resources:_____________________________________________________
> > mhonarc archive:
> http://darkwing.uoregon.edu/~llynch/newtrk/index.html
> 
> .

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

.

---

From: <[email-masked]>
Date: Tue, 2 Mar 2004 03:55:25 +0200

Hi Spencer,

> ... and well-meaning people who want to use our standards believe us,
> and implement TCP as STD 7, which is only 793 without congestion
> avoidance, large windows or SACK!

That's one of the gotchas that I think we need to fix.  If you believe
us, STDs are good - so if you want to make sure you implement TCP right,
then you should implement STD 7.  

John

.

---

From: [email-masked]
Date: Tue, 2 Mar 2004 11:24:04 +0100

Spencer,
This now brings us back to the base problem.  As I have commented before,
the IETF needs to improve the way external standards bodies can make
normative references to THE LATEST versions of IETF
specifications/standards.  A "good" solution to this problem should also
help solve the "referencing delay" aspect of the RFC Editor queue since
IETF WGs could use the same labels when  to refering to other WGs work in
progress.

IMHO, if we have made a label to refer to this "lumping" of published RFCs
(STD XXX for example) then we could easily extend it to cover works in
progress for which nor previous RFC has been published and for drafts of
ongoing revisions.  The interesting thing is that this same type of label
could be used to point to "stable snap shots" for WGs.

A few examples bring together the "lumping", "SSS" and status sheet ideas
would be:

label XXX:
previously : no record
currently: no record
current latest draft: SSS-XXX-WGfoo-3 (stable snapshot 3rd version from WG
"foo" of potential new STD "XXX")

label YYY:
previously: RFC ZZZ0 (not recommended for deployment in networks - known
errors)
previously: SSS-YYY-WGzoo-15 (not recommended for development nor
depoyment.  previous WG closed after failing to reach agreement with IESG
on proposed revision of STD)
previously: RFC ZZZ1 (recommended to deployment in networks)
currently: RFC ZZZ2 (recommended for experimentation)
current latest draft: SSS-YYY-WGboo-2 (stable snapshot 2nd version from WG
"boo" of proposed revision to STD YYY, also known as RFC ZZZ2bis)

Key points:
- RFC editor would assign new STD numbers "early" (in time for the first WG
SSS release)
- SSS label to include STD number prior to WG name (alpha-numeric sort
would then regroup SSSs for the same STD even if the WG is changed)

- Alistair

                      "Spencer Dawkins"                                                                                                   
                      <spencer@mcsr-labs.         To:      <[email-masked]>                                                     
                      org>                        cc:                                                                                     
                      Sent by:                    Subject: Re: [newtrk] RE: comments on "What Standards"                                  
                      owner-newtrk@lists.                                                                                                 
                      uoregon.edu                                                                                                         

                      02/03/2004 01:28                                                                                                    
                      Please respond to                                                                                                   
                      "Spencer Dawkins"                                                                                                   

Hi, Pekka,

My apologies for not being clearer.

I know from previous discussions that John's issue is also about
"lumping" specifications together - using the 791 example, 791 is part
of STD 5, which also includes 792, 922, 950, and 1112. You are correct
that updates/obsoletes is available for individual RFCs, but this type
of "lumping" is not.

You are also correct that additions to/removals from an STD are not
tracked in an obvious way, and this does happen. It doesn't happen
often, but we don't have very many STDs to add to/remove from.

Of course, "lumping" wasn't part of John's original post, so I was
replying based on hallway conversations, not on the actual quoted
message - sorry, and hope this is clearer.

Spencer

----- Original Message -----
From: "Pekka Savola" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 02, 2004 8:01 AM
Subject: Re: [newtrk] RE: comments on "What Standards"

> On Mon, 1 Mar 2004, Spencer Dawkins wrote:
> I think this is incorrect: Updates/Obsoletes are available for every
> specification -- so it is possible to create some "dependency" trees
> automatically based on that information.  Whether that's useful or
not
> is another issue.  That is, an important specification on "label"
can
> appear without having to Update or Obsolete any RFC under a "label".

.