Subject: Re: [Tsvwg] WGLC on the SCTP Implementer's Guide (draft-ietf-tsvwg-sctp-impguide-14.txt)

From: Joe Touch <[email-masked]>
Date: Tue, 23 Aug 2005 13:03:49 -0700

Allison Mankin wrote:
> Folks,
> 
> The procedure Michael summarizes was presented to the WG and given a hum, 
> in fact, but then some SCTP interoperability meetings intervened in which
> finishing touches were given to the actual deltas contained in the document.
> 
> One point that I intended to ask the editors (or perhaps may
> have suggested with too soft a voice, in the past), is for the 
> document to describe its own procedure clearly.  So, instead of saying:
> 
>    This document updates RFC2960 [6] and text within this document
>    supersedes the text found in RFC2960 [6].
> 
> It needs to say:
> 
>    This document is a compilation of all the deltas and errata...
>    Its name is a convention...
>    etc...
> 
> In its current form, and as an Informational, it won't be able to
> supersede and update RFC 2960.  That will only be done by 2960bis.
> If we want the current sentence to be true, we need to use the other
> procedure, making this document a PS, and then obsoleting it
> (really, obviating it) with 2960bis.
> 
> In either case, to underline something in Michael's summary, 2960bis 
> is to be derived from this document by editing alone.  So do consider
> this in your reviewing.

If that's the goal, then I agree with Brian, who questions the utility
of this variant as an interim step.

Joe
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Wed, 24 Aug 2005 14:18:41 -0400

Joe:

The goal of the document is to scope the work
to just an editting one for the RFC2960bis.

Otherwise everyone is going to want to add
all sorts of fun new things to SCTP. The I-G
is thought of as a way to restrain things a bit.

We discussed this in Minn... I am surprised if
you don't like the procedure that you did
not object then..

R

Joe Touch wrote:
> ------------------------------------------------------------------------
> 

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Aug 2005 13:35:13 -0700

> to just an editting one for the RFC2960bis.

That's what IDs are for, IMO, not RFCs. ;-)

> is thought of as a way to restrain things a bit.

Agreed - I don't object to the doc, but am confused by the title and the
consideration that it might have standards-track potential.

> you don't like the procedure that you did

That assumes it wasn't scheduled with an overlap with any other WGs. ;-)

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Aug 2005 13:35:39 -0700

> you don't like the procedure that you did

That assumes it wasn't scheduled with an overlap with any other WGs, and
is why last calls are done on mailing lists rather than at WG meetings ;-)

Joe

---

From: Randall Stewart <[email-masked]>
Date: Wed, 24 Aug 2005 18:51:04 -0400

> consideration that it might have standards-track potential.

Well.. please suggest a different title.. and if that
has WG consenses I would be MOST glad to change it.

I think the only reason it was named so is because we
were patterning an ITU document... not sure why but
I was told to do it that way ;-D

Now, if a different title is appropriate I will
be glad to edit it in .. you do have a much
better knack for naming things than I ;-)
> That assumes it wasn't scheduled with an overlap with any other WGs. ;-)

I think you were there... I remember you commenting on
a different topic.. at least I think :-0

My understanding of the proceedure will be:

a) I-G is last called and we get comments etc
b) The I-G will progress through the IESG and RFC editor
    to Informational status
c) When the I-G hits the RFC editors queue I will start
    the 2960Bis, based just on the I-G.
d) When the Bis finishes out the I-G's RFC will be
    changed to Historic.. aka here are the considerations
    as to how we changed the document from 2960 to xxxxx

That way the Bis, as Allison said, is just a fun
editting task...

I think I will convert the orignal 2960 to XML first
before starting that... sigh.. lots of fun in emacs :->

R

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Aug 2005 21:53:47 -0700

> has WG consenses I would be MOST glad to change it.

If this really is about "SCTP Protocol Specification Errata and Issues",
then that might be a good name (modulo tweaks).

This change might be useful regardless of whether it's going
standards-track or informational - esp. if informational might end up
going historic (but see caveat below).

>    as to how we changed the document from 2960 to xxxxx

This process doesn't seem productive. I am not in favor of creating new
documents which are destined to become historic on definite, short
timescales (esp. those that might be considered a few I-D cycles).

Informational doesn't seem like it ought to ever go to Historic unless
its an informational spec. RFC2026 talks about specifications going to
historic, and this isn't a specification - or doesn't seem to be named
such. I'd prefer the name reflect that it is a spec if that's the case,
but I still don't see why we're creating deliberately ephemeral RFCs.

Joe

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 25 Aug 2005 00:21:17 -0600

Joe,

> >    the 2960Bis, based just on the I-G.

What?  Meaning that the WG will not be allowed to make changes
or properly comment or go through last call on the 2960Bis
document.  That sounds highly irregular.  It might be necessary
to challenge such a document.

> but I still don't see why we're creating deliberately ephemeral RFCs.

I agree.  The RFC editor's queue is far too deep to be placing
such things in it.  Also, with the way things stand, and the
lower priority that is placed on informational RFCs, the 2960bis
PS stands a chance of beating it out of the RFC editor's queue.

What I can't understand is why we don't follow this process:

a)  Apply the changes from the I-G document to RFC 2960 creating
    draft-ietf-tsvwg-rfc2960bis-00.txt as a standards track I-D
    to replace RFC2960 (and RFC3309).

b)  Solicit comments on the I-D.

c)  Last call draft-ietf-tsvwg-rfc2960bis-xx.txt as a new PS
    replacing RFC2960 (and RFC3309).

skipping three of the four steps in the plan at the top of this
message.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Thu, 25 Aug 2005 06:29:23 -0400

> going historic (but see caveat below).

Well, WG, any objections.. if not I will change the
title per Joe's suggestion.. Any tweaks you want to add?
Speak up :-D

> but I still don't see why we're creating deliberately ephemeral RFCs.

Hmm.. it seems to me that the I-G could stay informational. I am
not sure when one marks things "historic"...

But this is not my decision.. its more up to the chairs and
the IESG :-D

R