Re: [Captive-portals] DHCP/Captive Portal Experiment at IETF106 - SIN
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
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
Re: [Captive-portals] DHCP/Captive Portal Experiment at IETF106 - SIN
On Sun, Nov 17, 2019 at 11:03 AM Michael Richardson 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... 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. What would be interesting would be to try figure out if the next few codes (162 - 174) are “clean”. 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 W > > > ___ > 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
Re: [Captive-portals] DHCP/Captive Portal Experiment at IETF106 - SIN
On Sun, 17 Nov 2019 at 12:03, Michael Richardson 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? > 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). We could ask for a new option, or we could decide that it's not a big enough problem in the real world. I've added this to a slide for discussion on Wednesday morning. I think my first inclination would be to speculate wildly and without data about whether the anticipated intersection of Polycom and captive portal networks is big enough to worry about. I mean, technically, they're "holding it wrong"... ___ 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
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? signature.asc Description: PGP signature ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
[Captive-portals] DHCP/Captive Portal Experiment at IETF106 - SIN
Howdy! 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 :( -chris fyi: There is a polycom community discussion about their behavior here: https://community.polycom.com/t5/VoIP-SIP-Phones/DHCP-Standardization-160-vs-66/m-p/72579/highlight/true#M13020 ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
