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

Tommy Pauly <tpauly@apple.com> Mon, 27 April 2020 23:22 UTC

Return-Path: <tpauly@apple.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 79BEF3A0DB2; Mon, 27 Apr 2020 16:22:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, 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=apple.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 vcRqRDE18y2E; Mon, 27 Apr 2020 16:22:08 -0700 (PDT)
Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14603A0DB1; Mon, 27 Apr 2020 16:22:07 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03RNLp0W038983; Mon, 27 Apr 2020 16:21:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=/VblsKDANfMw0MOQZ1qoMkYhPbxDYVId8kdpImJBDTM=; b=EXygR5HAl8a0ML+6QBoEvFsVXKMGuC8Fd62+40Hb/AlseQT2SZjuzEU/CyLXm5kSNHdi kQ6ls/2IrCFwUWq+Dqi58WbzXhpyy96n4xkrStZsrIMpvGlFNa0Krb3pnT38fme55Sqk xBcj9AmU9nvK3lwG9So+iEEjrcmNjMQ2bwFjOENhUroZEvbGurfiFroSYUPkXzg/jhiz 05DPD8Q1foCKwVpp+8RA9Lo8qfKeLTK92Y8GiwdTc0TgCOEE+DMs2kJkfW3xuvTsonXt aCr+cYCeuy9ClXD1l0qlh6RtfTTjZkiXB8rs7Gz8jb32uaXsNCgH61NFG2YHzyu2jHy0 vQ==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by nwk-aaemail-lapp02.apple.com with ESMTP id 30mhsgemtt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 27 Apr 2020 16:21:55 -0700
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9G00P5OZKJ5B60@rn-mailsvcp-mta-lapp01.rno.apple.com>; Mon, 27 Apr 2020 16:21:55 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q9G00900ZK55A00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 27 Apr 2020 16:21:55 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 5e0758ac758adaea6a44b8b32ea89e72
X-Va-E-CD: 4c3496c87ab7b1ff7b17389eb8ae0721
X-Va-R-CD: 520a34d4b8cb9c878c00047fb6d0b65f
X-Va-CD: 0
X-Va-ID: 90cd3d11-114c-4897-bb6a-eaadf1547a6f
X-V-A:
X-V-T-CD: 5e0758ac758adaea6a44b8b32ea89e72
X-V-E-CD: 4c3496c87ab7b1ff7b17389eb8ae0721
X-V-R-CD: 520a34d4b8cb9c878c00047fb6d0b65f
X-V-CD: 0
X-V-ID: 41d2f84b-6543-4419-9986-9fe4bdea804a
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-27_17:2020-04-27, 2020-04-27 signatures=0
Received: from [17.234.106.193] (unknown [17.234.106.193]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9G00W7DZKH9C00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 27 Apr 2020 16:21:54 -0700 (PDT)
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <CALaySJLxqtqGAytEK3X083zg3hyXSOQ6FdnaTz5t1tDNS8tKeA@mail.gmail.com>
Date: Mon, 27 Apr 2020 16:21:52 -0700
Cc: ddolson@acm.org, captive-portals@ietf.org, draft-ietf-capport-architecture.all@ietf.org
Content-transfer-encoding: quoted-printable
Message-id: <A274EB94-3A76-4EBB-BCF3-E472C9ABBBE2@apple.com>
References: <CALaySJ+K1FZu5POa=TLz2-ON8=jvyE03gqdi+5+cNj8X4E9RoA@mail.gmail.com> <a4a3747ef330d8b2ac94a178ab691ca8@golden.net> <CALaySJLxqtqGAytEK3X083zg3hyXSOQ6FdnaTz5t1tDNS8tKeA@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.3608.80.7.2.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-27_17:2020-04-27, 2020-04-27 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/p9FcKlYVrIAXTkRPMoebFf6Qj1I>
Subject: Re: [Captive-portals] AD review of draft-ietf-capport-architecture-07
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, 27 Apr 2020 23:22:10 -0000


> On Apr 27, 2020, at 7:21 AM, Barry Leiba <barryleiba@computer.org> wrote:
> 
> 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
>> https://github.com/capport-wg/architecture/commit/a9c87ba48aa64564bd9d0e1f21bd82906a2714f4
> 
> 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
> usage.

FWIW, the API document uses “URI” everywhere other than in its JSON keys. I’d agree that the architecture document should use URI as well.

Thanks,
Tommy
> 
> ---
> 
> 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 https://github.com/capport-wg/architecture/issues/61
>> 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 https://github.com/capport-wg/architecture/issues/62
> 
> 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
>> https://github.com/capport-wg/architecture/issues/63
> 
> 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.
> 
> Barry
> 
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals