Dave
Your suggestion is good for me
-éric
-----Original Message-----
From: David Dolson <ddol...@acm.org>
Reply-To: "ddol...@acm.org" <ddol...@acm.org>
Date: Monday, 15 June 2020 at 04:32
To: Eric Vyncke <evyn...@cisco.com>
Cc: Kyle Larose <k...@agilicus.com>, 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)
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 <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
