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.
Rob
/js
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
