Re: [netmod] 6087bis namespace recommendations

Andy Bierman <andy@yumaworks.com> Fri, 15 January 2016 14:49 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8271A1ACE5B for <netmod@ietfa.amsl.com>; Fri, 15 Jan 2016 06:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 9zPYiEHJ01wE for <netmod@ietfa.amsl.com>; Fri, 15 Jan 2016 06:49:22 -0800 (PST)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 8E5371ACE48 for <netmod@ietf.org>; Fri, 15 Jan 2016 06:49:21 -0800 (PST)
Received: by mail-lf0-x232.google.com with SMTP id c192so284190364lfe.2 for <netmod@ietf.org>; Fri, 15 Jan 2016 06:49:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FsLlKLol1mfnsiDlvPg9V3tOQlp7ndfS++hLKAzabAg=; b=bv55LLzJyAycjfAHD2X09t60SPlk5oMUJMOquhEerHPktAKFjRMQSgB0W2FclAWWbe LhAIy0DRnYP+AFw08Qx+IRioLD4ASbjinkDTRUB96YnPBiS6EGHixxo8sxsAM3DlfIl1 sjKw8BJg8pn1TURSOMRSFPYh1NdR7bM+N6t0+IIBkzIZkcqNlY3P9VsohFyF1B/W3vgT J1Ckjy61tdAhyi5KtRtbbpiMJ8/6Opx70/MJJWdbAsZ5cUndTqfBYQc4cZrTYnZqcrWR YbIbXHvZXIslJ7dKCxEBXdf0pn8lIJOGOBtekxQobUms1W6uMUKLzuuoJBQ13UMi77Qv 3kdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FsLlKLol1mfnsiDlvPg9V3tOQlp7ndfS++hLKAzabAg=; b=BPBXGF5cMcbiE2GvKZvv2CSu1UKBybQZbLU7a21I2WMFObwLDdLIxNMAlej/bYc289 4r9s8/T7zg85zJumslJNI4Hrmpkw2wDB0FmOwvODbzmplCLFl+8gPx68tuAE0/HuKeab gkecxbg9gXU7waUCX/yy3yr1aKMEdhVrlev7OnCHooZfnUMx8jpgMAz0OvXXRDQbY/CS tXOXHP/d2A4NcoibaYr3M+56+/P1UIO30Fr8ZCaOigNg7kWdgwra9AbEY/q9viWrhFk1 xWNCbXIi+VMV2j0kwQtP8YkUOcuQ1VN3t+xLwHDX2qP5Imgjd3C1+H2Mx/ypJbeURz32 yfxQ==
X-Gm-Message-State: AG10YOSwuLMI5HAankBblCL01zgOZccp3RJsgGEJbndVoJnMzVWt4/J8w621WuJCNtciDjs+3fdCBSHZ2iwNLQ==
MIME-Version: 1.0
X-Received: by 10.25.162.202 with SMTP id l193mr2862618lfe.138.1452869359584; Fri, 15 Jan 2016 06:49:19 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 15 Jan 2016 06:49:19 -0800 (PST)
In-Reply-To: <9DA7DD58-6890-4BC2-A7BE-6D6F15F1B08D@nic.cz>
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local> <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net> <CABCOCHTXa-XTkY73QhM3gzFbx0zQ_a24hijCz2HOaOQ9odL9DA@mail.gmail.com> <m2oacnnkbf.fsf@birdie.labs.nic.cz> <20160115114924.GA12322@elstar.local> <301372A9-0333-4D56-B501-207C405C79F3@nic.cz> <CABCOCHRrBSn7VX3dK54TZ_GES86ANn9xzzFQFue5sJF_d17EuQ@mail.gmail.com> <9DA7DD58-6890-4BC2-A7BE-6D6F15F1B08D@nic.cz>
Date: Fri, 15 Jan 2016 06:49:19 -0800
Message-ID: <CABCOCHQtEFH44gLqc4hRfpxv6kaaoW99qM04JKngNMSeRqkkzA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary="001a114119ec1563550529608239"
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/llXA2g4BKiUrk3p2X_7T2OIxEf4>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 15 Jan 2016 14:49:23 -0000

On Fri, Jan 15, 2016 at 6:19 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> > On 15 Jan 2016, at 15:10, Andy Bierman <andy@yumaworks.com> wrote:
> >
> >
> >
> > On Fri, Jan 15, 2016 at 3:55 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > > On 15 Jan 2016, at 12:49, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> > >
> > > On Fri, Jan 15, 2016 at 12:39:16PM +0100, Ladislav Lhotka wrote:
> > >>
> > >> Does this solve any practical problem? Modules are imported based on
> > >> the module name and revision. On the other hand, it does create new
> problems:
> > >> namespace URIs and their mappings to prefixes may be spread in many
> > >> places in the code, and these would have to be manually edited after
> an
> > >> I-D -> RFC transition.
> > >>
> > >> It would IMO be much better to use revision numbers rather than dates,
> > >> and adopt a convention, e.g., that modules in the I-D stage have
> > >> revisions 0.x that get bumped with each new revision of the I-D.
> > >>
> > >
> > > Lada, this is not how our current YANG 1.0 versioning and revision
> > > rules work and we are not going to change them in YANG 1.1 either.
> > > The rules we have do make a distinction between published modules and
> > > modules that are unpublished.
> >
> > I am not proposing it. The problem I'd like to get solved is proper
> module revisioning already at the I-D stage so that implementations be able
> to distinguish one revision from another. Appending DRAFT to the namespace
> URI doesn't help anything.
> >
> >
> >
> > Changing the module name constantly does not help.
> > It would be better to just keep using revision dates.
>
> Some I-Ds don't do even that, for example acl-model uses the same revision
> date in subsequent I-D revisions. I checked that this actually violates a
> MUST in RFC 6087.
>
>

If the YANG module does not change from one I-D to the next,
then the revision date does not need to change.



> Lada
>
>
Andy


> >
> >
> > Lada
> >
> >
> >
> > Andy
> >
> > >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>