Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-alpn-02

Alissa Cooper <alissa@cooperw.in> Wed, 23 March 2016 20:31 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB7712D154 for <rtcweb@ietfa.amsl.com>; Wed, 23 Mar 2016 13:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=L7QJPC2S; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=JMhMYE1h
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 yLNqfvtWCDT3 for <rtcweb@ietfa.amsl.com>; Wed, 23 Mar 2016 13:31:30 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B72412D66C for <rtcweb@ietf.org>; Wed, 23 Mar 2016 13:31:30 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 735C52097F for <rtcweb@ietf.org>; Wed, 23 Mar 2016 16:31:29 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 23 Mar 2016 16:31:29 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=CmTE3rl6MpSHLiM3RnGCwr7u6Ws=; b=L7QJPC 2S6im4NN3FtrshUu3hV8omZ7+TznJCpPDeFdZMLKj+OfYJaOVX5kuj8yUDLlr87/ +pIj/I41ca6G6EPGSPEUezcFq/vLxTAOL2jH8HBuixvnL9QCQR1RF6rkXGIvkqjQ HxL2FB6dBrpNrNsEpGBerlV9Wz32oSNK3bHuA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=CmTE3rl6MpSHLiM 3RnGCwr7u6Ws=; b=JMhMYE1hPdUgthw1Hq9bSRlWRBveBUYNLhWcGZLpcd4xlwA S6Xl89hJgn6ailJIkn5tW8vJdcc0l2vqUxSWLkKjWEnTzhjb2TRP++Pwi5lafwAo tFbREtHrIXwk0K1w8JJPfiXjdah3iLItcevi+aSa6yAV7VLoHQ2Ph8mwpiMA=
X-Sasl-enc: 7Oez5Elbo+Or+UFruTYUJRa5KenZS+nP1zv/LcYE1y87 1458765089
Received: from dhcp-171-68-122-59.cisco.com (dhcp-171-68-122-59.cisco.com [171.68.122.59]) by mail.messagingengine.com (Postfix) with ESMTPA id 031D0680230; Wed, 23 Mar 2016 16:31:28 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <CABkgnnX8Sf+DjNMZWm1d0tg-hOr8LdYzBwJHByJSGgjuX8s28Q@mail.gmail.com>
Date: Wed, 23 Mar 2016 13:31:48 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D1A3727-4AD3-49C4-B45F-25FF3EB01E85@cooperw.in>
References: <6B474A50-6399-472F-BD7B-5286DCD209BA@cooperw.in> <CABkgnnX8Sf+DjNMZWm1d0tg-hOr8LdYzBwJHByJSGgjuX8s28Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/O3aIKaai6P2TPIY7B95DCt8JKGg>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-alpn-02
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Mar 2016 20:31:32 -0000

These changes look good to me. Will issue IETF LC when you submit the -03.

Thanks,
Alissa

> On Mar 17, 2016, at 7:53 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> Thanks for the review Alissa,
> 
> I've put the changes up here: https://github.com/martinthomson/drafts/pull/30
> 
> I realize that you won't get a lot of time to look at this before I
> want to push -03, but I thought that I'd offer you the chance at
> least.
> 
> On 6 March 2016 at 09:44, Alissa Cooper <alissa@cooperw.in> wrote:
>> “Confidentiality protection” is a fairly general term, but it seems to be used throughout this document to mean something much more specific, i.e., media that is confidential to two peers in a webrtc connection. I think this needs to be clarified in the abstract and Sections 1, 2, and 5 where the more specific meaning is intended. Otherwise this document makes it sound as though data is being sent in the clear when it is not. E.g., in Section 2 this text should be more specific to confidentiality vis a vis the application: "However, data provided over data channels does not receive confidentiality protection.”
> 
> Yes, the early sections only implicitly rely on the definition in
> Section 3, and that isn't particularly strong.  I've given this a
> spin.
> 
>> = Section 3 =
>> 
>> "Any entity that forwards
>>   content, or records content for later access by entities other than
>>   the authenticated peer, SHOULD NOT offer or accept a session with the
>>   "c-webrtc" identifier.”
>> 
>> Acknowledging the there are other recommendations in this draft that basically up to the implementation to follow, why is this requirement a SHOULD NOT rather than a MUST NOT?
> 
> Made it a MUST.
> 
>> Nits:
>> 
>> = Section 1.1 =
>> 
>> Since this document uses RFC 2119 keywords, why does it not include the standard disclaimer recommended by RFC 2119? I think it’s fine to add further words to indicate that the normative requirements are aimed at implementation behavior, but the standard text shouldn’t be omitted.
> 
> OK, should that be the post-erratum boilerplate?
> 
>> Also, I’m not sure what it means for the document to "fall back on shorthands for establishing interoperability requirements on implementations.” What is the alternative that it is falling back from?
> 
> Actually saying what is meant using words.
> 
>> = Section 6.3 =
>> 
>> Is there a reason this reference is listed this way?
> 
> Blame the tools, which are a mystery to me.  I wanted to cite a
> specific section of the HTML5 spec, because finding a specific section
> in there is a nightmare.