[Int-dir] Intdir telechat review of draft-ietf-capport-rfc7710bis-07
Ralf Weber via Datatracker <noreply@ietf.org> Sat, 06 June 2020 12:11 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: int-dir@ietf.org
Delivered-To: int-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6453F3A0860; Sat, 6 Jun 2020 05:11:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ralf Weber via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
Cc: last-call@ietf.org, draft-ietf-capport-rfc7710bis.all@ietf.org, captive-portals@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159144551834.13294.561095521927993926@ietfa.amsl.com>
Reply-To: Ralf Weber <rweber@akamai.com>
Date: Sat, 06 Jun 2020 05:11:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/ZuunfKIN1j1L9YyfmGiiHV8U_3o>
Subject: [Int-dir] Intdir telechat review of draft-ietf-capport-rfc7710bis-07
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jun 2020 12:11:59 -0000
Reviewer: Ralf Weber Review result: Ready with Nits Moin! I am an assigned INT directorate reviewer for draft-ietf-capport-rfc7710bis. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ This draft defines an update to RFC7710 on the different methods a network can use to signal an existence of a captive portal. The draft is well written and actually addressed one nit I had with RFC7710 when reading it for the first time for the review of the bis document. There are two things that I would consider doing differently, but they don't affect the overall draft. In section two of the draft you have: In all variants of this option, the URI MUST be that of the captive portal API endpoint, conforming to the recommendations for such URIs [draft-ietf-capport-api]. Now I read the latest draft-ietf-capport-api on datatracker and there were no formal or recommendations at all for URI schemes. There were examples, but I guess if you are implementing this and you are told that there are guidelines they should be clearly spelled out. Protocol wise it is important that they implement the API endpoint correct and the URI really doesn't matter to much, so I would end the sentence at the comma. In section 3 Precedence of API URI the first paragraph tells me as am implementer that I'm free to implement whatever to use of the three methods described in the draft, however the second paragraph tells me that I should log an error if they are different. That makes no sense for a lazy coder like me as I would not look into other methods if one has succeeded. I think it is ok to give that freedom implied by the first paragraph to implementors here, but to really give them freed we should scrap the second paragraph. If the authors feel they need to describe the client logic in more detail this has to be extended way beyond a single paragraph. So long -Ralf
- [Int-dir] Intdir telechat review of draft-ietf-ca… Ralf Weber via Datatracker