Thank you Kyle, I appreciate your answer and your comments.
Good to go ;-)
-éric
-----Original Message-----
From: Kyle Larose <k...@agilicus.com>
Date: Sunday, 14 June 2020 at 17:07
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)
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
>
