Thanks Roman,
Responses inline
On Tue, 9 Jun 2020 at 17:26, Roman Danyliw via Datatracker
wrote:
>
> Roman Danyliw has entered the following ballot position for
> draft-ietf-capport-architecture-08: No Objection
>
>
> --
> COMMENT:
> --
>
> I support Martin and Ben's DISCUSS positions.
>
> Thanks for laying out the architecture to explain the subsequent protocol
> drafts. A few areas of feedback:
>
> ** Section 2.1. Per “At this time we consider …”, to what is “at this time”
> referring (maybe this is referring to the WG scope)? This might not age well
> as currently framed.
>
It is referring to the WG scope, but even that may not age well, I suppose.
How about just "This document only considers devices with ..."
> ** Section 2.2. The architecture doesn’t explicitly describe which component
> is responsibility for provisioning the user equipment sufficiently so it can
> access the IP network anywhere. I would have expected it to be the
> Provisioning Service. Section 2.1, 2.3 and 2.4 describe the role of these
> components in the architecture and their requirements. Section 2.2 does not.
> Instead it describes candidate technologies. It would be helpful to
> explicitly
> say.
>
I didn't want to assume that the provisioning service was required for network
access (in case the network used a technology that allowed stateless access
somehow). But, it can't hurt to mention that in many cases the provisioning
service will be the component that does that. A suggested rephrasing of the
first paragraph of that section.
"The Provisioning Service is primarily responsible for providing a portal URI to
the User Equipment when it connects to the network, and later if the
URI changes.
The provisioning service could also be the same service which is responsible for
provisioning the User Equipment for access to the Captive Network
(e.g. by providing
it with an IP address). This section discusses two mechanisms which may be used
to provide the portal URI to the User Equipment.
It is expected that the provided URI will be for the API described in
Section 2.3".
> ** Section 2.3. Perhaps this is too pedantic, but should the obvious be
> explicitly called out: the user equipment should only be able to check it’s
> own
> captivity status? This would be some explicit notion of authorization.
I recall discussing this, but I don't think we settled on a good,
simple solution. I'm
fine pointing out that the user equipment should only be able to check its own
state of captivity, but I worry that discussing authorization will
open a large can
of worms. Do the chairs have an opinion on this?
> ** Section 2.3 Per “A caller to the API needs to be presented with evidence
> that the content it is receiving is for a version of the API that it
> supports.”, is the caller the User Equipment, the web browser or the end user
> –
> does that distinction matter – does each layer need anything different?
>
I don't think the distinction matters. This is intended to allow
whatever application
is running the captive portal workflow to make a decision based on the
response it
gets back. E.g.. if it's one the uE doesn't support, it could display
a notification to the user
indicating that there appears to be a captive network, but it is unsupported.
> ** Section 3.2.1. Per “Each instance of User Equipment interacting with the
> Captive Network MUST be given an identifier that is unique among User
> Equipment
> interacting at that time.”, is “unique among user equipment interacting at
> that
> time” the same as saying “unique among the identifiers currently in use in the
> Captive Network”? It might be useful to frame this guidance within the scope
> of the previous definitions.
>
That is correct. I'll clarify by using your phrasing.
> ** Section 3.2.2. The acceptable workfactor for “hard” still isn’t clear here
> but I understand the difficulty of pinning it down while remaining flexible.
>
> ** Section 4. Does this section provide normative guidance? The introductory
> sentence suggests no by saying that this section describes “possible
> workflow[s]”. However, Section 4.3 uses a normative SHOULD.
It's meant to be informative. That statement likely belongs elsewhere.
I'll move it
to Section 2.1 (User Equipment)
>
> ** Section 4.2. Between step #2 and #3, did some kind of signaling happen to
> indicate that expiration is imminent, or did the UE keep state of some kind?
> Keeping state isn’t mentioned as a UE requirement in Section 2.1. Section
> 2.5.
> notes that a “signal might be generated when the end of a session is
> imminent”.
>
The implication is that there is state in this case -- the UE stored
the last response
it retrieved from the API so that it could consult the time remaining
(seconds-remaining
in the API document). I can update section 2.1 to indicate that the
