I, for one, disagree --

I believe the *risks* are that we: make network signaling optional, keep
going down the road of trying to solve network enforcement at an
Application layer, and ultimately just adding another way for Hotspots to
be "broken".

Just wanted to highlight a few comments made recently to the list
concerning ICMP:

"So using ICMP as hint and doing rate limited operatins based on that is

"if authenticating ICMP messages would be easy there would already be
authentication in them :-)

"I *agree* about viewing ICMP as a hint for the user equipment to visit the


On Fri, Apr 13, 2018 at 3:15 AM Martin Thomson <martin.thom...@gmail.com>

> Thanks to Lorenzo for kicking off the discussion about the desirable
> properties of a signal from the network.
> ( Thread starts:
> https://mailarchive.ietf.org/arch/msg/captive-portals/pYYQqxAzJp8ZVLtfu1QLqJdMiiM/?qid=7c89d24eec00ff0608ee5398c9bb9d33
> )
> The chairs have discussed this and would like to confirm the following
> conclusions:
> 1. We don't have any current proposal for a signal that the group
> deems suitable.  For now, we will remove pieces from the API and
> architecture documents that specifically mention ICMP.
> 2. We will add a description of the properties we believe that a
> signal should have to the architecture document, but note that no such
> signal is defined.  That is, the signal will be sent by the network
> when it believes that a UE should check with the API for updated
> information.  The UE will treat that signal as a hint and may talk to
> the API as a result.  Rate-limiting will likely be needed.
> 3. We will consider a proposal to define a signal in future.  That
> would be a stand-alone proposal if it appeared.  To my reading, it is
> within our charter to take on work like that, but we would probably
> need to have a discussion with our AD at that point because we're
> already past our milestones.
> Does anyone disagree with these conclusions?  I don't think that this
> completely rules out the use of ICMP, though Destination Unreachable
> might not be an ideal fit as was discussed in London.
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
Captive-portals mailing list

Reply via email to