[MMUSIC] Final MMUSIC Minutes from 57th IETF

Folks,

since we have not received any comments, we consider the minutes
final.

The slides are available at

http://www.dmn.tzi.org/ietf/mmusic/57/slides/57-mmusic-slides-ppt.zip
http://www.dmn.tzi.org/ietf/mmusic/57/slides/57-mmusic-slides-pdf.zip

Joerg

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

Minutes of the MMUSIC WG Meeting at the 57th IETF
=================================================

Reported by Joerg Ott and Colin Perkins
Notes taken by Colin Perkins

The MMUSIC WG met once at the 57th IETF.  The meeting was chaired by
Colin Perkins and Joerg Ott.  It was attended by some 90 participants.

Status Update
-------------

Joerg Ott reported on the status of the working and the general
progress since the 56th IETF in San Francisco:

- The new charter was finally approved.

- RFC 3524 was published on SDP extensions for reservation flows.

- Two documents are with the RFC editor: SDP extensions for NAT
    traversal and SDPng transition.

- Two documents are with the IESG, and comments have been received:

    - draft-rajeshkumar-mmusic-gpmd-03.txt was felt to overlap with work
      on capability negotiation carried out elsewhere; it was noted that
      this probably applies to most of SDP except that SDP was first.
      The chairs and authors will work with the IESG to sort this out.
    - draft-ietf-mmusic-sdp-new-13.txt received many comments which were
      discussed in a separate slot (see below).

- Two documents are under AD review:
    - draft-ietf-mmusic-sdp-srcfilter-05.txt
    - draft-ietf-mmusic-sdp-comedia-05.txt

- draft-ietf-mmusic-sdp-bwparam-04.txt is completing WGLC on 28 Jul
    2003.

- The SDP extensions for key management
    (draft-ietf-mmusic-kmgmt-ext-07.txt) have been waiting for the MIKEY
    work to complete which seems to progress.  A further revision is
    expected shortly after the IETF.

- The SDP implementation draft draft-ietf-mmusic-sdp-implem-00.txt has
    not been revised yet, but Tom Taylor is working on it.  He is trying
    to incorporate further implementation experience from inside his
    company as well as from the SIPit events.

Two potential new work items have been discussed for MMUSIC:

- Real-time fax (draft-ietf-sipping-realtimefax-01.txt) from the
    SIPPING WG is to provide implementers with guidelines on how to use
    registered SDP attributes for ITU-T T.38.  This document actually
    contains two logical parts: the use of offer/answer mechanics (which
    belongs to MMUSIC) and a discussion of SIP-specific signaling (which
    belongs to SIPPING).  It is suggested to investigate splitting the
    document to deal with each one in the respective WG.  But it was
    pointed out that this document merely contains examples only and
    hence should be done as a whole in just one WG.  To be resolved.

- Interactive connectivity establishment (ICE) also from the SIPPING WG
    (draft-rosenberg-sipping-ice-01.txt).  This is discussed later on
    the agenda.

Revised SDP (draft-ietf-mmusic-sdp-new-13.txt)
----------------------------------------------

Colin Perkins reported on the changes incorporated in the latest
revision of SDP: It was attempted to clarify when the k= attribute may
be used.  Further clarifications include: RTP may be used with
non-consecutive port numbers and a=charset is only allowed as a
session level attribute.  Also, unregistered X- attributes and media
format are deprecated.  Finally, IANA considerations and references
were updated.

Colin further reported on issues raised on revision -13 on the mailing
list, as well as from the IESG review.

- An ABNF inconsistency was found: a comment in the ABNF for
    "token-char" allowed for a larger set of characters than the actual
    definition.  One could either (1) change the comment to match the
    actual grammar (and thus reduce the set of allowed characters) or
    (2) modify the grammar to match the comment.  The group agreed to go
    with option (1), pending a check against the use of SDP in RFC 3108.
    Tom Taylor volunteered to find this out.

- The use of b= with layered coding should be clarified as follows:
    When using the CT modifier with RTP, if several RTP sessions are
    part of the conference, the conference total refers to total
    bandwidth of all RTP sessions.  This was accepted in principle but
    it was also pointed out that a bandwidth specification per layer
    would be helpful.  Further discussion is needed on the mailing
    list.

- Again with layered coding, it should be clarified which ports are
    associated with an m= line.  The clarification proposal was
    accepted.

- The k= is underspecified.  The most straightforward way would be
    to deprecate the use of this field altogether.  Opinions from
    implementers are sought.  It was reported that MS Messenger uses
    this field; the details are unknown at this moment though.  As there
    are implementation out there, just deprecating this field won't work.

    Therefore, further work needs to go into the specification of using
    k=.  In particular, when k= shall be used, a secure channel must be
    available and endpoints need to be sure that no third party can
    eavesdrop on the key.  These issues, however, need to be specified
    by those using SDP rather than SDP itself.

    The k= field currently supports an algorithm indicator, but it should
    also specify a key type.  This may be implied by the URI or the
    media protocol used.  For more complex scenarios, e.g. when more
    than one key is needed, either the sdescriptions work
    (draft-ietf-mmusic-sdescriptions-01.txt) or the key management
    (draft-ietf-mmusic-kmgmt-ext-07.txt) work should be used.

    It was proposed that the security considerations section should
    change "SHOULD NOT deliver the user into an interactive multimedia
    session..." to "MUST NOT...".  It was found that this is an issue of
    user authorization (e.g. the user may be able to pre-authorize the
    automatic joining of certain interactive sessions) and needs to be
    dealt with by the protocols using SDP.

- The suggestion to define a "IN" value for private address spaces was
    rejected because systems 1) cannot tell whether they are in a
    private address space (relative to their peers) and 2) this change
    would be not backward compatible.

- It will be clarified that UTF-8 normalization is not needed because
    comparisons are not done on fields with UTF-8.

- Proposal on a=inactive: it was agreed not to change the SDP spec here
    (this is an issue for users of SDP, which may establish conventions
    for use, not for SDP itself).

- Wording should be added that u= and k= may include URIs that may be
    dereferenced in some (but not all) cases.  Also, it should be noted
    a k= URI may typically be an http or https URI.  Both suggested
    wording additions were accepted.

Colin will fold the comments and the discussion into the document and
produce a new revision out within a couple of weeks.

SDP Security Descriptions (draft-ietf-mmusic-sdescriptions-01.txt)
------------------------------------------------------------------

Dan Wing briefly reviewed the document and the changes from the
previous revision: a new syntax is proposed for the a=crypto attribute
and the offer/answer part is revised which may need further review.
For the next steps, Colin noted that an IANA considerations section is
needed, including a discussion of the registration procedures.
Furthermore, reviewers for finishing the document were sought: Tom
Taylor, Magnus Westerlund, and Martin Euchner volunteered.

Offer/Answer Examples (draft-johnston-mmusic-offer-answer-examples-01.txt)
--------------------------------------------------------------------------

Alan Johnston presented the changes to the document: in particular, an
example for asymmetric use of a codec has been added.  This is to be
achieved using two distinct m= lines with the same port number, one
indicating "sendonly", the other "recvonly".  The proposed behavior
caused some discussion: it was felt that the mechanism was
underspecified and that (therefore) m= lines with the same port would
be a bad idea.  Yet, the right approach to achieve the desired
behavior seemed unclear.  Gonzalo Camarillo pointed out that the
RFC3388 provided a similar example, but with an explicit grouping
(which is not present in this draft).  The applicability of RFC3388 to
this problem was discussed further.  Orit Levin pointed out that the
intention clearly is to use RFC 3388 but the question is what happens
to the endpoints that don't support RFC 3388.  Gonzalo argued that
this is already defined in RFC 3388.  The chairs stated that they
would like to see the asymmetric codec behavior with two m= line
properly specified in a document.  The present offer/answer examples
draft is meant to be illustrative; the example should be kept in place
(with added grouping) but the normative text for this behavior needs
to be someplace else.  Flemming Andreasen suggested to specify part of
this practice in the revised SDP.

SDPng Update (draft-ietf-mmusic-sdpng-06.txt)
---------------------------------------------

Dirk Kutscher presented the latest progress on SDPng, addressing the
open issues from draft -06 (a new revision still needs to be
submitted).  The SDPng structure has been enhanced to decouple
capability negotiation for potential configurations from actual
configuration (and the respective session parameters).  While the
capability model has been kept, the syntax has been revised to
exclusively rely on XML mechanisms (rather than embedding own syntax
conventions for attributes) -- which is less efficient but much
cleaner.  Dirk presented the new syntax using several examples and
also showed a formal schema definition.  A further refinement from
draft -06 is to remove the concept of libraries and use inline
definitions instead -- so that SDPng documents would be self-contained.
There was little discussion.  Steve Casner asked whether this work was
getting enough traction and questioned whether people were really
preparing for a transition.  Joerg Ott argued that people are
desparately holding onto SDP (which is perceived easier with one small
extension at a time) -- but that examples show that this getting more
complicated so that SDP is likely to have only a finite lifetime.  So
it would be nice to get broader review from the community on a
replacements for SDP.

RTP DoS Attacks (draft-rosenberg-mmusic-rtp-denialofservice-00.txt)
Interactive Connectivity Establishment (draft-rosenberg-sipping-ice-01.txt)
---------------------------------------------------------------------------

Jonathan Rosenberg introduced the RTP DoS problem: An attacker may
easily direct the RTP stream(s) from an unsuspecting source to any
target by providing the target's IP address in the SDP.  This works
for SIP and RTSP -- with RTSP providing limited protection by allowing
unicast RTP streams only to the address of the originator (but NATs
make it worse as anyone behind the same NAT can easily be attacked).
As authentication mechanisms can at most help identify the attacker
(which may be very weak though), some kind of handshake mechanism is
needed so that sources do not start sending media streams unless they
know that the right receiver is actually waiting for it: a
request/response mechanism using the RTP ports is needed.  This is ICE
(see below) which has been chosen as a solution for SIP.  However, ICE
has broader applicability and may be appropriate for RTSP, too --
which needs to be determined by the group.  Jonathan reviewed the
properties of the ICE approach and briefly walked through the basic
ICE algorithm.  With ICE being signaling protocol independent, MMUSIC
is asked to take ICE up as a WG item.

ICE is felt to introduce quite some complexity for RTSP endpoints.
If, however, NAT traversal (which is an RTSP issue on its own, see
below) and security can be addressed by the same mechanism, it may be
worth the effort.  It is noted that even if we go for the ICE
mechanism for RTSP right now, this does not solve the problem as long
as old RTSP servers are still out there.

Regarding the ICE proposal as a WG item Magnus Westerlund argued that
if it is accepted, one should split the draft into several parts: the
SIP use, the ICE mechanism, the use with offer/answer, etc.
There was consensus in the group to accept ICE as new WG item, and to
fully document the RTP DoS issues as an informational document.

RTSP Update (draft-ietf-mmusic-rc2326bis-04.txt
-----------------------------------------------

Magnus Westerlund reported on the progress of the RTSP revision,
achieved by having a new co-editor joining the team, many
teleconference calls, and also quite some list discussion.  He
presented a number of changes from draft -03 (see the slides).  With
this, most known open issues are resolved, with only a few ones
remaining (see slides).  But many resolutions still need to be folded
into an updated revision of the draft.  When this is done, a second
phase of editing on the spec is needed: examples need to be fixed, the
spec's consistency needs to be checked as needs it overall
readability, and, potential new open issues need to be solved.  With
all this, the revised RTSP spec will not meet the October deadline as
currently documented in the MMUSIC charter.  Magnus suggests another
six months would be appropriate to finalize the work.

RTSP and NAT (draft-ietf-mmusic-rtsp-nat-01.txt)
------------------------------------------------

Magnus Westerlund introduced the revised draft on RTSP and NATs, the
purpose of which is to describe how to traverse NATs and firewalls
with RTSP.  It documents several possible NAT traversal approaches and
gives recommendations regarding RTSP for firewalls.  Approaches
requiring only modifications on the client side STUN, TURN, and
RTP/RTSP tunneled in RTSP.  Application-Layer Gateways (ALGs) for RTSP
will not require any modifications -- but are generally discouraged.
Magnus further discussed open issues, particurlarly the goals for RTSP
for NATs (i.e. what type of scenarios should be achievable) as well as
possible solutions (symmetric RTP, STUN, ICE, DCCP).

On the ALGs: The group generally agreed that ALGs are a bad thing and
should not be considered further (except for documentation purposes and
to communicate this clearly to outside the IETF -- and fast, as people
start deploying these).

On the document's purpose: Commenters state that, currently, the draft
does not give conclusive resolution of what to do as an implementer,
it is merely an inventory.  It is proposed to pick some solution and
write it up, e.g. in the RTSP spec.  Magnus wants to resolve the
structure of the document and then settle on a solution: one for the
server and one or more for the client side.  Jonathan Rosenberg and
Tom Marshal argue over the number of client-side solutions to be
documented: Jonathan wants only one while Tom prefers to have multiple
feasible solutions document.  In case multiple ones are documented,
Jonathan wants exactly one "MUST implement" solution to ensure
interoperability.

There was some further discussion on technical aspects of possible
solutions, but no real conclusions were reached.

Internet Media Guides (IMG)
---------------------------
draft-nomura-mmusic-img-requirements-01.txt
draft-nomura-mmusic-img-framework-01.txt

After a brief introduction by Joerg Ott, Rod Walsh presented the
progress on the IMG requirements document (which will be re-submitted
as WG draft by end of August).  He briefly reviewed the general
topology and IMG distribution aspects and then went through the
requirement categories identified in the draft: IMG description
requirements and IMG transport requirements.  The former primarily
address IMG envelopes for existing meta-data formats, the latter their
distribution in unicast and multicast, pull and push style scenarios.
For multicast push, SAPv2 is probably inadequate, so a successor is
sought, e.g. ALC from the RMT WG.  It is pointed that additions to ALC
need to be specified separately; while Rod wants to use the RMT
proposal FLUTE, Lorenzo argues that this may not be 100% appropriate
here; Lorenzo also points out that possible tasks in the RMT WG need
to happen quickly as the group is trying to wrap up.  For unicasting,
client-initiated actions could use HTTP while notifications from the
server could use SIP mechanims.

Rod discusses on the scalability requirements IMG transport and
presents a conceptual overview showing the different pieces of an IMG
framework and outlines the achieved flexibility.  He also addresses
data relationships and particularly security considerations as taken
into account in the requirements draft.

Rod finally discusses the way ahead: the requirements draft is pretty
close to finalization; the remaining efforts are mainly editorial and
consolidation.  The aim is to go for WGLC soon.  He also points to the
existing framework draft that will be revised by the end of August.

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic