Re: [Captive-portals] option 160 conflict
Tommy Pauly <tpauly@apple.com> Fri, 10 January 2020 17:19 UTC
Return-Path: <tpauly@apple.com>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036C3120A2F for <captive-portals@ietfa.amsl.com>; Fri, 10 Jan 2020 09:19:16 -0800 (PST)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 3LJaAb8vsBy1 for <captive-portals@ietfa.amsl.com>; Fri, 10 Jan 2020 09:19:13 -0800 (PST)
Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 2B535120914 for <captive-portals@ietf.org>; Fri, 10 Jan 2020 09:19:13 -0800 (PST)
Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id 00AH1uaX064529; Fri, 10 Jan 2020 09:19:11 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=wvUvDcPvrG3P6tby5QtlKMHCFRNIfLGp39t6f44PgWc=; b=CXNe5LA+LDWK7Z7EgqJyWmhPrTyhLV0EkerrxDxQ3BkNOYOoCoiDzKYevKbumukZCpxS 52oCFt6zrxZlZ/VgzcU0EHMGBdpFBgB6l6qAa/LeG5GfrHG0kUjEaygWFhET9nTwKwZB UB6AL1YwlWmvsA++ltIiNOxj1ew+Dz4Us148he7kW8J+NXw96q+embyRp17oNMn263Ie eL0iy+sHZn1H4XoWf+39DoXA64owR7cHtSL7hJIKCd8Dc0aE7FBkVcx4BbwSNXC5R0ZC UbQQh+NR4yT0JUSAcFQWoZRqQ770q/XXn2YUCdUdg0I5YVK4jlrM3HRAK8Lu/YZA8l2J zw==
Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2xe126mcw0-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 10 Jan 2020 09:19:11 -0800
Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q3W006ACIRWGH10@ma1-mtap-s02.corp.apple.com>; Fri, 10 Jan 2020 09:19:10 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q3W00G00I9RK100@nwk-mmpp-sz09.apple.com>; Fri, 10 Jan 2020 09:19:06 -0800 (PST)
X-Va-A:
X-Va-T-CD:
X-Va-E-CD:
X-Va-R-CD:
X-Va-CD: 0
X-Va-ID: 9f81caec-5088-452d-bb04-ac0ed1b91a0d
X-V-A:
X-V-T-CD: b9464ade94490f860e479577c6c808b3
X-V-E-CD: ab4b98dd9665150474513f41f5c654ad
X-V-R-CD: bc65fba3c5fd2e58404201a87315dfaf
X-V-CD: 0
X-V-ID: 42339c89-6911-4b35-abdb-aab1e1c6d6ba
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-10_01:,, signatures=0
Received: from [17.230.160.105] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q3W009U4IRTJC50@nwk-mmpp-sz09.apple.com>; Fri, 10 Jan 2020 09:19:06 -0800 (PST)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Message-id: <67A25A2A-04FF-4A1D-B0B5-F0CE14E15FC0@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_17346D64-1346-44D1-B099-169401E12D1B"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
Date: Fri, 10 Jan 2020 09:19:02 -0800
In-reply-to: <CAAedzxqhtYUv9hX8FqnnGT6T22Oa4=pSx_BFgyhxK-mQw9VDig@mail.gmail.com>
Cc: Warren Kumari <warren@kumari.net>, Michael Richardson <mcr+ietf@sandelman.ca>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, "captive-portals@ietf.org" <captive-portals@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
To: ek@loon.com
References: <CAKD1Yr2yvqqw=APnyAb=gygR5KK6U7tcx3STGa9e6a8kJYO03w@mail.gmail.com> <150E4F32-236A-4D59-B74C-36BF523DCE55@apple.com> <DM6PR11MB413791A02517F481815C5353CF2E0@DM6PR11MB4137.namprd11.prod.outlook.com> <8B5AF256-342B-4F7C-B5AE-6C3904DFB0DA@apple.com> <CAHw9_iJrtGY=qUFngb=epJuLxrwfryv5peD=wx=2GL-ScV3kFw@mail.gmail.com> <CAAedzxqhtYUv9hX8FqnnGT6T22Oa4=pSx_BFgyhxK-mQw9VDig@mail.gmail.com>
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-10_01:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/IRns8XQl5xT0MUMnIno4zEHknOw>
Subject: Re: [Captive-portals] option 160 conflict
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2020 17:19:16 -0000
> On Jan 2, 2020, at 6:24 PM, Erik Kline <ek@loon.com> wrote: > > 111 or 114 pending approval from Apple both seem fine to me. As far as approval, I checked with Dieter who originally registered it, and it's fine to use. So, Apple gives approval! > > I'll add an Appendix C with a brief summary of the 160 polycom experience for posterity. Sounds good. And do we just need to update the IANA Considerations to ask for 114? Best, Tommy > > On Thu, 2 Jan 2020 at 14:33, Warren Kumari <warren@kumari.net <mailto:warren@kumari.net>> wrote: > On Thu, Jan 2, 2020 at 2:29 PM Tommy Pauly <tpauly@apple.com <mailto:tpauly@apple.com>> wrote: > > > > One option we have is to use Code 114, which was reserved for use by Apple as a "URL" option. That particular codepoint wasn't ever used, so it should be open to be reclaimed as a CAPPORT API URL. Since this is in the range below 128, it should be safer to use. > > > I *really* like this idea - the options even contains something that > looks like a URL :-) > > Is there any reason *not* to reuse this? There is a note in RFC 3679 > (Unused DHCP Option Codes) saying: > > Code: 114 > Name: URL > Defined in: (none) > Contact: Dieter Siegmund, dieter@apple.com <mailto:dieter@apple.com> > Reason to recover: Never published in an RFC > > If this does get resulted for CAPPORT, should we file a Hold For > Document Update errata noting that this is no longer true? > > Thank you Tommy! > W > > > > > > Best, > > Tommy > > > > On Dec 23, 2019, at 11:27 AM, Bernie Volz (volz) <volz@cisco.com <mailto:volz@cisco.com>> wrote: > > > > Hi: > > > > OK, good to know. I had thought that there was support for using option 160 in implementations as RFC7710 was published in December 2015. > > > > I guess Warren will need to update the bis document to request IANA to assign a new DHCPv4 option (replacing 160) because of the potential conflict regarding its use – likely it would be useful to give some short justification for this (about the conflict). Likely the listing for option 160 will need to be something like: > > > > 160 DEPRECATED (see new-option-code) - DHCP Captive-Portal N DHCP Captive-Portal [RFC7710] > > 160 Polycom (vendor specific) > > > > It may also be appropriate to request IANA assign 111 (if still available) as it has no reported use and is in the original (<128) IANA assigned space (as per RFC2132). > > > > BTW: Code 115 (which was listed as used by failover in RFC3679) could also be a good choice as I am pretty sure it this was ever used (and if it was, it was for failover communication and not normal clients; and that use has long been deprecated). > > > > > > Bernie > > > > > > From: tpauly@apple.com <mailto:tpauly@apple.com> <tpauly@apple.com <mailto:tpauly@apple.com>> > > Sent: Monday, December 23, 2019 12:58 PM > > To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org <mailto:40google.com@dmarc..ietf.org>> > > Cc: Bernie Volz (volz) <volz@cisco.com <mailto:volz@cisco.com>>; Michael Richardson <mcr+ietf@sandelman.ca <mailto:mcr%2Bietf@sandelman.ca>>; captive-portals@ietf.org <mailto:captive-portals@ietf.org>; Warren Kumari <warren@kumari.net <mailto:warren@kumari.net>> > > Subject: Re: [Captive-portals] option 160 conflict > > > > > > > > > > On Dec 21, 2019, at 7:48 PM, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org>> wrote: > > > > > > On Sat, 21 Dec 2019, 07:53 Bernie Volz (volz), <volz@cisco.com <mailto:volz@cisco.com>> wrote: > > > > 1) It would not really remove the overlap for a long while (until all of the clients that used the "old" 160 Capport option are upgraded). So, devices will still need to deal with it for a long while. > > > > > > Do any clients or networks actually implement 160 to mean capport? I know that iOS and Android, which seem most interested in this option, do not yet. > > > > > > I am not aware of anything using the option yet. iOS does not use it; we used it for interop testing, but that is not in production code. > > > > > > If they do not, the right thing to do would be to get a new option code, and do so as soon as possible so the implementations that are being written this year can immediately start using the new one. > > > > > > I would also urge that if we want a new code, we allocate it soon so that the implementations can quickly test it out and ship the right value. > > > > Tommy > > > > > > _______________________________________________ > > Captive-portals mailing list > > Captive-portals@ietf.org <mailto:Captive-portals@ietf.org> > > https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals> > > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org <mailto:Captive-portals@ietf.org> > https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals> > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals
- [Captive-portals] option 160 conflict Michael Richardson
- Re: [Captive-portals] option 160 conflict Warren Kumari
- Re: [Captive-portals] option 160 conflict Bernie Volz (volz)
- Re: [Captive-portals] option 160 conflict Warren Kumari
- Re: [Captive-portals] option 160 conflict Bernie Volz (volz)
- Re: [Captive-portals] option 160 conflict Michael Richardson
- Re: [Captive-portals] option 160 conflict Lorenzo Colitti
- Re: [Captive-portals] option 160 conflict Tommy Pauly
- Re: [Captive-portals] option 160 conflict Bernie Volz (volz)
- Re: [Captive-portals] option 160 conflict Tommy Pauly
- Re: [Captive-portals] option 160 conflict Warren Kumari
- Re: [Captive-portals] option 160 conflict Erik Kline
- Re: [Captive-portals] option 160 conflict Michael Richardson
- Re: [Captive-portals] option 160 conflict Adam Roach
- Re: [Captive-portals] option 160 conflict Tommy Pauly
- Re: [Captive-portals] option 160 conflict Warren Kumari
- Re: [Captive-portals] option 160 conflict Erik Kline
- Re: [Captive-portals] option 160 conflict Erik Kline