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" <wlup...@broadband-forum.org> 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 <kwat...@juniper.net> 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"
<netmod-boun...@ietf.org on behalf of randy_pres...@alumni.stanford.edu> 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 <wlup...@broadband-forum.org>
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
<randy_pres...@alumni.stanford.edu> 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
<randy_pres...@alumni.stanford.edu <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
>
>
> _______________________________________________
> 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
