[Iot-directorate] Iotdir telechat review of draft-ietf-capport-rfc7710bis-07

Suresh Krishnan via Datatracker <noreply@ietf.org> Thu, 11 June 2020 13:45 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: iot-directorate@ietf.org
Delivered-To: iot-directorate@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E62B3A07C3; Thu, 11 Jun 2020 06:45:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Suresh Krishnan via Datatracker <noreply@ietf.org>
To: <iot-directorate@ietf.org>
Cc: captive-portals@ietf.org, last-call@ietf.org, draft-ietf-capport-rfc7710bis.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159188310238.1556.5262096580787222054@ietfa.amsl.com>
Reply-To: Suresh Krishnan <suresh@kaloom.com>
Date: Thu, 11 Jun 2020 06:45:02 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/6-_LrXi_gaRCh_TKd1ifYh97_2Q>
Subject: [Iot-directorate] Iotdir telechat review of draft-ietf-capport-rfc7710bis-07
X-BeenThere: iot-directorate@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Mailing list for the IoT Directorate Members <iot-directorate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-directorate/>
List-Post: <mailto:iot-directorate@ietf.org>
List-Help: <mailto:iot-directorate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2020 13:45:03 -0000

Reviewer: Suresh Krishnan
Review result: Ready

Overall I found the draft to be well written and easy to read but I one minor

* It is not clear how a constrained device (potentially without a user
interface) would handle the URI that it receives to escape the captive portal.
Has this been thought of? I think some new text in this regard would be useful
here, though one could make the case for this to be handled in the API draft