[MMUSIC] ICE-SIP-SDP : ice-options support vs activation framework

Suhas Nandakumar <suhasietf@gmail.com> Mon, 13 March 2017 08:55 UTC

Return-Path: <suhasietf@gmail.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 6EB5D12955C for <mmusic@ietfa.amsl.com>; Mon, 13 Mar 2017 01:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ShUngjruuloF for <mmusic@ietfa.amsl.com>; Mon, 13 Mar 2017 01:55:35 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 B3133127ABE for <mmusic@ietf.org>; Mon, 13 Mar 2017 01:55:34 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id v125so212944193qkh.2 for <mmusic@ietf.org>; Mon, 13 Mar 2017 01:55:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Rsxz1BdjQRRBiuRseA77FR8bv+ncmPfEt7Zb8mOYGGU=; b=buOOOWtoOO4b0kL3np8RGxnH0yHMIyOnPVg6JVeheM520RinUO1aI+Sy64vT2sHhhp JYa99TN7OBmsy+NCBOTeNvs+9nbM01aHTl/DuRPyE0O+i7hqjc19uJVzVHLRKZca5urb WkQYmGxTt9sGLDVz1Ev5RTJKIDFytYKtjukgYRLsY0vMZRbOiEftIMp/accgr54e2wNB 8PpXIxV+2qON0x+aVaUr1eERNWGVKvphFeXPVPuGxP/7AGeFHn79vCprzDRRAGq+v27e D6/DKgpfBWDhyxoh3EStdTsQhqTNaJs4+fzlns8P02yFhj6fVZD/or+E+TiQIMKkATTp JE7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Rsxz1BdjQRRBiuRseA77FR8bv+ncmPfEt7Zb8mOYGGU=; b=JiUlS6MJmU7PHB2QZzGkFsldQu9+VyKHZ46VVL5aoJ+08XyNdc43qMlhm1r7bCbxFL NQmeeexBH8uq/WmRJDM488Fz2+cSOcfVuelTh399D2DQqXmaB39Zz9upLdDUm6w+nkO4 kYhcgcrYOTouF8PS/Cjz8grGCslvx1CIhE5jUh/1F6AcFNkNTGpYgW5dtHHOy6sEs37d 6+FBIicORiHxWfLwYc8mUpKqD0wkvsQvRfBI39JVNgjQwpjrKMqBYCTLB8iyw/VW4dPZ pun6z8lKH7oxKvPrFRDXrgt5lCQOisbqMs11qpeKv5b4rSYb+Tny0rAcfrHEs6Qn4Bha qVrA==
X-Gm-Message-State: AFeK/H3HKRpmKqJgZiT+em/BEBi7Kqwns6z87wJ2yGMb6/mWj2jBMqjnb4AKPCetwFfFXcEUCktBedF3uW2cgQ==
X-Received: by 10.55.19.197 with SMTP id 66mr28944413qkt.73.1489395333638; Mon, 13 Mar 2017 01:55:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.46.163 with HTTP; Mon, 13 Mar 2017 01:55:33 -0700 (PDT)
From: Suhas Nandakumar <suhasietf@gmail.com>
Date: Mon, 13 Mar 2017 01:55:33 -0700
Message-ID: <CAMRcRGT=dnHBiYBTYi8bOL6sWw8qziG=QQ6t38yumKMX8yGH+w@mail.gmail.com>
To: mmusic WG <mmusic@ietf.org>, Adam Roach <adam@nostrum.com>
Content-Type: multipart/alternative; boundary=001a113fcf6ccab1fb054a98dffe
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/HHgGj0pM7Z1M-f_u0ZokTigPPvo>
Subject: [MMUSIC] ICE-SIP-SDP : ice-options support vs activation framework
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: Mon, 13 Mar 2017 08:55:37 -0000

Original Comment from Adam

"Section 4.1.1.2 discusses ice-options attributes in the terms of
"support", without any discussion of activation. Although this is treated
(somewhat lightly) later in the document, this smells like the same kind of
potential morass we ran into with SIP options tags: the patchwork means of
indicating feature *support* versus feature *activation* made it very
difficult to specify and implement things in a consistent fashion. I
strongly recommend that this document spend a bit more text discussing this
distinction, and maybe even consider a formal syntax for distinguishing
between supported and activated features"

[Suhas]
I am not sure how deep we need to go in defining a formal syntax. Would
love to get some text to accommodate the above request or thoughts on how
do we go about ...

Thanks
Suhas