Re: [Captive-portals] WGLC on draft-ietf-capport-architecture and ...-api

Kyle Larose <> Sat, 14 March 2020 16:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37A833A03FF for <>; Sat, 14 Mar 2020 09:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.901
X-Spam-Level: **
X-Spam-Status: No, score=2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Vu4ypELGcMX for <>; Sat, 14 Mar 2020 09:22:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 718D43A03FA for <>; Sat, 14 Mar 2020 09:22:11 -0700 (PDT)
Received: by with SMTP id h3so12172868ils.3 for <>; Sat, 14 Mar 2020 09:22:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KWv5xSG9QoLTz4DqUSW6aVKpyn9t0VIbmRpWYl2N7Xw=; b=PMukrJA0oUQDovMkDIlm7HTQc3BZSZA7bodTGEm1j/yq0Ao2V5iaCK3t1J8OgsgM96 J7lxY8FhkNTFo9d/Ok4DJr3n/43WgrNJ58HHzCIHPAGbFJii9mmS5YQGiVYZ7SKfQmX+ B3yxX4Fq9+AWEUXwpS4WMCbBZqGCC8gjkSMGR+36oGck9z1EzoTbcfzRp64MRgg6wCFD CxheF6ctvPH2avREn1Y1VHhJfSZQB+tMIrnFsAxGVqCkngiHPevL7hSc/lrbpcTG/JYt XaQXwQb+yH/4W+g4E1ukhqqFK6/U8Qx2Jb2SRXyXgTzL04CWYEqTmlnJdPbJJ/uzW2c7 Ev6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KWv5xSG9QoLTz4DqUSW6aVKpyn9t0VIbmRpWYl2N7Xw=; b=jVYFVX5efxr6UTJ8w+elHuFdlA6uL3v8i7XTAn1rHpK8KYdk0Crh5j9CUKT7JL5yAh A+QvTQ7Kq11U3Iry/RyU/WBcDtS578vMZy1bbZf+rZZftMB8jqmPQ7/47ndJjSb85sOy /28PiJ6Bv2QNAi9Xvjd4FBdoq0D0DkDbwjIx5ulrJQLTYP093SMTWfZsJDcKRSaPtevt AsDcC2RTQJmmkJ/CiyeGe15RuRw7zFRXtDMBkwhTkZonT7Le0dlHoC41ww3uvDLF5iCK Jb86iiWXY/ZWyMHLpYwsXehmQzrAw66P6mPs8rZwrwBDsjxr1sdSdURk5wv7gc/v/dFI HSEA==
X-Gm-Message-State: ANhLgQ3iwiukGU+A5tp34MDbSEKZuy87iHAFzz+sXLcHp/9VJZncego3 Sv9SwvycpMysAI1UJspbq44vpEzSP6Vob9uk3K5dpi37iw==
X-Google-Smtp-Source: ADFU+vuV06yYcNgjNMI8m8mQCBXVxCLjjQSwQoUhsMr/SmP5DnmDESuzaEtb7wD7B7Lg8Yv/ipfg5uYQ8oAZ6SFVDeY=
X-Received: by 2002:a92:6f10:: with SMTP id k16mr19290536ilc.275.1584202930320; Sat, 14 Mar 2020 09:22:10 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Kyle Larose <>
Date: Sat, 14 Mar 2020 12:21:56 -0400
Message-ID: <>
To: Martin Thomson <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Captive-portals] WGLC on draft-ietf-capport-architecture and ...-api
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Mar 2020 16:22:13 -0000


I support publication of capport-api. Thanks for all the hard work!

I have a bunch of minor comments:

Regarding Section 4.1.1:

>   If the certificates do
>   require the use of AIA, the captive network will need to allow client
>   access to the host specified in the URI.

Should this be phrased as "... the captive network MUST allow client
access..." Without this the solution won't work in this situation, so
isn't a strong requirement necessary?

Regarding this section as a whole, we are placing some requirements on
the enforcement device here... Do you think
those should be repeated in the architecture document so those
implementing only enforcement devices can consider them?

Regarding Section 4.2:

>     "bytes-remaining" (optional, integer): indicates the number of
>      bytes remaining, after which the client will be in placed into a
>      captive state.  The byte count represents the total number of IP
>      packet (layer 3) bytes sent and received by the client.  Captive
>      portal systems might not count traffic to whitelisted servers,
>      such as the API server, but clients cannot rely on such behavior.

We say that the "seconds-remaining" field should be omitted if
`captive=false`. We do
not for "bytes-remaining". That feels inconsistent. I think we should
add the following
statement to the end of this field's definition:

Added text:
The API server SHOULD include this value if the client is not captive
(i.e. captive=false)
and SHOULD omit this value for captive clients.

That brings me to another point. What should the API reply with if
there are no time or byte constraints
on the session? Should the fields be omitted in that case? The
document does not discuss that. If we do
decide to add that, do we need discussion about what the client
can/cannot infer from omission of these fields (i.e.
if bytes-remaining is not set, then there is no byte quota for the connection)?

Regarding the byte-count: we say it represents the total number of
tx/rx packets. I think it's obvious that this means
the sum of the total of each, but maybe it'd be better to make that
explicit. New text:

"The byte count represents the sum of the total number of IP packet
(layer 3) bytes sent and received by the client."

On that note, do most captive portal vendors count this way, or is
there often a distinction between tx/rx that we may
want to account for? Or is that complicating things too much, since
this is more a hint than anything else?

Finally, do we need to version the API (i.e. add a version field)? I'm
not sure what the best practice for IETF-defined HTTP APIs is.

Regarding section 6.2:

> Type:  The type of the JSON value to be stored, as one of the value
>    types defined in [RFC8259].

I don't think the types given in section 4.2 (the existing key
registry) exactly follow RFC8259.
In particular, whether or not a field is required/optional is not part
of its type in JSON.
Should we mention what the type field in the registry should include that?


> Type:  The type of the JSON value to be stored, as one of the value
>    types defined in [RFC8259], along with whether it is optional or required.

Or, add a new field:

> Required:  Whether or not the key is required in the document.

I guess it's unlikely that we'd add a new required field since the API
isn't versioned right now, but we should probably be explicit and
about it.


On Thu, 5 Mar 2020 at 01:56, Martin Thomson <> wrote:
> Hi folks,
> Our fine editor teams have contributed updates to these drafts.
> This starts a joint working group last call on these documents. Please respond this mail with your views regarding the suitability of these documents for publication (as Informational RFC and Proposed Standard RFC respectively) before 2020-03-23.
> There are a few minor issues, but I consider those to be minor enough to require only trivial fixes. Some appear to be already addressed. If you think that major changes are needed, or have proposed resolutions to issues, adding those to your email would be helpful.
> Issues are tracked here:
> I encourage people to add issues to the tracker as they review these documents. Directly raising minor editorial issues on GitHub will help us focus attention on substantive issues here.
> Cheers,
> Martin (and Erik)
> _______________________________________________
> Captive-portals mailing list