Thanks again, Eric. Resposnes inline. I'll take the same approach as you did, with KL>
On Tue, 9 Jun 2020 at 17:33, Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > > Hello Kyle > > Thank you for the prompt reply, look for EV> for any remaining non-blocking > comments of mine > > -eric > > -----Original Message----- > From: Kyle Larose <k...@agilicus.com> > Date: Tuesday, 9 June 2020 at 14:43 > To: Eric Vyncke <evyn...@cisco.com> > Cc: The IESG <i...@ietf.org>, "draft-ietf-capport-architect...@ietf.org" > <draft-ietf-capport-architect...@ietf.org>, "capport-cha...@ietf.org" > <capport-cha...@ietf.org>, captive-portals <captive-portals@ietf.org>, Martin > Thomson <m...@lowentropy.net> > Subject: Re: Éric Vyncke's No Objection on > draft-ietf-capport-architecture-08: (with COMMENT) > > 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. > > EV> you may add "(.g., local communication)" after "small number of services" > ? KL> Thanks for the suggestion! We'll clarify along those lines. > > > > -- 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? > > EV> nothing critical and possibly impacting too many other documents to be > changed now > > > -- 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? > > EV> 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. > > EV> I would suggest that at the first mention of " devices without user > interfaces", the text mention "for future version" or something in the same > line. The focus on user-interface devices is written a little too deep in the > document, should come earlier in the text to avoid confusion. KL> Thanks again for the suggestion. In section 1, where we first mention these devices, I'll add text along the following lines: "A future document could provide a solution for devices without user interfaces. This document focuses on devices with user interfaces." > > > > > -- 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" > > EV> perfect ;-) > > > -- 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" > > EV> could be good. And, I am not sure whether it is more difficult to spoof > an IP address vs. a MAC address. But, the added text is enough for me > > -éric > > > > > > > Thanks! > > Kyle > _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
