Re: [Rmt] Fwd: [MMUSIC] SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03

Brian Adamson <brian.adamson@nrl.navy.mil> Tue, 22 January 2013 15:52 UTC

Return-Path: <brian.adamson@nrl.navy.mil>
X-Original-To: rmt@ietfa.amsl.com
Delivered-To: rmt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DFE21F8586 for <rmt@ietfa.amsl.com>; Tue, 22 Jan 2013 07:52:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level:
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmcS5dlkqUoo for <rmt@ietfa.amsl.com>; Tue, 22 Jan 2013 07:52:22 -0800 (PST)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) by ietfa.amsl.com (Postfix) with ESMTP id 1A98421F8588 for <rmt@ietf.org>; Tue, 22 Jan 2013 07:52:20 -0800 (PST)
Received: from macsimus.itd.nrl.navy.mil (macsimus.itd.nrl.navy.mil [132.250.92.151]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id r0MFqIp2032423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Jan 2013 10:52:18 -0500
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-69-457978379
From: Brian Adamson <brian.adamson@nrl.navy.mil>
In-Reply-To: <50FE990A.10205@neclab.eu>
Date: Tue, 22 Jan 2013 10:49:43 -0500
Message-Id: <6CB7590C-EF84-44F2-BFA2-301FDE8658C6@nrl.navy.mil>
References: <7594FB04B1934943A5C02806D1A2204B09423B@ESESSMB209.ericsson.se> <50FE990A.10205@neclab.eu>
To: Martin Stiemerling <Martin.Stiemerling@neclab.eu>
X-Mailer: Apple Mail (2.1085)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Cc: rmt@ietf.org
Subject: Re: [Rmt] Fwd: [MMUSIC] SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmt>
List-Post: <mailto:rmt@ietf.org>
List-Help: <mailto:rmt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Jan 2013 15:52:23 -0000

Thanks Martin,

We will rally the troops to address these.

beset regards,


Brian Adamson
brian.adamson@nrl.navy.mil




On Jan 22, 2013, at 8:50 AM, Martin Stiemerling wrote:

> FYI, the first email about the SDP review of draft-ietf-rmt-flute-sdp-03. I will also forward the 2nd email, just in a second.
> 
> There a number of points that require attention. See below.
> 
> Martin
> 
> -- 
> IETF Transport Area Director
> 
> martin.stiemerling@neclab.eu
> 
> NEC Laboratories Europe - Network Research Division NEC Europe Limited
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
> Registered in England 283
> 
> 
> -------- Original Message --------
> Subject: 	[MMUSIC] SDP Directorate: Review of draft-ietf-rmt-flute-sdp-03
> Date: 	Tue, 8 Jan 2013 12:30:04 +0000
> From: 	Christer Holmberg <christer.holmberg@ericsson.com>;
> To: 	mmusic@ietf.org <mmusic@ietf.org>;
> CC: 	draft-ietf-rmt-flute-sdp@tools.ietf.org
> <draft-ietf-rmt-flute-sdp@tools.ietf.org>;
> 
> 
> 
> Hi,
> 
> I am the assigned SDP directorate reviewer for
> 
> draft-ietf-rmt-flute-sdp-03
> 
> For background on the SDP directorate, please see the FAQ at
> 
> http://www.ietf.org/iesg/directorate/sdp.html
> 
> Please wait for direction from your document shepherd or AD before
> posting a new version of the draft.
> 
> SUMMARY:
> 
> ==========
> 
> I have technical concerns with a number of the technical content of this
> document, and at least the “Composite Session” concept, as currently
> 
> defined in the document, would need to be discussed in MMUSIC. I think
> they need to be resolved/clarified before this document can be published.
> 
> Regards,
> 
> Christer
> 
> --------------------------------------------------------
> 
> TECHNICAL
> 
> =========
> 
> General:
> 
> ------------
> 
> T-GEN-1:              The draft seems to define a new generic SDP
> mechanism, “Composite Session”, for grouping media streams into
> protocol-specific sessions. I am not really sure what that means, but it
> seems to go outside the scope of FLUTE. I also think it overlaps with
> the SDP BUNDLE work, and such work shall be done in MMUSIC.
> 
>                 “The Composite Session mechanism enables the grouping
> of media lines
> 
>                 in to distinct sessions.  The complete Composite
> Session semantics
> 
>                 are protocol-specific - as determined by the protocol
> id of the
> 
>                 grouped media lines.”
> 
> T-GEN-2:              Maybe I’ve missed it, but it is a little unclear
> to me why the grouping framework is needed in the first place. If that
> is described somewhere, please tell me :)
> 
> In section 3.2.1, the text says:
> 
>                 “The Composite Session provides an unambiguous way to
> define multiple
> 
>                 FLUTE sessions as distinct from multiple the
> media-sessions semantics
> 
>                 of RTP.”
> 
> But, what is the technical need for this?
> 
> T-GEN-3:              The draft uses the same source address for every
> m- line associated with a group, but it uses different addresses in each
> m- line. Aren’t the media streams symmetric?
> 
> T-GEN-4:              There is chapter describing the SDP Offer/Answer
> aspects. How is the answer generated? What if the answerer does not
> support (or, supports, but don’t want to use) the mechanism?
> 
> If the mechanism is not to be used with SDP Offer/Answer, but e.g. for
> some kind of declaration, I think that needs to be described.
> 
> Section 1:
> 
> -------------
> 
> T-1-1:                    The text says:
> 
>                 “Note, this document may also be used to describe
> sessions of the
> 
>                 experimental FLUTE specification [RFC3926].”
> 
> I think you need to indicate whether or not there will be any changes in
> the usage of SDP in that case.
> 
> Section 3.2:
> 
> ---------------
> 
> T-3-2:                    I would like to have some input from the
> MMUSIC community whether “FLUTE/UDP/ESP” is appropriate to describe a
> IPSec encrypted FLUTE channel, or whether something like “SFLUTE/UDP”
> should be used instead.
> 
> Section 3.11:
> 
> -----------------
> 
> T-3_11-1:             As the syntax mandates at least one fmt value, I
> suggest that the document specifies which value SHALL be used.
> 
> EDITORIAL
> 
> =========
> 
> General:
> 
> -----------
> 
> E-GEN-1:              The Abstract and Introduction needs to explicitly
> state that the specification defines a new SDP grouping framework value.
> The Abstract also needs to mention the new SDP protocol values.
> 
> Section 1:
> 
> -------------
> 
> E-1-1:                    s/defines two new protocol identifiers/defines
> two new SDP protocol values
> 
> E-1-2:                    I suggest to remove “The formal ABNF syntax
> [RFC5234] is used for the attributes.” It only needs to be stated in the
> section defining the new SDP attributes.
> 
> Section 3:
> 
> -------------
> 
> E-3-1:                    I think the second last paragraph, comparing
> FLUTE with RTP media streams, sessions etc is confusing. I think it is
> enough to describe that each SDP m- line represents a FLUTE channel.
> 
> Section 3.1:
> 
> ---------------
> 
> E-3_1-1:               I would suggest to have a new parent chapter,
> “SDP Extensions”, with sub-chapters defining the new SDP protocol
> values, attributes etc.
> 
> Section 3.11:
> 
> -----------------
> 
> E-3_11-1:             I suggest to remove this section. It’s not needed,
> and I don’t even agree with the content.
> 
> Section 4:
> 
> -------------
> 
> E-4-1:                    Instead of saying “a=FEC-declaration line”, I
> suggest to say “SDP FEC-declaration attribute”. (Also applies to the
> description of the other attributes).
> 
> 
> -- 
> martin.stiemerling@neclab.eu
> 
> NEC Laboratories Europe - Network Research Division NEC Europe Limited
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
> Registered in England 283
> 
> 
> <Attached Message Part.txt>_______________________________________________
> Rmt mailing list
> Rmt@ietf.org
> https://www.ietf.org/mailman/listinfo/rmt