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
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals