Subject: [ANCP] Updates to draft-ietf-ancp-mc-extensions

From: Tom Taylor <[email-masked]>
Date: Tue, 25 Feb 2014 03:55:34 -0500

draft-ietf-ancp-mc-extensions-15.txt reflects changes that came from 
IESG comments and a discuss from Brian Haberman. The comments in turn 
resulted from a very thorough review by Dacheng Zhang for the Security 
Area directorate and a review by Mehmet Ersue for the Ops Directorate. 
Christer Holmberg also reviewed the document for GenArt, but no action 
items came out of that.

The substantive changes were as follows:

   -- allowed specification of multiple SSM flows to be added or deleted 
by the same Command in the Multicast Replication Control message. See 
full description in item 8) below.

   -- changed a SHOULD NOT to a MUST NOT for unsupported list types in 
the multicast flow profile. See item 4) below.

   -- changed the effect of changes to the Report-Buffering-Time TLV to 
avoid the possible need for two timers. See item 5) below.

Tom Taylor

Here is a summary of the complete set of changes, with a list of the 
affected sections.

1) Editorial: brought terminology into line with RFC 5851. Specifically, 
the terms "conditional access" and "admission control" are now used 
throughout the document in place of "policy-based admission control" and 
"resource-based admission control". Affects numerous sections beginning 
with the Abstract. See Section 2 Terminology for a formal statement.

2) Editorial: recognized that the two conditional access capabilities 
also include admission control by renaming them. Affects several 
sections beginning with the Abstract.

3) Editorial: in Section 1, second paragraph after the bulleted list of 
capabilities, described the multicast-related sub-sections of RFC 5851 
more accurately.

4) Editorial: added new sub-section 1.1 A Note On Scope to bring out 
architectural assumptions made in RFC 5851 and their impact.

5) Editorial/architectural: added a paragraph at the end of introductory 
Section 3 to say that in the use cases following, the Home Gateway could 
operate either in bridged or in routed mode, but the latter might be 
required to allow hosts behind the Home Gateway to get access to 
non-IPTV multicast services. The figures following were modified 
accordingly.

6) Substantive: in Section 4.1.1, changed the prohibition of a list type 
not supported by the negotiated set of capabilities from a SHOULD NOT to 
a MUST NOT.

7) Substantive: in Section 4.1.2, made a slight change to the effect of 
receiving a new value of the Report-Buffering-Time TLV. The original 
statement suggested that two timers might be needed rather than one.

OLD

The buffering time specified in an instance of the Report-Buffering-
Time TLV applies only to Committed Bandwidth Report messages
initiated after the new buffering time is received at the AN, not to
any message already in the process of accumulation.

NEW

The buffering time specified in an instance of the Report-Buffering-
Time TLV will not be applied until the current accumulation process
of Committed Bandwidth Report messages finishes.

8) Substantive: in SSM, IGMPv3 and MLDv2 allow the Join to specify 
multiple sources for a specific group. To support this, the 
Multicast-Flow TLV has been significantly restructured by using the 
previously reserved field to  give the number of source addresses and 
allowing multiple source addresses at the end of the TLV. See Section
5.12.

Receiver behaviour for the Multicast Replication Control message 
(Section 4.3.2) now talks about the Command TLV adding one or flows 
rather than a flow, and error processing in the same section now deals 
with the case of an error in the middle of processing a list of SSM flows.

A pending update to Section 5.12 to close out the Discuss will indicate 
that the Multicast-Flow TLV supports INCLUDE mode only, with reference 
to RFC 5790 for guidance on converting EXCLUDE mode to INCLUDE mode.

9) Non-normative: added new Section 7 Miscellaneous Considerations 
section discussing two topics. The first is an appropriate value for the 
Report-Buffering-Time TLV for the Committed Bandwidth Reporting 
capability and its potential impact. I would be happy for comments on 
this one, since the current text makes some rather extreme assumptions. 
The second topic is a warning to implementors that they have to be 
careful about control plane overloading, since otherwise a single 
channel-surfing subscriber might generate enough messaging traffic to 
bring down the AN or cause significant congestion.

10) Security recommendation: added a paragraph to Security 
Considerations recommending that operators protect the path between the 
NAS and AAA, in accordance with RFC 6733 if using Diameter, or applying 
RFC 6614 for RADIUS.

11) Editorial: extended the acknowledgements, added a number of references.