Skip to main content

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

Yes

(Barry Leiba)

No Objection

(Alvaro Retana)
(Deborah Brungard)
(Martin Duke)
(Martin Vigoureux)

Recuse

Erik Kline

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

Murray Kucherawy
No Objection
Comment (2020-05-31 for -07) Sent
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.
Roman Danyliw
No Objection
Comment (2020-06-09 for -07) Sent
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?
Éric Vyncke
No Objection
Comment (2020-06-11 for -07) Sent
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." ?
Erik Kline
Recuse
Warren Kumari
Recuse
Comment (2020-05-25 for -07) Not sent
'norther.
Barry Leiba Former IESG member
Yes
Yes (for -07) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2020-06-30 for -09) Sent for earlier
Thank you for addressing my Discuss (and Comment) points!
Deborah Brungard Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection (2020-06-25 for -09) Sent
Thanks for addressing my issue.
Martin Duke Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2020-06-11 for -07) Sent
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