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

Kyle Larose <> Tue, 12 May 2020 12:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C13683A0895 for <>; Tue, 12 May 2020 05:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id haMelS2wK-Uz for <>; Tue, 12 May 2020 05:45:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7B2E3A08A7 for <>; Tue, 12 May 2020 05:45:56 -0700 (PDT)
Received: by with SMTP id s10so13713787iog.7 for <>; Tue, 12 May 2020 05:45:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q2k58QU1GAjEK7YUq7oUvrPPiS9jWCxqDjdNNi5qWOM=; b=drBUzyqwdTe/bnavFMqme32oM7E0Q9ZXqr4oHBqPkrIkmvChW83y4CPNoIsD7Njqgq CeZCv54H6dORjtqc8x1G/LOFKyD3hxsyVkLi3BisuGQ00VEoJwYd5B0sJNNcQDtOB87K tXESg+2N9Gbfxqz9c4cwex9X6xUlY+RvKWDkmCTC92TpnxZsz/DrQWw7RiaTxgziEDim eeiwPl+ETfGF/kimgoYY1vARvbvNqFa54JS51YlM96Z6Lj5YfJ37IfRTWwQAYRdA+ahs pC3cyWXdeUZjlr/BZhpvCyRnPhDTV/De6BP+qE8CVPz2vwTgOYhtrQ18cEITIRhmVZtt FMlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q2k58QU1GAjEK7YUq7oUvrPPiS9jWCxqDjdNNi5qWOM=; b=eqi1CtmhKnpN5rBPw/2trfaVTjk0J5RozCFeXL978kdYsFYnYadvkYGEJ//wCYsKyL xQD6xLY9R34itd+jc/Ka8dfn2orFHJPMWFAaura4wftNSA0Yr1K9IliLTwprvyPy2FWS ekZslwiobZg4ayAFRtAE8lzy7PSsLsZbrSAx18Nmv+PD6pG+mUcwOFBRruJTzOyw2gzd YRPyu2xrZcm2QmZfw6YePh9coTVTdTNDFgcvbEOisIn8BVNVswwsutu8cDr/lYe91xoa V3VGnTMjmVNwl7mrzPXpzLBJL7bJB2LXcEp4+pYsfFmbN9SQXP6QEiL1yoyBC7JSy6QH eGsg==
X-Gm-Message-State: AGi0PuaYYggLKROC/OFc0pXqG4PuoMDi9tPfs+umqGC9ONSF4d2mnaky qSPhZl6/JMgdrlXVdYJ2O210a1VL7w/B7u+yMzWXlsz4kH1rXlA=
X-Google-Smtp-Source: APiQypI9Gc1R65ein5HA/j/q08Ei7moepDUpSToCklbqRreXHJ0EeWitbeycj86FsIl0UD2rJGTSIQ89kD/9QK1Y/FQ=
X-Received: by 2002:a02:a90e:: with SMTP id n14mr19975650jam.97.1589287555910; Tue, 12 May 2020 05:45:55 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Kyle Larose <>
Date: Tue, 12 May 2020 08:45:44 -0400
Message-ID: <>
To: S Moonesamy <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Captive-portals] Last Call: <draft-ietf-capport-architecture-08.txt> (CAPPORT Architecture) to Informational RFC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 May 2020 12:45:59 -0000


Thanks for the quick feedback

On Mon, 11 May 2020 at 15:25, S Moonesamy <> 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:

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