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