Re: [Captive-portals] Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)

[David Dolson <[e-mail]>]

One comment from me regarding this exchange:
>     >      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.

I don't think "local", implying physical proximity, is the correct word.
There are multiple technologies for serving DHCP, DNS, user portal, API, 
etc. from
*remote* machines. I feel that adding "e.g., local communication" would 
add more
confusion than clarity.

How about, "... permitted access to a small number of services 
(according to the
policies of the network provider) and is denied general network 
access..."

-Dave


On 2020-06-14 11:30, Eric Vyncke (evyncke) wrote:
> Thank you Kyle, I appreciate your answer and your comments.
> 
> Good to go ;-)
> 
> -éric
> 
> -----Original Message-----
> From: Kyle Larose <[e-mail]>
> Date: Sunday, 14 June 2020 at 17:07
> To: Eric Vyncke <[e-mail]>
> Cc: The IESG <[e-mail]>,
> "[e-mail]"
> <[e-mail]>, "[e-mail]"
> <[e-mail]>, captive-portals <[e-mail]>,
> Martin Thomson <[e-mail]>
> Subject: Re: Éric Vyncke's No Objection on
> draft-ietf-capport-architecture-08: (with COMMENT)
> 
>     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)
> <[e-mail]> 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 <[e-mail]>
>     > Date: Tuesday, 9 June 2020 at 14:43
>     > To: Eric Vyncke <[e-mail]>
>     > Cc: The IESG <[e-mail]>,
> "[e-mail]"
> <[e-mail]>, "[e-mail]"
> <[e-mail]>, captive-portals <[e-mail]>,
> Martin Thomson <[e-mail]>
>     > 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
>     >     <[e-mail]> 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
>     >