ietf
[Top] [All Lists]

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

2011-04-15 09:57:03
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Gen-ART LC Review of draft-ietf-ancp-protocol-15, Tom Taylor <=