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

["Eric Vyncke (evyncke)" <[e-mail]>]

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

Good to go ;-)

-éric

-----Original Message-----
From: Kyle Larose <[e-mail]>
Date: Sunday, 14 June 2020 at 17:07
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, captive-portals <[e-mail]>, Martin Thomson <[e-mail]>
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) <[e-mail]> 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 <[e-mail]>
    > Date: Tuesday, 9 June 2020 at 14:43
    > To: Eric Vyncke <[e-mail]>
    > Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, captive-portals <[e-mail]>, Martin Thomson <[e-mail]>
    > 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
    >     <[e-mail]> 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
    >