Subject: Re: Gen-ART LC Review of draft-ietf-ancp-protocol-15

From: Tom Taylor <[email-masked]>
Date: Thu, 14 Apr 2011 20:24:17 -0400

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.