Re: [Captive-portals] option 160 conflict

-01 uploaded.

On Fri, Jan 10, 2020 at 4:12 PM Erik Kline <ek@loon.com> wrote:

> sounds good.  I'll patch that in and upload a -01..
>
> On Fri, 10 Jan 2020 at 16:00, Warren Kumari <warren@kumari.net> wrote:
>
>>
>>
>> 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
>>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>