Subject: [Gen-art] Gen-ART Telechat review of draft-ietf-tsvwg-sctp-chunk-flags-01.txt

From: Suresh Krishnan <[email-masked]>
Date: Wed, 6 Oct 2010 01:29:34 -0400

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tsvwg-sctp-chunk-flags-01.txt
Reviewer: Suresh Krishnan
Review Date: 2010/10/05
IESG Telechat date: 2010/10/07

Summary: This draft is almost ready for publication as a Proposed 
Standard but it has two minor issues.

Minor
=====

* Introduction

The justification for the draft is a bit vague. It states the following 
as a justification

"Without publication
    of this document, the only way to have done this would have been to
    obsolete [RFC4960], which is not appropriate."

I am not sure how the authors reached such a conclusion. The protocol 
extension documents could just update RFC4960 in order to achieve the 
same result.Can you clarify or delete?

* Section 3.1

Even though this is under the IANA considerations section, the 
instructions seem to be aimed not at IANA but at protocol extension 
designers. Where does the required documentation need to be? In the 
relevant draft or in an IANA registry. The only IANA instruction I can 
see is the sentence beginning with "IANA creates for each new chunk type 
a registration table for the chunk flags for this type."

Thanks
Suresh

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 6 Oct 2010 19:50:08 +0200

Hi Suresh,

thank you very much for the review. See my comments in-line.

Best regards
Michael

On Oct 6, 2010, at 7:29 AM, Suresh Krishnan wrote:

> Summary: This draft is almost ready for publication as a Proposed Standard but it has two minor issues.
> 
> Minor
> =====
> 
> * Introduction
> 
> The justification for the draft is a bit vague. It states the following as a justification
> 
> "Without publication
> I am not sure how the authors reached such a conclusion. The protocol extension documents could just update RFC4960 in order to achieve the same result.Can you clarify or delete?
We can remove it... no problem.
The reason for the document is the following:
SCTP is an extensible protocol. Without that ID, some specification which define an
extension need actually to update the base specification. With the ID, the extension
can just define the extension without touching the base specification. So if someone
wants to implement the base specification, it can no so with completely ignoring the
extension.

Does this make sense to you?
> 
> * Section 3.1
> 
> Even though this is under the IANA considerations section, the instructions seem to be aimed not at IANA but at protocol extension designers. Where does the required documentation need to be? In the relevant draft or in an IANA registry. The only IANA instruction I can see is the sentence beginning with "IANA creates for each new chunk type a registration table for the chunk flags for this type."
Section 3.1 is the updated section 14.1 of RFC 4960. This is explained in Section 3:

   Section 3.1 describes the updated procedure for chunk type
   registration and replaces Section 14.1 of [RFC4960].  Section 3.2
   adds a new procedure for chunk flag registration to the updated
   section 14.1 of [RFC4960].

   IANA is requested to create an SCTP Chunk Flag registry.  The initial
   contents of the registry should be assigned using the values
   specified in Section 3.3.

So what we expect from IANA when this ID is approved is specified in section 3.3.

Does this clarify things?

I talked a while ago with IANA to make sure that they are happy with the document.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 6 Oct 2010 15:55:30 -0400

Hi Michael,
   Thanks for the quick response. Please see comments inline.

> wants to implement the base specification, it can no so with completely ignoring the

It is the word "obsolete" that threw me off in the sentence. It has a 
very specific meaning in RFCs. I see that you meant they need to 
"Update" RFC4960 each  time. Please go ahead remove the text if you are 
fine with doing so.

> So what we expect from IANA when this ID is approved is specified in section 3.3.

Makes sense. As I said, I had no issues with Section 3.2 and 3.3. They 
work great. Did you see the mail from Russ about proposed text for 
Section 3? That would resolve my concern and would make it clearer for 
IANA what they are expected to do.

Thanks
Suresh

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 6 Oct 2010 23:09:18 +0200

On Oct 6, 2010, at 9:55 PM, Suresh Krishnan wrote:

> It is the word "obsolete" that threw me off in the sentence. It has a very specific meaning in RFCs. I see that you meant they need to "Update" RFC4960 each  time. Please go ahead remove the text if you are fine with doing so.
Hi Suresh,

I've removed the text in my CVS version. The next revision will have this change.

Best regards
Michael
> Makes sense. As I said, I had no issues with Section 3.2 and 3.3. They work great. Did you see the mail from Russ about proposed text for Section 3? That would resolve my concern and would make it clearer for IANA what they are expected to do.
> 
> Thanks
> Suresh
>