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