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

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

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