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

[Kyle Larose <[e-mail]>]

Hi Rob,

Response inline.

On Thu, 11 Jun 2020 at 07:24, Rob Wilton (rwilton) <[e-mail]> wrote:
>
> 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).
>

We referenced that document in earlier versions of the draft. However,
since it didn't seem like it would be published any time soon, we
removed our reference to it. In doing so, we also decided not to
include any of its text to reduce document churn.

Martin, given that we're likely to make a non-trivial number of
changes to the document based on the recent review feedback, do you
think it's worth adding a few points discussing the problems faced by
existing captive portal implementations?

> Regards,
> Rob
>
>
> > -----Original Message-----
> > From: iesg <[e-mail]> On Behalf Of Robert Wilton via
> > Datatracker
> > Sent: 11 June 2020 10:57
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail]; draft-ietf-capport-
> > [e-mail]; [e-mail]
> > 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.
> >
> >

Thanks,

Kyle