Andy,
This thread started with discussion of an apparent ambiguity in the current
text:
OLD
It is acceptable to reuse the same revision statement within unpublished
versions (i.e., Internet-Drafts), but the revision date MUST be updated to a
higher value each time the Internet-Draft is re-pos
On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley wrote:
> Andy Bierman writes:
> > An Internet-Draft is NOT a means of "publishing" a specification;
>
> As I said, that's the theory, but practice is considerably different.
>
>
Anybody that implements a work-in-progress knows they are taking a ris
Andy Bierman writes:
> An Internet-Draft is NOT a means of "publishing" a specification;
As I said, that's the theory, but practice is considerably different.
Dale
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
On Thu, Aug 18, 2016 at 7:15 PM, Dale R. Worley wrote:
> William Lupton writes:
> > Regardless of the discussion about “published”, other organisations
> > may be planning to use YANG modules that are currently within
> > IDs. Obviously it’s vastly preferable if such IDs become RFCs before
> > t
William Lupton writes:
> Regardless of the discussion about “published”, other organisations
> may be planning to use YANG modules that are currently within
> IDs. Obviously it’s vastly preferable if such IDs become RFCs before
> these other organisations publish any specifications or data models
Hi,
IMO it is not useful to have lots of
copies of a module that just differ by revision date.
It is acceptable to reuse the same revision statement within
unpublished versions (e.g., Internet-Drafts), but the revision date
MUST be updated to a higher value each time the YANG module is
Oh dear :(. What do you think about this, which is what I really care about?
—
Regardless of the discussion about “published”, other organisations may be
planning to use YANG modules that are currently within IDs. Obviously it’s
vastly preferable if such IDs become RFCs before these other organ
Hi,
So this is the test that is supposed to replace 5.8, para 7:
It is acceptable to reuse the same revision statement within
unpublished versions (i.e., Internet-Drafts), but the revision date
MUST be updated to a higher value each time the Internet-Draft is re-
posted.
IMO the new
Thanks. Of course I am fine with this suggestion. This gives:
NEW:
It is not required to keep the full revision history of draft versions (e.g.,
modules contained within Internet-Drafts). That is, within a sequence of draft
versions, only the most recent revision need be recorded in the module.
William Lupton writes:
> Kent, all,
>
> OK :). I will take Lada’s update to my Monday text as a baseline and will
> give my proposed new text without further ado, followed by rationale.
>
> BASELINE:
>
> It is not required to keep the revision history of unpublished versions
> (e.g., Internet-D
Kent, all,
OK :). I will take Lada’s update to my Monday text as a baseline and will give
my proposed new text without further ado, followed by rationale.
BASELINE:
It is not required to keep the revision history of unpublished versions (e.g.,
Internet-Drafts). That is, within a sequence of un
Hi William,
Do you want to take a stab on consolidating on the comments into new proposed
draft-text? - there were two proposals put out before, and a number of
refinements since, but I’m unsure which were picked up or not. Since you
raised this issue originally, if would be helpful to get yo
Kent,
A couple of your comments have suggested that you feel that the “new version is
posted” language should be clarified in the direction (for IETF YANG) of “ID
becomes RFC”. That’s not how I read the original or how I read most of the
discussion, and it’s also not the clarification that I wa
On Mon, Aug 15, 2016 at 08:47:46PM +, Kent Watsen wrote:
> >Perhaps we should make it clear that 'publish' is meant in the
> >traditional RFC 2026 sense.
>
> We could add a reference to RFC 2026, but I think that it’s easy enough to
> make the text understandable to any reader, regard
>Perhaps we should make it clear that 'publish' is meant in the
>traditional RFC 2026 sense.
We could add a reference to RFC 2026, but I think that it’s easy enough to make
the text understandable to any reader, regardless their familiarity with IETF
process. I like that we’ve moved IE
On Mon, Aug 15, 2016 at 07:40:02PM +, Kent Watsen wrote:
> 2. “unpublished” is unclear. At least I consider submitting an I-D to
> datatracker as a form of publishing. I think it might be better here to
> refer to something like “works in progress”.
Perhaps this is what authors think thes
Nits:
1. First it says “unpublished” then it says “posted”, I think it better to
replace the latter with “published” so the terms are consistent.
2. “unpublished” is unclear. At least I consider submitting an I-D to
datatracker as a form of publishing. I think it might be better here to refer
Hi -
This also works for me, but I'd replace the odd "MAY" with the word "need".
(The semantics of "only" and of "MAY" don't quite mesh.)
Randy
On 8/15/2016 4:44 AM, Ladislav Lhotka wrote:
On 15 Aug 2016, at 13:31, William Lupton wrote:
Ah! Re-reading it I think that you are correct. In thi
Hi -
The new text works for me.
Randy
On 8/15/2016 4:31 AM, William Lupton wrote:
Ah! Re-reading it I think that you are correct. In this spirit I propose the
change shown below. I believe that all this does is (a) generalise, and (b)
clarify. I don’t believe that it changes the intended m
> On 15 Aug 2016, at 13:31, William Lupton wrote:
>
> Ah! Re-reading it I think that you are correct. In this spirit I propose the
> change shown below. I believe that all this does is (a) generalise, and (b)
> clarify. I don’t believe that it changes the intended meaning.
>
> OLD:
>
> It is
Ah! Re-reading it I think that you are correct. In this spirit I propose the
change shown below. I believe that all this does is (a) generalise, and (b)
clarify. I don’t believe that it changes the intended meaning.
OLD:
It is acceptable to reuse the same revision statement within unpublished
Ideally I’d like a stronger guarantee than that, e.g that all YANG modules in
WG-adopted IDs MUST have revision dates that reflect the most recent change to
that YANG (*). The key point is that other SDOs (such as BBF!) will often
develop YANG modules that (during the development phase) depend o
Hi -
I read the text as intended to make a distinction between the *date*
portion and the rest
of the revision statement. When a module is under development,
retaining a history
of specific incremental changes isn't terribly helpful, but changing the
date is essential
to helping tools d
Thanks. e.g rather than i.e sounds good, BUT my point (sorry if that wasn’t
clear) is that this sentence seems to be contradictory. It says:
Unpublished versions, i.e IDs, can reuse revision statements.
IDs MUST update their revision dates each time they are re-posted.
My suggestion of removing t
I think the issue is at the end of the sentence, my proposal:
- the Internet-Draft is re-posted.
+ the work is published (e.g., it becomes an RFC).
That said, for IETF drafts (not other SDOs), my understanding is that the
revision statement’s date value SHOULD be the date that the I-D i
Hi -
The situation with Internet-Drafts is what motivated this text in the
first place, so
I think it is important to retain that information. However, it seems
to me that
the "i.e." is too limiting, and should be replaced with an "e.g.".
Randy
On 8/11/2016 2:06 AM, William Lupton wrote:
A
All,
The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems unclear:
"It is acceptable to reuse the same revision statement within unpublished
versions (i.e., Internet-Drafts), but the revision date MUST be updated to a
higher value each time the Internet-Draft is re-posted”
Assumi
27 matches
Mail list logo
