Re: [rtcweb] [Tsv-art] Tsvart last call review of draft-ietf-rtcweb-ip-handling-11

Joe Touch <touch@strayalpha.com> Sat, 23 February 2019 01:33 UTC

Return-Path: <touch@strayalpha.com>
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 09F5F12D4E7; Fri, 22 Feb 2019 17:33:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level:
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 bsIWOhonVn1g; Fri, 22 Feb 2019 17:33:44 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 6D155130F83; Fri, 22 Feb 2019 17:33:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nsVzVrziw5gAPccQHP6yxsA2fPalvt0rdCorx1e3/FU=; b=fRq5d01ESTHPO5k9KH8sMc0c6 IXh1nBhO7yPHEtwykDmvVg1KA0T4Qt6iqFv+xXKWJ5ZG15V2+QXGkq9U5wuYwCp+PwjNd6o4XZRqw 8PZm728csNOcIVvrxs6OdYVeLWovXMg+DNG38kxvf9tiwi+upPS6gwXyfXKS0MTf5mmW3FBivVk0H 5D3/vLVZUedh6wj3+cZCAoI20heOWY/hEkG3OL4c9EoIAV/lWgoegTnOBqeZJ31Ene0VI7euCzkfR vYPVpLByO8R7RU5ffEPUuITpCnAYOZvrwx0i2L5YFmjtk2x3/4+MAH/OyXq2uxKkxeIHifU3iO/5M DEoCQ5Pnw==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57804 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1gxMCC-002oM2-ES; Fri, 22 Feb 2019 20:33:42 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_7E2481DD-3ECA-45AD-9DEC-3FDE5308948B"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <CAOJ7v-3Ue2oDCLiF8QK6i2f18-=pc+ADkeQDJL6TfH=5Wayeaw@mail.gmail.com>
Date: Fri, 22 Feb 2019 17:33:39 -0800
Cc: tsv-art@ietf.org, RTCWeb IETF <rtcweb@ietf.org>, IETF discussion list <ietf@ietf.org>, draft-ietf-rtcweb-ip-handling.all@ietf.org
Message-Id: <7214C146-4B65-429E-AA90-4ED9E2654472@strayalpha.com>
References: <155042612497.4083.2465692313767522646@ietfa.amsl.com> <CAOJ7v-3Ue2oDCLiF8QK6i2f18-=pc+ADkeQDJL6TfH=5Wayeaw@mail.gmail.com>
To: Justin Uberti <juberti=40google.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/-9vAaRVTcHQqesYEwJi2jRudvjc>
Subject: Re: [rtcweb] [Tsv-art] Tsvart last call review of draft-ietf-rtcweb-ip-handling-11
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 23 Feb 2019 01:33:47 -0000

You could just add “Unix” or “Unix-like” to before “connect”, or refer to these calls as “bind()” and “connect()”.

It is important that these are the semantics of Unix-like sockets; other APIs may not have a corresponding mechanism. Further, the UDP source address might change later (i.e., in TCP the “connect” always forces a static source IP address selected at the initiation of the TCP connection; in UDP, there’s no need for this to happen only once at the time the “connect()” is issued.

Joe

> On Feb 22, 2019, at 5:19 PM, Justin Uberti <juberti=40google.com@dmarc.ietf.org> wrote:
> 
> Thanks for your comments. See below.
> 
> On Sun, Feb 17, 2019 at 9:56 AM Joseph Touch <touch@strayalpha.com <mailto:touch@strayalpha.com>> wrote:
> Reviewer: Joseph Touch
> Review result: Ready
> 
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
> 
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@ietf.org <mailto:tsv-art@ietf.org> if you reply to or forward this review.
> 
> This document has no significant transport issues.
> 
> As a very minor issue, the document refers to the use of UDP "connect":
> 
>    Once a suitable remote IP has been determined, the implementation can
>    create a UDP socket, bind it to the appropriate wildcard address, and
>    tell it to connect to the remote IP.  Generally, this results in the
>    socket being assigned a local address based on the kernel routing
>    table, without sending any packets over the network.
> 
> It might be useful to be more clear that this is an OS command (not a protocol
> one). If the particular semantics of this command are relevant, that should be
> noted as well.
> 
> Agreed. Thoughts on what would make this clearer? 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art