Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: (with DISCUSS)

"Ben Campbell" <ben@nostrum.com> Thu, 02 March 2017 02:57 UTC

Return-Path: <SES=HREDB8-QPCN5R6R3N-=ben@nostrum.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1751129793; Wed, 1 Mar 2017 18:57:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8m23rXgpigO; Wed, 1 Mar 2017 18:57:49 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C901D129452; Wed, 1 Mar 2017 18:57:49 -0800 (PST)
Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v222vhCW044270 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 1 Mar 2017 20:57:44 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39]
From: "Ben Campbell" <ben@nostrum.com>
To: "Christer Holmberg" <christer.holmberg@ericsson.com>
Date: Wed, 01 Mar 2017 20:57:43 -0600
Message-ID: <6366ADF1-E3E4-4C91-8579-85246D3E3714@nostrum.com>
In-Reply-To: <D4D9F0A9.18675%christer.holmberg@ericsson.com>
References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <CABcZeBPPFUe-ZtW9Lt636OhoMH8ws2oVi94YQJeUQKXteC-XRg@mail.gmail.com> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <CABcZeBMpR+jE7jB4O=k_LPGhEBZPwUpo7vFnov4xvvhw_mYUAg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <CAD5OKxvtxyVn1r1pJhPCYMON-bTwWYjCvxts4K1ucgxaGFcCSg@mail.gmail.com> <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net> <CAD5OKxu7DJ5sMW0G_SvzyKiYVeyGxFVSub-aiT2u8kXCfqCF+g@mail.gmail.com> <86C5D8B5-40B6-4228-BF10-00BF9DFEB93C@nostrum.com> <492F1BF9-2F1C-4D16-8B9B-B9FD13592E13@kuehlewind.net> <D4D9F0A9.18675%christer.holmberg@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/oqct_ISm36KCPJiEvipvQyyftvo>
Cc: "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, Roman Shpount <rshpount@turbobridge.com>, "fandreas@cisco.com" <fandreas@cisco.com>, Mirja Kuehlewind <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, "draft-ietf-mmusic-sctp-sdp@ietf.org" <draft-ietf-mmusic-sctp-sdp@ietf.org>
Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?=
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2017 02:57:50 -0000

Hi all,

It seems like this conversation has not completed. What do we need to 
get to closure?

A few thoughts of my own:

- I'm not adverse to making non-ICE implementors look at the ICE specs 
for framing information, as long as the citations are precise enough 
that they don't need to read the entirety of ICE. (And the information 
is really there.)

- I am adverse to repeating normative text. I'm okay with adding 
informational text about non-ICE usage, as long as it is general enough 
to avoid confusion about where the authoritative text resides.

- If people think that ICE is not sufficiently specified, we can work on 
that. But I don't think the burden of doing that belongs to this draft.

- The draft is in fact IESG approved in its current state. Material 
changes should be kept to the minimum.

On 27 Feb 2017, at 7:06, Christer Holmberg wrote:

> Hi,
>
> ...
>
>> Also I¹m not sure if the ICE part is fully specified. In your 
>> previously
>> mail you wrote
>>
>> "As far as TCP/DTLS/SCTP transport tag is concerned, please note that 
>> ICE
>> end points are supposed to send a re-INVITE after nomination process 
>> is
>> completed with the selected candidate address in the m= line. So, if 
>> tcp
>> candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP
>> transport tag in the m= line. Also, any offers/answers after the ICE
>> nomination is complete, are supposed to send the currently selected
>> candidate in the m= line, which will also be TCP/DTLS/SCTP in case 
>> tcp
>> candidate is selected.³
>>
>> From what I understood from ekr, you might not in any case send an
>> re-invite; but maybe I understood this wrongly. I guess that could 
>> also
>> be further explained in the draft.
>
> Ekr was talking about the specific re-INVITE that is sent directly 
> after
> ICE nomination. *Other* re-INVITEs can always be sent during the 
> session.
> But, that is not specific to this draft.
>
> Regards,
>
> Christer