Re: [netmod] clarification of default values in leaf-list

[Ladislav Lhotka]

> On 17 Aug 2016, at 05:29, Andy Bierman  wrote:
> 
> 
> 
> On Tue, Aug 16, 2016 at 8:25 AM, Ladislav Lhotka  wrote:
> 
> > On 16 Aug 2016, at 14:54, Radek Krejčí  wrote:
> >
> > Dne 16.8.2016 v 14:36 Martin Bjorklund napsal(a):
> >> Radek Krejčí  wrote:
> >>> Hi all,
> >>> I'm not sure what is actually the default value in leaf-list if there
> >>> are multiple default statements.  Is it each of the values defined as
> >>> default or the set of default values together? My point is, in case of
> >>> NETCONF with-defaults capability, when the leaf-list instance is
> >>> supposed to be marked as default (report-all-tagged retrieval mode) -
> >>> when it contains one of the values defined as default or only when
> >>> there is a complete set of default values (and in case of user-ordered
> >>> leaf-list, when they are in correct order)?
> >>
> >> 6020bis says:
> >>
> >>  If a leaf-list has one or more "default" statement, the leaf-list's
> >>  default values are the values of the "default" statements, and if the
> >>  leaf-list is user-ordered, the default values are used in the order of
> >>  the "default" statements.
> >>
> >> Doesn't this answer your questions?
> >
> > no, it doesn't - the "leaf-list's default values are" indicates that there 
> > can be multiple default values for the leaf-list. So each of the default 
> > statement defines one of the leaf-list's default values. But the second 
> > part refers to the default values to be used together, as a set. I think 
> > that it makes better sense to use the leaf-list's default value as a set, 
> > but that first sentence confuses me.
> 
> leaf-list foo {
> type string;
> default "zig";
> default "zag";
> }
> 
> The default content is the sequence of values taken from all "default" 
> statements, i.e. in JSON encoding it is
> 
> "foo": ["zig", "zag"]
> 
> 
> Or the server could return ["zag", "zig"] because this is an ordered-by 
> system leaf-list.

Yes.

> 
> Let's say the client sets foo to the value "zag".
> If the server basic-mode=explicit, then foo = [ "zag" ] and foo is not a 
> default.
> But if the basic-mode=trim, then there was no node created, so foo is still
> a default ["zig", "zag"].
> 
> Is this correct? What matches the YANG default for this node in with-defaults 
> trim mode?

This is not how I understand it - the default value should be the list en bloc, 
so if the client sets the value to "zag", the default should be always replaced 
by the new value ["zag"], which is different from ["zig", "zag"].

But: when we say "client sets", does the edit operation matter? If it is 
"merge", should the new value be ["zig", "zag"] (= the original default content 
merged with the new value)?

Lada

> 
> 1)
>["zig", "zag"]
> 
> 2)
>["zig"] and ["zag"]
>  
> 
> 
> Andy
> 
> 
> 
> 
> 
>  
> Lada
> 
> >
> > Radek
> >
> >>
> >> /martin
> >
> >
> > ___
> > 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

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




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

Re: [netmod] clarification of default values in leaf-list

[Andy Bierman]

On Tue, Aug 16, 2016 at 8:25 AM, Ladislav Lhotka  wrote:

>
> > On 16 Aug 2016, at 14:54, Radek Krejčí  wrote:
> >
> > Dne 16.8.2016 v 14:36 Martin Bjorklund napsal(a):
> >> Radek Krejčí  wrote:
> >>> Hi all,
> >>> I'm not sure what is actually the default value in leaf-list if there
> >>> are multiple default statements.  Is it each of the values defined as
> >>> default or the set of default values together? My point is, in case of
> >>> NETCONF with-defaults capability, when the leaf-list instance is
> >>> supposed to be marked as default (report-all-tagged retrieval mode) -
> >>> when it contains one of the values defined as default or only when
> >>> there is a complete set of default values (and in case of user-ordered
> >>> leaf-list, when they are in correct order)?
> >>
> >> 6020bis says:
> >>
> >>  If a leaf-list has one or more "default" statement, the leaf-list's
> >>  default values are the values of the "default" statements, and if the
> >>  leaf-list is user-ordered, the default values are used in the order of
> >>  the "default" statements.
> >>
> >> Doesn't this answer your questions?
> >
> > no, it doesn't - the "leaf-list's default values are" indicates that
> there can be multiple default values for the leaf-list. So each of the
> default statement defines one of the leaf-list's default values. But the
> second part refers to the default values to be used together, as a set. I
> think that it makes better sense to use the leaf-list's default value as a
> set, but that first sentence confuses me.
>
> leaf-list foo {
> type string;
> default "zig";
> default "zag";
> }
>
> The default content is the sequence of values taken from all "default"
> statements, i.e. in JSON encoding it is
>
> "foo": ["zig", "zag"]
>
>
Or the server could return ["zag", "zig"] because this is an ordered-by
system leaf-list.

Let's say the client sets foo to the value "zag".
If the server basic-mode=explicit, then foo = [ "zag" ] and foo is not a
default.
But if the basic-mode=trim, then there was no node created, so foo is still
a default ["zig", "zag"].

Is this correct? What matches the YANG default for this node in
with-defaults trim mode?

1)
   ["zig", "zag"]

2)
   ["zig"] and ["zag"]



Andy







> Lada
>
> >
> > Radek
> >
> >>
> >> /martin
> >
> >
> > ___
> > 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
>
___
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.
> 

[netmod] netmod - New Meeting Session Request for IETF 97

["IETF Meeting Session Request Tool"]

A new meeting session request has just been submitted by Lou Berger, a Chair of 
the netmod working group.


-
Working Group Name: NETCONF Data Modeling Language
Area Name: Operations and Management Area
Session Requester: Lou Berger

Number of Sessions: 2
Length of Session(s):  2.5 Hours, 1 Hour
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority: netconf rtgwg 
 Second Priority: i2rs anima isis ospf
 Third Priority: saag


Special Requests:
  
-

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

Re: [netmod] clarification of default values in leaf-list

[Ladislav Lhotka]

> On 16 Aug 2016, at 14:54, Radek Krejčí  wrote:
> 
> Dne 16.8.2016 v 14:36 Martin Bjorklund napsal(a):
>> Radek Krejčí  wrote:
>>> Hi all,
>>> I'm not sure what is actually the default value in leaf-list if there
>>> are multiple default statements.  Is it each of the values defined as
>>> default or the set of default values together? My point is, in case of
>>> NETCONF with-defaults capability, when the leaf-list instance is
>>> supposed to be marked as default (report-all-tagged retrieval mode) -
>>> when it contains one of the values defined as default or only when
>>> there is a complete set of default values (and in case of user-ordered
>>> leaf-list, when they are in correct order)?
>> 
>> 6020bis says:
>> 
>>  If a leaf-list has one or more "default" statement, the leaf-list's
>>  default values are the values of the "default" statements, and if the
>>  leaf-list is user-ordered, the default values are used in the order of
>>  the "default" statements.
>> 
>> Doesn't this answer your questions?
> 
> no, it doesn't - the "leaf-list's default values are" indicates that there 
> can be multiple default values for the leaf-list. So each of the default 
> statement defines one of the leaf-list's default values. But the second part 
> refers to the default values to be used together, as a set. I think that it 
> makes better sense to use the leaf-list's default value as a set, but that 
> first sentence confuses me.

leaf-list foo {
type string;
default "zig";
default "zag";
}

The default content is the sequence of values taken from all "default" 
statements, i.e. in JSON encoding it is

"foo": ["zig", "zag"]

Lada

> 
> Radek
> 
>> 
>> /martin
> 
> 
> ___
> 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] clarification of default values in leaf-list

[Radek Krejčí]

Dne 16.8.2016 v 14:36 Martin Bjorklund napsal(a):
> Radek Krejčí  wrote:
>> Hi all,
>> I'm not sure what is actually the default value in leaf-list if there
>> are multiple default statements.  Is it each of the values defined as
>> default or the set of default values together? My point is, in case of
>> NETCONF with-defaults capability, when the leaf-list instance is
>> supposed to be marked as default (report-all-tagged retrieval mode) -
>> when it contains one of the values defined as default or only when
>> there is a complete set of default values (and in case of user-ordered
>> leaf-list, when they are in correct order)?
>
> 6020bis says:
>
>   If a leaf-list has one or more "default" statement, the leaf-list's
>   default values are the values of the "default" statements, and if the
>   leaf-list is user-ordered, the default values are used in the order of
>   the "default" statements.
>
> Doesn't this answer your questions?

no, it doesn't - the "leaf-list's default values are" indicates that there can 
be multiple default values for the leaf-list. So each of the default statement 
defines one of the leaf-list's default values. But the second part refers to 
the default values to be used together, as a set. I think that it makes better 
sense to use the leaf-list's default value as a set, but that first sentence 
confuses me.

Radek

>
> /martin


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

Re: [netmod] clarification of default values in leaf-list

[Martin Bjorklund]

Radek Krejčí  wrote:
> Hi all,
> I'm not sure what is actually the default value in leaf-list if there
> are multiple default statements.  Is it each of the values defined as
> default or the set of default values together? My point is, in case of
> NETCONF with-defaults capability, when the leaf-list instance is
> supposed to be marked as default (report-all-tagged retrieval mode) -
> when it contains one of the values defined as default or only when
> there is a complete set of default values (and in case of user-ordered
> leaf-list, when they are in correct order)?


6020bis says:

  If a leaf-list has one or more "default" statement, the leaf-list's
  default values are the values of the "default" statements, and if the
  leaf-list is user-ordered, the default values are used in the order of
  the "default" statements.

Doesn't this answer your questions?


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

[netmod] clarification of default values in leaf-list

[Radek Krejčí]

Hi all,
I'm not sure what is actually the default value in leaf-list if there are 
multiple default statements. Is it each of the values defined as default or the 
set of default values together? My point is, in case of NETCONF with-defaults 
capability, when the leaf-list instance is supposed to be marked as default 
(report-all-tagged retrieval mode) - when it contains one of the values defined 
as default or only when there is a complete set of default values (and in case 
of user-ordered leaf-list, when they are in correct order)?

Regards,
Radek Krejci

___
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,

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