Re: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)
Roman Danyliw <rdd@cert.org> Fri, 09 August 2019 01:23 UTC
Return-Path: <rdd@cert.org>
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 49BC012006E; Thu, 8 Aug 2019 18:23:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 pWcRF6QPuUNg; Thu, 8 Aug 2019 18:23:12 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5A212006A; Thu, 8 Aug 2019 18:23:11 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x791N7l9003145; Thu, 8 Aug 2019 21:23:07 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x791N7l9003145
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1565313787; bh=+s7/tuyrVXzu2hU6FEf7bj8QKnJQY0kK8zJMXdgDA5A=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=VN0BuuIGgyp5EImOTNhU5PJY41uh1mqy1Cs57LJKhSWVrECwo8qtnDrgFIaDW+KGo ad4j5e8j3G0aLzFwcRoag2PG2W+xAMpfsq42VLB+3o/yXImC/aGEYuDqQxVIpbyMvK pIZuc7WWmZIkc1nAYGrF1k5BsH6cM7FtZ6vJQKqI=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x791N7wI005938; Thu, 8 Aug 2019 21:23:07 -0400
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Thu, 8 Aug 2019 21:23:07 -0400
From: Roman Danyliw <rdd@cert.org>
To: Christer Holmberg <christer.holmberg@ericsson.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-mmusic-ice-sip-sdp@ietf.org" <draft-ietf-mmusic-ice-sip-sdp@ietf.org>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "fandreas@cisco.com" <fandreas@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)
Thread-Index: AQHVS/6tjWg4BE1sB0SFynsU3YUPIqbuWXyAgAN51/A=
Date: Fri, 09 Aug 2019 01:23:06 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B340302B@marchand>
References: <156505852285.2142.10774832459273251927.idtracker@ietfa.amsl.com> <HE1PR07MB3161315A543C3CBD5479C0CF93D50@HE1PR07MB3161.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB3161315A543C3CBD5479C0CF93D50@HE1PR07MB3161.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/V5udmxDtRjEpNmIaOAeHr6pPA1A>
Subject: Re: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 09 Aug 2019 01:23:13 -0000
Hi Christer! Thanks for the quick follow-up. There is one detail below to consider, but I've covered otherwise. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, August 6, 2019 9:03 AM > To: Roman Danyliw <rdd@cert.org>; The IESG <iesg@ietf.org> > Cc: draft-ietf-mmusic-ice-sip-sdp@ietf.org; mmusic-chairs@ietf.org; > fandreas@cisco.com; mmusic@ietf.org > Subject: VS: Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: > (with DISCUSS and COMMENT) > > Hi Roman, > > Thank You for the review! I will let someone that has more security expertise > then I have address your comments on section 8. For your other comments, > please see inline. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > (5) Section 3.2.6. The example in this section is appreciated. Additional > text to explain what this example is showing would be helpful. > > We will add text. > > --- > > > (6) Section 3.4.1.2.1. Per “the offer MUST include the same set of > > ICE-related information that the offerer included in the previous offer or > answer”, what happens if the ICE information is different? > > Depending on what is different the peer will either consider it a protocol > error, or an ICE restart. Understood. Thanks or the clarification. > --- > > > (7) Section 3.4.1.2.2. Per “In addition, if the agent is controlling, > > it MUST include the ‘a=remote-candidates’ attribute for each data stream > whose check list is in the completed state”, what is a ‘check list’ in this > context? > > There is a check list associated with each data stream (m= line). So, if the > check list associated with a given data stream is in the completed state, the > agent will include an a=remote-candidates attribute in the m= line > associated with that check list/data stream. > > The check list concept is described more in detail in RFC 8445 (it is not SDP > specific). Got it. That's context I didn't have. Thanks. > --- > > >(8) Section 4.4. Per “If two data streams have identical ice-ufrag's, they > MUST have identical ice-pwd's”, what happens if there are not identical? > > It is a protocol error. Is there generic guidance that would make that obvious in other SIP/SDP error handling, or should that be said explicitly? > --- > > >(9) Section 4.4. Per “Its large upper limit allows for increased amounts of > randomness to be added over time”, what is the time horizon being > mentioned? > >Is this saying that in the future, longer password and users could be > adopted? > > Yes. Got it. > >(10) Section 4.5. Unlike the other sections in 4.*, this one doesn’t have an > example. > > Don't know what happened - it was supposed to have one 😊 I will add an > example. Thanks. > -- > > >(13) Appendix A. (Just as Ben pointed out in his DISCUSS for the > >example in Section 4.6) Shouldn’t the examples in this appendix include a > “a=ice-options:ice2” per the guidance in Section 3.2.1.5? > > Yes. We will add the attribute. Thanks. > --- Regards, Roman > Regards, > > Christer
- [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mm… Roman Danyliw via Datatracker
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Christer Holmberg
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Adam Roach
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Christer Holmberg
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Christer Holmberg
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Roman Danyliw
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Roman Danyliw
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Roman Danyliw
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Suhas Nandakumar
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Roman Danyliw
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Christer Holmberg
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Roman Danyliw
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Suhas Nandakumar
- Re: [MMUSIC] Roman Danyliw's Discuss on draft-iet… Roman Danyliw