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

From: Allison Mankin <[email-masked]>
Date: Tue, 23 Aug 2005 06:05:03 -0700

Hi, TSVWG,

This begins the Working Group Last Call for 
draft-ietf-tsvwg-sctp-impguide-14.txt for Informational
publication.  Please send comments and reviews before 
September 5.  A couple of reviews that state "have read it
as part of my working group participation and
view it as ready for publication" would be appreciated.

(We're going to make this request on all the WGLC's,
not singling out the Implementer's Guide).

Thanks!

P.S. I'll send out an email addressing the four nits the
idnits tools finds.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Aug 2005 07:38:08 -0600

Allison,

I am confused about the "Informational" designation.  The
Implementor's Guide, as you know, is written in a style that
provides replacement text for RFC 2960, and uses requirements
language.  RFC 2960 is, of course, a "Proposed Standard".  So,
my confusion is how an "Informational" RFC can replace text in a
"Proposed Standard"?

--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 ¦

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Aug 2005 10:24:08 -0700

2960 is a protocol spec; this is an implementer's guide.

It's not clear either the term 'implementer's' or 'guide' should apply
to a standards-track doc. Maybe BCP?

Joe

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Aug 2005 11:54:50 -0600

Joe,

I believe the name is ala ITU, where:

   "Implementation Guide" => "Errata"

Normally in the SIGTRAN WG we take the imp guide and combine it with the
protocol spec to form a -bis (more ITU jargon) document, the final
document being a replacement protocol spec.

I thinks that this draft goes beyond a BCP, because it make corrections
and adds some new protocol requirements (such as max burst, cookie
handling, fixing security holes, adding code points for protocol
parameters requiring IANA actions, etc.  I does not contain many
interpretations or operational considerations.

I asked about the status of this document back in Feb 2003 and I was
told by Michael Tuexen that "the SCTP IG will never become an RFC as far
as I know.  It is the 'delta' which will be applied to RFC 2960 when
SCTP is moved from PS to DS or PS again."  A point with which I agree.

IMHO it has little to no use as an "Informational" RFC if it does not
actually modify the PS.  It might just as well remain a draft.

What I would prefer to see is the deltas detailed in the draft applied
to RFC 2960 to create an rfc2960-bis draft that we could comment on and
advance as a new, corrected and updated, PS for SCTP.

But that would be a lot of work and I don't know that the authors or the
WG are up to that challenge with all the other items on the work agenda.

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 23 Aug 2005 20:17:19 +0200

Brian,

the idea is to finalize the work on the IG by making it an
Informational RFC. After that, work on a -bis document which
is basically RFC2960 plus the deltas in the IG will be started
and results in a new protocol specification for SCTP, updating
RFC 2960.

This procedure makes sure that the information in the IG
(what has  changed to RFC 2960 and why) is not lost as compared to
'just making a -bis document'.

Best regards
Michael

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Aug 2005 12:58:43 -0700

>    "Implementation Guide" => "Errata"

Yes, but this being the IETF it would be more useful to indicate it as
"Update to the SCTP Protocol" than to imply that it is either a guide
(rather than a change in the required specification) or focused on
implementation (rather than specification) issues.

> WG are up to that challenge with all the other items on the work agenda.

Agreed on all points; IMO, most of the concerns might be addressed by
making the document title more clear, at least, regardless of what track
the document ends up on.

Joe