Re: [Captive-portals] AD review of draft-ietf-capport-architecture-07

Barry Leiba <> Mon, 27 April 2020 14:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD1D13A0B62; Mon, 27 Apr 2020 07:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.219
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ur5Cn2xipiQi; Mon, 27 Apr 2020 07:21:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F6B13A0B5E; Mon, 27 Apr 2020 07:21:18 -0700 (PDT)
Received: by with SMTP id e8so16797801ilm.7; Mon, 27 Apr 2020 07:21:18 -0700 (PDT)
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=TWr72PZnb+kqGFDPNnUd1SgAI94zOMkQa4Has2+TtUA=; b=Xh4e36EFLOeVcSgVwqjqquuYxHBdiWDjJyI3WcOENwWwWx5huZ5A1imRpjFnvWqzLg gjW866rPYliSoDWQVmIziQ1peY7y3irJbloX6yJcnf7u0gkA2x63x/D7i8ARqLgwYsvO anktSoKuY5NqmKxYvVHCTBBj7kRWZCTS4FcZdXJD/mTiRdBySaTxmkvPTCWHnBsHHgyw Rz6Hdr9IOCSYHs9dkd3zb3N7G3y04RvwyQfNJ87WYRXTmFR1K3S4F9LXNkS476dDtnC2 syhB7aEYVMB27zXo1IbjbqlwZl60wCoobY17Z62IW4xsr6a1ETSx0J9GHfdrg029G5q5 a6GQ==
X-Gm-Message-State: AGi0PuZZOq4hh18CQoa/uc82nHp1Be7ra5KcZTHFd2Ss3qzHQwOHJl57 TI5pGMkE9npjZm70UlzUHNON0FpyXeo6q6E5CLo=
X-Google-Smtp-Source: APiQypIu/PKhY35UrvT7LJgc6WYABs9ewM+e96bFFqNdedI/g7jWfPjo4c2EB9UTI+PYkvBtS32xSaqQtxu5/jeL5M8=
X-Received: by 2002:a92:414d:: with SMTP id o74mr21872758ila.266.1587997277176; Mon, 27 Apr 2020 07:21:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Mon, 27 Apr 2020 10:21:06 -0400
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Captive-portals] AD review of draft-ietf-capport-architecture-07
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, 27 Apr 2020 14:21:23 -0000

Thanks for the reply, Dave, and I think we're OK to start last call on
the document after you post a revised I-D with the changes so far --
most unresolved things are not at a blocking level.  Just one thing
I'd like to push on before you revise the I-D, though:

> > Please be consistent about using “URI”, and not “URL”.
> Changed all URI to URL in commit

But that's backward: the IETF formally defines "URI" [RFC3986], not
"URL", and that document says [Section 1.1.3]:

   Future specifications and related documentation should
   use the general term "URI" rather than the more restrictive terms
   "URL" and "URN"

(Additionally, we should probably include an informative reference to
3986 on first use of the term.)

If the working group really wants "URL" here I won't block it further,
but I would strongly prefer that we use "URI", consistent with IETF


Collecting the other points that aren't resolved, but that need not
block 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.
> I've reviewed all upper-case "MAY", and I believe they are used as
> intended.  We've allowed the user equipment to participate or not in various ways.

OK, then no more to do here.  This was mostly just a note that I
expect to see comments, and not an expectation of any changes to the
document.  Thanks for checking.

> > — 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?
> To me, this means that User Equipment can determine from the
> interaction that the API is implementing this architecture vs.
> being some random API. I imagine that a version number or content-
> type could achieve this.
> I've opened
> to track the issue.

OK.  A small wording tweak will be good at some point, but let's see
if anyone else raises this point in reviews.

> > — 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?
> I believe this is about choice of identifier in a solution/standard.
> Opened issue

Great; again, a small wording tweak will do it.

> > — Section 3.4.3 —
> > Is this section talking about using a context-free URI as a UEe
> > 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.
> I think this is trying to say the server should not be looking at
> Ethernet addresses, for example, because the server is probably not
> on the same subnet as the User Equipment. So the info needs to be
> in the URL.
> I hope others can weigh in on this. Created issue

To be clear here, I'm not concerned about the content of the section
as such, only about how it fits into the topic of identifier
selection.  So I think it's just a matter of clarifying that, and it
should be easy to deal with by the time last call ends.