Captive Portal Architecture
draft-ietf-capport-architecture-10

Pretty straightforward.  Again, nice work.

Some nits:

Although I see why you did it, the capitalization of the bullet list in Section 3.2 appears peculiar.

Also curious is that "User Equipment" is defined in Section 2.1, but not shortened to "UE" anywhere other than in Section 3.5.

In Section 4.1, what's an "RA"?

I support Martin and Ben's DISCUSS positions.

Thanks for laying out the architecture to explain the subsequent protocol drafts.  A few areas of feedback:

** Section 2.1. Per “At this time we consider …”, to what is “at this time” referring (maybe this is referring to the WG scope)?  This might not age well as currently framed.

** Section 2.2.  The architecture doesn’t explicitly describe which component is responsibility for provisioning the user equipment sufficiently so it can access the IP network anywhere.  I would have expected it to be the Provisioning Service.  Section 2.1, 2.3 and 2.4 describe the role of these components in the architecture and their requirements.  Section 2.2 does not.  Instead it describes candidate technologies.  It would be helpful to explicitly say.

** Section 2.3.  Perhaps this is too pedantic, but should the obvious be explicitly called out: the user equipment should only be able to check it’s own captivity status?  This would be some explicit notion of authorization.

** Section 2.3  Per “A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports.”, is the caller the User Equipment, the web browser or the end user – does that distinction matter – does each layer need anything different?

** Section 3.2.1.  Per “Each instance of User Equipment interacting with the Captive Network MUST be given an identifier that is unique among User Equipment interacting at that time.”, is “unique among user equipment interacting at that time” the same as saying “unique among the identifiers currently in use in the Captive Network”?  It might be useful to frame this guidance within the scope of the previous definitions.

** Section 3.2.2.  The acceptable workfactor for “hard” still isn’t clear here but I understand the difficulty of pinning it down while remaining flexible.

** Section 4.  Does this section provide normative guidance?  The introductory sentence suggests no by saying that this section describes “possible workflow[s]”.  However, Section 4.3 uses a normative SHOULD.

** Section 4.2.  Between step #2 and #3, did some kind of signaling happen to indicate that expiration is imminent, or did the UE keep state of some kind?  Keeping state isn’t mentioned as a UE requirement in Section 2.1.  Section 2.5. notes that a “signal might be generated when the end of a session is imminent”.

** Section 7.  This section would benefit from a discussion of the privacy impacts of the implicit identifiers embedded into the architecture (e.g., re-identification)

** Section 7.1. Per “If a user decides to incorrectly trust an attacking network ….”, you have an on-path attacker so additional risks include traffic redirection to arbitrary destinations to server malicious payloads; traffic analysis and loss of confidentiality; inline traffic modification; etc.

** Section 7.2.  Per “The solution described here assumes that when the User Equipment needs to trust the API …”, why is this conditional.  Doesn’t the UE have to trust the API server?

** Section 7.3.  In addition to integrity and confidentiality, is there an authenticity requirement?  I ask because Section 2.1. noted that the UE “SHOULD [be] allow[ed] access to any services that User Equipment could need to contact to perform certificate validation.”

Thank you for the work put into this document. The document is easy to read. I also appreciate the fact that "devices without user interfaces" are not ignored by this document.

Please find below a couple on non-blocking COMMENTs. A response/comment for those COMMENT will be read with interest.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Is there a reason why the words "captive portal" do not appear in the abstract? This would assist normal human beings (outside of the WG) to find the document.

I found no text about what happens to the traffic inside the captive network. Is it allowed even when still in captive mode ?

-- Section 1.2 --
Even if the document support "devices without user interfaces", I wonder why the I-D uses "User Equipment" rather than "Client Equipment" (which is also more aligned with "Server"). Nothing dramatic, just curious about the reason.

-- Section 2.1 --
"At this time we consider only devices with web browsers" while the previous text was about "devices without user interfaces". Finally, is this document for devices with or without human interface ?

-- Section 2.6 --
While the components are described as being optional collocated, what about resiliency ? I.e., having two different instances on one component.

-- Section 3.4.2 ---
While I appreciate that the section contains text about multiple IPv6 addresses, I suggest to mention the dual-stack use case explicitly.

-- Section  3.4 --
I was expecting to see the MAC address also used as identifier. Is there any reason why it is not mentioned? If so, may I suggest to document the absence of a MAC address section in the examples?

I have some minor comments:


(1) Please expand CAPPORT.


(2) §1: s/This document standardizes an architecture/This document describes an architecture   This is not a standard track document.


(3) §1: "MAY allow a device to be alerted"   Other parts of the document (even in the same section) talk about "devices can be notified" or "informs an end-user", while "alert" is not mentioned anywhere else.  Given that "alert" has the normative attachment, it would be nice to use consistent language.


(4) §2.1: "E.g....MAY avoid updating..."   s/MAY/may   This is an example, not a normative statement.


(5) §3.1: "An Identifier MAY be a field...Or, an Identifier MAY be an ephemeral property..."   s/MAY/may  These seem to be statements and not normative statements.

Thank you for addressing my Discuss (and comment!) points.

A few new notes on the -09:

Section 1.2 has a new instance of "Captive Network" that didn't get caught
up in the renaming of "Captive Network" to "Captive Portal"

Section 2.1

Maybe s/navigate the User Portal/navigate to the User Portal/?

Dave's suggested rewording
(https://mailarchive.ietf.org/arch/msg/captive-portals/nMLJv4gzGjBQZN_5-TJyrfZZbkI/) 
is correct but not parallel to how we discuss the DNS-ID case.
I'd recommend either rewording both cases or neither, but don't
have much of a stance on which is preferred.

After further discussion, I see that draft-09 does indeed address my Discuss - the user-portal-url is optional in practice, just something the api design has to cover.

I found the terminology around “Captive Portal API server” and “Captive Portal Server” to be a little confusing, as these are similar terms. The latter also doesn’t get its own discussion in Section 2 and is confusingly called the “web portal server” in Figure 1.

After Figure 1, this seems to be consistently called the “web portal” (sec 2.6 and 4). In the API doc it is called a "user portal." It would be great to unify the terminology across the documents as a whole.

I found this document easy to read, but have a few comments.

I support the 3rd bullet of Ben's discuss.

I was surprised by the diagram in section 2.6, since it seems to imply that the Provisioning Service kicks everything off, but I would have expected the User equipment to initiate the flow, which is articulated in the first step of section 4.1.  Hence, I think that the diagram could be more clear if it also showed the initial request from the client (as per the first step in 4.1).

Finally, I note that this document makes no mention of OAM considerations.  Having some text covering these aspects would probably be beneficial.