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

[Michael Tuexen <[e-mail]>]

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

> Hi Michael,
>  Thanks for the quick response. Please see comments inline.
> 
> On 10-10-06 01:50 PM, Michael Tuexen wrote:
>> 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:
>>> 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?
>> 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.
> 
> 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
> 
> 
>> 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.
> 
> 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
>