Re: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf-capport-api-07: (with DISCUSS)

[Mark Nottingham]

Just jumping in here, apologies if I don't have all context:

> On 11 Jun 2020, at 11:38 pm, Magnus Westerlund via Datatracker 
>  wrote:
> 
> First of all what is the intention of which HTTP version should be supported
> here? And which protocol are the port 443 you are recommending, TCP, UDP or
> SCTP? This also relates to HTTP/3 as it is getting close to being published, 
> we
> can expect that in the future maybe people would like to upgrade to HTTP/3.

It's generally bad practice for an API to specify a version of HTTP.

> Already now I am wondering if the written allow for HTTP/2 over TLS/TCP? Note,
> that I am mostly commenting from the perspective if you want to be specific
> that it is HTTP/1.1. over TLS/TCP that is the goal. Then this document should
> make certain changes in the formulation. If you want to be unspecific and 
> don't
> think that will hurt interoperability, then another formulation that the
> current is also needed.

I think what's desired is to say that the URL accessed must have a HTTPS scheme 
and a default port, not that communication happen over any specific wire format.

> Likely also a discussion about how a client will figure
> out what versions are supported.

Why would it be different than any other use of HTTP?

Cheers,

--
Mark Nottingham   https://www.mnot.net/

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf-capport-api-07: (with DISCUSS)

[Barry Leiba]

Your suggested rewording works for me, modulo one question:
Might it be better to say, "SHOULD use the default https port", rather
than giving the port number here?  Or perhaps, if you really want to
say "443", make it, "SHOULD use the default https port, 443."

Barry

On Thu, Jun 11, 2020 at 1:12 PM Tommy Pauly
 wrote:
>
>
>
> On Jun 11, 2020, at 6:38 AM, Magnus Westerlund via Datatracker 
>  wrote:
>
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-capport-api-07: Discuss
>
> 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-api/
>
>
>
> --
> DISCUSS:
> --
>
> Section 4.1:
>
>   The API server endpoint MUST be accessed using HTTP over TLS (HTTPS)
>   and SHOULD be served on port 443 [RFC2818].
>
> I have another reason than Roman to discuss this particular sentence.
>
> First of all what is the intention of which HTTP version should be supported
> here? And which protocol are the port 443 you are recommending, TCP, UDP or
> SCTP? This also relates to HTTP/3 as it is getting close to being published, 
> we
> can expect that in the future maybe people would like to upgrade to HTTP/3.
> Already now I am wondering if the written allow for HTTP/2 over TLS/TCP? Note,
> that I am mostly commenting from the perspective if you want to be specific
> that it is HTTP/1.1. over TLS/TCP that is the goal. Then this document should
> make certain changes in the formulation. If you want to be unspecific and 
> don't
> think that will hurt interoperability, then another formulation that the
> current is also needed. Likely also a discussion about how a client will 
> figure
> out what versions are supported.
>
>
> This is an interesting point. In my interpretation, this text does apply to 
> HTTP/1.1 over TLS/TCP,
> HTTP/2 over TLS/TCP, and HTTP/3 over QUIC (which uses TLS for encryption, 
> still uses port 443,
> and still maintains the URI scheme of https://).
>
>
> And maybe one of the ART ADs can help untangle if RFC 2818 really is the right
> normative reference here? Or if it should be RFC 7230 and possibly additional
> references for HTTP/2?
>
>
> Looking at RFCs like the one for DoH, 
> https://www.rfc-editor.org/rfc/rfc8484.html, RFC 2818 is still
> the reference for https:
>
> over HTTP
>[RFC7540] using https [RFC2818] URIs (and therefore TLS [RFC8446]
>security for integrity and confidentiality).
>
> My suggestion is that we can reword the sentence in question here to:
>
>   The API server endpoint MUST be accessed over HTTP using an https URI 
> [RFC2818],
>   and SHOULD be served on port 443.
>
> Does that work for everyone?
>
> Thanks,
> Tommy
>
>
>
>
>
>
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Roman Danyliw's Discuss on draft-ietf-capport-api-07: (with DISCUSS and COMMENT)

[Roman Danyliw]

Hi Tommy!

The proposed edits in the working copy look good and address all of my discuss 
and comments.  Thanks for making the changes.

Regards,
Roman

From: Tommy Pauly 
Sent: Wednesday, June 10, 2020 2:09 PM
To: Roman Danyliw 
Cc: The IESG ; draft-ietf-capport-...@ietf.org; 
capport-cha...@ietf.org; captive-portals@ietf.org; Martin Thomson 

Subject: Re: Roman Danyliw's Discuss on draft-ietf-capport-api-07: (with 
DISCUSS and COMMENT)

Hi Roman,

Thanks for your comments! I’ve updated our working copy with this commit:

https://github.com/capport-wg/api/commit/ef6f9afe84f2e49827560b5e2e8f292966107896

The full editor’s copy can be viewed here:

https://capport-wg.github.io/api/draft-ietf-capport-api.html


On Jun 9, 2020, at 7:51 PM, Roman Danyliw via Datatracker 
mailto:nore...@ietf.org>> wrote:

Roman Danyliw has entered the following ballot position for
draft-ietf-capport-api-07: Discuss

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-api/



--
DISCUSS:
--

“Discuss discuss”.  Section 4 says “The API server endpoint MUST be accessed
using HTTP over TLS (HTTPS) and SHOULD be served on port 443 [RFC2818].”  There
is also various guidance on verifying the API server identity and access to
revocation and time resources.  However, the way I read the definition of the
“Captive Portal API Server” per Section 2 and per Figure 1 of
draft-ietf-capport-architecture, the API server is logically different than the
service at the user-portal-url URL (i.e., Web Portal Server in the
architecture).

Section 7.1 helpfully points out “Information passed between a client and a
Captive Portal system may include a user's personal information, such as a full
name and credit card details.  Therefore, it is important that Captive Portal
API Servers do not allow access to the Captive Portal API over unencrypted
sessions.”  The first sentence is makes sense, but the second, while true,
doesn’t follow the first for me.  PII and credit card information would be the
kind of input you would provide to the _Web Portal Server_ not the Captive
Portal API (of course both are part of the overall Captive Portal system).

This has been updated to:

Information passed between a client and the user-facing web portal may include 
a user's personal information, such as a full name and credit card details. 
Therefore, it is important that both the user-facing web portal and the API 
server that points a client to the web portal are only accessed over encrypted 
connections.



 I
feel there is missing guidance roughly on the order of the user-portal-url
“provides the URL of a web portal _that MUST be accessed over TLS_ with which a
user can interact.” (and the venue-info-url SHOULD use TLS too).

Good point. This was implicit in some of our text, but needed to be stated:

- "user-portal-url" (string): provides the URL of a web portal that MUST be 
accessed over TLS with which a user can interact.
- "venue-info-url" (string): provides the URL of a webpage or site that SHOULD 
be accessed over TLS on which the operator of the network has information that 
it wishes to share with the user (e.g., store info, maps, flight status, or 
entertainment).




Both this draft and draft-ietf-capport-rfc7710bis-07 are fundamentally
providing pointers to other resources.  Would it be out of scope for this
document to place restrictions on what the API is capable of pointing to?  If
not here, then where?


--
COMMENT:
--

Thanks for describing the protocol interaction within the reference
architecture of draft-ietf-capport-architecture.

** Ben points to a few places to tighten up the TLS mechanics (e.g.,
referencing BCP195, non-OCSP stapling revocation) which I won't repeat here.
These are important.

Indeed. Please see responses to Ben’s comments.


** Are there any retry behavior to specify for the client?  Say the client
tries to the visit the API URL and the server returns an HTTP 500 error? Or,
the API server doesn’t respond at all?

I’ve added this text to clarify:

Client behavior for issuing requests for updated JSON content is 
implementation-specific, and can be based on user interaction or the 
indications of seconds and bytes remaining in a given session. If at any point 
the client does not receive valid JSON content from the API server, either due 
to an error or due to receiving no response,

Re: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf-capport-api-07: (with DISCUSS)

[Tommy Pauly]

> On Jun 11, 2020, at 6:38 AM, Magnus Westerlund via Datatracker 
>  wrote:
> 
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-capport-api-07: Discuss
> 
> 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-api/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Section 4.1:
> 
>   The API server endpoint MUST be accessed using HTTP over TLS (HTTPS)
>   and SHOULD be served on port 443 [RFC2818].
> 
> I have another reason than Roman to discuss this particular sentence.
> 
> First of all what is the intention of which HTTP version should be supported
> here? And which protocol are the port 443 you are recommending, TCP, UDP or
> SCTP? This also relates to HTTP/3 as it is getting close to being published, 
> we
> can expect that in the future maybe people would like to upgrade to HTTP/3.
> Already now I am wondering if the written allow for HTTP/2 over TLS/TCP? Note,
> that I am mostly commenting from the perspective if you want to be specific
> that it is HTTP/1.1. over TLS/TCP that is the goal. Then this document should
> make certain changes in the formulation. If you want to be unspecific and 
> don't
> think that will hurt interoperability, then another formulation that the
> current is also needed. Likely also a discussion about how a client will 
> figure
> out what versions are supported.

This is an interesting point. In my interpretation, this text does apply to 
HTTP/1.1 over TLS/TCP,
HTTP/2 over TLS/TCP, and HTTP/3 over QUIC (which uses TLS for encryption, still 
uses port 443,
and still maintains the URI scheme of https://).

> 
> And maybe one of the ART ADs can help untangle if RFC 2818 really is the right
> normative reference here? Or if it should be RFC 7230 and possibly additional
> references for HTTP/2?

Looking at RFCs like the one for DoH, 
https://www.rfc-editor.org/rfc/rfc8484.html 
, RFC 2818 is still
the reference for https:

over HTTP
   [RFC7540] using https [RFC2818] URIs (and therefore TLS [RFC8446]
   security for integrity and confidentiality).

My suggestion is that we can reword the sentence in question here to:

  The API server endpoint MUST be accessed over HTTP using an https URI 
[RFC2818],
  and SHOULD be served on port 443.

Does that work for everyone?

Thanks,
Tommy

> 
> 
> 
> 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Robert Wilton's No Objection on draft-ietf-capport-api-07: (with COMMENT)

[Tommy Pauly]

Hi Rob,

Thanks for the review!

Responses inline. You can also see updates in our working copy here:

https://capport-wg.github.io/api/draft-ietf-capport-api.html

> On Jun 11, 2020, at 4:17 AM, Robert Wilton via Datatracker  
> wrote:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-capport-api-07: 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-api/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Hi,
> 
> I found this document straight forward and easy to read.
> 
> Linda's comment in the Opsdir review is interesting.  I would have expected 
> the
> CAPPORT architecture document to discuss/reference the problem being solved,
> but it seems to be mostly silent on this.  I will redirect Linda's comment to
> the CAPPORT architecture.
> 
> In section 5. "API State Structure", it does not state whether a connection
> could be both time and data limited.  My reading of the spec is that this 
> would
> be allowed, assuming that is the case, the current text is fine.

Correct, there is no requirement that time and data limits are mutually 
exclusive.
> 
> 6.  Example Interaction
> 
>   Upon receiving this information the client will use this information
>   direct the user to the the web portal (as specified by the user-
>   portal-url value) to enable access to the external network.  Once the
>   user satisfies the requirements for extenal network access, the
>   client SHOULD query the API server again to verify that it is no
>   longer captive.
> 
> Nit: information direct => information to direct

Fixed on latest working copy.
> 
> 7.  Security Considerations
> 
> I'm slightly concerned about the third paragraph in the security
> considerations.  Ideally I would like a solution that doesn't require humans 
> to
> potentially spot potentially dubious spoofed domain names.  But I can
> appreciate that is probably out of scope here.

This has been removed and reworded in our working copy, from addressing Ben’s 
comments.
> 
> 7.1.  Privacy Considerations
> 
> Possibly worth adding a comment about the necessity to keep personal
> information secure.   In addition, should there be any comments about GDPR 
> like
> constraints (if they apply)?

This section has also be reworded slightly to make this more clear. I’m not 
sure if there’s anything we can state for GDPR or similar constraints here. I 
think that would mainly apply to what is shown in the user portal, not the API 
interaction.

Best,
Tommy
> 
> Thanks,
> Rob
> 
> 
> 

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-capport-rfc7710bis-07: 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-rfc7710bis/



--
COMMENT:
--

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." ?



___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

[Captive-portals] Magnus Westerlund's Discuss on draft-ietf-capport-rfc7710bis-07: (with DISCUSS)

[Magnus Westerlund via Datatracker]

Magnus Westerlund has entered the following ballot position for
draft-ietf-capport-rfc7710bis-07: Discuss

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-rfc7710bis/



--
DISCUSS:
--

IANA Section:

As this document is obsoleting RFC 7710 is the document that registered the
options for DHCPv6 and RA. Why isn't this document updating the registrations
to ensure that IANA has the current document as being owner of the codepoints?

In addition when it comes to BOOTP options code 160. What you have in this
document appear to potentially lead to another future assignment end up in
trouble? Wouldn't reserved be better status for this codepoint?





___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

[Captive-portals] Iotdir telechat review of draft-ietf-capport-rfc7710bis-07

[Suresh Krishnan via Datatracker]

Reviewer: Suresh Krishnan
Review result: Ready

Overall I found the draft to be well written and easy to read but I one minor
comment.

* It is not clear how a constrained device (potentially without a user
interface) would handle the URI that it receives to escape the captive portal.
Has this been thought of? I think some new text in this regard would be useful
here, though one could make the case for this to be handled in the API draft
instead.


___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

[Captive-portals] Magnus Westerlund's Discuss on draft-ietf-capport-api-07: (with DISCUSS)

[Magnus Westerlund via Datatracker]

Magnus Westerlund has entered the following ballot position for
draft-ietf-capport-api-07: Discuss

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-api/



--
DISCUSS:
--

Section 4.1:

   The API server endpoint MUST be accessed using HTTP over TLS (HTTPS)
   and SHOULD be served on port 443 [RFC2818].

I have another reason than Roman to discuss this particular sentence.

First of all what is the intention of which HTTP version should be supported
here? And which protocol are the port 443 you are recommending, TCP, UDP or
SCTP? This also relates to HTTP/3 as it is getting close to being published, we
can expect that in the future maybe people would like to upgrade to HTTP/3.
Already now I am wondering if the written allow for HTTP/2 over TLS/TCP? Note,
that I am mostly commenting from the perspective if you want to be specific
that it is HTTP/1.1. over TLS/TCP that is the goal. Then this document should
make certain changes in the formulation. If you want to be unspecific and don't
think that will hurt interoperability, then another formulation that the
current is also needed. Likely also a discussion about how a client will figure
out what versions are supported.

And maybe one of the ART ADs can help untangle if RFC 2818 really is the right
normative reference here? Or if it should be RFC 7230 and possibly additional
references for HTTP/2?





___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Benjamin Kaduk's Discuss on draft-ietf-capport-architecture-08: (with DISCUSS and COMMENT)

[Kyle Larose]

Hi Benjamin,

Thanks for the thorough review!

Responses inline

On Tue, 9 Jun 2020 at 01:30, Benjamin Kaduk via Datatracker
 wrote:
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-capport-architecture-08: Discuss
>
> --
> DISCUSS:
> --
>
> (1) and (2) should be easy to fix; (3) may well be "fixed" by telling me
> I'm too naive :)
>
> (1) Given that section 1 describes other options, the abstract should not
> limit to just DHCP and RA as options for provisioning the API URL.
>

Should be simple enough to open up the wording. E.g.

"Network provisioning protocols such as DHCP or Router Advertisements,
an optional signaling protocol..."


> (2) Section 4.1 says that:
>
>5.  The Captive Portal API server indicates to the Enforcement Device
>that the User Equipment is allowed to access the external
>network.
>
> but I believe this should be the "Captive Portal Server" (or, as the
> previous point has it, the "web portal").
>

You're right. We'll change it up.

> (3) Probably a "discuss discuss", but ... in Section 1 we have:
>
>*  Solutions SHOULD NOT require the forging of responses from DNS or
>   HTTP servers, or any other protocol.  In particular, solutions
>   SHOULD NOT require man-in-the-middle proxy of TLS traffic.
>
> I'd like to understand the motivation for this one a little better.
> Naively, it seems like we could get away with "MUST NOT require" while
> still allowing it to be done.  Am I missing something obvious?
>
>

I'll continue the discussion here by replying to Michael's reply.

> --
> COMMENT:
> --
>
> I'd like to see some more discussion of which signals are authenticated
> and how, and what kind of authorization checks are possible.  In
> well-run networks DHCP and RA signals should be relatively trustworthy,
> but clients don't always have a good indicator for whether a given
> network falls into that category.  Are there (other) mechanisms that can
> be used to give trust in the authenticity of a given Captive Portal API
> URI and that that API is authorthorized to provide unconstrained access
> for the network in question?  We require TLS for accessing the API
> server, but (as I note inline) there are more details that can be given
> about this TLS usage.  What can be done to authenticate and authorize
> the Captive Portal Server?  Most importantly (and most appropriately for
> an architecture document), which of these properties are strictly
> required vs. merely optional?  These are not Discuss-level points
> because an architecture does not strictly-speaking need to specify all
> of them, but having some indication of how we plan to achieve them would
> give greater confidence that this architecture will be a useful one.
>
> I'm happy to see the response to the genart reviewer's comment regarding
> "a" vs. "the" capport architecture; thanks!
>
> Abstract
>
>This document describes a CAPPORT architecture.  DHCP or Router
>Advertisements, an optional signaling protocol, and an HTTP API are
>used to provide the solution.  The role of Provisioning Domains
>
> nit: there's perhaps a bit of a lack of parallelism in the list
> structure, where we talk about specific mechanisms for provisioning
> without describing the more abstract concept of provisioning, and list
> that alongside an abstract mention of "a signaling protocol" and the
> both-abstract-and-concrete "HTTP API".

I  think my proposal in response to your Discuss for this section
addresses this. Does it?

>
> Section 1
>
>Implementations generally require a web server, some method to allow/
>block traffic, and some method to alert the user.  Common methods of
>
> nit: I'd suggest clarifying that this is "implementations of captive
> portals" (or is it "captive networks"?).

Will do


>
>alerting the user involve modifying HTTP or DNS traffic.
>
> nit: perhaps "at present" or "prior to this work"?  If I understand
> correctly one of the goals of this work is to shift the balance of
> captive portals away from these practices (while acknowledging that
> fully eliminating them is not feasible in the near future).
>

Fair point. I'd hope that readers of this statement 10 years from now would
be confused unless we change it!


>*  Solutions MAY allow a device to be alerted that it is in a captive
>   network when attempting to use any application on the network.
>
> I'm also not sure I understand this one, especially in light of the
> following (paraphrased) "SHOULD allow learning of captivity before
> application attempts to use the network".  What's the alternative to
> "MAY allow", not-allowing such detection at all?

In short, the SHOULD case is covered by using netwo

[Captive-portals] Robert Wilton's No Objection on draft-ietf-capport-rfc7710bis-07: (with COMMENT)

[Robert Wilton via Datatracker]

Robert Wilton has entered the following ballot position for
draft-ietf-capport-rfc7710bis-07: 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-rfc7710bis/



--
COMMENT:
--

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



___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] Robert Wilton's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)

[Rob Wilton (rwilton)]

Hi,

Linda Dunbar raised the following comment during the OPSDIR review of the 
capport-api draft:

What improvement does the proposed API have over today's existing communication 
between clients and  Captive Server(s)? Captive servers have been deployed 
everywhere, like airport or restaurants trying to access free WIFI. What 
problems does the existing method have to justify this newly proposed APIs?

The CAPPORT architecture document seems to be decidedly silent on why it exists 
and what problem is being solved.  It seems that there was an ID covering some 
of the this (https://tools.ietf.org/html/draft-nottingham-capport-problem-01), 
but it doesn't look like that document progressed.  It feels like it would have 
been beneficial if some of the information in that problem statement draft was 
captured or referenced from this architecture document in some way (e.g. in a 
Problem Description section, or in an appendix).

Regards,
Rob


> -Original Message-
> From: iesg  On Behalf Of Robert Wilton via
> Datatracker
> Sent: 11 June 2020 10:57
> To: The IESG 
> Cc: captive-portals@ietf.org; capport-cha...@ietf.org; draft-ietf-capport-
> architect...@ietf.org; m...@lowentropy.net
> Subject: Robert Wilton's No Objection on draft-ietf-capport-architecture-
> 08: (with COMMENT)
> 
> Robert Wilton 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:
> --
> 
> I found this document easy to read, but have a few comments.
> 
> I support the 3rd bullet of Ben's discuss.
> 
> I was surprised by the diagram in section 2.6, since it seems to imply
> that the
> Provisioning Service kicks everything off, but I would have expected the
> User
> equipment to initiate the flow, which is articulated in the first step of
> section 4.1.  Hence, I think that the diagram could be more clear if it
> also
> showed the initial request from the client (as per the first step in 4.1).
> 
> Finally, I note that this document makes no mention of OAM considerations.
> Having some text covering these aspects would probably be beneficial.
> 
> 

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

[Captive-portals] Robert Wilton's No Objection on draft-ietf-capport-api-07: (with COMMENT)

[Robert Wilton via Datatracker]

Robert Wilton has entered the following ballot position for
draft-ietf-capport-api-07: 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-api/



--
COMMENT:
--

Hi,

I found this document straight forward and easy to read.

Linda's comment in the Opsdir review is interesting.  I would have expected the
CAPPORT architecture document to discuss/reference the problem being solved,
but it seems to be mostly silent on this.  I will redirect Linda's comment to
the CAPPORT architecture.

In section 5. "API State Structure", it does not state whether a connection
could be both time and data limited.  My reading of the spec is that this would
be allowed, assuming that is the case, the current text is fine.

6.  Example Interaction

   Upon receiving this information the client will use this information
   direct the user to the the web portal (as specified by the user-
   portal-url value) to enable access to the external network.  Once the
   user satisfies the requirements for extenal network access, the
   client SHOULD query the API server again to verify that it is no
   longer captive.

Nit: information direct => information to direct

7.  Security Considerations

I'm slightly concerned about the third paragraph in the security
considerations.  Ideally I would like a solution that doesn't require humans to
potentially spot potentially dubious spoofed domain names.  But I can
appreciate that is probably out of scope here.

7.1.  Privacy Considerations

Possibly worth adding a comment about the necessity to keep personal
information secure.   In addition, should there be any comments about GDPR like
constraints (if they apply)?

Thanks,
Rob



___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

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

[Robert Wilton via Datatracker]

Robert Wilton 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:
--

I found this document easy to read, but have a few comments.

I support the 3rd bullet of Ben's discuss.

I was surprised by the diagram in section 2.6, since it seems to imply that the
Provisioning Service kicks everything off, but I would have expected the User
equipment to initiate the flow, which is articulated in the first step of
section 4.1.  Hence, I think that the diagram could be more clear if it also
showed the initial request from the client (as per the first step in 4.1).

Finally, I note that this document makes no mention of OAM considerations. 
Having some text covering these aspects would probably be beneficial.



___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals