Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)

Erik Kline <> Mon, 08 June 2020 00:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D2CC3A07D8; Sun, 7 Jun 2020 17:03:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QF4KaUbRQ467; Sun, 7 Jun 2020 17:03:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 38DC33A07D6; Sun, 7 Jun 2020 17:03:28 -0700 (PDT)
Received: by with SMTP id p70so13695022oic.12; Sun, 07 Jun 2020 17:03:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=62ETbVBWC9rlLaQDiU9T3Sjh3RiNwZZT7HrLZ44/B04=; b=XmTuE0WKdh61id97lT4HV8k/ZIcqo17eGnMj/Xn4aonMZzoKK1L0Zsm6Ems3o4ZWqB qIxdFETYrzw4FIbebC80FEaEc/3hR62VDX0CuurZSvlMXB/n9x8fBYnDqUXSv/cjdeX1 68/NWDgqo+//k3GeFXPch8M1X7DwjaqnNeRYYxEeSNNYrr+gMYznc1FN4TBkAx9IEsoS DilajCQL+YW6F9kSX/gRclY2hdzHh+wrNak2cNnmQF6NbVelk9diCWwlUAqqHpfEpyaB BF5vswNdT6FT2ZbBGx19kkiXhqBmkp5fwHM+ukgbFaQS7hQwF3hoYRRj6lGx0JzrTSAz eJZg==
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=62ETbVBWC9rlLaQDiU9T3Sjh3RiNwZZT7HrLZ44/B04=; b=YVXPIAGgHAkucmi0jeF4Ka+HlU0h6NTIy1onQA+9NLn5Ffhc0Enu5PSauixiwouRcC xlXCfi+HFKK2/bUWD+M185EOorHY8qTw4boJoNFKWB6fh4FygSA29UcftWkw7sWoYNdG dBHF3AdypCWg80Q9OCsH9DTprQ8tM1e61W8+QD3f8tCrOesLRY85C6Z8rjrQz+Zf+t/P pAsL8FjT32pOU4GD8odpH9CwNpjxKyUlesq5H4p8Ko2HdXezlgBmCeZ40iX/sUuwqhrq qsCLo5olpTvpsoSFXnIsweK62ytzlqS0jjOzx/t7kiGMEgv1C7Isa9fXVacmWOlXN0yl Q/4w==
X-Gm-Message-State: AOAM532aftaukDoFC5V3QQXTcZqLpdBSN5UI7qR75ce49+R5dmdbYC84 I4EVwOm/+MOCrj88OVKe8Wddoz1etZ/dcAX/PGw=
X-Google-Smtp-Source: ABdhPJz8WQkcKpBwchEizkeKYKlC8jpfKVNvUTOiHzHNwNJoTho+HCFkXLzABPtA9Tdv66y6j5SQKEqSwH9u+YYLC2c=
X-Received: by 2002:aca:da55:: with SMTP id r82mr9246235oig.100.1591574607500; Sun, 07 Jun 2020 17:03:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Erik Kline <>
Date: Sun, 7 Jun 2020 17:03:16 -0700
Message-ID: <>
To: Martin Duke <>
Cc: Tommy Pauly <>, Martin Thomson <>, The IESG <>,, captive-portals <>,,,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Captive-portals] Martin Duke's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)
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: Mon, 08 Jun 2020 00:03:30 -0000

On Sat, Jun 6, 2020 at 7:54 PM Martin Duke <> wrote:
> On Sat, Jun 6, 2020 at 4:52 PM Tommy Pauly <> wrote:
>> I believe in this case the architecture document needs to change, or clarify that this MUST refers to that the mechanism needs to be *able* to communicate such a URI, not that such a URI must always be communicated.
>> The group has discussed this several times, and I believe the API doc reflects the consensus: while we aren’t tackling solutions for captive portals that don’t involve User Portal pages (future solutions using a more OS-driven experience and perhaps built in payment, etc), we want to allow the API JSON to be usable in those new models. Not all captive networks will necessarily use this kind of URI in the future, and there’s no need to make the registry lock that in as mandatory.
> Very well, I’d like to hear from one of the chairs, but if confirmed I’m happy to move my DISCUSS to -architecture.

Tommy is correct.  I think the architecture document should add a
qualifying subclause to clarify that requirement (2) only applies "if
captive portal enforcement may be active on the given network" or

The model supports, for example, the very experiment we ran on the
IETF 106 network [106EXP].  In that experiment we handed out an API
URI via 7710/7710bis mechanisms to an API that told the client it was
/not/ captive but that a venue-info-url was available (which led to a
service that redirected clients to the agenda page, IIRC).