Re: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt

"Schwarz, Albrecht (Albrecht)" <> Mon, 28 April 2014 15:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C1F0D1A07A6 for <>; Mon, 28 Apr 2014 08:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EJJ5G4odXUmh for <>; Mon, 28 Apr 2014 08:47:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AED491A0352 for <>; Mon, 28 Apr 2014 08:47:34 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id s3SFlWYt001259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Apr 2014 10:47:33 -0500 (CDT)
Received: from ( []) by (GMO) with ESMTP id s3SFlVJa025639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Apr 2014 17:47:31 +0200
Received: from ([]) by ([]) with mapi id 14.02.0247.003; Mon, 28 Apr 2014 17:47:32 +0200
From: "Schwarz, Albrecht (Albrecht)" <>
To: "Belling, Thomas (NSN - DE/Munich)" <>, "" <>
Thread-Topic: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt
Thread-Index: AQHPSZ11tlxeVOi9qUaF/6Ya6nB3kJr0rpiAgAvrKICADCrMcIAamYQg
Date: Mon, 28 Apr 2014 15:47:30 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Apr 2014 15:47:36 -0000

Thanks for support of this activity Thomas!
to filename: dependent on adoption by MMUSIC of this draft
to introductory text: the lenghty background was motivated by the fact that this draft doesn't originate in MMUSIC itself, hence we need to provide more description (than for the H.248 experts community in ITU-T).


-----Original Message-----
From: Belling, Thomas (NSN - DE/Munich) [] 
Sent: Freitag, 11. April 2014 19:40
To: Schwarz, Albrecht (Albrecht);
Subject: RE: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt

Hi Albrecht,

thanks for your attempt to register the codepoints in Clause 8 of your draft at IANA. I understand this is the main intention of this draft and a internet draft seems indeed required for that purpose.

Perhaps you should choose a filename containing "mmusic", e.g. "draft-schwarz-mmusic-sdp-for-gw" to direct new version notifications and discussions to the proper group. I understand a version 2 of the draft is now available.

I believe clauses 1 and 2 are rather long and could be shortened a bit. Is all the history essential and are all abbreviations and conventions really used within the draft?

Regards, Thomas

-----Original Message-----
From: mmusic [] On Behalf Of ext Christian Groves
Sent: Friday, April 04, 2014 3:43 AM
Subject: Re: [MMUSIC] FW: I-D Action: draft-schwarz-sdp-for-gw-01.txt

Hello Albrecht,

Thanks for submitting the draft. I support the addition of the extra <proto> codepoints for scenarios where a gateway performs application agnostic inter working. In general the background to H.248/Megaco usage of SDP is good but I'm not sure if the reasons for the new codepoints are documented sufficiently in the draft.

Some specific comments below:
Clause 1.4 Scope: I propose to word this slightly differently to indicate the scope is the collection of SDP codepoints for GCPs in order to identify additional ones that REQUIRE registration with IANA.

Clause 4: There appears to be some duplication in the headings, i.e. 4 and 4.5. Perhaps also "<proto> element" needs to be removed from the title of heading 4 as clause 4.4 covers the <type> element?

Clause 4.1 Purpose, Last Para: To me this is the reason for the entire draft. The draft has cataloged how SDP is used by GCPs(H.248/Megaco) however hasn't really gone into much depth on why the additional codepoints are needed. Perhaps a paragraph for each additional codepoint could be added indicating where it is used/needed?

Clause 4.4: I think the draft could indicate that H.248 uses the <attrtype> values as defined on the IANA registry and no additional IANA registrations are required.

Clause 5.1: I think it would be good to note that this has already been registered with IANA.

Clause 7.1: TCP/TLS is already registered. See RFC4572 clause 4. However I'm not sure that in the case of agnostic interworking that the MUST indicated in that clause (/An 'm' line that specifies 'TCP/TLS' MUST further qualify the protocol using a fmt identifier to indicate the application being run over TLS./) applies.

I've also noticed some other minor editorial issues that i'll forward to you off-line.

Regards, Christian

On 27/03/2014 8:48 PM, Schwarz, Albrecht (Albrecht) wrote:
> fyi, this is a spin off activity from
> 	draft-ietf-mmusic-udptl-dtls
> in order to define additional codepoints as required for DTLS security session termination (so called end-to-access edge security mode) and DTLS transparent forwarding (e.g. as part of end-to-end security mode) in middleboxes.
> -Albrecht
> -----Original Message-----
> From: I-D-Announce [] On Behalf Of
> Sent: Donnerstag, 27. März 2014 10:03
> To:
> Subject: I-D Action: draft-schwarz-sdp-for-gw-01.txt
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>          Title           : SDP codepoints for gateway control
>          Author          : Albrecht Schwarz
> 	Filename        : draft-schwarz-sdp-for-gw-01.txt
> 	Pages           : 12
> 	Date            : 2014-03-27
> Abstract:
>     SDP is used in many signalling protocols at call control level (such
>     as SAP, SIP, BICC), bearer control level (such as RTSP, IPBCP) and
>     gateway control level (such as H.248/MEGACO, MGCP). Scope of this RFC
>     is related to gateway control specific SDP usage. Gateway control
>     protocols do usually NOT define and introduce any new SDP parameters,
>     however, gateway control protocols need specific SDP parameter values
>     in addition to SDP usage at call or bearer control level. Such SDP
>     codepoints are collected by this RFC with the purpose of registration
>     with IANA.
> The IETF datatracker status page for this draft is:
> There's also a htmlized version available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft directories: or
> _______________________________________________
> mmusic mailing list

mmusic mailing list