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

Martin Duke <martin.h.duke@gmail.com> Mon, 08 June 2020 15:11 UTC

Return-Path: <martin.h.duke@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 E9D4B3A0C8F; Mon, 8 Jun 2020 08:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 q7z2wQyLim97; Mon, 8 Jun 2020 08:10:56 -0700 (PDT)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 1A7603A0893; Mon, 8 Jun 2020 08:10:56 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id s18so19064934ioe.2; Mon, 08 Jun 2020 08:10:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZRbugDdft6BD9J2at2m0Iqt6ox+6antV44PFc3QaMpc=; b=AxjqmmudjKsacoe/dE+Dw4LtDW8GV9hIaMVnUigZoOOmYdi/tvFJjIRz/Es7265KA6 8u+w370VCdDbV+ISLwNAnvxEloxMEuPx4jUKsF4aof87BSfxUgolsoSyeI45QX65+tO2 sD2c5sbhx6POSxJphBHef83Ps9Bq6p+yZFSSDBU2BP0VwdF69EMzy59hcD81A6/n8K3A BKTxUaqJ68jGaWp7Z+UlR/pJ6ZsZq53i8+AsnWT+YDLUHk1pbGzQIskdb7SRz4BxZxxu jNrbGR19PnzHwVvCD/yHnPkahPvbnu+/vQj6GRReudKEO+dr34i9JcC6NEOurc0pnNsP leUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZRbugDdft6BD9J2at2m0Iqt6ox+6antV44PFc3QaMpc=; b=k4Nf3TVvyCxcSYXGslrCls+bfg4w1eTkWv6YgEmy1aFwBjK7rVcr73JY9o2rUxoc5+ ukcTuffvLNzuTXyVmIHknbT8hUM0Vs1uKWFkEbKbD/+70G6+KouNvSmgcHpOTD1k2rjr 0UMDwFDPU9Hb9SgX5VZ4eE5DtWLcdOKIK2WxLCB4Av0mdIDNej3oBu22v9Ixn3dZ3Dtg R2P/EtvfmB2yZl6j9lPjQ/QCEYyzEIgRgYJ88RlnnYwAglDjrYCzg4bRoqsNYV/nuruj ArctG5EOeYn8XUFvKHltC752pUk84KpMql7QmpUf6ohjH6bZtwjvtZtDlmk62NF9AQeg GYsw==
X-Gm-Message-State: AOAM531wolveo78/eGiZyBqaZ0m4J+4ZCxC1LWpeUI/GyRY7wIgILlBv pwtsKi3zPbLE414EJKs0nxsfwHDbSHr1vOGVLdsp6PaP
X-Google-Smtp-Source: ABdhPJyp/DLhKwwb0h36zGaAh3VFaPhOEiIhaJu/bzA6emy8RERTM11RIKik5DlUpGj3sF8Sb5iSiCrTA4o42LWpzrY=
X-Received: by 2002:a6b:6604:: with SMTP id a4mr22279635ioc.19.1591629055376; Mon, 08 Jun 2020 08:10:55 -0700 (PDT)
MIME-Version: 1.0
References: <159142258883.16243.3241443167484328995@ietfa.amsl.com> <CACuvLgwGn1xgfdV+4KomoDTDe+gRJGkuNa13b9x66Hi=5xN4ng@mail.gmail.com>
In-Reply-To: <CACuvLgwGn1xgfdV+4KomoDTDe+gRJGkuNa13b9x66Hi=5xN4ng@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Mon, 8 Jun 2020 08:10:44 -0700
Message-ID: <CAM4esxRYGno=ZSH9rdS19661Nq2=w5ciHkJ2U8i+ymh-FLDY9Q@mail.gmail.com>
To: Kyle Larose <kyle@agilicus.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-capport-architecture@ietf.org, capport-chairs@ietf.org, captive-portals@ietf.org, Martin Thomson <mt@lowentropy.net>
Content-Type: multipart/alternative; boundary="00000000000075c3b905a7940425"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/KZf9uOkgGAI1OWORNWyx6aA8qhc>
Subject: Re: [Captive-portals] Martin Duke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)
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: Mon, 08 Jun 2020 15:11:52 -0000

Thanks Kyle. I had to move this to a DISCUSS based on the
inconsistent requirements with -api, but it sounds like this is about to be
resolved.

On Mon, Jun 8, 2020 at 5:05 AM Kyle Larose <kyle@agilicus.com> wrote:

> Hi Martin,
>
> Thanks for the review!
>
> Responses inline
>
> On Sat, 6 Jun 2020 at 01:49, Martin Duke via Datatracker
> <noreply@ietf.org> wrote:
> >
> > Martin Duke has entered the following ballot position for
> > draft-ietf-capport-architecture-08: No Objection
> >
>
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > I found the terminology around “Captive Portal API server” and “Captive
> Portal
> > Server” to be a little confusing, as these are similar terms. The latter
> also
> > doesn’t get its own discussion in Section 2 and is confusingly called
> the “web
> > portal server” in Figure 1.
> >
>
>
> The Captive Portal API Server is the server hosting the Captive Portal
> API. The Captive Portal Server is the server hosting the page(s) used
> to communicate with the user visually via some form of client.
>
> I think, given your comments in the API review, and of the other
> working group members who commented there, that we should use Tommy's
> suggestion of "User Portal" in place of Captive Portal Server. That
> should hopefully remove any confusion caused by the similarity between
> the two terms.
>
> > After Figure 1, this seems to be consistently called the “web portal”
> (sec 2.6
> > and 4). It would be great to unify the terminology across the document
> as a
> > whole.
> >
>
> I agree. That's a mistake; the document should be consistent. We'll fix
> that up.
>
> Thanks!
>
> Kyle
>