Thanks for doing this Gurshabad. I think we've debated the removal of the signaling section on a number of occasions. Could this text perhaps be reduced to something simpler, especially in light of our decision not to specify anything?
Perhaps: --->8-- When User Equipment first connects to a network, or when there are changes in status, the Enforcement Device could generate a signal toward the User Equipment. This signal indicates that the User Equipment might need to contact the API Server to receive updated information. For instance, this signal might be generated when the end of a session is imminent. An Enforcement Device MUST rate limit any signal; User Equipment MUST rate limit attempts to contact the API Server; see Section 7.4. --8<--- That loses a lot of text, but I don't know that any of what is presently there is critical. For instance, the current text recommends against a spoofable signal, but doesn't really say what it means to spoof. What do the editors of the spec think? On Tue, Mar 24, 2020, at 13:52, Gurshabad Grover wrote: > On 3/5/20 12:25 PM, Martin Thomson wrote:> This starts a joint working > group last call on these documents. Please respond this mail with your > views regarding the suitability of these documents for publication (as > Informational RFC and Proposed Standard RFC respectively) before 2020-03-23. > > > > Thanks for all the great work, authors and editors! I have reviewed > capport-architecture, and I support its publication as an RFC. Some > comments below. > > On capport signal > ----------------- > The Captive Portal Signal section (2.5) was a bit confusing to me. > > Is 'signal' only meant to be binary information, i.e. whether traffic is > restricted or not? (pt. 3 in the section) If yes, the inclusion of a > 'pending expiry' notification in the same section seems contradictory. > (It also assumes that some information is available since "On receipt of > preemptive notification, the User Equipment can prompt the user to > refresh.") > > I think the clearest explanation of it is offered in the Security > Considerations rather than the section itself, i.e. the signal should > not carry any information at all, that it just acts as a prompt for the > User Equipment to contact the API. (This explanation makes other things > fall in line as well: the 'pending expiry' notification is just a > timed-signal that is no different from any other except for when it was > triggered.) > > I would suggest rephrasing sentences in the Captive Portals section to > make them as clear as the security considerations text. If my > understanding is correct, please let me know and I'm happy to submit a > PR to this effect. > > > Pull request > ------------ > I have submitted a pull request with some editorial suggestions; happy > to elaborate on them if the motivation is not clear from the changes. > <https://github.com/capport-wg/architecture/pull/51> > > > Privacy considerations > ---------------------- > Since we're dealing with unique identifiers and traffic information, > would love to hear people's thoughts on whether a brief privacy > considerations section would be useful. If yes, happy to help with that. > > > > Thank you. > -Gurshabad > _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
