[Captive-portals] AD review of draft-ietf-capport-architecture-07
Barry Leiba <barryleiba@computer.org> Fri, 24 April 2020 23:36 UTC
Return-Path: <barryleiba@gmail.com>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1168D3A0F59; Fri, 24 Apr 2020 16:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.219
X-Spam-Level:
X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYtzoKI0V0Gr; Fri, 24 Apr 2020 16:36:05 -0700 (PDT)
Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A29E3A0F58; Fri, 24 Apr 2020 16:36:02 -0700 (PDT)
Received: by mail-io1-f44.google.com with SMTP id k6so12263870iob.3; Fri, 24 Apr 2020 16:36:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=UbV1mUYyzr3mK5z6yJPUUcM1uld+xEvKhX5FlG4Z3do=; b=ZxRObsDnBWU+YZyEk+9mf9Tqk/fCpwMIT8pbcO23ueh4KAZvgM2YLb69oRm/V1UgQA deR8ceB6xeT3Y/zEtSXJRJdkqaS2w0KDZtftVhhJTRCXsAaNe3g+E/gvvbpzm0Tc4p+d egOZAed1n14oVR1YIGK4N7QerI9EMXmhp+zL6MKEse5bubPRoSzx8rCZlYoHnQcc0lRQ 9g6l+0I0NiQBOxbNpDZdnNxzrFcr4PnVSDpCR9zarmPxh9MXGT/xGSg+GfpqS2BsEUeo k8IGhNRt2XoqfXHRgrJ+wIeVCe9B0rKFpy7BSxnmw0E9J28T/iPFv/ivk2jF6fFTAi4n 8LoA==
X-Gm-Message-State: AGi0PuboOQCLu73uF0oeZAsKUM2wi++U+Rb02sZgvG4VAa1/PNm4EEoW h5OC7Q0iGcywRclyMVPohHlwBSgj31NMrPzsLVZepooaSJU=
X-Google-Smtp-Source: APiQypJlXcT4QARd0iMHNhak+6NN2lLvHVOGui7DeO0sVVBDIXqfo31gNY5ODP17m6bBp4iimBcF3jjDc5cKbxgUhJ8=
X-Received: by 2002:a5d:9a8d:: with SMTP id c13mr973710iom.160.1587771361202; Fri, 24 Apr 2020 16:36:01 -0700 (PDT)
MIME-Version: 1.0
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 24 Apr 2020 19:35:49 -0400
Message-ID: <CALaySJ+K1FZu5POa=TLz2-ON8=jvyE03gqdi+5+cNj8X4E9RoA@mail.gmail.com>
To: draft-ietf-capport-architecture.all@ietf.org
Cc: captive-portals@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/kCEUyhvlu2hizNjBZ94qXqNR0pc>
Subject: [Captive-portals] AD review of draft-ietf-capport-architecture-07
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2020 23:36:07 -0000
Thanks for the work in this document. Here’s my AD review; I think a revised I-D is needed before we go to last call. General: Expect comments during IESG Evaluation about the extensive use of BCP 14 key words in an Informational document. I don’t object to it here, though I do find all the “MAY”s odd (example: “A device MAY query this API at any time”, rather than “A device may query this API at any time”), but I do expect some ADs to comment on it. Please check consistency in capitalization of defined terms. The one that stands out to me as inconsistent is “User Equipment” / “user equipment”, but I’ve also noticed others, such as “enforcement device”. Please be consistent about using “URI”, and not “URL”. — Section 1 — This document standardizes an architecture for implementing captive portals that provides tools for addressing most of those problems. We are guided by these principles: The text that comes before this doesn’t identify anything as problems, so I don’t see, from what’s written, what “those problems” refers to. Maybe it would be better to say, “most of the problems that result from current captive portal mechanisms, guided by these principles:” or some such? * Solutions MUST operate at the layer of Internet Protocol (IP) or above, not being specific to any particular access technology such as Cable, WiFi or 3GPP. 3GPP is not an access technology; it’s an SDO (or a consortium of SDOs). Maybe “mobile telecom”, or “LTE”, or “5G”? Or if you want to retain 3GPP, maybe “protocols developed in 3GPP”? I think my preference is “5G” (and it’s only an example anyway). * End-user devices can be notified of captivity with Captive Portal Signals in response to traffic. This notification should work with any Internet protocol, not just clear-text HTTP. I’m not quite sure what this means. It sounds like it says that the notification will be in-band with any Internet protocol, which clearly isn’t possible. I think it’s talking about a separate protocol to deliver the notification, which can work alongside any Internet protocol, rather than having it be in-band to clear-text HTTP. Maybe re-wording that sentence will help. — Section 1.2 — hosts (typically the internet). Nit: capitalize “Internet”. Captive Portal API: Also known as API. An HTTP API allowing User Equipment to query its state of captivity within the Captive Portal. This (and the Abstract) says “an HTTP API”, but there’s nothing at the architecture level that assumes HTTP, is there? Instantiation may well be via HTTP, but why does that need to be in the architecture? I don’t see anything else in this document, apart from these two definitions, binding the API to HTTP at the architecture level. If User Equipment supports the Captive Portal API, it MUST validate API server TLS certificate (see [RFC2818]). Nit: “validate the API server’s TLS certificate” — Section 2.3 — The API SHOULD provide evidence to the caller that it supports the present architecture. I don’t understand what this means; can you explain? — Section 2.4 — The Captive Portal Enforcement component restrict the network access Nit: “restricts” * Allows traffic through for allowed User Equipment that has “Allows traffic through” reads oddly to me. Maybe “Allows traffic to pass through”? Or “Allows general Internet traffic”? — Section 2.6 — In Figure 1, shouldn’t “Query captivity status” and “Portal user interface” both have bidirectional arrows? — Section 3 — these interactions, the components must be able to both identify the user equipment from their interactions with it, and be able to agree Common problem with “both” and “either”: “be able” is already outside the scope of “both”, so having it inside for the second case is wrong (and the comma is unnecessary): NEW these interactions, the components must be able to both identify the User Equipment from their interactions with it and to agree END — Section 3.2.1 — In order to uniquely identify the User Equipment, at most one user equipment interacting with the other components of the Captive Portal MUST have a given value of the identifier. The way “MUST” is used here feels very odd. I think you mean the MUST to be related to the uniqueness, not to what components MUST have. Maybe something like this works better?: NEW In order that User Equipment be uniquely identified, a given identifier MUST NOT represent more than one User Equiment that interacts with the other components of the Captive Portal. END — Section 3.2.3 — Since the API Server will need to perform operations which rely on the identity of the user equipment, such as query whether it is captive, the API Server needs to be able to relate requests to the User Equipment making the request. The API server doesn’t query whether the UE is captive, it responds to such queries. — Section 3.2.4 — The Enforcement Device will decide on a per packet basis whether it should be permitted to communicate with the external network. Nit: hyphenate “per-packet”. “It” should be referring to the packet, not to the ED, so “whether the packet should”. — Section 3.3 — Are we really talking about evaluating individual identifiers here? Or does this really mean to discuss *methods* of generating or choosing identifiers? — Section 3.4.3 — Is this section talking about using a context-free URI as a UE identifier? It should be clearer about that, if so (and if that’s not what it’s about, the section is misplaced). There’s nothing in here that discusses how such identifiers would meet the specified criteria. — Section 4 — Please be consistent about the use of “workflow” vs “work-flow”. — Appendix A — method is to attempt to make a HTTP request to a known, vendor hosted Nit: hyphenate “vendor-hosted” DNS queries not using UDP may potentially fail this test if operating over TCP or DNS over HTTP. Nit: it’s “DNS over HTTPS”. But I would say, “DNS queries not using UDP may potentially fail this test if operating over TCP or HTTPS.” -- Barry
- [Captive-portals] AD review of draft-ietf-capport… Barry Leiba
- Re: [Captive-portals] AD review of draft-ietf-cap… David Dolson
- Re: [Captive-portals] AD review of draft-ietf-cap… Barry Leiba
- Re: [Captive-portals] AD review of draft-ietf-cap… Tommy Pauly
- Re: [Captive-portals] AD review of draft-ietf-cap… Barry Leiba
- Re: [Captive-portals] AD review of draft-ietf-cap… Kyle Larose
- Re: [Captive-portals] AD review of draft-ietf-cap… Michael Richardson
- Re: [Captive-portals] AD review of draft-ietf-cap… Barry Leiba
- Re: [Captive-portals] AD review of draft-ietf-cap… Barry Leiba
- Re: [Captive-portals] AD review of draft-ietf-cap… Barry Leiba
- Re: [Captive-portals] AD review of draft-ietf-cap… Martin Thomson