Skip to main content

Telechat Review of draft-ietf-capport-rfc7710bis-07

Request Review of draft-ietf-capport-rfc7710bis
Requested revision No specific revision (document currently at 11)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2020-06-09
Requested 2020-05-27
Requested by Éric Vyncke
Authors Warren "Ace" Kumari , Erik Kline
I-D last updated 2020-06-06
Completed reviews Secdir Last Call review of -04 by Rifaat Shekh-Yusef (diff)
Genart Last Call review of -04 by Stewart Bryant (diff)
Opsdir Last Call review of -04 by Tim Chown (diff)
Iotdir Telechat review of -07 by Suresh Krishnan (diff)
Intdir Telechat review of -07 by Ralf Weber (diff)
Especially around the IPv6 DHCP/RA and IPv4 DHCP.
Thank you
Assignment Reviewer Ralf Weber
State Completed
Request Telechat review on draft-ietf-capport-rfc7710bis by Internet Area Directorate Assigned
Posted at
Reviewed revision 07 (document currently at 11)
Result Ready w/nits
Completed 2020-06-06

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

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

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