Re: [netmod] 6087bis namespace recommendations

[t.petch <[e-mail]>]

----- Original Message -----
From: "Robert Wilton" <[e-mail]>
To: "Ladislav Lhotka" <[e-mail]>; "Andy Bierman"
<[e-mail]>; <[e-mail]>
Sent: Sunday, January 17, 2016 10:20 PM
> On 17/01/2016 09:52, Juergen Schoenwaelder wrote:
> > On Fri, Jan 15, 2016 at 03:38:00PM +0000, Robert Wilton wrote:
> >> Since an ID is effectively superseded by any new versions, I think
that
> >> it is useful if a module defined in an ID has a revision date that
> >> matches the published ID, and also a reference back to the ID
version
> >> that defines it.  At least if someone ends up implementing that
module
> >> they can check its provenance.  Both of these properties would also
be
> >> verifiable by idnits.
> >>
> > Right now, we seem in the "hey lets invent more rules mode" and
> > tomorrow I am sure we are again in the "hey the IETF is way to
> > complicated to work in" mode.
> This was the approach that I followed when posting and updating the
> drafts that I was working on, perhaps mis-understanding the statement
> "The revision statement MUST have a reference substatement. It MUST
> identify the published document that contains the module." for which I
> presumed that the "published document" also includes the version
number.
>
> > If you have a unique revision date, why is google and the like not
> > sufficient to find the matching I-D? Sure, the proposed rule itself
> > does not hurt, but an increasingly large collection of rules may
start
> > to hurt. So please, lets try to find the minimum number of rules
where
> > we have evidence that they avoid big problems.
> I'm also against having too many rules to follow, it starts to make
the
> process too laborious.
>
> My assumption is that given the relatively slow pace that standards
> models are being formally standardized that vendors/operators are
likely
> to want/need to temporarily ship with pre-standard versions of the
> models.  Hence, in this case I personally feel that the additional
> clarity that is gained by explicitly referencing both date and full
> document name outweighs the slight hassle in updating it when a new
> version of the draft is posted.

I was looking at
draft-liang-rtgwg-staticrt-yang-cfg-00
which contains
"   <CODE BEGINS> file "[e-mail]"
....
     revision 2015-10-17 {
       description
         "Initial revision.";
       reference
         " [draft-ietf-netmod-routing-cfg-16]
          A YANG Data Model for Routing Management.
         ";
 and then I looked at
draft-liang-rtgwg-staticrt-yang-cfg-01
which contains
"   <CODE BEGINS> file "[e-mail]"
.....
     revision 2015-10-16 {
       description
         "Initial revision.";
       reference
         " [draft-ietf-netmod-routing-cfg-16]
          A YANG Data Model for Routing Management.
         ";

mmmm  I think that this happens, and quite often.  There is a gap
between getting what seems to us a good set of conventions out into an
RFC and getting those adopted, especially when there is nothing to catch
what, to us, may seem obvious flaws.  Automation, by the tools team,
seems the obvious answer. The second I-D was published on 2015-12-16
which, assuming a typo, accounts for some, but not all, of the quirks.

In passing, s.4.1 has an example containing
           description "Latest revision";
True, and it could have said "Current revision" or "Most recent
revision" or ...
I would change that to, say,
"Revised after comments on the use of opstate"
(or some such).

Tom Petch

>
> Rob
>
> >
> > /js