Re: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05

Warren Kumari <warren@kumari.net> Fri, 11 December 2020 17:17 UTC

Return-Path: <warren@kumari.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770943A0D21 for <v6ops@ietfa.amsl.com>; Fri, 11 Dec 2020 09:17:54 -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, 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 6d5dhe-TPJeo for <v6ops@ietfa.amsl.com>; Fri, 11 Dec 2020 09:17:51 -0800 (PST)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 57B5A3A0D32 for <v6ops@ietf.org>; Fri, 11 Dec 2020 09:17:50 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id m13so11720231ljo.11 for <v6ops@ietf.org>; Fri, 11 Dec 2020 09:17:50 -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:content-transfer-encoding; bh=oD2kOg1JDZSDE6mNRB9tT/6g87azSwcM7BbbUJzJLEw=; b=Ze1euAbKFxSSwyxL4IL9PuwyulaS1CoM8O5CjWIaCnvaSgC65yfX5pk4DGHEwkumrC ecoevSd8zgaL/V79sqoFiVuLd56+vY6bANFN325BYH0iL8kQWksWTCxXYTvjXvKQrR8X Ued/v3Qan0d7wEOSx+dRODvP+E6a0NY55YDeCmRXefx5/lm2h2YKFprt62Z5DkSYCgC6 24lkF4ywQW6iGMleZCQd0hd9zcGNH79PpZ0xHoa6dGPujJpn6qKOZeSnqrbFJSagb2Jj 540odaxr14e3Ou5RbHCXG/BwWUoaaeoc/anZsXHINw+kDYBL6JJXUWqNM7uw1vjspTar 9Xhw==
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:content-transfer-encoding; bh=oD2kOg1JDZSDE6mNRB9tT/6g87azSwcM7BbbUJzJLEw=; b=WDJjvvDmdB8wSudEnXiyXMYnsZdTtokI+/4N9435rv8MQdtZ6bjXwYpRKmNFbw732Q d1s7Reh3tUy8oPDG7oruNUMsq7Kta4RhRJU8JMRziaUfx8qywXDE3EWWC+Qoag+ojOv5 zaPKvelWzSZYYVnIViH7k5S8oQBIXJrKTvPgAlbjoNuCFEtY71vVgxLZfMvwU4fpCmiz YBB5PNF/BucZfnKmxBlEFhVfSRRviD5KJq6TgpZ9V55RcUQqW3pDdtFUJPMMvOdkm5sm xTMXE55xBkldyuLh78x4DBj3ah/c0BuIZLTp72rTcJxjmHeLJpm1SwEp3wC7h4enuxRn 3z4Q==
X-Gm-Message-State: AOAM531rCAVPcPRGiwuvKhl1okW9/bECRG0i6Gkeb8rs4Rs7HrYFuysX 1OYNj+l9YJvSVSMj2YvXINslr+EOB3+N5F47Lq9L08c9r13smijn
X-Google-Smtp-Source: ABdhPJxHc5soOjdjdwprNMz0bUBqowB30h2Hi/aS9Xc48fNYIE43yHKUUVnbYLWZOJbyC1t2CXJEZ6WIww9X+WYh78E=
X-Received: by 2002:a05:651c:1214:: with SMTP id i20mr5428638lja.324.1607707065771; Fri, 11 Dec 2020 09:17:45 -0800 (PST)
MIME-Version: 1.0
References: <CAHw9_iKr2HF4iZYfDWXTqi59HHKcv3UzpLST7VB_rook3MZMWA@mail.gmail.com> <CAHw9_i+G-j-S8H9VBf=n0L-HFXYzV6Dk0nrRpe1C_eADP+6XMg@mail.gmail.com> <BY5PR11MB43558BFEFAF2F34BACE545C9B5CC0@BY5PR11MB4355.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB43558BFEFAF2F34BACE545C9B5CC0@BY5PR11MB4355.namprd11.prod.outlook.com>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 11 Dec 2020 12:17:08 -0500
Message-ID: <CAHw9_iKqs8O9u5zE0Dy19K9vUT4mi2OZw+t2jme3evLw=cGYGw@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: IPv6 Operations <v6ops@ietf.org>, Fernando Gont <fgont@si6networks.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/23R_SlJP9l5pdkgFTglDZh1sh7Y>
Subject: Re: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Dec 2020 17:17:55 -0000

[ Top post ]


Awesome, thank you everyone.

I'm returning this document to the V6OPS WG, and requesting that it be
updated with:
1: The "normal" RFC2119/RFC8174 language
2: The track to be BCP

Hopefully it can be WGLCed soon, and that the comments are restricted
to just those needed for the above changes.
Once the WG sends it back to me I'll do another IETF LC (required
because of the track change).

Thank you everyone, and sorry for the process wonkey -- changing
status "up" is harder than changing "down" :-)
W


On Wed, Dec 9, 2020 at 8:54 AM Rob Wilton (rwilton) <rwilton@cisco.com> wrote:
>
> I also agree with Warren that option 1 is best.
>
> Regards,
> Rob
>
>
> > -----Original Message-----
> > From: Warren Kumari <warren@kumari.net>
> > Sent: 08 December 2020 21:14
> > To: IPv6 Operations <v6ops@ietf.org>; Fernando Gont
> > <fgont@si6networks.com>; Rob Wilton (rwilton) <rwilton@cisco.com>
> > Subject: Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-
> > 05
> >
> > [ Subject edited to start new thread ]
> > Hello again all,
> >
> > I started this thread back in October, and then didn't really follow-up;
> > sorry.
> >
> > This document went through WGLC as Informational, but uses
> > "pseudo-RFC2119" language
> > (https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/,
> > Section 2). This section says things like (cribbed from RFC7084):
> > " Take careful note: Unlike other IETF documents, the key words "MUST",
> >    "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
> >    "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as
> >    described in [RFC2119].  This document uses these keywords not
> >    strictly for the purpose of interoperability, but rather for the
> >    purpose of establishing industry-common baseline functionality. "
> >
> > This caused confusion during IESG eval -- what does the MUST in "CE
> > routers MUST signal stale configuration..." mean if not in the RFC2119
> > sense?
> >
> > Also, much of the document reads like a BCP - Alissa specifically
> > called this out in her DISCUSS, but there were quite a few others who
> > agreed.
> >
> > As an example, is it not a Best Current Practice that e.g: "CE routers
> > SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon reboot
> > events."? If not, what does this document mean for an implementer?
> >
> >
> > There are 2 options here:
> > 1: We change Section 2 to use normal RFC2119/RFC8174 language. I send
> > it back to the WG and it gets WGLCed as BCP.
> >
> > 2: We remove Section 2, and all of the uppercase/lowercase words. I
> > send it back to the WG (because of the changes) and it gets WGLCed as
> > Informational again.
> >
> > I really prefer Option 1 -- to me it reads much more like a BCP,
> > documenting Best Current Practices for CPE implementers.
> >
> > The last time I sent this, there was only one response[0] and then the
> > thread died -- I'd REALLY appreciate clear responses from the WG on
> > which option (1 or 2) you prefer...
> >
> > W
> >
> > [0]:
> > https://mailarchive.ietf.org/arch/msg/v6ops/xVv4f73kB8tRFag3yJCBAraXwXk/
> >
> >
> > On Thu, Oct 22, 2020 at 11:53 AM Warren Kumari <warren@kumari.net> wrote:
> > >
> > > Hi all,
> > >
> > > draft-ietf-v6ops-cpe-slaac-renum-05 was on today's telechat, and ran
> > > into issues.
> > >
> > > Alissa (based on the Gen ART review) asked why this was not a BCP, and
> > > there was general agreement within the IESG that BCP seems like most
> > > reasonable status.
> > > There was also discussions on the:
> > > "Take careful note: Unlike other IETF documents, the key words "MUST",
> > > [...]  "OPTIONAL" in this document are not used as described in
> > [RFC2119]."
> > > and that this was very confusing.
> > >
> > > I proposed that we change the status to BCP, and that the terms be
> > > used in the normal manner.
> > >
> > > I'd like to give the WG 2 weeks to object to this proposal, and, if
> > > none received, start another IETF LC as BCP.
> > >
> > > So, please let me know (by Nov 5th) if you strongly object to this
> > > becoming a BCP, and the "normal" RFC2119/BCP14 meanings being used for
> > > the recommendations **in this document**.
> > >
> > >
> > > W
> > >
> > > --
> > > 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
> >
> >
> >
> > --
> > The computing scientist’s main challenge is not to get confused by the
> > complexities of his own making.
> >   -- E. W. Dijkstra



-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra