Re: [Captive-portals] option 160 conflict

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 21 December 2019 22:52 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E0B12007C for <captive-portals@ietfa.amsl.com>; Sat, 21 Dec 2019 14:52:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9znrYnCntxPY for <captive-portals@ietfa.amsl.com>; Sat, 21 Dec 2019 14:52:43 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832AE120073 for <captive-portals@ietf.org>; Sat, 21 Dec 2019 14:52:43 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0846F3897E; Sat, 21 Dec 2019 17:52:36 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 222993FB; Sat, 21 Dec 2019 17:52:42 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "captive-portals@ietf.org" <captive-portals@ietf.org>
CC: "Bernie Volz (volz)" <volz@cisco.com>
In-Reply-To: <DM6PR11MB4137AEA878279A39A4C5E6BBCF2D0@DM6PR11MB4137.namprd11.prod.outlook.com>
References: <CAFU7BARZsgP_B+PvAdc1nKrypukBb1sJv8PU1Nq-vPipHG6h9w@mail.gmail.com> <30673.1574666680@dooku.sandelman.ca> <DM6PR11MB41370A13C93D12CA569A13D2CF450@DM6PR11MB4137.namprd11.prod.outlook.com> <15823.1574863018@dooku.sandelman.ca> <DM6PR11MB4137A09CC0527175C8F11EEDCF440@DM6PR11MB4137.namprd11.prod.outlook.com> <18576.1574927790@dooku.sandelman.ca> <CAHw9_iLOqTeY-zos50y_knwg4jtS4d608wDJatQF_XFLFwK8Wg@mail.gmail.com> <DM6PR11MB4137D61D3EC43B7133559509CF2D0@DM6PR11MB4137.namprd11.prod.outlook.com> <CAHw9_i+09y0D9AX9FXnym8fLHZsAnvBB2ef-43LWKiEoSY2P1Q@mail.gmail.com> <DM6PR11MB4137AEA878279A39A4C5E6BBCF2D0@DM6PR11MB4137.namprd11.prod.outlook.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sat, 21 Dec 2019 17:52:42 -0500
Message-ID: <23694.1576968762@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/4jwVPbPlu896O_oLQ-LZqhKSp1o>
Subject: Re: [Captive-portals] option 160 conflict
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Dec 2019 22:52:46 -0000

Bernie Volz (volz) <volz@cisco.com> wrote:
    > I see that: 1) It would not really remove the overlap for a long while
    > (until all of the clients that used the "old" 160 Capport option are
    > upgraded). So, devices will still need to deal with it for a long
    > while.

I think that this is a single upgrade cycle for some smartphone OSs.
I think that could occur faster than the RFC-editor queue will process the
document actually.

    > 2) It creates additional problems as new clients likely need to
    > request both and prefer the new one over the old 160. As it could also
    > be a while until servers in the field are upgraded (software and
    > configuration). And, since this URI might be long, servers without
    > special handling would return both which could cause MTU issues. (See
    > below *).

    > 3) When, if ever, could you stop supporting the old option?
    > I guess a server operator could take a survey, but if there are these
    > phones around, they may still request it and would the operator be able
    > to tell the difference?

I think that there are few production server systems out there to worry
about.   I think that the people involved are on this list.
I think that we could switch very quickly.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-