Captive-Portal Identification in DHCP and Router Advertisements (RAs)
draft-ietf-capport-rfc7710bis-11

Note: This ballot was opened for revision 07 and is now closed.

Barry Leiba Yes

Deborah Brungard No Objection

Roman Danyliw No Objection

Comment (2020-06-09 for -07)
Thanks for this updated document.

** I support Ben's Discuss position

** (Editorially) Is there a reason that this draft doesn’t reference draft-ietf-capport-architecture-08 and use the notional architecture and terminology it defines?  It would be clearer if it did.

** Section 2.2 and 2.3.  Per “The maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer than 255 bytes should not be provisioned via IPv6 DHCP options.”
-- should this be a normative SHOULD?

-- recommend stating when this length can be ignored (e.g., IPv6 only environment)

** Section 5.  Per “In the absence of security measures like RA Guard ([RFC6105], [RFC7113]) or DHCP Shield [RFC7610] …”, are these recommended for operators to use in the Captive Portal System?

Martin Duke No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-06-30 for -09)
No email
send info
Thank you for addressing my Discuss (and Comment) points!

Murray Kucherawy No Objection

Comment (2020-05-31 for -07)
Nice work.  A couple of minor things:

In Section 2, paragraph 2, it says the operator "SHOULD ensure that the URIs provisioned by each method are equivalent".  Does "equivalent" here mean "identical", or just "synonymous"?

In Sections 2.1 and 2.2, the lists are bulleted and the names being described are delimited by colons.  I suggest the same be done for 2.3.

> Thanks IANA!

RFC8126 should've required this of all documents.

Alvaro Retana No Objection

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2020-06-11 for -07)
Thank you for the work put into this document. The document is easy to read. I really like the signaling of 'no captive portal'.

Please find below one non-blocking COMMENT (but you know the story) and 2 nits.

Please also address all Suresh's comments in his IoT review:
https://datatracker.ietf.org/doc/review-ietf-capport-rfc7710bis-07-iotdir-telechat-krishnan-2020-06-11/

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 2.2 ==
In "should not be provisioned", I would suggest to use the normative "SHOULD".
  
== NITS ==

-- Abstract --
Not all users of a captive portal are 'customers', they can be guests, students, employees, ... suggest to use 'users' (and even in the world of IoT).

-- Section 2 --
Authors, being English natives, are probably correct but " should not be provisioned via IPv6 DHCP nor IPv6 RA options." looks weird to m; why not " should be provisioned via neither IPv6 DHCP nor IPv6 RA
 options." ?

Magnus Westerlund (was Discuss) No Objection

Comment (2020-06-25 for -09)
Thanks for addressing my issue.

Robert Wilton No Objection

Comment (2020-06-11 for -07)
Just one minor nit:

I would have preferred if the packet diagram for "IPv4 DHCP Option" looked a lot more like the one in section 2.3 for "IPv6 RA", but perhaps there is a reason why the v4 DHCP represents the URL as two separate fields.

Regards,
Rob

Erik Kline Recuse

Warren Kumari Recuse

Comment (2020-05-25 for -07)
No email
send info
'norther.