Re: [Captive-portals] option 160 conflict

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