Re: [Captive-portals] AD review of draft-ietf-capport-api-06

Tommy Pauly <tpauly@apple.com> Mon, 27 April 2020 17:55 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 D21D13A1322; Mon, 27 Apr 2020 10:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=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=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 LA94cAnqZvqq; Mon, 27 Apr 2020 10:55:33 -0700 (PDT)
Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 301383A139D; Mon, 27 Apr 2020 10:55:21 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03RHcEcT042642; Mon, 27 Apr 2020 10:55:19 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=kjbNGfqzIuStyW5XTU58LM3B+iY92SEJ1ka5ulT6A+U=; b=GxnjdjNvcPvCjTHP284eufaPNwzTQCCJZgw4ko5x1pEDPjFJlVKbR3WEdTskTfgcF71h AQASphtziBMnsSPSc6FzSg0JSas4GbHLHL4jhE10QQGfvHnD82QPGxYNDNcSCUG8Sd9Q cZYis4ziBie9mU3yMgA9p2METuJvat+z79n8y3VlUnKF6dCZcTx0m9dBNXdCVMV8cVQr 0X0Vw7ksxWSPKP8edjXiy3DGL6ZZPb0vrae8pLkue1pidZq1929T9hYCWxLCroXvOTkz vPXi3oRyJWbKZLs0UZs8HpYczkwKpFDHT6gc5e1CBPgvAKCb1vdjXGKICzJ6OeaRl/Mb wQ==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp03.apple.com with ESMTP id 30n4wp9bss-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 27 Apr 2020 10:55:19 -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-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9G00IDFKG6SW50@rn-mailsvcp-mta-lapp04.rno.apple.com>; Mon, 27 Apr 2020 10:55:19 -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 <0Q9G00000KFXTM00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 27 Apr 2020 10:55:19 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 5e0758ac758adaea6a44b8b32ea89e72
X-Va-E-CD: 6dced62a1fe819a2200a9a482f7b28d9
X-Va-R-CD: 8688b2514350ccb010b7e7419d158bca
X-Va-CD: 0
X-Va-ID: 4c8f4316-cec7-4505-9fe4-96ababcab844
X-V-A:
X-V-T-CD: 5e0758ac758adaea6a44b8b32ea89e72
X-V-E-CD: 6dced62a1fe819a2200a9a482f7b28d9
X-V-R-CD: 8688b2514350ccb010b7e7419d158bca
X-V-CD: 0
X-V-ID: 54051da7-9936-4afe-b6f8-e64beb8e698b
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-27_12: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 <0Q9G00ZI3KFYWR00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 27 Apr 2020 10:55:14 -0700 (PDT)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <888F926E-60A9-4767-B8DD-76FEF53414AE@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_07F0A485-D7DA-4FC2-AF48-AC01A2F5662B"
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\))
Date: Mon, 27 Apr 2020 10:55:08 -0700
In-reply-to: <CALaySJK_O2veDT8NU4D6gTadm6-cFRhzFHDBrL8t+t25fzydog@mail.gmail.com>
Cc: "draft-ietf-capport-api.all@ietf.org" <draft-ietf-capport-api.all@ietf.org>, "captive-portals@ietf.org" <captive-portals@ietf.org>
To: Barry Leiba <barryleiba@computer.org>
References: <CALaySJK_O2veDT8NU4D6gTadm6-cFRhzFHDBrL8t+t25fzydog@mail.gmail.com>
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_12:2020-04-27, 2020-04-27 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/YFMBMKlanzMnAZWMlMKT9CPmrXQ>
Subject: Re: [Captive-portals] AD review of draft-ietf-capport-api-06
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 17:55:37 -0000

Hi Barry,

Thanks for the review! Update made here:

 https://github.com/capport-wg/api/commit/27cd22fd8a8db696efb9772acd6c05d24a86c81d <https://github.com/capport-wg/api/commit/27cd22fd8a8db696efb9772acd6c05d24a86c81d>

This has been posted as draft-ietf-capport-api-07: https://tools.ietf.org/html/draft-ietf-capport-api-07 <https://tools.ietf.org/html/draft-ietf-capport-api-07>

> On Apr 23, 2020, at 10:03 PM, Barry Leiba <barryleiba@computer.org> wrote:
> 
> Thanks for a nice document.  Here’s my AD review prior to last call.  For a few reasons, I think we need a revised I-D before going to last call.
> 
> — Section 2 —
> 
>    *  Captive Portal API Server: The server exposing the API's defined
> 
> Nit: no apostrophe should be in “APIs” (it’s not possessive).

Fixed
> 
> This section also needs BCP 14 boilerplate (and the document needs normative references to RFCs 2119 and 8174), as Sections 4 and 5 use BCP 14 key words.

Added
> 
> — Section 3 —
> I think 7710bis is an informative reference, not a normative one.

Changed to informative.
> 
> — Section 4.1 —
> 
>    valid certificate for the hostname in the URI (such as
>    "example..com <http://example.com/>").
> 
> It’s a small point, and not wrong as written, but as there is an example already given right above at the end of Section 4, I suggest referring to it:
> 
> NEW
>    valid certificate for the hostname in the URI
>    ("example.org <http://example.org/>", in the example above).
> END

Changed as suggested.
> 
> — Section 5 —
> 
> In the bullet about seconds-remaining:
> 
>       The API server SHOULD include this value if the client is
>       not captive (i.e. captive=false) and the client session is time-
>       limited, and SHOULD omit this value for captive clients (i.e.
>       captive=true).
> 
> What about captive=false and the client is not time-limited?  I think you want, “and SHOULD omit this value value for captive clients (i.e. captive=true) or when the client sessiin is not time-limited.”  Or, simpler and better, “and SHOULD omit this value otherwise.”
> 
> And similarly for the next bullet about bytes-remaining.

Changed for both cases.
> 
> — Section 6 —
> The example violates the SHOULD in Section 5, “seconds-remaining”.  That’s not a good idea.  It might be good to have two examples, one with captive=true and one with captive=false.

Split the server response example into two.

> 
>    Upon receiving this information the client will provide this
>    information to the user so that they may navigate the web portal
> 
> The client isn’t really going to provide the information to the user, is it?  It will provide the information to another application, or will use the information to allow the user to navigate the portal.  Can you rephrase this so it doesn’t sound as if the client will say, “Here’s the portal URI; go wild.” ?

The sentence now reads: "Upon receiving this information the client will use this information direct the user to the the web portal (as specified by the user-portal-url value) to enable access to the external network."

> 
> — Section 8.1 —
> Please double-check the registration template for media types in RFC 6838 and make sure this complies.

Updated for the missing "Fragment identifier considerations” field.
> 
> — Section 8.2 —
> 
>    New assignments for Captive Portal API Keys Registry will be
>    administered by IANA through Expert Review [RFC8126].  The Designated
>    Expert is expected to validate the existence of documentation
>    describing new keys in a permanent publicly available specification.
> 
> How, then, is this not Specification Required?

Good point =) Updated to Specification Required, as that is what the text explains.

Best,
Tommy
> 
> — 
> Barry
> 
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals