Re: [Captive-portals] Last Call: (CAPPORT Architecture) to Informational RFC
On Tue, May 12, 2020, at 22:32, Bob Harold wrote: > > How does the capport wg feel as a whole about this question? [MAC as > > identifier] > > I am also wondering the same thing. We did discuss this, if I recall. From memory, there were a few reasons not to go further: MAC randomization means that the identifier might not be stable (I don't think that this is relevant in retrospect as MAC is no worse in this way than IP) The nature of MAC and what entities could access that information means that it is more vulnerable to spoofing. That is, an entity that is not on the same network segment would be unable to see the MAC and verify that incoming data was attributed to the UE. No one volunteered to do a more thorough analysis. As we have the generic criteria Kyle refers to, that was considered enough. ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Last Call: (CAPPORT Architecture) to Informational RFC
Hello, Thanks for the quick feedback On Mon, 11 May 2020 at 15:25, S Moonesamy wrote: > > I took a quick look at the draft. The third paragraph in the > Introduction section states that the document standardizes an > architecture for implementing captive portals. Does it meant that > this draft is intended to be a standard? > The draft is intended to be informational. We should probably rephrase that section. I have submitted a gh issue: https://github.com/capport-wg/architecture/issues/74 > The principles listed to guide the architecture looks more like > requirements. Anyone who has been at an airport understands that > existing protocols are being intercepted, forged, broken, etc. to get > to reach the user to go through the "captive" experience. The > "SHOULD NOT" (why are the words in uppercase?) comes out as a > principle that "one should follow the existing standards". > I don't quite understand your point here. Are you suggesting that because it is commonly known that existing captive portal implementations do these things, saying that we should not do them instead means we should? Our goal is to document an architecture that allows providers to offer a service that does not use these mechanisms. This is why we're suggesting that a solution shouldn't do that. Do you have a suggestion for alternate phrasing that is less confusing? > What are there "MAY" principles? > Perhaps we shouldn't be calling these principles, but rather the requirements the document is placing on a solution that will lead to a good outcome. I've submitted https://github.com/capport-wg/architecture/issues/75 for us to consider reworking this section. I welcome any suggestions for how to improve it. > This document is about the architecture. Where does it provide for > incremental migration? > We don't have an explicit section, but we considered existing captive portal implementations when putting together the document. The new components are not tightly coupled by the architecture, meaning that any of them could be omitted. You wouldn't have the functionality they provide, but a solution without them would still work. > On reading further, I would say that the draft is a mix of > requirements and "solution" instead of a draft about architecture. > I view an architecture as guidelines for how components of a system interact as well as definitions of those components. Perhaps that is the wrong view, but it is what I think we documented. The draft does talk about solutions, since the end goal of the components we're describing is a solution to the problem of providing internet access through wifi hotspots. It places requirements on the components which form the system, and their interactions The document also provides examples for clarity. Perhaps the examples consume too much of the document, making them seem like recommendations for a particular solution, or the interactions are not sufficiently abstract to allow for multiple solutions? Does anything in particular stand out to you that warrants change? Thanks, Kyle ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Last Call: (CAPPORT Architecture) to Informational RFC
On Tue, May 12, 2020 at 8:10 AM Kyle Larose wrote: > Hi Bob, > > Thanks for the quick feedback. > > > I am curious why section 3.4 does not consider the MAC Address as a > possible identifier? > > Its omission doesn't mean that the MAC Address is not a valid > identifier. One should evaluate it using the criteria provided in 3.2 > and 3.3. When I wrote the skeleton of this section, I left the MAC > Address out more to keep the section short than anything, though I did > consider adding it. > > Bob, do you think the MAC address needs to be considered in this > section for completeness? > I won't argue too much if you decide to leave it out, but it seems like the most obvious identifier, and is used by many things, so it would be good to list its pros and cons. > How does the capport wg feel as a whole about this question? > I am also wondering the same thing. Thanks, > > Kyle > > On Mon, 11 May 2020 at 13:36, Bob Harold wrote: > > > > I am curious why section 3.4 does not consider the MAC Address as a > possible identifier? > > > > -- > > Bob Harold > > > > > > On Mon, May 11, 2020 at 12:56 PM The IESG > wrote: > >> > >> > >> The IESG has received a request from the Captive Portal Interaction WG > >> (capport) to consider the following document: - 'CAPPORT Architecture' > >>as Informational RFC > >> > >> The IESG plans to make a decision in the next few weeks, and solicits > final > >> comments on this action. Please send substantive comments to the > >> last-c...@ietf.org mailing lists by 2020-05-25. Exceptionally, > comments may > >> be sent to i...@ietf.org instead. In either case, please retain the > beginning > >> of the Subject line to allow automated sorting. > >> > >> Abstract > >> > >> > >>This document describes a CAPPORT architecture. DHCP or Router > >>Advertisements, an optional signaling protocol, and an HTTP API are > >>used to provide the solution. The role of Provisioning Domains > >>(PvDs) is described. > >> > >> > >> > >> > >> The file can be obtained via > >> https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/ > >> > >> > >> > >> No IPR declarations have been submitted directly on this I-D. > > ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
Re: [Captive-portals] Last Call: (CAPPORT Architecture) to Informational RFC
Hi Bob, Thanks for the quick feedback. > I am curious why section 3.4 does not consider the MAC Address as a possible > identifier? Its omission doesn't mean that the MAC Address is not a valid identifier. One should evaluate it using the criteria provided in 3.2 and 3.3. When I wrote the skeleton of this section, I left the MAC Address out more to keep the section short than anything, though I did consider adding it. Bob, do you think the MAC address needs to be considered in this section for completeness? How does the capport wg feel as a whole about this question? Thanks, Kyle On Mon, 11 May 2020 at 13:36, Bob Harold wrote: > > I am curious why section 3.4 does not consider the MAC Address as a possible > identifier? > > -- > Bob Harold > > > On Mon, May 11, 2020 at 12:56 PM The IESG wrote: >> >> >> The IESG has received a request from the Captive Portal Interaction WG >> (capport) to consider the following document: - 'CAPPORT Architecture' >>as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits final >> comments on this action. Please send substantive comments to the >> last-c...@ietf.org mailing lists by 2020-05-25. Exceptionally, comments may >> be sent to i...@ietf.org instead. In either case, please retain the beginning >> of the Subject line to allow automated sorting. >> >> Abstract >> >> >>This document describes a CAPPORT architecture. DHCP or Router >>Advertisements, an optional signaling protocol, and an HTTP API are >>used to provide the solution. The role of Provisioning Domains >>(PvDs) is described. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/ >> >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> >> >> ___ >> Captive-portals mailing list >> Captive-portals@ietf.org >> https://www.ietf.org/mailman/listinfo/captive-portals ___ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
