[Captive-portals] Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-capport-architecture-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. The document is easy to read. I
also appreciate the fact that "devices without user interfaces" are not ignored
by this document.

Please find below a couple on non-blocking COMMENTs. A response/comment for
those COMMENT will be read with interest.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Is there a reason why the words "captive portal" do not appear in the abstract?
This would assist normal human beings (outside of the WG) to find the document.

I found no text about what happens to the traffic inside the captive network.
Is it allowed even when still in captive mode ?

-- Section 1.2 --
Even if the document support "devices without user interfaces", I wonder why
the I-D uses "User Equipment" rather than "Client Equipment" (which is also
more aligned with "Server"). Nothing dramatic, just curious about the reason.

-- Section 2.1 --
"At this time we consider only devices with web browsers" while the previous
text was about "devices without user interfaces". Finally, is this document for
devices with or without human interface ?

-- Section 2.6 --
While the components are described as being optional collocated, what about
resiliency ? I.e., having two different instances on one component.

-- Section 3.4.2 ---
While I appreciate that the section contains text about multiple IPv6
addresses, I suggest to mention the dual-stack use case explicitly.

-- Section  3.4 --
I was expecting to see the MAC address also used as identifier. Is there any
reason why it is not mentioned? If so, may I suggest to document the absence of
a MAC address section in the examples?