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

Barry Leiba <barryleiba@computer.org> Fri, 24 April 2020 05:03 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1101B3A0B50; Thu, 23 Apr 2020 22:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.218
X-Spam-Status: No, score=-2.218 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8QHbvShrvfJe; Thu, 23 Apr 2020 22:03:40 -0700 (PDT)
Received: from mail-il1-f173.google.com (mail-il1-f173.google.com []) (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 713F03A0B57; Thu, 23 Apr 2020 22:03:35 -0700 (PDT)
Received: by mail-il1-f173.google.com with SMTP id x2so8102853ilp.13; Thu, 23 Apr 2020 22:03:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=grblTfjwqYfKgj1v99YQn4TliFtwJkDtYPAKBlaN6Ic=; b=mMaGJ8LJS0qcu0A7/pqP0pkgLa5dLdTZpv7/4gy5b3vSNfQ5Atf3v3IvhdPA24RwRw Qw6IhLM58q4GQg66riKiM5tSuKvvKFwMupCnRTSfRDSVRnfZucdXBx4sPlB74Pv9HqJ2 XV6K7cxw6oBd0YCNCMRSNcVD6DtvqocnPgkNfFQUgqlSZw7xPJJMeYJr8y2hv9LCNVeJ AQu9jS/K3LPUayEip6xZMKry3w90JqK+y/0gfGIE6AWtc24+xTt67Dp+LipwsjILhsst rSFLvRVjoQQe/l8grJLH7ekAPee59KoN6azvcLxhmafJlAU0pASZTmElMLYb2mp94Nwa 9ymQ==
X-Gm-Message-State: AGi0PuYHY5MaQZ9EzyWUXGhu6d9RaMZRHG1Z6z+GktwD8yIOwCAJeQYM S3Z9wg5iQ4mwT8XTJcM2xq25cJeSKHC2/F4XYjsHshp5
X-Google-Smtp-Source: APiQypKeGE3ncnKhlVuhLT5jxpnY/K79xgRVfgfGaxZZ/rzaT5Z0Y4FZSx7MycfOZrJMWydKms6n4ZgCc5DNkc2CSWc=
X-Received: by 2002:a92:ca81:: with SMTP id t1mr6799487ilo.187.1587704614237; Thu, 23 Apr 2020 22:03:34 -0700 (PDT)
MIME-Version: 1.0
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 24 Apr 2020 01:03:23 -0400
Message-ID: <CALaySJK_O2veDT8NU4D6gTadm6-cFRhzFHDBrL8t+t25fzydog@mail.gmail.com>
To: "draft-ietf-capport-api.all@ietf.org" <draft-ietf-capport-api.all@ietf.org>
Cc: "captive-portals@ietf.org" <captive-portals@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008a3bf205a40249b3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/wckqWG47eRlzc4CkFD55So8EMdg>
Subject: [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: Fri, 24 Apr 2020 05:03:47 -0000

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).

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.

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

— Section 4.1 —

   valid certificate for the hostname in the URI (such as

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

   valid certificate for the hostname in the URI
   ("example.org", in the example above).

— 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.

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.

— 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.

   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.” ?

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

— 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?