Subject: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments on draft-maglione)

From: "Maglione Roberta" <[email-masked]>
Date: Fri, 23 Nov 2007 08:35:36 +0100

Hello,
	as we discussed during Chicago meeting below is a proposal for modification to the text of draft-ietf-ancp-framework-04.txt in order to introduce Multicast Grey List and leave Black List (i.e. deny) as default behavior. 
We'd appreciate feedback.

Regards,
Roberta

Section 3.4.1
Replace:
" Provisioning the conditional access information on the AN can be done using a "White list" and/or a "Black list".
A White list associated with an Access Port identifies the multicast flows that are allowed to be replicated to that port.  A Black list associated with an Access Port identifies the multicast flows that are not allowed to be replicated to that port."

By:
" Provisioning the conditional access information on the AN can be done using a "White list", "Grey list",  and/or a "Black list". A White list associated with an Access Port identifies the multicast flows that are allowed to be replicated to that port.  A Black list associated with an Access Port identifies the multicast flows that are not allowed to be replicated to that port. A Grey list associated with an Access Port identifies the multicast flows for which the AN on receiving a Join message, before starting traffic replication queries NAS for further authorization. 
Each list contains zero, one or multiple entries and each entry may specify a single flow or contain ranges (i.e. mask on Group address and/or mask on Source address). 

Replace:
"Upon receiving a join message on an Access Port, the Access Node will first check if the requested multicast flow is part of a White list or a Black list associated with that Access Port.  If it is part of a White list, the AN can autonomously start replicating multicast   traffic.  If it is part of a Black list, the AN can autonomously discard the message because the request is not authorized" 

By:

"Upon receiving a join message on an Access Port, the Access Node will first check if the requested multicast flow is part of a White, Grey or a Black list associated with that Access Port.  If it is part of a White list, the AN can autonomously start replicating multicast traffic.  If it is part of a Black list, the AN can autonomously discard the message because the request is not authorized. If it is part of a Grey list the AN uses ANCP to query the NAS, that in turn will respond to the AN indicating whether the join is to be honored (and hence replication performed by the AN) or denied (and hence replication not performed by the AN.)
If a Join message is received by AN for a flow which is not on any list, then it is rejected (i.e. the default behavior is to drop such messages.) If a join is received by AN for a flow that matches multiple lists, then a deterministic algorithm (to be specified in ancp-protocol) is used by the AN to decide which list behavior takes precedence.
Following are some example scenarios:

Scenario 1:
	* no config:
	==> any Join message gets rejected by AN

Scenario 2:
	* White List = { <S=*,G=G1> , <S=*,G=G2>, ... <S=*,G=Gn> }
	==> Join ( S=*,G=Gi) gets honored by AN  ( 1<=i<=n )
	==> everything else gets rejected by AN

Scenario 3:
	* White List = { <S=*,G=G1> , <S=*,G=G2>, ... <S=*,G=Gn> }
	* Grey List = { <S=s,G=Gm> }   m>n
	==> Join ( S=*,G=Gi) gets honored by AN  ( 1<=i<=n )
	==> Join ( S=s,G=Gm) triggers ANCP Admission Request to NAS
	==> everything else gets rejected by AN

Section 3.4.2

Replace:
" One approach is for the AN to query the NAS so that both unicast
      and multicast CAC for the access line are performed by the NAS.
      In this case, the AN can use ANCP to query the NAS, that in turn
      performs multicast CAC and responds to the AN indicating whether
      the join is to be honored (and hence replication performed by the
      AN) or denied.  In the process, the NAS may communicate with a
      Policy Server. 
"
With:
" One approach is for the AN to query the NAS so that both unicast
      and multicast CAC for the access line are performed by the NAS.
      In this case, upon receiving a join to a multicast flow which matches the Grey List, the AN can use ANCP to query the NAS, that in turn
      performs multicast CAC and responds to the AN indicating whether
      the join is to be honored (and hence replication performed by the
      AN) or denied.  In the process, the NAS may communicate with a
      Policy Server. 

Section 4.2
Replace
" The ANCP MUST support providing multicast conditional access
      information to Access Ports on an Access Node, using Black lists
      and White lists. "
By
" The ANCP MUST support providing multicast conditional access
      information to Access Ports on an Access Node, using Black, Grey
      and White lists. "

Replace

"The ANCP MUST support binding a particular Black list and White
      List to a given Access Port"
By:

" The ANCP MUST support binding a particular Black, Grey and White
      List to a given Access Port
"
Replace:

The ANCP MUST support partial updates of the White lists and Black
      lists.
by
The ANCP MUST support partial updates of the White, Grey and Black
      lists.

Replace:
The ANCP MUST allow the AN to query the NAS to request an
      admission decision for replicating a multicast flow to a
      particular Access Port.

By
Upon receiving a join to a multicast flow which matches the Grey List the ANCP MUST allow the AN to query the NAS to request an admission decision for replicating that multicast flow to a particular Access Port.

Section 4.7.6
Replace and split in two

" Upon receiving a join to a multicast flow which does not match any
      entry in the Black List nor in the White List for a specific
      Access Port, the AN must support using ANCP to query the NAS to
      receive a response indicating whether that join is to be honored
      or denied."

By:

" Upon receiving a join to a multicast flow which matches the Grey List for a specific  Access Port, the AN must support using ANCP to query the NAS to receive a response indicating whether that join is to be honored or denied.
"
" The AN must deny any join to a multicast flow that does not match any
      entry in the Black List nor in the White List  nor Grey List for the relevant Access Port"

Adding the following requirements:

"Upon receiving a join to a multicast flow which matches the Grey List, AN is not allowed to propagate that join request, before the successful authorization from the NAS is received."

"Upon receiving a leave to a multicast flow which matches the Grey List, AN SHOULD be able to autonomously stop replication and SHOULD be able to advertise this event to the NAS." 

Section 4.8.6
Adding:
The NAS MUST support using ANCP to incrementally add, remove and modify individual entries in White, Black and Grey lists.

-------------------------------------------------------
Roberta Maglione  - CCIE #18425
Telecom Italia
Broadband Network Services Innovation
------------------------------------------------------- 
________________________________________
From: Michel Platnic [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 8:22 PM
To: Francois Le Faucheur IMAP
Cc: Garofalo Angelo; [email-masked]
Subject: RE: [ANCP] Comments on draft-maglione

Hi Francois,
Please see my comments inline,
Regards,
Michel.

________________________________________
From: Francois Le Faucheur IMAP [mailto:[email-masked]]
Sent: Mon 7/23/2007 6:23 PM
To: Michel Platnic
Cc: Francois Le Faucheur IMAP; OOGHE Sven; [email-masked]; [email-masked]
Subject: Re: [ANCP] Comments on draft-maglione
Hi Michel, 

<Michel> Using access control capabilities within the access network provides the two main following benefits:
- refrain from sending any content to a customer that was not paid for (mostly relevant when Encryption is not used)
- provides a filter against end-user applications/hackers that may send IGMP requests with invalid IP address
 
A solution where all the IP addresses that are not part of either the Black-list or the White-List are sent to a central policy server for authorization gives me some concerns regarding the robustness of the whole system. Same concern regarding the treatment of unknown IP source addresses ('Everything else').

Agreed. We had these concerns in mind also. This is why the Black-Lists and White-Lists include the ability to define arbitrarily large ranges/masks. In particular, as an example, one can easily define a Black-List which contains a single "catch-all" entry that matches any Multicast address & Source. Then you can define a White-List with the explicit channels you want to allow. This effectively implements a policy whereby everything is blocked by AN, except the channels that have been explicitly allowed in the White-List.
In other words, the Black-List can be used for explicit listing of channels, or it can easily be used as a "catch-all" (for all, or for arbitrarily large ranges of channels).

This should address your concern of making sure that the "default" behavior for any non-explicitly defined channel is not to query NAS/Central_server.

See in draft-maglione:
"
The White List and Black List can contain entries allowing:
   o  an exact match for a (*,G) ASM group (e.g. <G=g.h.i.l>) 
   o  an exact match for a (S,G) SSM channel (e.g. <S=s.t.u.v,G=g.h.i.l> 
   o  a mask-based range match for a (*,G) ASM group (e.g. 
      <G=g.h.i.l/Mask>) 
   o  a mask-based range match for a (S,G) SSM channel (e.g. 
      <S=s.t.u.v/Mask,G=g.h.i.l/Mask> 
"
 <Michel> Let me try to rephrase your proposal; there would be a default state wherein any channel being neither part of White-list nor Black-list would be discarded. 
If its the case I agree with you that this solution solves the security issue.
 
But what about when AN is not in this default state?
If "Accept everything else" is used then again same problem of security is encountered, and any hacker or application can overload the policy server with requests. 
To my understanding, the model proposed, where the NAS is getting the customer request for authorization, requires this mode of operation.
So we still have the same problem.
Did I miss anything?

______________________________________________________________________________
I understand that some applications may require sophisticated policy decision making and that, as a matter of fact, some AN/central policy server synchronization mechanism should to be proposed,
but the solution must be Robust and Scalable.
For now I am not convinced that solution proposed is either Robust or Scalable.

Let us know if you have specific robustness/scalability concerns (beyond the one discussed above)?
Then we could work together on addressing those. 
 
 <Michel> Well, there is still this scalable issue when duplicating the messages that need to be treated in real-time by the NAS. Sven already made some counting regarding this topic. I believe this point could lead to scalability issues. If we had the above described potential disaster, then we end-up getting serious Robustness issues.

Thanks

Francois

Regards,
Michel.
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: "OOGHE Sven" <[email-masked]>
Date: Fri, 23 Nov 2007 17:16:31 +0100

Hello Roberta,

Thinking a bit further about the default behavior, I am not sure that
dropping would be the right approach. (cf. "If a Join message is
received by AN for a flow which is not on any list, then it is
rejected")

Imagine any multicast flow out there on the Internet (e.g. Internet TV),
then if it is not configured on the Access Node, it will be rejected. I
don't think this is what an end-user would want.

Instead, I would argue that if the flow is not part of any of the lists,
that the behavior would be to accept it as best effort, i.e. accept
without further admission control checks.

What do you think?

Regards,
Sven

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]] 
Sent: vrijdag 23 november 2007 8:36
To: [email-masked]
Cc: Ullio Mario; Michel Platnic
Subject: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments
ondraft-maglione)

Hello,
	as we discussed during Chicago meeting below is a proposal for
modification to the text of draft-ietf-ancp-framework-04.txt in order to
introduce Multicast Grey List and leave Black List (i.e. deny) as
default behavior. 
We'd appreciate feedback.

Regards,
Roberta

Section 3.4.1
Replace:
" Provisioning the conditional access information on the AN can be done
using a "White list" and/or a "Black list".
A White list associated with an Access Port identifies the multicast
flows that are allowed to be replicated to that port.  A Black list
associated with an Access Port identifies the multicast flows that are
not allowed to be replicated to that port."

By:
" Provisioning the conditional access information on the AN can be done
using a "White list", "Grey list",  and/or a "Black list". A White list
associated with an Access Port identifies the multicast flows that are
allowed to be replicated to that port.  A Black list associated with an
Access Port identifies the multicast flows that are not allowed to be
replicated to that port. A Grey list associated with an Access Port
identifies the multicast flows for which the AN on receiving a Join
message, before starting traffic replication queries NAS for further
authorization. 
Each list contains zero, one or multiple entries and each entry may
specify a single flow or contain ranges (i.e. mask on Group address
and/or mask on Source address). 

Replace:
"Upon receiving a join message on an Access Port, the Access Node will
first check if the requested multicast flow is part of a White list or a
Black list associated with that Access Port.  If it is part of a White
list, the AN can autonomously start replicating multicast   traffic.  If
it is part of a Black list, the AN can autonomously discard the message
because the request is not authorized" 

By:

"Upon receiving a join message on an Access Port, the Access Node will
first check if the requested multicast flow is part of a White, Grey or
a Black list associated with that Access Port.  If it is part of a White
list, the AN can autonomously start replicating multicast traffic.  If
it is part of a Black list, the AN can autonomously discard the message
because the request is not authorized. If it is part of a Grey list the
AN uses ANCP to query the NAS, that in turn will respond to the AN
indicating whether the join is to be honored (and hence replication
performed by the AN) or denied (and hence replication not performed by
the AN.) If a Join message is received by AN for a flow which is not on
any list, then it is rejected (i.e. the default behavior is to drop such
messages.) If a join is received by AN for a flow that matches multiple
lists, then a deterministic algorithm (to be specified in ancp-protocol)
is used by the AN to decide which list behavior takes precedence.
Following are some example scenarios:

Scenario 1:
	* no config:

Scenario 2:

Scenario 3:

Section 3.4.2

Replace:
" One approach is for the AN to query the NAS so that both unicast
      and multicast CAC for the access line are performed by the NAS.
      In this case, the AN can use ANCP to query the NAS, that in turn
      performs multicast CAC and responds to the AN indicating whether
      the join is to be honored (and hence replication performed by the
      AN) or denied.  In the process, the NAS may communicate with a
      Policy Server. 
"
With:
" One approach is for the AN to query the NAS so that both unicast
      and multicast CAC for the access line are performed by the NAS.
      In this case, upon receiving a join to a multicast flow which
matches the Grey List, the AN can use ANCP to query the NAS, that in
turn
      performs multicast CAC and responds to the AN indicating whether
      the join is to be honored (and hence replication performed by the
      AN) or denied.  In the process, the NAS may communicate with a
      Policy Server. 

Section 4.2
Replace

Replace

Replace:

By
Upon receiving a join to a multicast flow which matches the Grey List
the ANCP MUST allow the AN to query the NAS to request an admission
decision for replicating that multicast flow to a particular Access
Port.

Section 4.7.6
Replace and split in two

By:

" Upon receiving a join to a multicast flow which matches the Grey List
for a specific  Access Port, the AN must support using ANCP to query the
NAS to receive a response indicating whether that join is to be honored
or denied.
"
" The AN must deny any join to a multicast flow that does not match any
      entry in the Black List nor in the White List  nor Grey List for
the relevant Access Port"

"Upon receiving a join to a multicast flow which matches the Grey List,
AN is not allowed to propagate that join request, before the successful
authorization from the NAS is received."

"Upon receiving a leave to a multicast flow which matches the Grey List,
AN SHOULD be able to autonomously stop replication and SHOULD be able to
advertise this event to the NAS." 

Section 4.8.6
Adding:
The NAS MUST support using ANCP to incrementally add, remove and modify
individual entries in White, Black and Grey lists.

Hi Francois,

________________________________________
From: Francois Le Faucheur IMAP [mailto:[email-masked]]
Sent: Mon 7/23/2007 6:23 PM
To: Michel Platnic
Cc: Francois Le Faucheur IMAP; OOGHE Sven; [email-masked];
[email-masked]
Subject: Re: [ANCP] Comments on draft-maglione Hi Michel, 

<Michel> Using access control capabilities within the access network
provides the two main following benefits:
- refrain from sending any content to a customer that was not paid for
(mostly relevant when Encryption is not used)
- provides a filter against end-user applications/hackers that may send
IGMP requests with invalid IP address
 
A solution where all the IP addresses that are not part of either the
Black-list or the White-List are sent to a central policy server for
authorization gives me some concerns regarding the robustness of the
whole system. Same concern regarding the treatment of unknown IP source
addresses ('Everything else').

Agreed. We had these concerns in mind also. This is why the Black-Lists
and White-Lists include the ability to define arbitrarily large
ranges/masks. In particular, as an example, one can easily define a
Black-List which contains a single "catch-all" entry that matches any
Multicast address & Source. Then you can define a White-List with the
explicit channels you want to allow. This effectively implements a
policy whereby everything is blocked by AN, except the channels that
have been explicitly allowed in the White-List.
In other words, the Black-List can be used for explicit listing of
channels, or it can easily be used as a "catch-all" (for all, or for
arbitrarily large ranges of channels).

This should address your concern of making sure that the "default"
behavior for any non-explicitly defined channel is not to query
NAS/Central_server.

See in draft-maglione:
"

   o  a mask-based range match for a (*,G) ASM group (e.g. 
      <G=g.h.i.l/Mask>) 
   o  a mask-based range match for a (S,G) SSM channel (e.g. 
      <S=s.t.u.v/Mask,G=g.h.i.l/Mask>
"
 <Michel> Let me try to rephrase your proposal; there would be a default
state wherein any channel being neither part of White-list nor
Black-list would be discarded. 
If its the case I agree with you that this solution solves the security
issue.
 
But what about when AN is not in this default state?
If "Accept everything else" is used then again same problem of security
is encountered, and any hacker or application can overload the policy
server with requests. 
To my understanding, the model proposed, where the NAS is getting the
customer request for authorization, requires this mode of operation.
So we still have the same problem.
Did I miss anything?

________________________________________________________________________
______
I understand that some applications may require sophisticated policy
decision making and that, as a matter of fact, some AN/central policy
server synchronization mechanism should to be proposed, but the solution
must be Robust and Scalable.
For now I am not convinced that solution proposed is either Robust or
Scalable.

Let us know if you have specific robustness/scalability concerns (beyond
the one discussed above)?
Then we could work together on addressing those. 
 
 <Michel> Well, there is still this scalable issue when duplicating the
messages that need to be treated in real-time by the NAS. Sven already
made some counting regarding this topic. I believe this point could lead
to scalability issues. If we had the above described potential disaster,
then we end-up getting serious Robustness issues.

Thanks

Francois

Regards,
Michel.

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received the
message in error, be informed that any use of the content hereof is
prohibited. Please return it immediately to the sender and delete the
message. Should you have any questions, please contact us by replying to
[email-masked].

        Thank you

                                        www.telecomitalia.it

---

From: "Maglione Roberta" <[email-masked]>
Date: Sun, 25 Nov 2007 22:26:02 +0100

Hi Sven,
	thanks for your comments;
your point makes sense to me, "accept as best effort" is a valid option for default behavior.
The basic idea for the default action is to avoid query the NAS for all 
multicast flows that do not match any list:  the reason why we selected  
drop as the default behavior for unconfigured multicast flows 
is in order to be consistent with the typical ACL behavior, 
and also because this seemed to be the preferred action 
according to the discussion we had in Chicago and on the mailing list, 
but I open to modify the default behavior, according to Working group
feedback. 

Regards,
Roberta  

-----Original Message-----
From: OOGHE Sven [mailto:[email-masked]]
Sent: Fri 11/23/2007 5:16 PM
To: Maglione Roberta; [email-masked]
Cc: Ullio Mario; Michel Platnic
Subject: RE: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments ondraft-maglione)
 
Hello Roberta,

What do you think?

Regards,
Sven

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]] 
Sent: vrijdag 23 november 2007 8:36
To: [email-masked]
Cc: Ullio Mario; Michel Platnic
Subject: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments
ondraft-maglione)

Hello,

Regards,
Roberta

Section 3.4.1
Replace:

By:

Replace:

By:

Scenario 1:
	* no config:

Scenario 2:

Scenario 3:

Section 3.4.2

Replace:

Section 4.2
Replace

Replace

Replace:

By

Section 4.7.6
Replace and split in two

By:

Section 4.8.6
Adding:

Hi Francois,

 

See in draft-maglione:
"

 

Thanks

Francois

Regards,
Michel.

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 26 Nov 2007 10:08:25 +0100

Roberta, Sven, and all,

It is worth noting that Roberta's proposal below allows the behavior  
described by Sven with very trivial extra config:
simply add one "catch-all" entry (<S=*,G=*>) in the White List.
Then any flow that doesn't match the Black or Grey list will be  
accepted by AN.

For example, we could add:

Scenario 4:
	* White-List = { <S=*,G=*>}
	==> any Join message gets accepted by AN

Scenario 5:
	* White-List = { <S=*,G=*>}
	* Black-List = { <S=*,G=G1> , <S=*,G=G2>, ... <S=*,G=Gn> }
	==> Join ( S=*,G=Gi) gets rejected by AN  ( 1<=i<=n )
	==> everything else gets accepted by AN

So the choice is between:

	* "Black-Default":  proposal below where:
		- Default ==> everything that doesn't match Black/Grey gets blocked
		- add a single-entry catch-all in White-List==> everything that  
doesn't match Black/Grey gets accepted

	* "White-Default": modified proposal where:
		- Default ==> everything that doesn't match Black/Grey gets accepted
		- add a single-entry catch-all in Black-List==> everything that  
doesn't match Black/Grey gets blocked

Both proposals can easily achieve both required behaviors (ie "block  
if doesn't match" _and_  "accept if doesn't match"). The only  
difference is about whether you need to add the single catch-all  
entry or not to achieve your favorite behavior.

 From previous discussion on that topic, it sounded to me like  
several folks were more comfortable with the conservative side (ie if  
there has not been a conscious decision to allow a flow, then better  
block it;  it is easy enough to explicitly "allow-all" if operator is  
so inclined).

So considering the above ... what do people prefer?
Perhaps we could also poll the WG in Vancouver on that topic.

Francois

On 25 Nov 2007, at 22:26, Maglione Roberta wrote:

> This message and its attachments are addressed solely to the  
> persons above and may contain confidential information. If you have  
> received the message in error, be informed that any use of the  
> content hereof is prohibited. Please return it immediately to the  
> sender and delete the message. Should you have any questions,  
> please contact us by replying to [email-masked].
>
>         Thank you
>
>                                         www.telecomitalia.it
>

---

From: "OOGHE Sven" <[email-masked]>
Date: Tue, 27 Nov 2007 14:29:20 +0100

Francois,

I agree that a catch-all statement can be used to create either "accept
all" or "reject all" behavior. Perhaps one nuance: it would make sense
to indicate wheher such channels could be accepted as "best effort".
That means that in case other premium channels are requested lateron,
the best effort content (e.g. internet TV) would be the first to suffer.

Perhaps the way forward is the following:
- indicate in the framework that by default, all joins for a channel
that is not in one of the configured lists, will be rejected.
- the operator can override this behavior by configuring such a wildcard
entry in one of the lists. It should be possible to indicate whether or
not the channel is a best effort channel or premium content.

Comments?

Regards,
Sven

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: maandag 26 november 2007 10:08
To: Maglione Roberta; OOGHE Sven
Cc: Francois Le Faucheur IMAP; [email-masked]; Michel Platnic; Ullio
Mario
Subject: Re: Introducing Mutlicast Grey-List (was RE: [ANCP] Comments
ondraft-maglione)

Roberta, Sven, and all,

It is worth noting that Roberta's proposal below allows the behavior
described by Sven with very trivial extra config:
simply add one "catch-all" entry (<S=*,G=*>) in the White List.
Then any flow that doesn't match the Black or Grey list will be accepted
by AN.

Scenario 4:

Scenario 5:

	* "Black-Default":  proposal below where:
		- Default ==> everything that doesn't match Black/Grey
gets blocked
		- add a single-entry catch-all in White-List==>
everything that doesn't match Black/Grey gets accepted

	* "White-Default": modified proposal where:
		- Default ==> everything that doesn't match Black/Grey
gets accepted
		- add a single-entry catch-all in Black-List==>
everything that doesn't match Black/Grey gets blocked

Both proposals can easily achieve both required behaviors (ie "block if
doesn't match" _and_  "accept if doesn't match"). The only difference is
about whether you need to add the single catch-all entry or not to
achieve your favorite behavior.

 From previous discussion on that topic, it sounded to me like several
folks were more comfortable with the conservative side (ie if there has
not been a conscious decision to allow a flow, then better block it;  it
is easy enough to explicitly "allow-all" if operator is so inclined).

Francois

On 25 Nov 2007, at 22:26, Maglione Roberta wrote:

> The basic idea for the default action is to avoid query the NAS for 
> all multicast flows that do not match any list:  the reason why we 
> selected drop as the default behavior for unconfigured multicast flows

> is in order to be consistent with the typical ACL behavior, and also 
> because this seemed to be the preferred action according to the 
> discussion we had in Chicago and on the mailing list, but I open to 
> modify the default behavior, according to Working group feedback.
>
> Regards,
> Roberta
>
>
> Imagine any multicast flow out there on the Internet (e.g. Internet 
> TV), then if it is not configured on the Access Node, it will be 
> rejected. I don't think this is what an end-user would want.
>
> Instead, I would argue that if the flow is not part of any of the 
> lists, that the behavior would be to accept it as best effort, i.e. 
> accept without further admission control checks.
>
> What do you think?
>
> Regards,
> Sven
>
>
> modification to the text of draft-ietf-ancp-framework-04.txt in order 
> to introduce Multicast Grey List and leave Black List (i.e. deny) as 
> default behavior.
> " Provisioning the conditional access information on the AN can be 
> done using a "White list" and/or a "Black list".

> " Provisioning the conditional access information on the AN can be 
> done using a "White list", "Grey list",  and/or a "Black list". A 
> White list associated with an Access Port identifies the multicast 

> not allowed to be replicated to that port. A Grey list associated with

> an Access Port identifies the multicast flows for which the AN on 
> receiving a Join message, before starting traffic replication queries 
> NAS for further authorization.
> ______________________________________________________________________

> __