Re: [netmod] versioning procedures (RFC vs. I-D)

Andy Bierman <andy@yumaworks.com> Wed, 01 April 2020 18:07 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502223A14F9 for <netmod@ietfa.amsl.com>; Wed, 1 Apr 2020 11:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.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 cPvXKn7E28gb for <netmod@ietfa.amsl.com>; Wed, 1 Apr 2020 11:07:21 -0700 (PDT)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 698B23A14EA for <netmod@ietf.org>; Wed, 1 Apr 2020 11:07:21 -0700 (PDT)
Received: by mail-yb1-xb2c.google.com with SMTP id l84so575115ybb.1 for <netmod@ietf.org>; Wed, 01 Apr 2020 11:07:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VO1PH+iQXhd4ZXI9CJa2xG3AuRfJlDACv4s45nMWf2Y=; b=0LtOSDsN2hi6+vIeTpMX5WSNDRYT35t3VH4uYtsiJk50dMd9FY/mvkJFGV6DJm3WKL 3CRYxT3g6QWkRdXzMwzqf6QLV7eZcYj4lLUTQLsKyAi8QLVg359AogADw9Mt9DXyd+76 BX2k+MwcY/Uo30PBkNy+40EhZ121d+NFmoaqgGUDbB+ChE5B/LGZvwUC+g3rCvQH20nL 3P7LcS6dj7mRftm0sjvDjWovXIDIEJi+3ZZadmbzmUhbLBjrUq3S91E49aYIpbsdrCtK Hk9MobI8EWQqLZL7HGiDyh49P+1lg2upV+yxiA8H4QjaR2I7EOk3RUv15IDL2+08A9fw 6L8A==
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=VO1PH+iQXhd4ZXI9CJa2xG3AuRfJlDACv4s45nMWf2Y=; b=U2p6of4VA7tMs0r2mTXfI4gUlMMCPaVs3G/qf5sKXnOJVpvTuT8+AlZcy8DpPJMcu2 sMAHlzwYhWfDFgQHNTQh8VN+Pe8tsrPausDpmeXxhPgliplkBL7DrCiRyy200nbhTbya XRmNMbF5G8DAgrRtEaG5j/UID2aC2ld/TIrL+kokpmrWrO08Tibcftl8Pw0aXnVXkaYF aHUTJjs53Ii+d2NMPvIlttcAyzI6Gx56jCBUdxu2wovQK++HUorzrE+lqYFtrnY03dB3 jgRw6E6BEDmuRM3oIFWR4EiBIOnSAmVngvNxhgtVPPe4HvQAV0/jjDN+s+nEdPW6XBgp aL+w==
X-Gm-Message-State: ANhLgQ1TTXrSEeqnMfH4Yw3yEKpTyKjnUbhs02f/CVV/mWeMbgLISX7X vHsaI2qlU66Lx7pwe06zoKno7mbxeH3DnXHvLCdJ9Q==
X-Google-Smtp-Source: ADFU+vvdfLBIwAbFfQbFXdo6W/ImoWsBLj7s2tfFC+XnF3EVc9h1CdSMZKoic8Nx0t+n7rlwU0Vah0ZC87I5RXs4Kf4=
X-Received: by 2002:a25:158a:: with SMTP id 132mr31987314ybv.145.1585764440104; Wed, 01 Apr 2020 11:07:20 -0700 (PDT)
MIME-Version: 1.0
References: <CABCOCHQWssUucRvnsi8O8+GhCHb0-xS--swf3R4q-6P3Qfq0TA@mail.gmail.com> <D63416FC-2C33-4015-BF23-51ABCD75A020@cisco.com>
In-Reply-To: <D63416FC-2C33-4015-BF23-51ABCD75A020@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 1 Apr 2020 11:07:09 -0700
Message-ID: <CABCOCHSTnYJbB9ainkmCuBinjRZAi-wEWgQoFCrhs+m8NBAAYQ@mail.gmail.com>
To: "Joe Clarke (jclarke)" <jclarke@cisco.com>
Cc: NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000268a6d05a23e8e62"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/RNyqvvJydrbzJGTsBrdRsG83GKU>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 18:07:24 -0000

On Wed, Apr 1, 2020 at 10:39 AM Joe Clarke (jclarke) <jclarke@cisco.com>
wrote:

>
>
> > On Apr 1, 2020, at 13:28, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > Hi,
> >
> > I just want to confirm that all the proposed documentation procedures
> > using new extensions are limited in scope to published modules only,
> > and not applied to unpublished modules (terms defined in RFC 8407).
> >
> > IMO it would be harmful to module usability to assign revision-labels or
> > include revision-related extensions in unpublished modules (e.g.,
> Internet Drafts).
> > Consider how cluttered and confusing the client-server modules would be
> > if the 50+ NBC changes and versions were tracked through all the I-Ds.
> >
> > For IETF modules, the first usage of the revision-label
> > should be in the initial RFC, and be set to 1.0.0.
> >
> > If the RFC is ever republished then one can expect to find an updated
> > revision-label and possibly extensions tracking NBC changes.
>
> The semver scheme allocates a major version of 0 for pre-releases where
> the BC/NBC rules do not apply.  I agree that a first official RFC release
> should be 1.0.0 (from a semver revision-label standpoint).  From a design
> team standpoint, I know we mentioned the 0 versioning early on, but I don’t
> think we spent much time talking about modules under development overall.
>
>

IMO it is confusing to ignore the semver rules for the special 0.x.y
releases.
There are many NBC changes made at this point which are treated as minor or
patch changes.
The procedure is really broken once you consider a WG developing any
RFC-bis module.
Now the major version is not 0 and all updates look like real releases.


> My take would align to yours that we wouldn’t clutter a module with
> development NBC tracking.
>
> Joe


Andy