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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 08 Jun 2020 07:06:47 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-capport-architecture-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/

----------------------------------------------------------------------
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.

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?

---

From: Kyle Larose <[email-masked]>
Date: Tue, 9 Jun 2020 08:43:27 -0400

Hi Éric,

Thanks for the review!

Responses inline.

Good point! We'll fix that up.

> 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.

> 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?

> 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.

> 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.

> 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"

> 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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 9 Jun 2020 21:33:05 +0000

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 <[email-masked]>
Date: Tuesday, 9 June 2020 at 14:43
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, captive-portals <[email-masked]>, Martin Thomson <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)

    Hi Éric,

    Thanks for the review!

    Responses inline.

EV> you may add "(.g., local communication)" after "small number of services" ?

EV> nothing critical and possibly impacting too many other documents to be changed now

EV> correct

    -- Section 1 --

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.

    I.e. something like

EV> perfect ;-)

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

---

From: Kyle Larose <[email-masked]>
Date: Sun, 14 Jun 2020 11:06:57 -0400

Thanks again, Eric.

Resposnes inline. I'll take the same approach as you did, with KL>

> EV> you may add "(.g., local communication)" after "small number of services" ?

KL> Thanks for the suggestion! We'll clarify along those lines.

> 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 writ…

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."

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 14 Jun 2020 15:30:43 +0000

Thank you Kyle, I appreciate your answer and your comments.

Good to go ;-)

-éric

-----Original Message-----
From: Kyle Larose <[email-masked]>
Date: Sunday, 14 June 2020 at 17:07
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, captive-portals <[email-masked]>, Martin Thomson <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)

    Thanks again, Eric.

---

From: David Dolson <[email-masked]>
Date: Sun, 14 Jun 2020 22:31:56 -0400

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:
> Cc: The IESG <[email-masked]>,
> "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, captive-portals <[email-masked]>,
> Martin Thomson <[email-masked]>
> Subject: Re: Éric Vyncke's No Objection on
> draft-ietf-capport-architecture-08: (with COMMENT)
> 
>     Thanks again, Eric.
> 
>     > Cc: The IESG <[email-masked]>,
> "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, captive-portals <[email-masked]>,
> Martin Thomson <[email-masked]>
>     > Subject: Re: Éric Vyncke's No Objection on
> draft-ietf-capport-architecture-08: (with COMMENT)
>     >
>     >     Hi Éric,
>     >
>     >     Thanks for the review!
>     >
>     >     Responses inline.
>     >
>     > 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.
> 
>     > 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
>     >

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 15 Jun 2020 07:49:41 +0000

Dave

Your suggestion is good for me

-éric

-----Original Message-----
From: David Dolson <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Monday, 15 June 2020 at 04:32
To: Eric Vyncke <[email-masked]>
Cc: Kyle Larose <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, captive-portals <[email-masked]>, Martin Thomson <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)

    -Dave