Re: [Webpush] [IANA #929427] Last Call: <draft-ietf-webpush-protocol-10.txt> (Generic Event Delivery Using HTTP Push) to Proposed Standard

Alissa Cooper <alissa@cooperw.in> Tue, 11 October 2016 19:40 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: webpush@ietfa.amsl.com
Delivered-To: webpush@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4101B129633 for <webpush@ietfa.amsl.com>; Tue, 11 Oct 2016 12:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 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_H2=-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=cooperw.in header.b=BdDj1bM3; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=X0dL/SZE
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 RRJLPInFiD1d for <webpush@ietfa.amsl.com>; Tue, 11 Oct 2016 12:40:01 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B271294B7 for <webpush@ietf.org>; Tue, 11 Oct 2016 12:40:01 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7F702205CE; Tue, 11 Oct 2016 15:40:00 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 11 Oct 2016 15:40:00 -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=C1+ZG0OUqlo3Jz1YhgOmcFbxULU=; b=BdDj1b M3a9FmgqaDcyygp+5DMK0FkQKcJygqbEUfde8xBv+DKuKVuAtWMu0z6fWRJuUUz7 axBNuviGpnq92NLovPMWv/p+89EAzERpC84G6btdOL2AmtGoenXTi4tBmSl2yEqj c+e+iovd9FUbwX+Qq8b8tn+jOxKr999gmHsUE=
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=C1+ZG0OUqlo3Jz1 YhgOmcFbxULU=; b=X0dL/SZEmYJMfQi7Dd23VS1FSPl85UYgsdCehw8QPg1g0h1 lJNMDfGbHupHdjsjz0iTQPPSIs8ch5tout8nr0ZosCUPuuF/NyMa2CdyYK901N4U Ad6ALlKh6xLfT7WjsMbPif3UqSOTXlEYwbi7d4evX5Aheuqk/YOdOAXC5a2Y=
X-Sasl-enc: rXqX3IWzUwMvsfMs5F97YIR+1IJcKAYp2Krteq+vusC9 1476214800
Received: from dhcp-10-150-9-172.cisco.com (unknown [173.38.117.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 26920F2988; Tue, 11 Oct 2016 15:40:00 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <CY1PR03MB23805587C435A163FFDE858083DA0@CY1PR03MB2380.namprd03.prod.outlook.com>
Date: Tue, 11 Oct 2016 15:39:59 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E0B3D9D-3194-4321-B928-1BC9D4D0508B@cooperw.in>
References: <RT-Ticket-929427@icann.org> <147499081575.4580.11302740752421976418.idtracker@ietfa.amsl.com> <rt-4.2.9-12355-1476135259-539.929427-9-0@icann.org> <9D4B66B4-C906-4D39-B124-3CB761DA394C@cooperw.in> <CY1PR03MB23805587C435A163FFDE858083DA0@CY1PR03MB2380.namprd03.prod.outlook.com>
To: Brian Raymor <Brian.Raymor@microsoft.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/B-OgljzrbI8hEuq0_t1NIyluHW4>
Cc: "webpush@ietf.org" <webpush@ietf.org>
Subject: Re: [Webpush] [IANA #929427] Last Call: <draft-ietf-webpush-protocol-10.txt> (Generic Event Delivery Using HTTP Push) to Proposed Standard
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Oct 2016 19:40:03 -0000

> On Oct 11, 2016, at 12:17 PM, Brian Raymor <Brian.Raymor@microsoft.com> wrote:
> 
> 
> On October 11, 2016, at 6:17 AM, Alissa Cooper <alissa@cooperw.in> wrote:
> 
>> I had assumed that port 1001 was specified in this document because it’s already in use.
>> Assuming the authors definitely want 1001 assigned for this purpose, the WG chairs will
>> need to do a quick consensus call about requesting early allocation for port 1001. Assuming
>> the WG has consensus to do that, the chairs can then send a request for early allocation to IANA.
> 
> If it would be simpler, then it would be acceptable to change 1001 to TBD and request IANA to
> make the assignment.
> 
> This is related to https://github.com/webpush-wg/webpush-protocol/issues/37. We could not specify the port
> numbers that are currently in use for push services because 5223 and 5228 are already registered with IANA for 
> other protocols. (The ports are registered to hpvirtgrp and hpvroom, although unofficially used by APNS and GCM.)
> In reviewing RFC6335 Section 8.1.1, perhaps I misinterpreted the guidance to provide a suggestion to IANA, which
> is why 1001 was requested:
> 
> https://tools.ietf.org/html/rfc6335
> 
>   o  Port Number: If assignment of a port number is desired, either the
>      port number the requester suggests for assignment or indication of
>      port range (user or system) MUST be provided.  If only a service
>      name is to be assigned, this field is left empty.  If a specific
>      port number is requested, IANA is encouraged to assign the
>      requested number.  If a range is specified, IANA will choose a
>      suitable number from the User or System Ports ranges.  Note that
>      the applicant MUST NOT use the requested port in implementations
>      deployed for use on the public Internet prior to the completion of
>      the assignment, because there is no guarantee that IANA will
>      assign the requested port.

Ah, I see. Since it’s not already in use I think the right thing to do is to request 1001 if it’s available, or another port number in the range if it’s not. I believe the problem for IANA is that it’s possible that 1001 will be assigned before this document gets published (by another document in the RFC Editor’s queue ahead of this one, for example). Let me run that by IANA and confirm.

Alissa 

> 
> ...Brian