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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf