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

2020-06-08 Thread Martin Duke
Thanks Kyle. I had to move this to a DISCUSS based on the
inconsistent requirements with -api, but it sounds like this is about to be
resolved.

On Mon, Jun 8, 2020 at 5:05 AM Kyle Larose  wrote:

> Hi Martin,
>
> Thanks for the review!
>
> Responses inline
>
> On Sat, 6 Jun 2020 at 01:49, Martin Duke via Datatracker
>  wrote:
> >
> > Martin Duke has entered the following ballot position for
> > draft-ietf-capport-architecture-08: No Objection
> >
>
> >
> > --
> > COMMENT:
> > --
> >
> > I found the terminology around “Captive Portal API server” and “Captive
> Portal
> > Server” to be a little confusing, as these are similar terms. The latter
> also
> > doesn’t get its own discussion in Section 2 and is confusingly called
> the “web
> > portal server” in Figure 1.
> >
>
>
> The Captive Portal API Server is the server hosting the Captive Portal
> API. The Captive Portal Server is the server hosting the page(s) used
> to communicate with the user visually via some form of client.
>
> I think, given your comments in the API review, and of the other
> working group members who commented there, that we should use Tommy's
> suggestion of "User Portal" in place of Captive Portal Server. That
> should hopefully remove any confusion caused by the similarity between
> the two terms.
>
> > After Figure 1, this seems to be consistently called the “web portal”
> (sec 2.6
> > and 4). It would be great to unify the terminology across the document
> as a
> > whole.
> >
>
> I agree. That's a mistake; the document should be consistent. We'll fix
> that up.
>
> Thanks!
>
> Kyle
>
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals


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

2020-06-08 Thread Kyle Larose
Hi Martin,

Thanks for the review!

Responses inline

On Sat, 6 Jun 2020 at 01:49, Martin Duke via Datatracker
 wrote:
>
> Martin Duke has entered the following ballot position for
> draft-ietf-capport-architecture-08: No Objection
>

>
> --
> COMMENT:
> --
>
> I found the terminology around “Captive Portal API server” and “Captive Portal
> Server” to be a little confusing, as these are similar terms. The latter also
> doesn’t get its own discussion in Section 2 and is confusingly called the “web
> portal server” in Figure 1.
>


The Captive Portal API Server is the server hosting the Captive Portal
API. The Captive Portal Server is the server hosting the page(s) used
to communicate with the user visually via some form of client.

I think, given your comments in the API review, and of the other
working group members who commented there, that we should use Tommy's
suggestion of "User Portal" in place of Captive Portal Server. That
should hopefully remove any confusion caused by the similarity between
the two terms.

> After Figure 1, this seems to be consistently called the “web portal” (sec 2.6
> and 4). It would be great to unify the terminology across the document as a
> whole.
>

I agree. That's a mistake; the document should be consistent. We'll fix that up.

Thanks!

Kyle

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


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

2020-06-05 Thread Martin Duke via Datatracker
Martin Duke 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 the terminology around “Captive Portal API server” and “Captive Portal
Server” to be a little confusing, as these are similar terms. The latter also
doesn’t get its own discussion in Section 2 and is confusingly called the “web
portal server” in Figure 1.

After Figure 1, this seems to be consistently called the “web portal” (sec 2.6
and 4). It would be great to unify the terminology across the document as a
whole.



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