Subject: Re: [MMUSIC] Updated "SDP source filter" Internet draft

From: Magnus Westerlund <[email-masked]>
Date: Mon, 04 Nov 2002 13:23:17 +0100

Hi Ross,

I have some comments on your draft.

- You mention the source filters as one attribute when they are in fact 
two SDP attributes (a=incl and a=excl). Your language should be updated 
to reflect this or prefix an attribute name , e.g. 
(a=src-filt:<filter-mode>:<filter-spec>).
- You need to clarify your specification on what is allowed and not. I 
recommend you to use more of the CAPITALIZED word of RFC 2119 to declare 
different requirements and possibilities. Especially in chapter 2.1. 
- Why is it not allowed to use number of addresses in the destination 
field to specify a list for all the addresses at the same time. 
- Clarify the definition of what "excl" and "incl" means. They should 
have there own paragraph where they are defined.
- Example in 2.2.4 is ambiguous. The attributes are lacking syntax 
elements to distinguish the case you describe in this example from one 
when one destination address has three acceptable source addresses. I 
would suggest that you simple remove this type of functionality. By 
specifying a single multicast destination address out of a range the 
list should only contain the addresses relative to that address. If  the 
next address in the range needs a filter, that needs to have its own 
filter line. And to simplify when a range has the same source addresses 
it should be possible to write ranges in the destination field.
- A note about the use of FQDN and load balancing with the help of DNS 
is to recommend. If some one DNS assigns different addresses depending 
on time or load the filter functionality may not be the intended.
- Depending on what you select to do with your attribute, you either 
should specify that you register 2 session and media level attributes or 
a single attribute. That single attribute would in its turn have a 
registry for filter modes.
- The BNF are lacking references to where the different BNF names 
"addrtype", "IP4-address", etc, are taken from.
- Splitting the references into normative and informal ones is 
recommended. 

Regards

Magnus

Ross Finlayson wrote:

> FYI, I have submitted an updated version of the "SDP source filter" 
> Internet draft.  Until it appears on the IETF web site, you an get a 
> copy at <http://www.live.com/mmusic-sdp-srcfilter-02.txt>
>
> This new draft incorporates most of the comments that people had about 
> the previous version.  However, there are still a couple of open 
> issues that I'd like to get comments on:
>
> Before Yokohama, someone commented:
>
>> Section 2 and Appendix A.
>> The definition of the filter attribute. Wouldn't it be better to 
>> define a short attribute name to the source filter instead of having 
>> two attributes called incl and excl? I would propose 
>> a=SF:<filter-mode>:<filter-spec>.
>
>
> To which I replied:
> I'm not sure.  The syntax of "a=incl:" and "a=excl:" seems more 
> consistent with that of other SDP attributes.  OTOH, they introduce 
> two new attributes rather than one.  A possible alternative might be 
> something like
>         a=filter <filter-mode> <filter-spec>
> where <filter-mode> is "incl" or "excl" (or "include" or "exclude").
>
> Does anyone else have an opinion on this?
>
> There was also the comment:
>
>> Section 2.2.4
>> The example text is in contradiction with the processing rules in 
>> section 2.1. According to the processing rules all three src adresses 
>> (1.1.1.1, 2.2.2.2 and 3.3.3.3) are valid for any of the three 
>> multicast adresses.
>
>
> Question for Bob (Quinn): Section 2.1 says
>         "all unicast addresses in the <src-list> are valid sources for 
> any
>         of the multicast addresses in the address series implied by the
>         <number of addresses>."
> but the example in 2.2.4 contradicts this.  Which semantics did you 
> intend?
>
>         Ross.
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
>

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: Ross Finlayson <[email-masked]>
Date: Mon, 04 Nov 2002 17:48:03 -0800

Magnus,

Thanks for the comments.

>two SDP attributes (a=incl and a=excl). Your language should be updated to 
>reflect this or prefix an attribute name , e.g. 

Yes, that probably makes more sense (having one attribute name instead of 
two).  So far, noone else has commented on this, so unless someone objects, 
I'll change this in the next version of the draft.

>would suggest that you simple remove this type of functionality.

I tend to agree.  I haven't heard back from Bob Quinn (the original author 
of this draft) about what he intended here.  But I think you're right - the 
functionality described in section 2.2.4 is too complex; it'd be simpler to 
require filters for individual addresses to be specified exactly, and to 
also allow "/<number-of-addresses>" in the filter spec (matching that in 
the corresponding "c=" line).

>- Splitting the references into normative and informal ones is recommended.

Really?  I've never seen such a split made (at least, not explicitly) in 
any other draft.  I think every Internet Draft I've seen has just a single 
list of references.

         Ross.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 04 Nov 2002 22:16:04 -0500

--> Ross Finlayson writes:
...
>any other draft.  I think every Internet Draft I've seen has just a single 

The RFC editor and IESG are recommending the split for all new drafts. See
draft-rfc-editor-rfc2223bis-03.txt

Colin