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 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.
[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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf