Re: [Captive-portals] Last Call: <draft-ietf-capport-architecture-08.txt> (CAPPORT Architecture) to Informational RFC

[Kyle Larose <[e-mail]>]

Hello,

Thanks for the quick feedback

On Mon, 11 May 2020 at 15:25, S Moonesamy <[e-mail]> wrote:
>
> I took a quick look at the draft.  The third paragraph in the
> Introduction section states that the document standardizes an
> architecture for implementing captive portals.  Does it  meant that
> this draft is intended to be a standard?
>

The draft is intended to be informational. We should probably rephrase
that section.

I have submitted a gh issue:
https://github.com/capport-wg/architecture/issues/74

> The principles listed to guide the architecture looks more like
> requirements.  Anyone who has been at an airport understands that
> existing protocols are being intercepted, forged, broken, etc. to get
> to reach the user to go through the "captive" experience.  The
> "SHOULD NOT" (why are the words in uppercase?) comes out as a
> principle that "one should follow the existing standards".
>

I don't quite understand your point here.  Are you suggesting that because it
is commonly known that existing captive portal implementations do
these things, saying
that we should not do them instead means we should? Our goal is to
document an architecture
that allows providers to offer a service that does not use these
mechanisms. This is why we're
suggesting that a solution shouldn't do that. Do you have a suggestion
for alternate phrasing
that is less confusing?


> What are there "MAY" principles?
>

Perhaps we shouldn't be calling these principles, but rather the
requirements the document is
placing on a solution that will lead to a good outcome.

I've submitted https://github.com/capport-wg/architecture/issues/75
for us to consider reworking this section. I
welcome any suggestions for how to improve it.

> This document is about the architecture.  Where does it provide for
> incremental migration?
>

We don't have an explicit section, but we considered existing captive
portal implementations
when putting together the document. The new components are not tightly
coupled by the architecture,
meaning that any of them could be omitted. You wouldn't have the
functionality they provide, but
a solution without them would still work.

> On reading further, I would say that the draft is a mix of
> requirements and "solution" instead of a draft about architecture.
>

I view an architecture as guidelines for how components of a system
interact as well as definitions
of those components. Perhaps that is the wrong view, but it is what I
think we documented.
The draft does talk about solutions, since the end goal of the
components we're describing is a solution to the problem
of providing internet access through wifi hotspots. It places
requirements on the components which form the system,
and their interactions

The document also provides examples for clarity. Perhaps the examples
consume too much of the document, making them seem
like recommendations for a particular solution, or the interactions
are not sufficiently abstract to allow for multiple solutions?

Does anything in particular stand out to you that warrants change?

Thanks,

Kyle