Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

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-posted.

—— 

It became clear from the subsequent discussion (thanks Randy!) that the above 
text isn’t intended to mean “reuse the identical revision statement, INCLUDING 
THE REVISION DATE” but to mean “reuse the revision statement, UPDATING THE 
REVISION DATE”.

Then other people raised other points, e.g only updating the revision date if 
the YANG has changed, distinguishing between the document and the YANG 
contained therein, and distinguishing between YANG in IDs and YANG created by 
other SDOs. My proposed new text tries to address all of these:

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. 
However, if the module has changed, the revision date of the most recent 
revision MUST be updated to a later date whenever a new version is made 
available (e.g., via a new version of an Internet-Draft).

——

I believe that this retains the original intent in a way that resolves the 
original ambiguity and addresses the other points that were raised. It it’s 
“worse”, how is it worse (apart from being longer, on which point mea culpa)?

Thanks,
William

> On 19 Aug 2016, at 15:42, Andy Bierman  wrote:
> 
> On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley  > wrote:
> Andy Bierman mailto:a...@yumaworks.com>> 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 risk
> on an unstable document.  The guideline already says MUST update
> the revision date.
> 
> Not sure what more you want to guidelines document to do.
>  
> Dale
> 
> Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Andy Bierman]

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 risk
on an unstable document.  The guideline already says MUST update
the revision date.

Not sure what more you want to guidelines document to do.



> Dale
>


Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Dale R. Worley]

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

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Andy Bierman]

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
> > these other organisations publish any specifications or data models
> > that use such draft IETF YANG, but it might occasionally be necessary
> > to reference a draft model (hopefully one that has already been sent
> > for AD review) in a published standard. This is why I would like the
> > clarification to cover IDs (at least WG-adopted ones)!
>
> Unfortunately, this sort of problem has to be considered.  I remember
> when the "SIP multiple line appearances" draft was being worked on.
> Ultimately, there were products on the market that supported the -03
> version, the -04 version, and the final (RFC) version.
>
> My suggestion is that any time a version of a module is "published", it
> must either be identical to the previous "published" version, or have a
> newer revision date.  As far as I can see, the *practical* meaning of
> "published" is a document that has a permanent URL, because you can't
> convince a customer that a document is a "specification" if it doesn't
> have a stable URL.  For Internet Drafts, that seems to mean each
> numbered version entered into the Data Tracker.
>


The current text says the revision date MUST be updated
if the YANG module changed at all.  Seems clear to me.

I think I will add a reference to RFC 2026, sec. 2.2
to use the term  "published" specification

An Internet-Draft is NOT a means of "publishing" a specification;



Andy



>
> But there is a further problem:  A sequence of versions of a module with
> different revision dates are required to be related by the rules of
> section 11 of RFC 6020 (or draft-ietf-netmod-rfc6020bis), i.e., each
> newer version is a proper extension of the older version(s).  Clearly,
> we *don't* want to have that constraint between versions of modules in a
> sequence of I-Ds, we want to be able to delete elements.
>
> Dale
>
> ___


Andy


> 
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Dale R. Worley]

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
> that use such draft IETF YANG, but it might occasionally be necessary
> to reference a draft model (hopefully one that has already been sent
> for AD review) in a published standard. This is why I would like the
> clarification to cover IDs (at least WG-adopted ones)!

Unfortunately, this sort of problem has to be considered.  I remember
when the "SIP multiple line appearances" draft was being worked on.
Ultimately, there were products on the market that supported the -03
version, the -04 version, and the final (RFC) version.

My suggestion is that any time a version of a module is "published", it
must either be identical to the previous "published" version, or have a
newer revision date.  As far as I can see, the *practical* meaning of
"published" is a document that has a permanent URL, because you can't
convince a customer that a document is a "specification" if it doesn't
have a stable URL.  For Internet Drafts, that seems to mean each
numbered version entered into the Data Tracker.

But there is a further problem:  A sequence of versions of a module with
different revision dates are required to be related by the rules of
section 11 of RFC 6020 (or draft-ietf-netmod-rfc6020bis), i.e., each
newer version is a proper extension of the older version(s).  Clearly,
we *don't* want to have that constraint between versions of modules in a
sequence of I-Ds, we want to be able to delete elements.

Dale

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Andy Bierman]

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 changed.
   The revision date MAY be updated if nothing in the module has changed.



Andy


On Thu, Aug 18, 2016 at 10:26 AM, William Lupton <
wlup...@broadband-forum.org> wrote:

> 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 organisations
> publish any specifications or data models that use such draft IETF YANG,
> but it might occasionally be necessary to reference a draft model
> (hopefully one that has already been sent for AD review) in a published
> standard. This is why I would like the clarification to cover IDs (at least
> WG-adopted ones)!
> —
>
> William
>
> On 18 Aug 2016, at 18:21, Andy Bierman  wrote:
>
> 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 text is worse.
>
> I like the suggestion to define "published" and "unpublished"
> to have the semantics defined in RFC 2026.
>
>
>
> Andy
>
> On Thu, Aug 18, 2016 at 10:08 AM, William Lupton <
> wlup...@broadband-forum.org> wrote:
>
>> 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. However, if the module has changed, the revision date of the
>> most recent revision MUST be updated to a later date whenever a new version
>> is made available (e.g., via a new version of an Internet-Draft).
>>
>> > On 18 Aug 2016, at 13:21, Ladislav Lhotka  wrote:
>> >
>> > 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-Drafts). That is, within a sequence of unpublished
>> versions, only the most recent revision MAY be recorded in the module or
>> submodule. However, the revision date of the most recent revision MUST be
>> updated to a higher value each time a new version (e.g., of the
>> Internet-Draft) is posted.
>> >>
>> >> 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. However, if the module has changed, the
>> >> revision date of the most recent revision MUST be updated to a higher
>> >> value whenever a new version is made available (e.g., via a new
>> >> version of an Internet-Draft).
>> >
>> > I like this text. Perhaps "a higher value" could be replaced with "a
>> > later date"?
>> >
>> > Lada
>> >
>> >>
>> >> ——
>> >>
>> >> The main comments and suggestions on the baseline text were:
>> >> Why say MAY rather than MUST? Suggestion to say “need” to avoid
>> difficulty with “only” and “MAY”.
>> >> Should be more precise re the difference between a draft and a module
>> contained within a draft.
>> >> Should allow or encourage the module revision date to be bumped only
>> if the YANG has changed (or on the containing draft becoming a standard).
>> >> Discussion of “published” / “posted” etc., and their meanings in an
>> IETF context.
>> >> Support for the principle that the text should be both general
>> (applying to all organisations) and specific (applying to IETF) and note
>> that IETF-specific text should be parenthesised.
>> >> Assertion that all publicly-available “adopted” modules (whether draft
>> or standard) must bump revision dates if the YANG changes.
>> >>
>> >> Here are a few notes to forestall some of your possible comments:
>> >> I didn’t mention submodules, because of the generic (Section 2.3) note
>> that “module” means “module or submodule” unless specifically discussing
>> submodules.
>> >> I didn’t mention RFC publication as a special case (revision date MUST
>> be unconditionally updated) because this paragraph is only about drafts. I
>> assume that requirements governing modules in RFCs are already covered
>> elsewhere.
>> >> I hope that I avoided IETF-emotive terms outsi

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

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 organisations 
publish any specifications or data models that use such draft IETF YANG, but it 
might occasionally be necessary to reference a draft model (hopefully one that 
has already been sent for AD review) in a published standard. This is why I 
would like the clarification to cover IDs (at least WG-adopted ones)!
— 

William

> On 18 Aug 2016, at 18:21, Andy Bierman  wrote:
> 
> 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 text is worse.
> 
> I like the suggestion to define "published" and "unpublished"
> to have the semantics defined in RFC 2026.
> 
> 
> 
> Andy
> 
> On Thu, Aug 18, 2016 at 10:08 AM, William Lupton  > wrote:
> 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. 
> However, if the module has changed, the revision date of the most recent 
> revision MUST be updated to a later date whenever a new version is made 
> available (e.g., via a new version of an Internet-Draft).
> 
> > On 18 Aug 2016, at 13:21, Ladislav Lhotka  > > wrote:
> >
> > 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-Drafts). That is, within a sequence of unpublished 
> >> versions, only the most recent revision MAY be recorded in the module or 
> >> submodule. However, the revision date of the most recent revision MUST be 
> >> updated to a higher value each time a new version (e.g., of the 
> >> Internet-Draft) is posted.
> >>
> >> 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. However, if the module has changed, the
> >> revision date of the most recent revision MUST be updated to a higher
> >> value whenever a new version is made available (e.g., via a new
> >> version of an Internet-Draft).
> >
> > I like this text. Perhaps "a higher value" could be replaced with "a
> > later date"?
> >
> > Lada
> >
> >>
> >> ——
> >>
> >> The main comments and suggestions on the baseline text were:
> >> Why say MAY rather than MUST? Suggestion to say “need” to avoid difficulty 
> >> with “only” and “MAY”.
> >> Should be more precise re the difference between a draft and a module 
> >> contained within a draft.
> >> Should allow or encourage the module revision date to be bumped only if 
> >> the YANG has changed (or on the containing draft becoming a standard).
> >> Discussion of “published” / “posted” etc., and their meanings in an IETF 
> >> context.
> >> Support for the principle that the text should be both general (applying 
> >> to all organisations) and specific (applying to IETF) and note that 
> >> IETF-specific text should be parenthesised.
> >> Assertion that all publicly-available “adopted” modules (whether draft or 
> >> standard) must bump revision dates if the YANG changes.
> >>
> >> Here are a few notes to forestall some of your possible comments:
> >> I didn’t mention submodules, because of the generic (Section 2.3) note 
> >> that “module” means “module or submodule” unless specifically discussing 
> >> submodules.
> >> I didn’t mention RFC publication as a special case (revision date MUST be 
> >> unconditionally updated) because this paragraph is only about drafts. I 
> >> assume that requirements governing modules in RFCs are already covered 
> >> elsewhere.
> >> I hope that I avoided IETF-emotive terms outside the parentheses, e.g I 
> >> used the terms “draft” and “made available”.
> >> I nearly added “statement” as in “revision date of the most recent 
> >> revision statement”. I would certainly be happy with that change.
> >> I don’t really like “higher value” because that makes it sounds like a 
> >> numeric value. However, no-one has commented on this and I guess it’s 
> >> unambiguous. So let fido sleep on.
> 

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Andy Bierman]

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 text is worse.

I like the suggestion to define "published" and "unpublished"
to have the semantics defined in RFC 2026.



Andy

On Thu, Aug 18, 2016 at 10:08 AM, William Lupton <
wlup...@broadband-forum.org> wrote:

> 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. However, if the module has changed, the revision date of the
> most recent revision MUST be updated to a later date whenever a new version
> is made available (e.g., via a new version of an Internet-Draft).
>
> > On 18 Aug 2016, at 13:21, Ladislav Lhotka  wrote:
> >
> > 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-Drafts). That is, within a sequence of unpublished
> versions, only the most recent revision MAY be recorded in the module or
> submodule. However, the revision date of the most recent revision MUST be
> updated to a higher value each time a new version (e.g., of the
> Internet-Draft) is posted.
> >>
> >> 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. However, if the module has changed, the
> >> revision date of the most recent revision MUST be updated to a higher
> >> value whenever a new version is made available (e.g., via a new
> >> version of an Internet-Draft).
> >
> > I like this text. Perhaps "a higher value" could be replaced with "a
> > later date"?
> >
> > Lada
> >
> >>
> >> ——
> >>
> >> The main comments and suggestions on the baseline text were:
> >> Why say MAY rather than MUST? Suggestion to say “need” to avoid
> difficulty with “only” and “MAY”.
> >> Should be more precise re the difference between a draft and a module
> contained within a draft.
> >> Should allow or encourage the module revision date to be bumped only if
> the YANG has changed (or on the containing draft becoming a standard).
> >> Discussion of “published” / “posted” etc., and their meanings in an
> IETF context.
> >> Support for the principle that the text should be both general
> (applying to all organisations) and specific (applying to IETF) and note
> that IETF-specific text should be parenthesised.
> >> Assertion that all publicly-available “adopted” modules (whether draft
> or standard) must bump revision dates if the YANG changes.
> >>
> >> Here are a few notes to forestall some of your possible comments:
> >> I didn’t mention submodules, because of the generic (Section 2.3) note
> that “module” means “module or submodule” unless specifically discussing
> submodules.
> >> I didn’t mention RFC publication as a special case (revision date MUST
> be unconditionally updated) because this paragraph is only about drafts. I
> assume that requirements governing modules in RFCs are already covered
> elsewhere.
> >> I hope that I avoided IETF-emotive terms outside the parentheses, e.g I
> used the terms “draft” and “made available”.
> >> I nearly added “statement” as in “revision date of the most recent
> revision statement”. I would certainly be happy with that change.
> >> I don’t really like “higher value” because that makes it sounds like a
> numeric value. However, no-one has commented on this and I guess it’s
> unambiguous. So let fido sleep on.
> >>
> >> Comments?
> >>
> >> Thanks,
> >> William
> >>
> >>> On 16 Aug 2016, at 19:02, Kent Watsen  wrote:
> >>>
> >>> 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 your
> current take on it.
> >>>
> >>> Thanks,
> >>> Kent
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

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. 
However, if the module has changed, the revision date of the most recent 
revision MUST be updated to a later date whenever a new version is made 
available (e.g., via a new version of an Internet-Draft).

> On 18 Aug 2016, at 13:21, Ladislav Lhotka  wrote:
> 
> 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-Drafts). That is, within a sequence of unpublished versions, 
>> only the most recent revision MAY be recorded in the module or submodule. 
>> However, the revision date of the most recent revision MUST be updated to a 
>> higher value each time a new version (e.g., of the Internet-Draft) is posted.
>> 
>> 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. However, if the module has changed, the
>> revision date of the most recent revision MUST be updated to a higher
>> value whenever a new version is made available (e.g., via a new
>> version of an Internet-Draft).
> 
> I like this text. Perhaps "a higher value" could be replaced with "a
> later date"?
> 
> Lada
> 
>> 
>> —— 
>> 
>> The main comments and suggestions on the baseline text were:
>> Why say MAY rather than MUST? Suggestion to say “need” to avoid difficulty 
>> with “only” and “MAY”.
>> Should be more precise re the difference between a draft and a module 
>> contained within a draft.
>> Should allow or encourage the module revision date to be bumped only if the 
>> YANG has changed (or on the containing draft becoming a standard).
>> Discussion of “published” / “posted” etc., and their meanings in an IETF 
>> context.
>> Support for the principle that the text should be both general (applying to 
>> all organisations) and specific (applying to IETF) and note that 
>> IETF-specific text should be parenthesised.
>> Assertion that all publicly-available “adopted” modules (whether draft or 
>> standard) must bump revision dates if the YANG changes.
>> 
>> Here are a few notes to forestall some of your possible comments:
>> I didn’t mention submodules, because of the generic (Section 2.3) note that 
>> “module” means “module or submodule” unless specifically discussing 
>> submodules.
>> I didn’t mention RFC publication as a special case (revision date MUST be 
>> unconditionally updated) because this paragraph is only about drafts. I 
>> assume that requirements governing modules in RFCs are already covered 
>> elsewhere.
>> I hope that I avoided IETF-emotive terms outside the parentheses, e.g I used 
>> the terms “draft” and “made available”.
>> I nearly added “statement” as in “revision date of the most recent revision 
>> statement”. I would certainly be happy with that change.
>> I don’t really like “higher value” because that makes it sounds like a 
>> numeric value. However, no-one has commented on this and I guess it’s 
>> unambiguous. So let fido sleep on.
>> 
>> Comments?
>> 
>> Thanks,
>> William
>> 
>>> On 16 Aug 2016, at 19:02, Kent Watsen  wrote:
>>> 
>>> 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 your 
>>> current take on it.
>>> 
>>> Thanks,
>>> Kent
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Ladislav Lhotka]

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-Drafts). That is, within a sequence of unpublished versions, 
> only the most recent revision MAY be recorded in the module or submodule. 
> However, the revision date of the most recent revision MUST be updated to a 
> higher value each time a new version (e.g., of the Internet-Draft) is posted.
>
> 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. However, if the module has changed, the
> revision date of the most recent revision MUST be updated to a higher
> value whenever a new version is made available (e.g., via a new
> version of an Internet-Draft).

I like this text. Perhaps "a higher value" could be replaced with "a
later date"?

Lada

>
> —— 
>
> The main comments and suggestions on the baseline text were:
> Why say MAY rather than MUST? Suggestion to say “need” to avoid difficulty 
> with “only” and “MAY”.
> Should be more precise re the difference between a draft and a module 
> contained within a draft.
> Should allow or encourage the module revision date to be bumped only if the 
> YANG has changed (or on the containing draft becoming a standard).
> Discussion of “published” / “posted” etc., and their meanings in an IETF 
> context.
> Support for the principle that the text should be both general (applying to 
> all organisations) and specific (applying to IETF) and note that 
> IETF-specific text should be parenthesised.
> Assertion that all publicly-available “adopted” modules (whether draft or 
> standard) must bump revision dates if the YANG changes.
>
> Here are a few notes to forestall some of your possible comments:
> I didn’t mention submodules, because of the generic (Section 2.3) note that 
> “module” means “module or submodule” unless specifically discussing 
> submodules.
> I didn’t mention RFC publication as a special case (revision date MUST be 
> unconditionally updated) because this paragraph is only about drafts. I 
> assume that requirements governing modules in RFCs are already covered 
> elsewhere.
> I hope that I avoided IETF-emotive terms outside the parentheses, e.g I used 
> the terms “draft” and “made available”.
> I nearly added “statement” as in “revision date of the most recent revision 
> statement”. I would certainly be happy with that change.
> I don’t really like “higher value” because that makes it sounds like a 
> numeric value. However, no-one has commented on this and I guess it’s 
> unambiguous. So let fido sleep on.
>
> Comments?
>
> Thanks,
> William
>
>> On 16 Aug 2016, at 19:02, Kent Watsen  wrote:
>> 
>> 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 your 
>> current take on it.
>> 
>> Thanks,
>> Kent
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

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 unpublished versions, only the 
most recent revision MAY be recorded in the module or submodule. However, the 
revision date of the most recent revision MUST be updated to a higher value 
each time a new version (e.g., of the Internet-Draft) is posted.

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. 
However, if the module has changed, the revision date of the most recent 
revision MUST be updated to a higher value whenever a new version is made 
available (e.g., via a new version of an Internet-Draft).

—— 

The main comments and suggestions on the baseline text were:
Why say MAY rather than MUST? Suggestion to say “need” to avoid difficulty with 
“only” and “MAY”.
Should be more precise re the difference between a draft and a module contained 
within a draft.
Should allow or encourage the module revision date to be bumped only if the 
YANG has changed (or on the containing draft becoming a standard).
Discussion of “published” / “posted” etc., and their meanings in an IETF 
context.
Support for the principle that the text should be both general (applying to all 
organisations) and specific (applying to IETF) and note that IETF-specific text 
should be parenthesised.
Assertion that all publicly-available “adopted” modules (whether draft or 
standard) must bump revision dates if the YANG changes.

Here are a few notes to forestall some of your possible comments:
I didn’t mention submodules, because of the generic (Section 2.3) note that 
“module” means “module or submodule” unless specifically discussing submodules.
I didn’t mention RFC publication as a special case (revision date MUST be 
unconditionally updated) because this paragraph is only about drafts. I assume 
that requirements governing modules in RFCs are already covered elsewhere.
I hope that I avoided IETF-emotive terms outside the parentheses, e.g I used 
the terms “draft” and “made available”.
I nearly added “statement” as in “revision date of the most recent revision 
statement”. I would certainly be happy with that change.
I don’t really like “higher value” because that makes it sounds like a numeric 
value. However, no-one has commented on this and I guess it’s unambiguous. So 
let fido sleep on.

Comments?

Thanks,
William

> On 16 Aug 2016, at 19:02, Kent Watsen  wrote:
> 
> 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 your current take on 
> it.
> 
> Thanks,
> Kent
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Kent Watsen]

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 your current take on 
it.

Thanks,
Kent


On 8/16/16, 7:57 AM, "William Lupton"  wrote:

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 was hoping 
for!

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 that use such draft IETF YANG, but it 
might occasionally be necessary to reference a draft model (hopefully one that 
has already been sent for AD review) in a published standard. This is why I 
would like the clarification to cover IDs (at least WG-adopted ones)!

Thanks,
William

> On 15 Aug 2016, at 20:40, Kent Watsen  wrote:
> 
> 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 
to something like “works in progress”.
> 
> 3. Instead of saying “when a new version (of the I-D) is posted”, it 
would be clearer to say “when a new version is posted (e.g., it becomes an 
RFC)”.
> 
> Kent  // as a contributor
> 
> 
> 
> 
> On 8/15/16, 3:17 PM, "netmod on behalf of Randy Presuhn" 
 wrote:
> 
>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 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 versions (i.e., Internet-Drafts), but the revision date MUST be 
updated to a higher value each time the Internet-Draft is re-posted.
>>> 
>>> NEW:
>>> 
>>> It is acceptable to reuse the same revision statement within 
unpublished versions (e.g., Internet-Drafts), but the revision date (i.e., the 
revision statement’s argument) MUST be updated to a higher value each time a 
new version (e.g., of the Internet-Draft) is posted.
>> It seems strange to talk about reusing the revision statement and, in 
the same sentence, require to change its argument. What about this:
>> 
>> NEW
>> 
>> It is not required to keep the revision history of unpublished versions 
(e.g., Internet-Drafts). That is, within a sequence of unpublished versions, 
only the most recent revision MAY be recorded in the module or submodule. 
However, the revision date of the most recent revision MUST be updated to a 
higher value each time a new version (e.g., of the Internet-Draft) is posted.
>> 
>> Lada
>> 
>>> ——
>>> 
>>> Comments?
>>> 
 On 11 Aug 2016, at 17:26, Randy Presuhn 
 wrote:
 
 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 decide among the versions floating around in the lab.
 
 
 Randy (experimenting with mail readers, please forgive formatting 
anomalies)
 
 
 On 8/11/2016 9:17 AM, William Lupton wrote:
> 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:
> 
> 1. Unpublished versions, i.e IDs, can reuse revision statements.
> 2. IDs MUST update their revision dates each time they are re-posted.
> 
> My suggestion of removing the parenthesised text was to remove this 
contradiction. Right now I’m not clear that I can rely on revision dates in 
YANG modules contained within IDs.
> 

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

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 was hoping for!

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 that use such draft IETF YANG, but it 
might occasionally be necessary to reference a draft model (hopefully one that 
has already been sent for AD review) in a published standard. This is why I 
would like the clarification to cover IDs (at least WG-adopted ones)!

Thanks,
William

> On 15 Aug 2016, at 20:40, Kent Watsen  wrote:
> 
> 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 to something like “works in progress”.
> 
> 3. Instead of saying “when a new version (of the I-D) is posted”, it would be 
> clearer to say “when a new version is posted (e.g., it becomes an RFC)”.
> 
> Kent  // as a contributor
> 
> 
> 
> 
> On 8/15/16, 3:17 PM, "netmod on behalf of Randy Presuhn" 
>  
> wrote:
> 
>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 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 
>>> versions (i.e., Internet-Drafts), but the revision date MUST be updated to 
>>> a higher value each time the Internet-Draft is re-posted.
>>> 
>>> NEW:
>>> 
>>> It is acceptable to reuse the same revision statement within unpublished 
>>> versions (e.g., Internet-Drafts), but the revision date (i.e., the revision 
>>> statement’s argument) MUST be updated to a higher value each time a new 
>>> version (e.g., of the Internet-Draft) is posted.
>> It seems strange to talk about reusing the revision statement and, in the 
>> same sentence, require to change its argument. What about this:
>> 
>> NEW
>> 
>> It is not required to keep the revision history of unpublished versions 
>> (e.g., Internet-Drafts). That is, within a sequence of unpublished versions, 
>> only the most recent revision MAY be recorded in the module or submodule. 
>> However, the revision date of the most recent revision MUST be updated to a 
>> higher value each time a new version (e.g., of the Internet-Draft) is posted.
>> 
>> Lada
>> 
>>> ——
>>> 
>>> Comments?
>>> 
 On 11 Aug 2016, at 17:26, Randy Presuhn 
  wrote:
 
 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 decide among the versions floating around in the lab.
 
 
 Randy (experimenting with mail readers, please forgive formatting 
 anomalies)
 
 
 On 8/11/2016 9:17 AM, William Lupton wrote:
> 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:
> 
> 1. Unpublished versions, i.e IDs, can reuse revision statements.
> 2. IDs MUST update their revision dates each time they are re-posted.
> 
> My suggestion of removing the parenthesised text was to remove this 
> contradiction. Right now I’m not clear that I can rely on revision dates 
> in YANG modules contained within IDs.
> 
> William
> 
> PS, I think that the removal of this text removes the contradiction 
> because in order to make sense of the sentence the reader will be forced 
> to the conclusion that IDs are not regarded as being “unpublished”.
> 
>> On 11 Aug 2016, at 17:07, Randy Presuhn 
>> > > wrote:
>> 
>> 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 li

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Juergen Schoenwaelder]

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, regardless their familiarity with 
> IETF process.   I like that we’ve moved IETF-specific text into parentheses, 
> and hence hoping to avoid any IETF-loaded words outside parentheses where 
> possible.
>

Whatever the wording is, I believe there is a fundamental difference
between someone simply making something available and something that
becomes accessible (persistently) after having gone through a review
and quality ensurance process.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Kent Watsen]

>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 IETF-specific text into parentheses, and 
hence hoping to avoid any IETF-loaded words outside parentheses where possible.

Kent
 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Juergen Schoenwaelder]

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 these days but RFC 2026 makes a
clear distinction between 'publish' and 'made available'. See section
2.2 for more details. Uploading a document to a server really is not
the same as publishing in the traditional sense (and clearly not for
people with an academic background).

Yes, uploading some text to a server makes the text publicly
accessible (make avaliable in RFC 2016 terms) but there is a big
difference between a formally published document in a certain series
that exercises some sort of quality control according to the rules of
the series and simply making something public.

Perhaps we should make it clear that 'publish' is meant in the
traditional RFC 2026 sense.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Kent Watsen]

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 
to something like “works in progress”.

3. Instead of saying “when a new version (of the I-D) is posted”, it would be 
clearer to say “when a new version is posted (e.g., it becomes an RFC)”.

Kent  // as a contributor




On 8/15/16, 3:17 PM, "netmod on behalf of Randy Presuhn" 
 wrote:

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 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 
versions (i.e., Internet-Drafts), but the revision date MUST be updated to a 
higher value each time the Internet-Draft is re-posted.
>>
>> NEW:
>>
>> It is acceptable to reuse the same revision statement within unpublished 
versions (e.g., Internet-Drafts), but the revision date (i.e., the revision 
statement’s argument) MUST be updated to a higher value each time a new version 
(e.g., of the Internet-Draft) is posted.
> It seems strange to talk about reusing the revision statement and, in the 
same sentence, require to change its argument. What about this:
>
> NEW
>
> It is not required to keep the revision history of unpublished versions 
(e.g., Internet-Drafts). That is, within a sequence of unpublished versions, 
only the most recent revision MAY be recorded in the module or submodule. 
However, the revision date of the most recent revision MUST be updated to a 
higher value each time a new version (e.g., of the Internet-Draft) is posted.
>
> Lada
>
>> ——
>>
>> Comments?
>>
>>> On 11 Aug 2016, at 17:26, Randy Presuhn 
 wrote:
>>>
>>> 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 decide among the versions floating around in the lab.
>>>
>>>
>>> Randy (experimenting with mail readers, please forgive formatting 
anomalies)
>>>
>>>
>>> On 8/11/2016 9:17 AM, William Lupton wrote:
 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:

 1. Unpublished versions, i.e IDs, can reuse revision statements.
 2. IDs MUST update their revision dates each time they are re-posted.

 My suggestion of removing the parenthesised text was to remove this 
contradiction. Right now I’m not clear that I can rely on revision dates in 
YANG modules contained within IDs.

 William

 PS, I think that the removal of this text removes the contradiction 
because in order to make sense of the sentence the reader will be forced to the 
conclusion that IDs are not regarded as being “unpublished”.

> On 11 Aug 2016, at 17:07, Randy Presuhn 
mailto:randy_pres...@alumni.stanford.edu>> 
wrote:
>
> 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:
>> 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”
>>
>> Assuming that the intent is that the revision statements in YANG 
models contained within IDs must be updated whenever the models are updated,  
wouldn’t it be clearer if the parenthesised text "(i.e., Internet-Drafts)” was 
deleted?
>>
>> Thanks,
>> William
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/net

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Randy Presuhn]

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 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 
versions (i.e., Internet-Drafts), but the revision date MUST be updated to a 
higher value each time the Internet-Draft is re-posted.

NEW:

It is acceptable to reuse the same revision statement within unpublished 
versions (e.g., Internet-Drafts), but the revision date (i.e., the revision 
statement’s argument) MUST be updated to a higher value each time a new version 
(e.g., of the Internet-Draft) is posted.

It seems strange to talk about reusing the revision statement and, in the same 
sentence, require to change its argument. What about this:

NEW

It is not required to keep the revision history of unpublished versions (e.g., 
Internet-Drafts). That is, within a sequence of unpublished versions, only the 
most recent revision MAY be recorded in the module or submodule. However, the 
revision date of the most recent revision MUST be updated to a higher value 
each time a new version (e.g., of the Internet-Draft) is posted.

Lada


——

Comments?


On 11 Aug 2016, at 17:26, Randy Presuhn  
wrote:

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 decide among the versions floating around in the lab.


Randy (experimenting with mail readers, please forgive formatting anomalies)


On 8/11/2016 9:17 AM, William Lupton wrote:

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:

1. Unpublished versions, i.e IDs, can reuse revision statements.
2. IDs MUST update their revision dates each time they are re-posted.

My suggestion of removing the parenthesised text was to remove this 
contradiction. Right now I’m not clear that I can rely on revision dates in 
YANG modules contained within IDs.

William

PS, I think that the removal of this text removes the contradiction because in 
order to make sense of the sentence the reader will be forced to the conclusion 
that IDs are not regarded as being “unpublished”.


On 11 Aug 2016, at 17:07, Randy Presuhn mailto:randy_pres...@alumni.stanford.edu>> wrote:

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:

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”

Assuming that the intent is that the revision statements in YANG models contained 
within IDs must be updated whenever the models are updated,  wouldn’t it be clearer 
if the parenthesised text "(i.e., Internet-Drafts)” was deleted?

Thanks,
William

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C







---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Randy Presuhn]

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 meaning.

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-posted.

NEW:

It is acceptable to reuse the same revision statement within unpublished 
versions (e.g., Internet-Drafts), but the revision date (i.e., the revision 
statement’s argument) MUST be updated to a higher value each time a new version 
(e.g., of the Internet-Draft) is posted.

——

Comments?


On 11 Aug 2016, at 17:26, Randy Presuhn  
wrote:

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 decide among the versions floating around in the lab.


Randy (experimenting with mail readers, please forgive formatting anomalies)


On 8/11/2016 9:17 AM, William Lupton wrote:

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:

1. Unpublished versions, i.e IDs, can reuse revision statements.
2. IDs MUST update their revision dates each time they are re-posted.

My suggestion of removing the parenthesised text was to remove this 
contradiction. Right now I’m not clear that I can rely on revision dates in 
YANG modules contained within IDs.

William

PS, I think that the removal of this text removes the contradiction because in 
order to make sense of the sentence the reader will be forced to the conclusion 
that IDs are not regarded as being “unpublished”.


On 11 Aug 2016, at 17:07, Randy Presuhn mailto:randy_pres...@alumni.stanford.edu>> wrote:

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:

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”

Assuming that the intent is that the revision statements in YANG models contained 
within IDs must be updated whenever the models are updated,  wouldn’t it be clearer 
if the parenthesised text "(i.e., Internet-Drafts)” was deleted?

Thanks,
William



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Ladislav Lhotka]

> 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 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.
> 
> NEW:
> 
> It is acceptable to reuse the same revision statement within unpublished 
> versions (e.g., Internet-Drafts), but the revision date (i.e., the revision 
> statement’s argument) MUST be updated to a higher value each time a new 
> version (e.g., of the Internet-Draft) is posted.

It seems strange to talk about reusing the revision statement and, in the same 
sentence, require to change its argument. What about this:

NEW

It is not required to keep the revision history of unpublished versions (e.g., 
Internet-Drafts). That is, within a sequence of unpublished versions, only the 
most recent revision MAY be recorded in the module or submodule. However, the 
revision date of the most recent revision MUST be updated to a higher value 
each time a new version (e.g., of the Internet-Draft) is posted.

Lada

> 
> ——
> 
> Comments?
> 
>> On 11 Aug 2016, at 17:26, Randy Presuhn  
>> wrote:
>> 
>> 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 decide among the versions floating around in the lab.
>> 
>> 
>> Randy (experimenting with mail readers, please forgive formatting anomalies)
>> 
>> 
>> On 8/11/2016 9:17 AM, William Lupton wrote:
>>> 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:
>>> 
>>> 1. Unpublished versions, i.e IDs, can reuse revision statements.
>>> 2. IDs MUST update their revision dates each time they are re-posted.
>>> 
>>> My suggestion of removing the parenthesised text was to remove this 
>>> contradiction. Right now I’m not clear that I can rely on revision dates in 
>>> YANG modules contained within IDs.
>>> 
>>> William
>>> 
>>> PS, I think that the removal of this text removes the contradiction because 
>>> in order to make sense of the sentence the reader will be forced to the 
>>> conclusion that IDs are not regarded as being “unpublished”.
>>> 
 On 11 Aug 2016, at 17:07, Randy Presuhn >>> > wrote:
 
 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:
> 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”
> 
> Assuming that the intent is that the revision statements in YANG models 
> contained within IDs must be updated whenever the models are updated,  
> wouldn’t it be clearer if the parenthesised text "(i.e., 
> Internet-Drafts)” was deleted?
> 
> Thanks,
> William
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

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 
versions (i.e., Internet-Drafts), but the revision date MUST be updated to a 
higher value each time the Internet-Draft is re-posted.

NEW:

It is acceptable to reuse the same revision statement within unpublished 
versions (e.g., Internet-Drafts), but the revision date (i.e., the revision 
statement’s argument) MUST be updated to a higher value each time a new version 
(e.g., of the Internet-Draft) is posted.

——

Comments?

> On 11 Aug 2016, at 17:26, Randy Presuhn  
> wrote:
> 
> 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 decide among the versions floating around in the lab.
> 
> 
> Randy (experimenting with mail readers, please forgive formatting anomalies)
> 
> 
> On 8/11/2016 9:17 AM, William Lupton wrote:
>> 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:
>> 
>> 1. Unpublished versions, i.e IDs, can reuse revision statements.
>> 2. IDs MUST update their revision dates each time they are re-posted.
>> 
>> My suggestion of removing the parenthesised text was to remove this 
>> contradiction. Right now I’m not clear that I can rely on revision dates in 
>> YANG modules contained within IDs.
>> 
>> William
>> 
>> PS, I think that the removal of this text removes the contradiction because 
>> in order to make sense of the sentence the reader will be forced to the 
>> conclusion that IDs are not regarded as being “unpublished”.
>> 
>>> On 11 Aug 2016, at 17:07, Randy Presuhn >> > wrote:
>>> 
>>> 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:
 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”
 
 Assuming that the intent is that the revision statements in YANG models 
 contained within IDs must be updated whenever the models are updated,  
 wouldn’t it be clearer if the parenthesised text "(i.e., Internet-Drafts)” 
 was deleted?
 
 Thanks,
 William

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

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 on YANG modules 
from IDs, so it’s important to be able to rely on their revision dates.

(*) Or the ID publication date if you prefer, but 6087bis already says “The 
revision date does not need to be updated if the module contents do not change 
in the new document revision”. Is this intended to apply to IDs?

> On 11 Aug 2016, at 17:18, Kent Watsen  wrote:
> 
> 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 is uploaded 
> to IETF datatracker.  All my drafts are built using a Makefile that includes 
> `sed` processing instructions to set the YANG module dates to the current 
> date - and they include RFC-Editor instructions to reset the value again to 
> the date the RFC is published.
> 
> Kent   // as a contributor
> 
> 
> On 8/11/16, 5:06 AM, "netmod on behalf of William Lupton" 
>  wrote:
> 
>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”
> 
>Assuming that the intent is that the revision statements in YANG models 
> contained within IDs must be updated whenever the models are updated,  
> wouldn’t it be clearer if the parenthesised text "(i.e., Internet-Drafts)” 
> was deleted?
> 
>Thanks,
>William
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Randy Presuhn]

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 decide among the versions floating around in the lab.


Randy (experimenting with mail readers, please forgive formatting anomalies)


On 8/11/2016 9:17 AM, William Lupton wrote:
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:


 1. Unpublished versions, i.e IDs, can reuse revision statements.
 2. IDs MUST update their revision dates each time they are re-posted.


My suggestion of removing the parenthesised text was to remove this 
contradiction. Right now I’m not clear that I can rely on revision 
dates in YANG modules contained within IDs.


William

PS, I think that the removal of this text removes the contradiction 
because in order to make sense of the sentence the reader will be 
forced to the conclusion that IDs are not regarded as being “unpublished”.


On 11 Aug 2016, at 17:07, Randy Presuhn 
> wrote:


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:

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”


Assuming that the intent is that the revision statements in YANG 
models contained within IDs must be updated whenever the models are 
updated,  wouldn’t it be clearer if the parenthesised text "(i.e., 
Internet-Drafts)” was deleted?


Thanks,
William
___
netmod mailing list
netmod@ietf.org 
https://www.ietf.org/mailman/listinfo/netmod



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod





---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

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 the parenthesised text was to remove this 
contradiction. Right now I’m not clear that I can rely on revision dates in 
YANG modules contained within IDs.

William

PS, I think that the removal of this text removes the contradiction because in 
order to make sense of the sentence the reader will be forced to the conclusion 
that IDs are not regarded as being “unpublished”.

> On 11 Aug 2016, at 17:07, Randy Presuhn  
> wrote:
> 
> 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:
>> 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”
>> 
>> Assuming that the intent is that the revision statements in YANG models 
>> contained within IDs must be updated whenever the models are updated,  
>> wouldn’t it be clearer if the parenthesised text "(i.e., Internet-Drafts)” 
>> was deleted?
>> 
>> Thanks,
>> William
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Kent Watsen]

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 is uploaded to 
IETF datatracker.  All my drafts are built using a Makefile that includes `sed` 
processing instructions to set the YANG module dates to the current date - and 
they include RFC-Editor instructions to reset the value again to the date the 
RFC is published.

Kent   // as a contributor


On 8/11/16, 5:06 AM, "netmod on behalf of William Lupton" 
 wrote:

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”

Assuming that the intent is that the revision statements in YANG models 
contained within IDs must be updated whenever the models are updated,  wouldn’t 
it be clearer if the parenthesised text "(i.e., Internet-Drafts)” was deleted?

Thanks,
William
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Randy Presuhn]

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:

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”

Assuming that the intent is that the revision statements in YANG models contained 
within IDs must be updated whenever the models are updated,  wouldn’t it be clearer 
if the parenthesised text "(i.e., Internet-Drafts)” was deleted?

Thanks,
William
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

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”

Assuming that the intent is that the revision statements in YANG models 
contained within IDs must be updated whenever the models are updated,  wouldn’t 
it be clearer if the parenthesised text "(i.e., Internet-Drafts)” was deleted?

Thanks,
William
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod