Re: [Captive-portals] option 160 conflict

Warren Kumari <warren@kumari.net> Fri, 20 December 2019 02:54 UTC

Return-Path: <warren@kumari.net>
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 D801C1207FD for <captive-portals@ietfa.amsl.com>; Thu, 19 Dec 2019 18:54:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 114qsQfK5cQ1 for <captive-portals@ietfa.amsl.com>; Thu, 19 Dec 2019 18:54:01 -0800 (PST)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27271200EC for <captive-portals@ietf.org>; Thu, 19 Dec 2019 18:54:01 -0800 (PST)
Received: by mail-qt1-x82b.google.com with SMTP id l12so6910123qtq.12 for <captive-portals@ietf.org>; Thu, 19 Dec 2019 18:54:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3l6rnigsTjLWsoLPnecp4DY7Ks2l2KfSi/TwtjvTyiM=; b=h1jCRI9l8FjSwZhbIm/eGXA6Srlksey5uUCok8Fma47tPNKj3qPnUZ/Zq6Nxvo0ifV wE3kgM2r/EmCmIipTt3fWOC16cPFeRUfdMNZR104QUcN3tth0ecm8LBOzccjyR5pl2hV bRYJT0YeXafHVV8p02UQ3A63pRf8b2e0FAGdcc1bbFIftMhsB5LDYQajyRe5yHY5r/oA yn1iweR+VZFWdZulagXvzNNK2/iojkw50Tf7yWfAl4r8e7yM5vk/kBK7abax2DCbKmTe H4ckpo9+YT2Bxlft52cVnmOlYT5zHEB6koLohRbPDmj1emQJta/pb+YZi50NreUYL4yb HzPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3l6rnigsTjLWsoLPnecp4DY7Ks2l2KfSi/TwtjvTyiM=; b=IgMCS5P3n12dPb+2enHHJWb9TJG1iPwnIDfRnXNgklarahpzba2zTTH2FhgyzzodAQ 4JM1YZmUDbkbr1iIXzDxLgrRbhNXja0z/GwzW+Fp9SrX3nujWX7/3rNQiQSO1GDw67J3 BI9VdAAwvQk3VykFF/yrIVgXotPF1TRR3zZlXWTH1j1YheK26DGkUWjRkeIbWRZ3Iw0S QKcTjtCZb+8NBTe/3Vew7fmqMwV9h5PdEfeFiwUceaoCf6poD48xpo9cspFpO2juX4CY YwfMtlr3zXtdCosECpUgEhSmWus0Vmvw3jfQvHfLJy0uEU/Sa+AAr+7XLh44vL8Wg8qr d7zQ==
X-Gm-Message-State: APjAAAWVOKROHQasyan1JbQUE6+3EA74F1O1xptE+msn4B3HEwGLQMnl TLSQdo7QYZR0tvFqGv++z7dIcReVXXpbcNd1KGZciA==
X-Google-Smtp-Source: APXvYqwTmMqHRaccUkz+03f11f30fNH1TPRdwIw+CDHiIPDzvVVNKZ+GZS5IzKSy/v3MgWdPEbpSxuOyrBSNKUJxu8s=
X-Received: by 2002:ac8:387b:: with SMTP id r56mr10116857qtb.364.1576810440597; Thu, 19 Dec 2019 18:54:00 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <18576.1574927790@dooku.sandelman.ca>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 19 Dec 2019 21:53:24 -0500
Message-ID: <CAHw9_iLOqTeY-zos50y_knwg4jtS4d608wDJatQF_XFLFwK8Wg@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "Bernie Volz (volz)" <volz@cisco.com>
Cc: captive-portals@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/em6n659y4czT4rImk7BkQwySktg>
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: Fri, 20 Dec 2019 02:54:04 -0000

On Thu, Nov 28, 2019 at 2:56 AM Michael Richardson
<mcr+ietf@sandelman.ca> wrote:
>
>
> Bernie Volz (volz) <volz@cisco.com> wrote:
>     > The issue with the 128-254 option range is that they were, originally,
>     > site-specific options (i.e., available for use within a site). However,
>     > many vendors hijacked them. And, when we reassigned much of this range
>     > to the IANA assigned options pool, the vendors failed to request a more
>     > permanent assignment for their option use. I suspect though that you
>     > are well aware of that entire process
>     > (https://tools.ietf.org/html/rfc3942).
>
>     > I don't know when Polycom decided to use this 160 option as RFC3942
>     > dates back to November 2004.
>
> This explains a lot about why we conflicted on option 160, and that perhaps
> we shouldn't have been so upset.
>


Reviving an old thread -- I was one of the people a: who was
super-annoyed by this and b: helping run the CAPPORT experiment at
IETF106, where we discovered the issue.

Having had some time to reflect on this, and with the history lesson
from Bernie, I am leaning towards the "Meh, we should just stick with
Option 160" stance...

We *could* ask for a new one in the -bis, and I suspect that e.g 169
won't be as "polluted", but I might be wrong, and it might be as bad
or worse....

Here is a random PDF of known usages -
https://link.springer.com/content/pdf/bbm%3A978-1-4302-2773-1%2F1.pdf
-- does anyone have a more complete list?

W

> It seems to me that DHC WG has to help IANA avoid conflicts like this in the
> future.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf