Re: [Gen-art] Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt
Ben - Thanx for the review. Inline. -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Tuesday, October 05, 2010 12:06 PM To: draft-ietf-isis-genapp@tools.ietf.org; General Area Review Team Cc: The IETF Subject: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-isis-genapp-03.txt Reviewer: Ben Campbell Review Date: 05 Oct 2010 IESG Telechat date: 07 Oct 2010 Summary: The draft is almost ready for publication as a proposed standard, but I have some concerns that I think should be addressed first. Major issues: -- This draft creates an expansion code point in an IANA registry, where the expansion registration requirements are weaker than those of the parent registry. This always makes me nervous, as it opens the window for end-runs around the registration requirements of the parent. In this particular instance, the parent registry policy is expert review while the proposed expansion registry policy is specification required. This draft puts normative requirements on the content of the required specifications, and makes additional non-normative statements about the intended use of the GENINFO code point. This implies to me that the review process needs to do more than determine that sufficient specification exists. Rather, it needs to determine that the criteria in this draft are met by that specification. Therefore, I think that it would be appropriate for the GENINFO registry to use the expert review policy. From RFC 5226: Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification... We deliberately chose Specification Required because: a)It requires a public specification b)It allows the public specification to be other than an RFC c)It requires expert review Minor issues: -- section 4.2, 2nd paragraph: Where this is not possible, the two affected LSPs SHOULD be flooded as an atomic action Any reason that this is not a MUST, since it seems like the safety-net behavior for when the aforementioned SHOULD is not possible to follow? It is a recommended behavior. If an implementation does not do this it does not create an interoperability issue - but it may create sub-optimal behavior. -- Section 4.3: When information in the two GENINFO TLVs conflicts i.e there are different settings for a given attribute, the procedure used to choose which copy shall be used is undefined. Should their be normative requirement not to create this undefined condition in the first place? If the revised version of a GENINFO TLV is sent in an LSP with a different number from the previous version there can be transient windows where other systems have two copies of information regarding the same application. This may be unavoidable. For completeness we specify that the choice of what to do in such transient situations is implementation specific (undefined). This section does specify ways to minimize the occurrence/duration of such transient periods. -- Security Considerations: This seems too lightweight. Is it impossible for GENINFO applications to include sensitive information? Are there no security guidelines that should apply to GENINFO application specifications? We have no way of knowing what type of information might be advertised by a given application - and we are not limiting what may be advertised. Clearly the public document which specifies the application would need to address the security issues it introduces. We cannot do that here. Even if the answer is that the underlying IS-IS protocol provides sufficient security for any reasonable use of the GENINFO code point, it would be worth saying that explicitly. Nits/editorial comments: -- section 2 Please expand IS-IS and PDU on first mention. OK -- section 6, last paragraph: Expected/desired by whom? Well, at least by the authors. :-) -- Outdated reference for draft-ietf-isis-mi It was current at the time the draft was written. Les ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt
Thanks for the quick response. Comments inline: On Oct 6, 2010, at 7:55 AM, Les Ginsberg (ginsberg) wrote: Ben - Thanx for the review. Inline. -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Tuesday, October 05, 2010 12:06 PM To: draft-ietf-isis-genapp@tools.ietf.org; General Area Review Team Cc: The IETF Subject: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-isis-genapp-03.txt Reviewer: Ben Campbell Review Date: 05 Oct 2010 IESG Telechat date: 07 Oct 2010 Summary: The draft is almost ready for publication as a proposed standard, but I have some concerns that I think should be addressed first. Major issues: -- This draft creates an expansion code point in an IANA registry, where the expansion registration requirements are weaker than those of the parent registry. This always makes me nervous, as it opens the window for end-runs around the registration requirements of the parent. In this particular instance, the parent registry policy is expert review while the proposed expansion registry policy is specification required. This draft puts normative requirements on the content of the required specifications, and makes additional non-normative statements about the intended use of the GENINFO code point. This implies to me that the review process needs to do more than determine that sufficient specification exists. Rather, it needs to determine that the criteria in this draft are met by that specification. Therefore, I think that it would be appropriate for the GENINFO registry to use the expert review policy. From RFC 5226: Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification... We deliberately chose Specification Required because: a)It requires a public specification b)It allows the public specification to be other than an RFC c)It requires expert review Completing the sentence in your quote: who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. My understanding of Specification Required is that the expert review is merely to ensure that the documentation is sufficiently complete and readable to implement in an interoperable way. That review is not intended to ensure compliance to other criteria specified in the draft. However, the draft includes some specific criteria for GENINFO applications. If you want the reviewer to enforce those criteria, then I think you need at least Expert Review. OTOH, in RFC5226, the expert review policy has less to say about the required level of documentation, so the draft might require some more meat in that area. I note that while RFC3563, which established the IS-IS TLV Codepoint registry, says Expert Review, the review criteria is pretty much equivalent to standards action. I'm guessing the only reason it was not standards action was to allow ISO/IEC JTC1/SC6 to submit specifications, which are to be held to the same standard as a standards-track RFC, but do not actually get published as such. So for practical purposes, the proposed policy for GENINFO is significantly weaker than for the parent registry--more so than one might think from just looking at the registry itself. Minor issues: -- section 4.2, 2nd paragraph: Where this is not possible, the two affected LSPs SHOULD be flooded as an atomic action Any reason that this is not a MUST, since it seems like the safety-net behavior for when the aforementioned SHOULD is not possible to follow? It is a recommended behavior. If an implementation does not do this it does not create an interoperability issue - but it may create sub-optimal behavior. Okay. -- Section 4.3: When information in the two GENINFO TLVs conflicts i.e there are different settings for a given attribute, the procedure used to choose which copy shall be used is undefined. Should their be normative requirement not to create this undefined condition in the first place? If the revised version of a GENINFO TLV is sent in an LSP with a different number from the previous version there can be transient windows where other systems have two copies of information regarding the same application. This may be unavoidable. For completeness we specify that the choice of what to do in such
Re: [Gen-art] Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt
Ben - -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Wednesday, October 06, 2010 7:10 AM To: Les Ginsberg (ginsberg) Cc: draft-ietf-isis-genapp@tools.ietf.org; General Area Review Team; The IETF Subject: Re: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp- 03.txt Thanks for the quick response. Comments inline: On Oct 6, 2010, at 7:55 AM, Les Ginsberg (ginsberg) wrote: Ben - Thanx for the review. Inline. -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Tuesday, October 05, 2010 12:06 PM To: draft-ietf-isis-genapp@tools.ietf.org; General Area Review Team Cc: The IETF Subject: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-isis-genapp-03.txt Reviewer: Ben Campbell Review Date: 05 Oct 2010 IESG Telechat date: 07 Oct 2010 Summary: The draft is almost ready for publication as a proposed standard, but I have some concerns that I think should be addressed first. Major issues: -- This draft creates an expansion code point in an IANA registry, where the expansion registration requirements are weaker than those of the parent registry. This always makes me nervous, as it opens the window for end-runs around the registration requirements of the parent. In this particular instance, the parent registry policy is expert review while the proposed expansion registry policy is specification required. This draft puts normative requirements on the content of the required specifications, and makes additional non-normative statements about the intended use of the GENINFO code point. This implies to me that the review process needs to do more than determine that sufficient specification exists. Rather, it needs to determine that the criteria in this draft are met by that specification. Therefore, I think that it would be appropriate for the GENINFO registry to use the expert review policy. From RFC 5226: Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification... We deliberately chose Specification Required because: a)It requires a public specification b)It allows the public specification to be other than an RFC c)It requires expert review Completing the sentence in your quote: who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. My understanding of Specification Required is that the expert review is merely to ensure that the documentation is sufficiently complete and readable to implement in an interoperable way. That review is not intended to ensure compliance to other criteria specified in the draft. However, the draft includes some specific criteria for GENINFO applications. If you want the reviewer to enforce those criteria, then I think you need at least Expert Review. OTOH, in RFC5226, the expert review policy has less to say about the required level of documentation, so the draft might require some more meat in that area. This is a bit distressing - because you are suggesting that RFC 5226 doesn't define a category which is appropriate for our usage - which means we have to try to define a unique policy. I am not quite sure how to do that with sufficient authority and minimal controversy. My understanding is that RFC 5226 is specific to IANA considerations - so we have attempted to define a clear policy as to how the review of code point assignments is done. Beyond that, it seems clear that a given Application specification could specify behavior that might be seen as undesirable e.g. it could specify some extremely high rate of updates. Given that we allow application specification to be defined in public documents from a variety of sources, I don't see how we could define an enforceable review policy for the application specifications. It is at the IANA codepoint allocation that we have control - and certainly it seems within the purview of an expert to say I think your specification is flawed and I won't approve the allocation of codepoints until the issues of concern are addressed. I note that while RFC3563, which established the IS-IS TLV Codepoint registry, says Expert Review, the review criteria is pretty much equivalent to standards action. I'm guessing the only
Re: [Gen-art] Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt
On Oct 6, 2010, at 10:14 AM, Les Ginsberg (ginsberg) wrote: [...] From RFC 5226: Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification... We deliberately chose Specification Required because: a)It requires a public specification b)It allows the public specification to be other than an RFC c)It requires expert review Completing the sentence in your quote: who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. My understanding of Specification Required is that the expert review is merely to ensure that the documentation is sufficiently complete and readable to implement in an interoperable way. That review is not intended to ensure compliance to other criteria specified in the draft. However, the draft includes some specific criteria for GENINFO applications. If you want the reviewer to enforce those criteria, then I think you need at least Expert Review. OTOH, in RFC5226, the expert review policy has less to say about the required level of documentation, so the draft might require some more meat in that area. This is a bit distressing - because you are suggesting that RFC 5226 doesn't define a category which is appropriate for our usage - which means we have to try to define a unique policy. I am not quite sure how to do that with sufficient authority and minimal controversy. My understanding is that RFC 5226 is specific to IANA considerations - so we have attempted to define a clear policy as to how the review of code point assignments is done. Beyond that, it seems clear that a given Application specification could specify behavior that might be seen as undesirable e.g. it could specify some extremely high rate of updates. Given that we allow application specification to be defined in public documents from a variety of sources, I don't see how we could define an enforceable review policy for the application specifications. It is at the IANA codepoint allocation that we have control - and certainly it seems within the purview of an expert to say I think your specification is flawed and I won't approve the allocation of codepoints until the issues of concern are addressed. Yes, both specification required and expert review involve expert review. But they have significant differences in the scope of the review. Specification required means that the expert should review to make sure the specification is clear enough to be implemented in an interoperable fashion. It doesn't in any way indicate that the expert thinks the code point is good, or that it conforms to the purpose of the registry. Certainly, the expert could offer advise on issues, but the registrant would not be under any obligation to follow the advise. Expert Review means that the expert should review a registration to make sure that it conforms to the criteria set forth in the document that defined the registry. I really think that is what you are looking for, particularly from your last sentence above about the expert being able to block allocation of a flawed code point. For example, RFC 3563 calls out Expert Review, and sets a number of criteria, one of which is the assertion that registrations require standards actions, or that they require publications from ISO/IEC JTC1/SC6 that meant the normal requirements for an RFC. In your case, I think you need Expert Review, with criteria along the lines that registrants must meet the requirements of specification required, that it must describe its expected rate of updates (and that this not be excessive), that it must address any security considerations, etc. I note that while RFC3563, which established the IS-IS TLV Codepoint registry, says Expert Review, the review criteria is pretty much equivalent to standards action. I'm guessing the only reason it was not standards action was to allow ISO/IEC JTC1/SC6 to submit specifications, which are to be held to the same standard as a standards-track RFC, but do not actually get published as such. So for practical purposes, the proposed policy for GENINFO is significantly weaker than for the parent registry--more so than one might think from just looking at the registry itself. I am not clear on why Expert Review is seen as a stronger review criteria than Specification Required - which includes expert review as well as a requirement for a public specification. Actually, expert review doesn't have to be stronger than specification required. But it can be. It's all a matter of how you define the review criteria. The difference is, in expert
Re: [Gen-art] Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt
Ben - The points you make below make sense to me - but I am not sure how we get the stronger review process associated w Expert Review and at the same time require that some public document exist for each application. Are you saying that we can require both? I actually thought that was the intent of Specification Required - but your comments suggest otherwise. I really wish RFC 5226 addressed this more robustly... Les -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Wednesday, October 06, 2010 8:55 AM To: Les Ginsberg (ginsberg) Cc: draft-ietf-isis-genapp@tools.ietf.org; General Area Review Team; The IETF Subject: Re: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp- 03.txt On Oct 6, 2010, at 10:14 AM, Les Ginsberg (ginsberg) wrote: [...] From RFC 5226: Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification... We deliberately chose Specification Required because: a)It requires a public specification b)It allows the public specification to be other than an RFC c)It requires expert review Completing the sentence in your quote: who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. My understanding of Specification Required is that the expert review is merely to ensure that the documentation is sufficiently complete and readable to implement in an interoperable way. That review is not intended to ensure compliance to other criteria specified in the draft. However, the draft includes some specific criteria for GENINFO applications. If you want the reviewer to enforce those criteria, then I think you need at least Expert Review. OTOH, in RFC5226, the expert review policy has less to say about the required level of documentation, so the draft might require some more meat in that area. This is a bit distressing - because you are suggesting that RFC 5226 doesn't define a category which is appropriate for our usage - which means we have to try to define a unique policy. I am not quite sure how to do that with sufficient authority and minimal controversy. My understanding is that RFC 5226 is specific to IANA considerations - so we have attempted to define a clear policy as to how the review of code point assignments is done. Beyond that, it seems clear that a given Application specification could specify behavior that might be seen as undesirable e.g. it could specify some extremely high rate of updates. Given that we allow application specification to be defined in public documents from a variety of sources, I don't see how we could define an enforceable review policy for the application specifications. It is at the IANA codepoint allocation that we have control - and certainly it seems within the purview of an expert to say I think your specification is flawed and I won't approve the allocation of codepoints until the issues of concern are addressed. Yes, both specification required and expert review involve expert review. But they have significant differences in the scope of the review. Specification required means that the expert should review to make sure the specification is clear enough to be implemented in an interoperable fashion. It doesn't in any way indicate that the expert thinks the code point is good, or that it conforms to the purpose of the registry. Certainly, the expert could offer advise on issues, but the registrant would not be under any obligation to follow the advise. Expert Review means that the expert should review a registration to make sure that it conforms to the criteria set forth in the document that defined the registry. I really think that is what you are looking for, particularly from your last sentence above about the expert being able to block allocation of a flawed code point. For example, RFC 3563 calls out Expert Review, and sets a number of criteria, one of which is the assertion that registrations require standards actions, or that they require publications from ISO/IEC JTC1/SC6 that meant the normal requirements for an RFC. In your case, I think you need Expert Review, with criteria along the lines that registrants must meet the requirements of specification required, that it must describe its expected rate of updates (and that this not be excessive), that it must address any security considerations, etc. I note that while RFC3563, which established the IS-IS TLV Codepoint registry, says Expert Review, the review criteria is pretty much equivalent to
Re: [Gen-art] Gen-ART Telechat review of draft-ietf-tsvwg-sctp-chunk-flags-01.txt
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. 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. Thanks Suresh ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-grow-bgp-graceful-shutdown-requirements-04
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other last call comments you may receive. Document: draft-ietf-grow-bgp-graceful-shutdown-requirements-04 Reviewer: Wassim Haddad Review Date: 2010-10-06 IETF LC End Date: 2010-09-27 IESG Telechat date: 2010-10-07 Summary: The draft is ready for publication as an informational standard. Major issues: None Minor issues: None Regards, Wassim H. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Telechat review of draft-ietf-tsvwg-sctp-chunk-flags-01.txt
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. 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 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Telechat review of draft-ietf-tsvwg-sctp-chunk-flags-01.txt
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 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC/Telechat Review of draft-ietf-isis-genapp-03.txt
On Oct 6, 2010, at 11:08 AM, Les Ginsberg (ginsberg) wrote: Ben - The points you make below make sense to me - but I am not sure how we get the stronger review process associated w Expert Review and at the same time require that some public document exist for each application. Are you saying that we can require both? I actually thought that was the intent of Specification Required - but your comments suggest otherwise. I really wish RFC 5226 addressed this more robustly... Don't take the choices in RFC 5226 as the only thing you can do--there's room for tweaking them to your needs. It seems like you are really looking for the union of Expert Review and Specification Required. It's easier to start from Expert Review since it is the more flexible of the two policies ( in that it explicitly states that the document that establishes the registry will contain the criteria for the review.) It's perfectly okay to have that criteria include something to the effect of The code point must be defined in a publicly available document that substantially meets the requirements of the 'Specification Required' policy in RFC 5226. Les -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Wednesday, October 06, 2010 8:55 AM To: Les Ginsberg (ginsberg) Cc: draft-ietf-isis-genapp@tools.ietf.org; General Area Review Team; The IETF Subject: Re: Gen-ART LC/Telechat Review of draft-ietf-isis-genapp- 03.txt On Oct 6, 2010, at 10:14 AM, Les Ginsberg (ginsberg) wrote: [...] From RFC 5226: Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification... We deliberately chose Specification Required because: a)It requires a public specification b)It allows the public specification to be other than an RFC c)It requires expert review Completing the sentence in your quote: who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. My understanding of Specification Required is that the expert review is merely to ensure that the documentation is sufficiently complete and readable to implement in an interoperable way. That review is not intended to ensure compliance to other criteria specified in the draft. However, the draft includes some specific criteria for GENINFO applications. If you want the reviewer to enforce those criteria, then I think you need at least Expert Review. OTOH, in RFC5226, the expert review policy has less to say about the required level of documentation, so the draft might require some more meat in that area. This is a bit distressing - because you are suggesting that RFC 5226 doesn't define a category which is appropriate for our usage - which means we have to try to define a unique policy. I am not quite sure how to do that with sufficient authority and minimal controversy. My understanding is that RFC 5226 is specific to IANA considerations - so we have attempted to define a clear policy as to how the review of code point assignments is done. Beyond that, it seems clear that a given Application specification could specify behavior that might be seen as undesirable e.g. it could specify some extremely high rate of updates. Given that we allow application specification to be defined in public documents from a variety of sources, I don't see how we could define an enforceable review policy for the application specifications. It is at the IANA codepoint allocation that we have control - and certainly it seems within the purview of an expert to say I think your specification is flawed and I won't approve the allocation of codepoints until the issues of concern are addressed. Yes, both specification required and expert review involve expert review. But they have significant differences in the scope of the review. Specification required means that the expert should review to make sure the specification is clear enough to be implemented in an interoperable fashion. It doesn't in any way indicate that the expert thinks the code point is good, or that it conforms to the purpose of the registry. Certainly, the expert could offer advise on issues, but the registrant would not be under any obligation to follow the advise. Expert Review means that the expert should review a registration to make sure that it conforms to the criteria set forth in the document that defined the registry. I really think that is what you are looking for, particularly from your last sentence above about the expert being able to block allocation of a flawed code point. For example,
