Subject: Re: [ANCP] [Fwd: I-D ACTION:draft-ietf-ancp-mc-extensions-01.txt]

From: Tom Taylor <[email-masked]>
Date: Sun, 14 Feb 2010 21:40:19 -0500

I'm working on getting the multicast extensions document into shape for review 
leading up to WGLC, and responding to these comments as a part of the process. 
See responses below marked [PTT].

Francois Le Faucheur wrote:
> Tom and all,
> 
>> Francois had a hand in getting the main ideas into shape, but due to 
>> circumstances on my side he didn't have a chance to read and approve 
>> the final version of the draft.
> 
> I reviewed the final text of section 6. In general, it is in line with 
> the discussions & conclusions Tom and I had.
> 
> Below are a the most important comments that I'd like to make sure we 
> agree on:
> 
> * 6.2.1. The case where CAC is done on NAS is clearly implied but not 
> explicit. I think we want to be explicit about it. So I propose:
> REPLACE:
> "The NAS MAY enable admission control at the AN for Nas-initiated 
> replication.  To do this, it MUST include the MRepCtl-CAC TLV in a 
> Provisioning message sent to the AN.  It MUST also include a 
> Bandwidth-Allocation TLV in a Port Management message for each access line.
> "
> BY:
> "The NAS MAY perform admission control of the NAS-initiated replication. 
> Alternatively, the NAS MAY enable admission control at the AN for 
> NAS-initiated replication.  To do this, it MUST include the MRepCtl-CAC 
> TLV in a Provisioning message sent to the AN and it MUST include a 
> Bandwidth-Allocation TLV in a Port Management message for each access line.
> "
[PTT] Done.
> 
> * 6.2.3.1. The case where CAC is done on NAS is clearly implied but not 
> explicit. I think we want to be explicit about it. So I propose:
> REPLACE:
> "The NAS can enable admission control at the AN for Grey-listed flows. 
> To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning 
> message sent to the AN.  It MUST also provide a Bandwidth-Allocation TLV 
> in a Port Management message for each access line.
> "
> BY:
> "The NAS MAY perform admission control for grey-listed flows. 
> Alternatively, the NAS MAY enable admission control at the AN for 
> Grey-listed flows. To do this, it MUST include the MRepCtl-CAC TLV in a 
> Provisioning message sent to the AN and MUST also provide a 
> Bandwidth-Allocation TLV in a Port Management message for each access line.
> "
> 
[PTT] Done.
> 
> * Result Codes
> On Tom's proposal, -01 reverted to using Result values AckAll & NAck 
> instead of Ignore (as was done in previous versions) with a few commands 
> where AckAll & NAck seem ed to match teh desired response behavior. I 
> don't feel strongly about that, but want to point out this is a 
> departure from what was agreed before and I am requesting WG opinions on 
> that.
> 
[PTT] I've assumed this is acceptable to the WG.
> 
> * Response to Multicast Replication Control:
> This comment assumes that the WG agrees that Results AckAll & NAck is 
> the right approach for some commands like Multicast Replication Control.
> Tom and I agreed that the NAS decides whether to use AckAll or NAck.
> This has been reflected correctly in 4.3.1:
> "In that case, the NAS MUST set the Result field to AckAll (0x2) or Nack 
> (0x1) according to its requirements."
> But it has not yet been reflected in the multiple relevant subsections 
> under section 6.
> For example, section 6.2.3.2 says:
> " It MUST then send a Multicast Admission Control message to the NAS 
> indicating the deletion."
> While this should depend on Result Code.
> Also, section 6.3.2 says:
> "If the flow was Grey-listed, the AN MUST then send a Multicast 
> Admission Control message to the NAS indicating the deletion.  Thus the 
> AN needs to retain the fact that
>    the flow was Grey-listed for the life of the flow."
> Again, I think responding would depend on the Result field. And I think 
> the AN need not retain the fact that the flow was Grey-Listed.
> 
[PTT] I suspect you're a little confused on the timing. The response or 
non-response is to the Multicast Replication Control message that causes the 
flow to be enabled in the first place. The existing text respects that at the 
time of flow creation. These follow-up Multicast Admission Control messages 
occur perhaps hours later, when the subscriber leaves the flow. The messages 
have the vital task of allowing the NAS to keep its records of active flows up 
to date.
> 
> * section 6.3.3:
> it says:
> "If either or both conditional access capabilities are combined with the 
> delegated bandwidth capability, the AN always does admission
>    control. "
> I think this text is not correct and needs to be updated to reflect the 
> White-List-CAC TLV and the MRepCtl-CAC TLV
> 
[PTT] Fixed, I think. New text is:

  The provisioning and bandwidth management procedures of Section 6.2.4 apply in 
addition to the procedures in Section 6.2.2, Section 6.2.3, or Section 6.3.1 as 
applicable. Admission control follows the rules for conditional access rather 
than the rules in Section 6.2.4.2.
> 
> There is also a bunch of editos I will share off-line with co-authors 
> for next rev.
> 
> Francois
> 
>

---

From: Tom Taylor <[email-masked]>
Date: Sun, 14 Feb 2010 21:42:53 -0500

That is stated in the last paragraph of section 6.2.4.1. I think that's the 
right place for it.

Francois Le Faucheur wrote:
> One additional comment:
> 
> In section 6.2.4.2 (Delegated Bandwidth), I think we need to add a 
> statement along the lines of "The NAS MAY at any time change the 
> allocated bandwidth using …"
> 
> 
> Francois
> 
>...