Re: [Captive-portals] option 160 conflict

Erik Kline <ek@loon.com> Fri, 03 January 2020 02:25 UTC

Return-Path: <ek@google.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 DF4491200EF for <captive-portals@ietfa.amsl.com>; Thu, 2 Jan 2020 18:25:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.249
X-Spam-Level:
X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.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 U3aHkmNUE8Gl for <captive-portals@ietfa.amsl.com>; Thu, 2 Jan 2020 18:25:12 -0800 (PST)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 1401F12004D for <captive-portals@ietf.org>; Thu, 2 Jan 2020 18:25:12 -0800 (PST)
Received: by mail-yb1-xb29.google.com with SMTP id z10so10781394ybr.9 for <captive-portals@ietf.org>; Thu, 02 Jan 2020 18:25:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.com; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=/V6g8g84E+qJM1Y3edWa0PNP3Jz0BNbZrnjB5uO/KQ4=; b=KeHWXhP1PwtKBCsPvi8JHcno3ZNctBxatvfyKGddUCm7nm6KhNLE6ki2CQhijvdCYj K9ghb0OtLevYrSiFeTupDz8Hamyd6h60Fx+CVaslxVWYzAQmKJh6EAFKe2H64+ArwMOn J2YO+2FAbn9BOGP/4rPZeiU/A2xTmoB9MnQrE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=/V6g8g84E+qJM1Y3edWa0PNP3Jz0BNbZrnjB5uO/KQ4=; b=nndd8KXxr0ErFY8IEZOu3MA+D5IBOwU3v+PK7Se1ldUpNAGsz4twEELHOXHo+XpV9V qHXLmHTgtt5vdsElVmKD6jJZ1snX9oq9L9dC0g5q04k2+wWaaOyDXobQ1z39iHCNu1/q Se2C9P9fZ7ggH8KzUCmHzrWyHy8+gXOyOaYAc970e6IUND8Pl3TH6ebgtVUCxGB700Jh y6dJ1sDVPzhCv3f86mXKNNjUo788kbT825Y515YoCrypN8OgveG+6qExyxk+6Yu4M0RH lkKT8B6BakAU+m8H0+f0xSxaZ+HBbF+5gPWGPESoMI09OIYcQ0V9OyQTwCY+33MHP7it m7CQ==
X-Gm-Message-State: APjAAAVyBG8fU9oPokYqjFFImKp+/W+LqtUHBC8NZiSkXLS1mAPIZipJ JNLjeyWfb3v2uOtBXX5LkDD2g3a4E107GnlFXK4kVQ==
X-Google-Smtp-Source: APXvYqyhOhdYnTfJdpeQhnlW6M37/5QYiPpkYLPUEVIda2VO8+FgWwpwDFvfDPNKQPmsBaExzn10D+3cCpf36hbd3ng=
X-Received: by 2002:a25:7349:: with SMTP id o70mr66549745ybc.476.1578018310706; Thu, 02 Jan 2020 18:25:10 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <CAHw9_iJrtGY=qUFngb=epJuLxrwfryv5peD=wx=2GL-ScV3kFw@mail.gmail.com>
Reply-To: ek@loon.com
From: Erik Kline <ek@loon.com>
Date: Thu, 02 Jan 2020 18:24:59 -0800
Message-ID: <CAAedzxqhtYUv9hX8FqnnGT6T22Oa4=pSx_BFgyhxK-mQw9VDig@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: Tommy Pauly <tpauly@apple.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "captive-portals@ietf.org" <captive-portals@ietf.org>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>
Content-Type: multipart/alternative; boundary="000000000000dc2f8b059b330443"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/tSyNgcEsFvRWZ24308NouUMa6U0>
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, 03 Jan 2020 02:25:14 -0000

111 or 114 pending approval from Apple both seem fine to me.

I'll add an Appendix C with a brief summary of the 160 polycom experience
for posterity.

On Thu, 2 Jan 2020 at 14:33, Warren Kumari <warren@kumari.net> wrote:

> On Thu, Jan 2, 2020 at 2:29 PM Tommy Pauly <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
>    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> 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 <tpauly@apple.com>
> > Sent: Monday, December 23, 2019 12:58 PM
> > To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
> > Cc: Bernie Volz (volz) <volz@cisco.com>; Michael Richardson <
> mcr+ietf@sandelman.ca>; captive-portals@ietf.org; Warren Kumari <
> 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> wrote:
> >
> > 
> > On Sat, 21 Dec 2019, 07:53 Bernie Volz (volz), <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
> > 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
> https://www.ietf.org/mailman/listinfo/captive-portals
>