Re: [Captive-portals] option 160 conflict

On Fri, Jan 10, 2020 at 12:19 PM Tommy Pauly <tpauly@apple.com> wrote:
>
>
>
> 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?

Yup.

I'd think that adding something like the below to the IANA Considerations
section would work:

[RFC Ed: Please remove before publication:
RFC7710 uses DHCP Code 160 -- unfortunately, it was discovered that this
option code is already widely used by Polycom (see Appendix C).
Option 114 (URL) is currently assigned to Apple (RFC3679, Section 3.2.3 -
Contact: Dieter Siegmund, dieter@apple.com - Reason to recover: Never
published in an RFC)
Tommy Pauly (Apple) and Dieter Siegmund confirm that this codepoint hasn't
been used, and Apple would like to relinquish it for use in CAPPORT.
Please see thread:
https://mailarchive.ietf.org/arch/msg/captive-portals/TmqQz6Ma_fznD3XbhwkH9m2dB28
for more background ]

The IANA is requested to update the "BOOTP Vendor Extensions and DHCP
Options" registry (
https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml)
to:
Tag: 114
Name: DHCP Captive-Portal
Length: N
Meaning: DHCP Captive-Portal
Reference: [THIS-RFC]

Tag: 160
Name: REMOVED/Unassigned
Length:
Meaning:
Reference: [RFC7710][Deprecated].

——
Seeing as this is an unusual case, I’ll ask the IANA / Michele nicely how
this should best be worded / explain the background / ask nicely...

W

>
> Best,
> Tommy
>
>
> 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
>
> _______________________________________________
> 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
-- 
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