Re: [Captive-portals] option 160 conflict

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.

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 <mailto:lorenzo=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>