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
>
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
