Re: [Captive-portals] DHCP/Captive Portal Experiment at IETF106 - SIN

2019-11-17 Thread Michael Richardson

Erik Kline  wrote:
> Some of the comments in that thread seem very disappointing and
> aggravating even (saying they'll use 161 if they need to, for example,
> which is allocated for MUD).

DHCP options are not hard to get.
Polycom should know better.



signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals


Re: [Captive-portals] DHCP/Captive Portal Experiment at IETF106 - SIN

2019-11-17 Thread Michael Richardson

Warren Kumari  wrote:
>> Christopher Morrow  wrote: > During
>> setup at the IETF meeting this week in Singapore the noc folk > setup
>> an experiment on the IETF wireless network, specifically on the > IETF
>> SSID to test your shiny new DHCP option(s) for captive portal, >
>> information about that is detailed here: >
>> https://tickets.meeting.ietf.org/wiki/CAPPORT
>> 
>> > So far, during our setup we noticed Polycom conference phones are >
>> 'unhappy' with this DHCP option (over ipv4). The Polycoms appear to >
>> believe that option 160 is for 'boot file location' :( Ingesting a
>> json > file for booting makes the Polycom sad :(
>> 
>> So, did they squat on this option, and should CAPPORT ask for a new
>> number?

> So, I had a very brief chat with IANA about this - because the
> assignment is in an RFC, changing it will be hard - it would require
> deprecating RFC7710, and publishing a new one with just the port
> changed...

Oh, yes.. I forgot that it was in the RFC not the new ID.

> Seeing as RFC7719bis is almost done (hopefully!) it seem to me that it
> would make more sense to just ask for a new port in that.

I think that we can do that. 
Unless the result is that polycom devices brick, in which case, I think we
should stick with 160, and Polycom can deal with being bad netizens.

> What would be interesting would be to try figure out if the next few
> codes (162 - 174) are “clean”.

Yes, I agree that we need to do that, and to recycle 160 to the end of the
list to be marked as unused and to be allocated at the end.

I'm so glad we discovered this now.

> E.g: Wyze seems to squat on 162, 163 is
> “Cisco-client-last-transaction-time” (?), etc.

> The current conflict with Polycom seems really bad (People having
> remote meetings often travel with polycoms). We really shouldn’t let
> squatters-rights drive our decisions, and I don’t think that conflicts
> with others will be as bad

Warren,
I'd like to ask the IAB Program that produced draft-iab-protocol-maintenance
to consider some set of processes for squatters.  (Squatters are tolerated by
by being liberal in what you accept)

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 



signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals