Re: [dispatch] Ops Directorate review of draft-pd-dispatch-msrp-websocket-12

"Ben Campbell" <ben@nostrum.com> Thu, 30 June 2016 18:57 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8C012D10E; Thu, 30 Jun 2016 11:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 IOLrHGTP0-vY; Thu, 30 Jun 2016 11:57:30 -0700 (PDT)
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 BD91F12B012; Thu, 30 Jun 2016 11:57:30 -0700 (PDT)
Received: from [10.0.1.4] (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 u5UIvP9H009324 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 30 Jun 2016 13:57:26 -0500 (CDT) (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.4]
From: Ben Campbell <ben@nostrum.com>
To: Fred Baker <fred@cisco.com>
Date: Thu, 30 Jun 2016 13:57:25 -0500
Message-ID: <527B64C7-DB2C-49DA-9AD5-5DE420513816@nostrum.com>
In-Reply-To: <71C83619-87E7-4C92-83A0-3834A6B6931C@cisco.com>
References: <71C83619-87E7-4C92-83A0-3834A6B6931C@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/KtNe62PuzxvylCKxvW7iLEqqcP4>
Cc: "ops-dir@ietf.org" <ops-dir@ietf.org>, "dispatch@ietf.org" <dispatch@ietf.org>, "draft-pd-dispatch-msrp-websocket.all@ietf.org" <draft-pd-dispatch-msrp-websocket.all@ietf.org>
Subject: Re: [dispatch] Ops Directorate review of draft-pd-dispatch-msrp-websocket-12
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2016 18:57:32 -0000

Hi Fred, thanks for your review!

I think there may be room for tuning the language and citations a bit (I 
will let the authors address details), but the text that you quote is 
intended as an overview of WebSocket, not normative text about how you 
do MSRP over WebSocket. I think the best that _this_ draft can do is 
describe WebSocket as it exists now. Nothing in those sections should be 
taken to constrain how WebSocket might be updated to adapt to things 
like TLS 1.3 or HTTP/2.

Alexey: Any thoughts on this from the perpective of an RFC 6455 author?

Thanks!

Ben.

On 30 Jun 2016, at 12:57, Fred Baker (fred) wrote:

> I am reviewing this document as part of the Operational directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG. These comments were written with the intent of improving the 
> operational aspects of the IETF drafts. Comments that are not 
> addressed in last call may be included in AD reviews during the IESG 
> review. Document editors and WG chairs should treat these comments 
> just like any other last call comments.
>
> I have a few questions regarding the document. My perception, which 
> may or may not be correct, is that it targets down-rev protocols - 
> http/s 1.1 and TLS 1.2, the former of which has been obsoleted and 
> replaced and the latter is (I'm told) about to be. I'm fine with 
> having those as options, but it seems like publishing this without 
> references to the current technology means that it will need to be 
> updated or replaced soon with a document that does.
>
> Note that I am not registering these as objections; I think this is a 
> conversation that needs to be had, but if the consensus of people more 
> expert than myself in this technology is to stay down-rev, I'm OK with 
> it.
>
>> 1.  Introduction
>>
>>    The WebSocket [RFC6455] protocol enables message exchange between
>>    clients and servers on top of a persistent TCP connection 
>> (optionally
>>    secured with TLS [RFC5246]).  The initial protocol handshake makes
>>    use of HTTP [RFC7230] semantics, allowing the WebSocket protocol 
>> to
>>    reuse existing HTTP infrastructure.
>
> I understand HTTP 1.1 (which is to say "pipelined TCP"), but I was 
> surprised to not read about RFC 7540 HTTP 2.0 (Secure TCP). Is there a 
> reason to not allow for the latter, at least as an option?
>
>> 3.  WebSocket Protocol Overview
>>
>>    The WebSocket protocol [RFC6455] is a transport layer on top of 
>> TCP
>>    (optionally secured with TLS [RFC5246]) in which both client and
>>    server exchange message units in both directions.
>
> Is this extensible to TLS 1.3, which I'm told is in the offing? That 
> would obsolete RFC 5246.