Session Description Protocol (SDP) Source Filters
RFC 4570

Note: This ballot was opened for revision 10 and is now closed.

(Harald Alvestrand) Discuss

Discuss (2004-09-02 for -** No value found for 'p.get_dochistory.rev' **)
Sigh.

I really hate to approve documents that contain MUSTs that are impossible to implement. Consider the following two pieces of texts:

   SDP does not define a protocol, but only the syntax to describe a
   multimedia session with sufficient information to discover and
   participate in that session.  Session descriptions may be sent using
   any number of existing application protocols for transport
   (e.g., SAP, SIP, RTSP, email, HTTP, etc.).

   Note that the unicast source addresses specified by this attribute
   are those that are seen by a receiver.  If source addresses undergo
   translation en route from the original sender to the receiver
   - e.g., due to NAT (Network Address Translation) or some tunneling
   mechanism - then the SDP "source-filter" attribute - as presented to
   the receiver - MUST be translated accordingly.

To which I can only say.... "dream on".

If the document says something like:

"... then the receiver has to use a modified SDP description that uses local knowledge to figure out what the local representation of the address presented in the SDP "source-filter" attribute is"

then it's OK. But the text reads like "NATs have to go muck with SDP even if it's inside email", and I don't want to mandate that.

I do not understand this (3.1):

   An SDP description MUST NOT contain more than one session-level
   "source-filter" attribute, nor more than one media-level
   "source-filter" attribute for the same medium.

in conjunction with this (3.2.4):

        <session-description>

        c=IN IP4 224.2.1.1/127/3
        a=source-filter: incl IN IP4 224.2.1.1 192.168.9.10
        a=source-filter: incl IN IP4 224.2.1.3 192.168.9.42

Isn't this > 1 source-filter attribute at session level?

(Steven Bellovin) Discuss

Discuss (2004-09-01 for -** No value found for 'p.get_dochistory.rev' **)
RFC 2827 should be cited instead of [CA-96.21]

There is no motivation provided for the "excl" feature.  Either 
motivation should be provided or the feature should be removed.  Beyond 
that, the security considerations section should discuss the risks of 
an unauthenticated mechanism --- IGMP -- that tells a router to block 
packets for a given source/dest pair.

(Jon Peterson) Yes

(Brian Carpenter) (was Discuss) No Objection

Comment (2005-06-15)
No email
send info
Inconsistency noted by Harald:


I do not understand this (3.1):

  An SDP description MUST NOT contain more than one session-level
  "source-filter" attribute, nor more than one media-level
  "source-filter" attribute for the same medium.

in conjunction with this (3.2.4):

        <session-description>

        c=IN IP4 224.2.1.1/127/3
        a=source-filter: incl IN IP4 224.2.1.1 192.168.9.10
        a=source-filter: incl IN IP4 224.2.1.3 192.168.9.42

Isn't this > 1 source-filter attribute at session level?

(Margaret Cullen) No Objection

(Bill Fenner) (was Discuss) No Objection

(Ted Hardie) No Objection

Comment (2004-08-30 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Reading through the document it seemed like it would be possible to
have an address based filter that applied to one or more of the c= addresses 
and a second FQDN-based filter that applied to all of them, e.g.:

  <session-description>


        c=IN IP4 224.2.1.1/127/3
        a=source-filter: incl IN IP4 224.2.1.1 192.168.9.10
        a=source-filter: incl IN * channel-1.example.com src-1.example.com


        <media-description 1>

An example of it might be useful if the draft will be revised for
other reasons.

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

(Allison Mankin) (was Discuss) No Objection

Comment (2005-06-13)
No email
send info
Addressed my concern for forged exclusions by:

From Ross Finlayson:  
- Section 5 (security considerations) discusses the general importance of 
   needing to ensure the integrity of the addresses mentioned in SDP 
  "source-filter" attributes (of which a "excl" address is just one case).

(Thomas Narten) No Objection

(Bert Wijnen) (was Discuss) No Objection

Comment (2004-09-02)
No email
send info
In the references section:
   [UTF-8]     Yergeau, F., "UTF-8, a transformation format of Unicode
               and ISO 10646," RFC 2044, October 1996.
This one has been obsoleted twice already. Current document is RFC3629.

(Alex Zinin) No Objection