Re: Gen-ART LC Review of draft-ietf-ancp-protocol-15
Here are our considered responses, generated while I am still editing the -16 version, but I think they'll stick. Tom Taylor On 09/03/2011 7:08 PM, Ben Campbell wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ athttp://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-ancp-protocol-15 Reviewer: Ben Campbell Review Date: 2011-03-09 IETF LC End Date: 2011-03-09 IESG Telechat date: (if known) Summary: This draft is essentially ready for publication as a proposed standard. I have a few minor comments that might be worth considering prior to final publication. Major issues: None Minor issues: -- section 1.1: This specification uses requirements language in lower case and between quotation marks (e.g., must) to denote requirements on the interface between ANCP and the control application. Such requirements are inherently untestable but need to be taken into account by the implementor. I must admit to be curious as to the goal of this approach to normative language. I don't necessarily think it's a problem--I'm just calling it out as unusual in case anyone else cares. [PTT] The intention was to call out potential work items for the Broadband Forum. We agreed in Prague to either drop the text concerned or replace it by narrative descriptions where desirable. -- section 3.1, definition of Identifier Is there any concern about distinguishing between the two (effectively different) protocols with the same value? [PTT] This issue drew a lot of comment/discusses from the IESG. The final resolution was to make ANCP stand alone (RFC 3292 purely informational) and to set up a joint registry for GSMP and ANCP versions (1-3 for GSMP, 50+ for ANCP). The key differentiator between the two protocols would therefore be the version number, which comes at the beginning of every message. -- section 3.2, 2nd to last paragraph: Port 6068 is used for TCP connection. Is this a default, or is it required to always be 6068? [PTT] The list decision was to make it mandatory. -- section 3.5.2, 2nd paragraph: It is RECOMMENDED that both ends specify the same timer value; What are the implications if they dont? [PTT] The timer is related to liveness testing exchanges. One side sends an ACK on timer expiry, the other returns an ACK. It doesn't seem necessary to repeat the exchange with the other side being the initiator. The second exchange can be avoided by adding the instruction that when an ACK is received, the receiver resets its timer. -- 3.6.1.4, Code value 7, recommended action : If multiple instances of this error occur... Can you provide any guidance on how many? I'm not asking for an exact count, but a general idea would be helpful. [PTT] I provided an analysis to the list yesterday showing that this error can never actually occur. The error is defined in GSMPv3, but if you make the assumption that multiple adjacencies can be multiplexed over the same TCP connection (something the WG decided a year or two ago), messages get demultiplexed by Partition ID. Thus a message with the wrong Partition ID never gets steered to an adjacency where it is wrong. (It is dropped silently if the ID isn't in use.) Nits/editorial comments: -- section 1, 1st paragraph: Please expand QoS on first mention [PTT] Done. -- 3.1, RFC Editor's Note: Any reason not to make the change in the draft prior to approval? [PTT] Done. Also got rid of sub-version and just specified the version to be 50 (0x32). -- 5.1.2, heading before first bullet: As normative requirements on ANCP agents conforming to this section: I don't follow the sentence structure for this heading. [PTT] Rephrased to: ANCP agents conforming to this section MUST satisfy the following requirements: -- 9.2, general: Can you reference the explicit URLs for the mentioned existing registries? [PTT] Will do, but with independence from RFC 3292, the only existing one that will be referenced relates to port assignments. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-ancp-protocol-15
Thanks for your comments. On 09/03/2011 7:08 PM, Ben Campbell wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ athttp://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-ancp-protocol-15 Reviewer: Ben Campbell Review Date: 2011-03-09 IETF LC End Date: 2011-03-09 IESG Telechat date: (if known) Summary: This draft is essentially ready for publication as a proposed standard. I have a few minor comments that might be worth considering prior to final publication. Major issues: None Minor issues: -- section 1.1: This specification uses requirements language in lower case and between quotation marks (e.g., must) to denote requirements on the interface between ANCP and the control application. Such requirements are inherently untestable but need to be taken into account by the implementor. I must admit to be curious as to the goal of this approach to normative language. I don't necessarily think it's a problem--I'm just calling it out as unusual in case anyone else cares. [PTT] My concern as the editor who came up with this was to call out requirements for the Broadband Forum to consider if and when they get around to updating TR-147. -- section 3.1, definition of Identifier Is there any concern about distinguishing between the two (effectively different) protocols with the same value? [PTT] As far as we know, GSMP has never been deployed. -- section 3.2, 2nd to last paragraph: Port 6068 is used for TCP connection. Is this a default, or is it required to always be 6068? [PTT] Good question. I hope someone else on the distribution list can answer it. -- section 3.5.2, 2nd paragraph: It is RECOMMENDED that both ends specify the same timer value; What are the implications if they dont? [PTT] I can't see what would break, myself. Presumably the state machines would run independently. I don't know if other people have a more specific view. -- 3.6.1.4, Code value 7, recommended action : If multiple instances of this error occur... Can you provide any guidance on how many? I'm not asking for an exact count, but a general idea would be helpful. [PTT] I suppose, more than one. Adjacency reset is a drastic measure and it seemed like some sort of brake was needed. I see your point about lack of precision, though. Nits/editorial comments: -- section 1, 1st paragraph: Please expand QoS on first mention [PTT] OK -- 3.1, RFC Editor's Note: Any reason not to make the change in the draft prior to approval? [PTT] That's a thought. Now that the WG is done with the draft, it should be OK. -- 5.1.2, heading before first bullet: As normative requirements on ANCP agents conforming to this section: I don't follow the sentence structure for this heading. s/As/Here are the/ -- 9.2, general: Can you reference the explicit URLs for the mentioned existing registries? [PTT] OK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC Review of draft-ietf-ancp-protocol-15
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-ancp-protocol-15 Reviewer: Ben Campbell Review Date: 2011-03-09 IETF LC End Date: 2011-03-09 IESG Telechat date: (if known) Summary: This draft is essentially ready for publication as a proposed standard. I have a few minor comments that might be worth considering prior to final publication. Major issues: None Minor issues: -- section 1.1: This specification uses requirements language in lower case and between quotation marks (e.g., must) to denote requirements on the interface between ANCP and the control application. Such requirements are inherently untestable but need to be taken into account by the implementor. I must admit to be curious as to the goal of this approach to normative language. I don't necessarily think it's a problem--I'm just calling it out as unusual in case anyone else cares. -- section 3.1, definition of Identifier Is there any concern about distinguishing between the two (effectively different) protocols with the same value? -- section 3.2, 2nd to last paragraph: Port 6068 is used for TCP connection. Is this a default, or is it required to always be 6068? -- section 3.5.2, 2nd paragraph: It is RECOMMENDED that both ends specify the same timer value; What are the implications if they dont? -- 3.6.1.4, Code value 7, recommended action : If multiple instances of this error occur... Can you provide any guidance on how many? I'm not asking for an exact count, but a general idea would be helpful. Nits/editorial comments: -- section 1, 1st paragraph: Please expand QoS on first mention -- 3.1, RFC Editor's Note: Any reason not to make the change in the draft prior to approval? -- 5.1.2, heading before first bullet: As normative requirements on ANCP agents conforming to this section: I don't follow the sentence structure for this heading. -- 9.2, general: Can you reference the explicit URLs for the mentioned existing registries? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC Review of draft-ietf-ancp-protocol-15
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-ancp-protocol-15 Reviewer: Ben Campbell Review Date: 2011-03-09 IETF LC End Date: 2011-03-09 IESG Telechat date: (if known) Summary: This draft is essentially ready for publication as a proposed standard. I have a few minor comments that might be worth considering prior to final publication. Major issues: None Minor issues: -- section 1.1: This specification uses requirements language in lower case and between quotation marks (e.g., must) to denote requirements on the interface between ANCP and the control application. Such requirements are inherently untestable but need to be taken into account by the implementor. I must admit to be curious as to the goal of this approach to normative language. I don't necessarily think it's a problem--I'm just calling it out as unusual in case anyone else cares. -- section 3.1, definition of Identifier Is there any concern about distinguishing between the two (effectively different) protocols with the same value? -- section 3.2, 2nd to last paragraph: Port 6068 is used for TCP connection. Is this a default, or is it required to always be 6068? -- section 3.5.2, 2nd paragraph: It is RECOMMENDED that both ends specify the same timer value; What are the implications if they dont? -- 3.6.1.4, Code value 7, recommended action : If multiple instances of this error occur... Can you provide any guidance on how many? I'm not asking for an exact count, but a general idea would be helpful. Nits/editorial comments: -- section 1, 1st paragraph: Please expand QoS on first mention -- 3.1, RFC Editor's Note: Any reason not to make the change in the draft prior to approval? -- 5.1.2, heading before first bullet: As normative requirements on ANCP agents conforming to this section: I don't follow the sentence structure for this heading. -- 9.2, general: Can you reference the explicit URLs for the mentioned existing registries? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
