Hi Éric, Thanks for the review!
Responses inline. On Mon, 8 Jun 2020 at 10:07, Éric Vyncke via Datatracker <nore...@ietf.org> wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-capport-architecture-08: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 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. > Good point! We'll fix that up. > I found no text about what happens to the traffic inside the captive network. > Is it allowed even when still in captive mode ? This would be up to the network operator, I suppose -- they define the extent of the walled garden. The only hosts that must be reachable are any necessary to perform the workflows related to gaining access. The document mentions those in a few places. In section 2.4, the document states: Typically User Equipment is permitted access to a small number of services and is denied general network access until it satisfies the Captive Portal Conditions. Perhaps we could add some language indicating that this isn't intended to be a normative requirement -- the restrictions placed by the captive portal depend on its use-case. > > -- 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. > This is the language that evolved during our discussions. I can't recall any particular reason we chose this. Does anyone with a better memory than me remember why we chose User Equipment over Client Equipment? > -- 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 ? When we first set out to tackle the architecture, we were hoping to solve the problem for devices without user interfaces. However, the working group aligned on solving it for the simpler use-case of devices with user interfaces. To ensure we're talking about the same thing, the earlier text you're referring to is this, correct? -- Section 1 -- A side-benefit of the architecture described in this document is that devices without user interfaces are able to identify parameters of captivity. However, this document does not yet describe a mechanism for such devices to escape captivity. Our intent was to point out that solutions for devices without user interfaces could be developed using the mechanisms provided by the architecture, but that those solutions were out of scope for the document. Which text do you think conflicts with that? Perhaps we should rephrase it to be less confusing. > > -- Section 2.6 -- > While the components are described as being optional collocated, what about > resiliency ? I.e., having two different instances on one component. > That's a good point (and one I was thinking about the other day!) We should add some text pointing that out. Let's mention scale for good measure as well. > -- 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. > I.e. something like "Further attention should be paid to a device using dual-stack [rfc4213]: it could have both an IPv4 and an IPv6 address at the same time. There could be no properties in common between the two addresses, meaning that some form of mapping solution could be required to form a single identity from the two address" > -- 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? > This was also raised during an earlier last call. The primary reason to leave it out was brevity, but there were some concerns about its security as well. Perhaps we can leave a simple note along the lines of the following since it is likely others will ask the same question: "The MAC address of a device is often used as an identity in existing implementations. A discussion of it has been omitted for brevity, but the MAC address could be used subject to the criteria in section 3.2" > > Thanks! Kyle _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
