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

Tommy Pauly <> Sun, 22 March 2020 23:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FDDA3A05A0 for <>; Sun, 22 Mar 2020 16:42:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.899
X-Spam-Level: **
X-Spam-Status: No, score=2.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, 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 PuKnBbeWajIy for <>; Sun, 22 Mar 2020 16:42:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ECE3B3A040F for <>; Sun, 22 Mar 2020 16:42:00 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 02MNfvZi024768; Sun, 22 Mar 2020 16:41:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=+Z/fmGDuAxF7ohj1w9qfHuIYi2fdpSS7FfeSdDqF54U=; b=vHHMQskdrNnHry4TmvG4okb9H76qA5LdIAA3857CWlDuupEm+DP2ecoJ8sRTYgCUXj23 L0MAK9grh2D+61xzGfZO9m+Tk/bi5NRFQiYAWrH1N4Gnkd+vDGpY7RffJygDay/EvTU1 K/TIf9shjqDWRtYHmQM2gfYfpfBo8w4F0x0hvwHYwYCDopwdDQFz1PunqQDUwkI5Fpvr B/2T0EosNbMS+2v8L1LLpk+OEkUJp59FR4mMsGlA4U4ghfWpMuX0botxHWAIXLu1VEVH PfB2mUOT4oI6GInBjanhcOK9J9tV28podHxXsg6DgVkzMq9SN9KxDzoavFqAIUmuq9WF Kg==
Received: from ( []) by with ESMTP id 2ywhk2sc5u-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 22 Mar 2020 16:41:57 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) with ESMTPS id <>; Sun, 22 Mar 2020 16:41:52 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) id <>; Sun, 22 Mar 2020 16:41:52 -0700 (PDT)
X-Va-T-CD: dcc3cb1b467cc9eade91106ab311b67f
X-Va-E-CD: 5cd3a4adeb0ed1d13d091f805584d6b0
X-Va-R-CD: 98b0ab745a428dbbab73aed79a6d8f09
X-Va-CD: 0
X-Va-ID: 662edfef-d599-4d00-a2fa-e2b9a9a83ee4
X-V-T-CD: dcc3cb1b467cc9eade91106ab311b67f
X-V-E-CD: 5cd3a4adeb0ed1d13d091f805584d6b0
X-V-R-CD: 98b0ab745a428dbbab73aed79a6d8f09
X-V-CD: 0
X-V-ID: 7ee3e768-e12d-48d2-a759-8c797d17edd2
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-22_08:2020-03-21, 2020-03-22 signatures=0
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) with ESMTPSA id <>; Sun, 22 Mar 2020 16:41:52 -0700 (PDT)
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Tommy Pauly <>
In-reply-to: <>
Date: Sun, 22 Mar 2020 16:41:51 -0700
Cc: Martin Thomson <>,
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <> <>
To: Kyle Larose <>
X-Mailer: Apple Mail (2.3608.
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-22_08:2020-03-21, 2020-03-22 signatures=0
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: Sun, 22 Mar 2020 23:42:05 -0000

Hi Kyle,

Thanks for the review! I’ve made some editorial fixes in this commit:

> On Mar 14, 2020, at 9:21 AM, Kyle Larose <> wrote:
> Hello,
> 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?

Agreed, changed the wording as suggested.
> 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.
> "

Added clarification as suggested.

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

I added some clarification that these fields only SHOULD be included when the client session is indeed limited in the fashion described.

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

Fair clarification! Added as suggested.
> 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?

This is a strategy that some portals use at least, based on previous discussion. More complex strategies (which are harder to describe in the API, and harder for the client to be able to estimate) could always be added later.

> 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.

My impression is that we don’t need any version field at the moment. We always could add a new field that would indicate a re-interpretation of fields, etc.

> 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?
> E.g.:
>> 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
> consistent
> about it.

To note, we already did have the following comment:

“All keys other than the ones defined in this document as "required" will be considered optional.”

I think the main issue was that the list was one list with the (requirement, type) tuple being listed together. I rearranged the text into two lists: a list of one entry for the only required field, and a list following of the optional fields. I think this should address your comment.


> Thanks,
> Kyle
> 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
> _______________________________________________
> Captive-portals mailing list