[netmod] Can a derived type of instance-identifier change the require-instance property?

[Fengchong (frank)]

Hi all and martin,

If I have defined a typedef a
typedef a {
  type instance-identifier {
  require-instance false;
  }
}

And then I define another typedef b

typedef b {
  type a {
require-instance true;
  }

}

Is it correct?

The same scenario is leafref.
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!

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

Re: [netmod] Must offline-validation of alone be valid?

[Jürgen Schönwälder]

On Tue, Dec 14, 2021 at 07:43:47PM +, Kent Watsen wrote:
> 
> 
> >> Right, and in both cases, the idea was that  contains all
> >> data needed for the transformation into .  So a client that
> >> wants to do "offline" validation would need the data + the
> >> transformation algorithms.  But no additional data.
> >> 
> > 
> > Having to know proprietary transformation algorithms really kills the
> > idea of interoperable offline validation. It does not really get any
> > worse if transformation algorithms merge in additional definitions.
> 
> 
> Of the three transform algs under discussion (pruning inactive, merging 
> system, and expanding templates), only the last may be proprietary and, even 
> then, nothing is stopping IETF from standardizing one or a few well known 
> templating mechanisms.
>

I doubt that existing implementations will converge to a standard
solution (which will take years to define); it seems the window of
opportunity for standards in this space is closed.

/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] Must offline-validation of alone be valid?

[Kent Watsen]

>> Right, and in both cases, the idea was that  contains all
>> data needed for the transformation into .  So a client that
>> wants to do "offline" validation would need the data + the
>> transformation algorithms.  But no additional data.
>> 
> 
> Having to know proprietary transformation algorithms really kills the
> idea of interoperable offline validation. It does not really get any
> worse if transformation algorithms merge in additional definitions.


Of the three transform algs under discussion (pruning inactive, merging system, 
and expanding templates), only the last may be proprietary and, even then, 
nothing is stopping IETF from standardizing one or a few well known templating 
mechanisms.

K.

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

Re: [netmod] Must offline-validation of alone be valid?

[Jan Lindblad]

Kent, all,

>>> It is also notable that RFC 8341 say nothing about the fact that clients 
>>> effected by NACM may not be able to pass validation (it’s not even 
>>> mentioned).
>> 
>> That a client with insufficient privileges may have trouble understanding or 
>> controlling a server is no surprise to me. I don't quite see why you think 
>> this observation is relevant for the discussion about whether a datastore is 
>> valid or not?
> 
> It’s related to if offline validation can succeed or not.  Effectively, all 
> but the "recovery session” clients will not be able to offline-validate an 
> update to  prior to pushing config to the server.

I'm not sure why you say so. In my field experience, NACM is seldom, if ever, 
an issue for validation. Clients may have a full or partial view of the server, 
but even when partial, I can't recall seeing a case where that subset has been 
broken from a validity standpoint. Whoever is responsible for the deployment 
makes sure the client sees what it needs to see, and that that in itself is a 
consistent, valid (subset of) running.

>  That RFC 8341 doesn’t even mention this fact suggests that “validation” is a 
> concept that only manifests in servers.  Just pointing to evidence of 
> precedence is all.

I disagree :-) I don't think this is something we have agreed, and I don't see 
the point with this stance. In what way is the world a better place if we take 
this "suggestion" seriously?

> Of course, I strongly support client-validation prior to push.  My 
> recommendation is that clients, when interacting with an NMDA-server, learn 
> how to “cook”  and validate that instead of just .

Great. While it sounds very nice to be able to validate both running and 
intended properly, establishing agreement on one particular industry wide 
recipe for how to cook running into intended sounds hard, and at the very least 
some way off. Even if we would agree on the cooking, I still think running 
needs to remain valid(*). Running is the interface that clients can interact 
with, and they should have a clear definition of what the contract looks like 
without spending an hour in the kitchen.

*) Validity, as defined today, concerns running. It does not involve resolving 
templates etc. While intended should also be validated, as mentioned in 8342, 
there are no clear rules for how that validation should happen. Clearly it 
would be possible for a client to come up with a config that is valid in 
running, but gibberish in intended. The server is, already today, free to 
reject such a config. That this final part of the validation cannot happen in 
running is no argument for not validating running, and allowing running to 
violate the YANG constraints defined for it.

> The question is what to do about legacy clients?  
> 
> First, we need to discuss what an “aware” (i.e., not “legacy”) client is.  It 
> seems that “awareness" would have to be more than just understanding that 
>  exists; the client would also have to understand each “cooking” 
> step (pruning inactive nodes, expanding templates, merging system nodes, 
> etc.) the server supports.  There would need to be a client- compatibility 
> check such that, if the client doesn’t understand all of the steps, then it 
> must NOT proceed (aside: this reminds me of the “critical” extension that 
> Lada and I discussed before).  Actually, we might consider reversing the 
> handshake and instead have the client present to the server a list of all the 
> “critical” things it understands and for the server to effectively drop the 
> client if it’s missing anything, since clients cannot predict what new 
> critical things may arise, there could be no false-positives.  Warning, we’re 
> deep into NETCONF-next and RESTCONF-next territory here.

Yes, if we agree to let legacy clients and servers behave as specified in the 
RFCs, we could come up with very creative things for "aware" systems. Some of 
that might be in *-next territory, but much of it could also happen today, as 
long as we have mutual consent from the participants.

> It might turn out that the server, once upgraded to support “next” stuff, can 
> ONLY interact with next-clients.  If so, there would be never be a mix of 
> legacy and not-legacy clients, and thus this entire hybrid-client 
> compatibility concern disappears.

Even if I think the industry usually goes for evolution rather than revolution, 
I'm fine with that. As long as we get some value return for the work, and it 
doesn't break what's out there already, it's worth discussing.

/jan

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

Re: [netmod] Must offline-validation of alone be valid?

[Jürgen Schönwälder]

On Tue, Dec 14, 2021 at 01:14:17PM +0100, Martin Björklund wrote:
> 
> Right, and in both cases, the idea was that  contains all
> data needed for the transformation into .  So a client that
> wants to do "offline" validation would need the data + the
> transformation algorithms.  But no additional data.
>

Having to know proprietary transformation algorithms really kills the
idea of interoperable offline validation. It does not really get any
worse if transformation algorithms merge in additional definitions.

/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] Must offline-validation of alone be valid?

[Kent Watsen]

Hi Jan,

>> It is also notable that RFC 8341 say nothing about the fact that clients 
>> effected by NACM may not be able to pass validation (it’s not even 
>> mentioned).
> 
> That a client with insufficient privileges may have trouble understanding or 
> controlling a server is no surprise to me. I don't quite see why you think 
> this observation is relevant for the discussion about whether a datastore is 
> valid or not?

It’s related to if offline validation can succeed or not.  Effectively, all but 
the "recovery session” clients will not be able to offline-validate an update 
to  prior to pushing config to the server.  That RFC 8341 doesn’t even 
mention this fact suggests that “validation” is a concept that only manifests 
in servers.  Just pointing to evidence of precedence is all.

Of course, I strongly support client-validation prior to push.  My 
recommendation is that clients, when interacting with an NMDA-server, learn how 
to “cook”  and validate that instead of just .

The question is what to do about legacy clients?  

First, we need to discuss what an “aware” (i.e., not “legacy”) client is.  It 
seems that “awareness" would have to be more than just understanding that 
 exists; the client would also have to understand each “cooking” step 
(pruning inactive nodes, expanding templates, merging system nodes, etc.) the 
server supports.  There would need to be a client- compatibility check such 
that, if the client doesn’t understand all of the steps, then it must NOT 
proceed (aside: this reminds me of the “critical” extension that Lada and I 
discussed before).  Actually, we might consider reversing the handshake and 
instead have the client present to the server a list of all the “critical” 
things it understands and for the server to effectively drop the client if it’s 
missing anything, since clients cannot predict what new critical things may 
arise, there could be no false-positives.  Warning, we’re deep into 
NETCONF-next and RESTCONF-next territory here.

It might turn out that the server, once upgraded to support “next” stuff, can 
ONLY interact with next-clients.  If so, there would be never be a mix of 
legacy and not-legacy clients, and thus this entire hybrid-client compatibility 
concern disappears.

K. // contributor



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

Re: [netmod] Must offline-validation of alone be valid?

[Jan Lindblad]

Hi Kent,

>>> Of course, some will point to Section 5.1.3:
>>> 
>>>However,  MUST always be a valid configuration data tree,
>>>as defined in Section 8.1 of [RFC7950] 
>>> .
>>> 
>>> But it has to be obvious that this is a bug.  For instance,
>>> 
>>>   - YANG defines a leaf is of type union { uint8 | variable }
>>>   -  defines the leaf having value “MAX_FOOBAR” 
>>> with a template that defines MAX_FOOBAR=1000.
>>>   - so,  would be syntactically valid but
>>> semantically invalid.
>> 
>> I must confess I raised my eyebrows a little when I saw this. Well, I have 
>> often heard server implementors pick some of their least favorite sentences 
>> out of an RFC and say that "this is obviously a bug". Still, it's quite 
>> another thing when something like that is coming from someone so deeply 
>> knowledgeable and immersed in IETF and the WG as Kent. 
> 
> I apologize if I’ve done or said anything to offend you.  Please, let’s keep 
> the discussion on the level.

I'm not offended in any way. It was certainly my intention keep things 
perfectly level and impersonal. If that's not how it came through, I'm truly 
sorry.

> Regarding raised eyebrows, did you catch that the value “1000” doesn’t fit 
> into a uint8?

Of course. My raised eyebrow was regarding how you, being both deeply 
knowledgeable and chair, could dismiss clear statements in RFCs as "obvious 
that this is a bug." The RFCs are documents that we have agreed. Agreeing is 
not an easy process, so we should be proud over what we have. While RFCs may 
have bugs, holes and shortcomings, I think treating RFCs with some respect is 
in order. We don't want to undermine their authority, or make people believe 
they can ignore a few rules that are unpleasant to them ("obviously a bug") and 
still call themselves compliant.

>  The point was/is that validation might miss that error without template 
> expansion.  In this case, pyang/yanglint validation on (unexpanded)  
> would pass, but I don’t think that we would want to settle for that, right?  
> Again, it was the intention of the authors that validation is moved to 
> ; Rob, Juergen, Martin, and I have all affirmed this understanding 
> recently.  I think that the quoted s5.1.3 line above escaped scrutiny, as 
> well perhaps some text missing in Section 6.1 (to replace or extend “running” 
> with “intended").  I recall that the authors were drawing a fine line 
> bridging being compatible with RFC 7950 and this intention.  I think that an 
> Errata on RFC 8342 may be warranted here, but I’m unsure what it might say 
> just yet.

I agree that your example is at odds with a whole collection of RFCs. But 
instead of thinking all the RFCs are in error, my conclusion is that the 
example you give is not supported yet. We can work on making templates usable 
within the YANG framework, but just as you already recognized above, it doesn't 
fit in without further work.

>> Kent, may I ask that you clarify if you do mean what you said, and if you 
>> do, if that would be a statement from a contributor or chair?
> 
> All my responses on this thread to this point, and in general, unless 
> explicitly called out with an “as co-chair” designation, are from me as a 
> contributor.  I do try to put a “as a contributor” on my messages for 
> brevity, but it is easy to forget sometimes. 

Thanks Kent. I do appreciate all you do for the WG.

/jan

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

Re: [netmod] Must offline-validation of alone be valid?

[Kent Watsen]

Hi Jan,

>> Of course, some will point to Section 5.1.3:
>> 
>>However,  MUST always be a valid configuration data tree,
>>as defined in Section 8.1 of [RFC7950] 
>> .
>> 
>> But it has to be obvious that this is a bug.  For instance,
>> 
>>   - YANG defines a leaf is of type union { uint8 | variable }
>>   -  defines the leaf having value “MAX_FOOBAR” 
>> with a template that defines MAX_FOOBAR=1000.
>>   - so,  would be syntactically valid but
>> semantically invalid.
> 
> I must confess I raised my eyebrows a little when I saw this. Well, I have 
> often heard server implementors pick some of their least favorite sentences 
> out of an RFC and say that "this is obviously a bug". Still, it's quite 
> another thing when something like that is coming from someone so deeply 
> knowledgeable and immersed in IETF and the WG as Kent. 

I apologize if I’ve done or said anything to offend you.  Please, let’s keep 
the discussion on the level.

Regarding raised eyebrows, did you catch that the value “1000” doesn’t fit into 
a uint8?  The point was/is that validation might miss that error without 
template expansion.  In this case, pyang/yanglint validation on (unexpanded) 
 would pass, but I don’t think that we would want to settle for that, 
right?  Again, it was the intention of the authors that validation is moved to 
; Rob, Juergen, Martin, and I have all affirmed this understanding 
recently.  I think that the quoted s5.1.3 line above escaped scrutiny, as well 
perhaps some text missing in Section 6.1 (to replace or extend “running” with 
“intended").  I recall that the authors were drawing a fine line bridging being 
compatible with RFC 7950 and this intention.  I think that an Errata on RFC 
8342 may be warranted here, but I’m unsure what it might say just yet.


> Kent, may I ask that you clarify if you do mean what you said, and if you do, 
> if that would be a statement from a contributor or chair?

All my responses on this thread to this point, and in general, unless 
explicitly called out with an “as co-chair” designation, are from me as a 
contributor.  I do try to put a “as a contributor” on my messages for brevity, 
but it is easy to forget sometimes. 


K.

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

Re: [netmod] Must offline-validation of alone be valid?

[Jan Lindblad]

Kent,

>> Here you are introducing two concepts that the RFCs (6020, 7950, 8342) are 
>> never mentioning: online and offline validation. Then you say that because 
>> the RFCs don't talk about these concepts, the behavior is undefined. I 
>> strongly disagree. The RFCs talk about validation, and describes the rules 
>> for how that happens. These rules always apply, regardless of online, 
>> offline or the phase of the moon.
> 
> Look, specs are very simple: stuff is written down in black and white and 
> either it’s there or not.  In this case, the fact remains that there is no 
> document I can point to that says offline validation is a thing.  

Absolutely. Today the words written down in the specs are only talking about 
one kind of validation. 

Offline validation is not a concept I have been using. It's not used in the 
RFCs. If you think this concept has merit, it would be good if you took the 
time to define it. And if you also think the RFCs that currently do not use it, 
should use it, then by all means suggest changes.

> It is also notable that RFC 8341 say nothing about the fact that clients 
> effected by NACM may not be able to pass validation (it’s not even mentioned).

That a client with insufficient privileges may have trouble understanding or 
controlling a server is no surprise to me. I don't quite see why you think this 
observation is relevant for the discussion about whether a datastore is valid 
or not?

>> If you think the online and offline validation concepts have merit, I would 
>> like to see proper definitions of them, and how you would like to modify the 
>> existing RFCs with respect to these concepts. It might also be a good idea 
>> to update the proposed draft, which currently does not mention these 
>> concepts.
> 
> This is part of the discussion we’re having now.  The outcome of which may 
> trigger clarifications to some RFCs.   All fine suggestions, but replace 
> “you” with “folks”, as it’s not on my shoulders to do any of this.

Ok, fair enough.

To whom it may concern: Regarding "offline validation" or "online validation", 
please note that these concepts are yet undefined in any RFCs or drafts (as far 
as I'm aware). If you intend to use these concepts, please be so kind as to 
either define or point to definitions of them.

>> The added value and the core essence of YANG is enabling us to reason about 
>> configurations and compute configuration changes without necessarily asking 
>> the server if a configuration is valid by "trial and error". This is 
>> possible because a YANG model is a detailed and reasonably complete 
>> description of the management interface. Introducing changes to YANG that 
>> breaks this basic premise would be dumbing down YANG, and I can't see the 
>> benefit with this change, or how this would be compatible with YANG 1.0, or 
>> 1.1 rules.
> 
> I never said offline validation shouldn’t be possible.  Rather, please know 
> that, NACM aside, my understanding of the goal of the draft is that offline 
> validation *is* supported...but it entails clients merging their view of 
>  with the server’s  before doing the validation (i.e., 
>  alone may not be enough, see Subject line).  Good news is that, 
> since  is effectively static, no new round-trips are incurred.

Good to hear. My preference would be that the validation rules already 
established in 6020, 7950 and 8342 stay close to what they are. If we decide to 
accommodate further use cases, that should be allowed by clients that flag 
awareness of extended mechanisms. Old, unaware servers and clients should be 
able to continue staying true to their legacy.


>>> In the meanwhile, can we discuss the issues around a legacy client failing 
>>> an offline validation?  In this case, a production deployment must have 1) 
>>> deployed devices that support , 2) deployed at least one client 
>>> that supports , and 3) decided to let clients start pushing config 
>>> using .   While in the pre-production testing phase, it would be 
>>> quickly discovered that all legacy clients need to be updated.  By the time 
>>> of going to production, the deployment should have all the clients updated, 
>>> so it seems that only the forgotten (relatively insignificant) clients 
>>> might have an offline validation of  failure.  Is this a fair 
>>> assessment?
>> 
>> 1) agreed, without devices that support the system datastore, no problem
>> 2,3) well, a "client" in this case could very well be a CLI operator or 
>> other management interface. Even in highly automated networks, CLI operators 
>> are still common
> 
> Sure, but there’s no impact to CLI operators as they’re effectively getting 
> server-side validation all the time.  Just saying that CLI-ops don’t seem to 
> be effected by any of this, right?

Well, I'm not worried about the CLI users getting trouble. I'm worried that CLI 
users would cause trouble for automation clients, by for example referencing 
something out of the system datastore. 

Re: [netmod] Resolving schema node identifier

[Michal Vaško]

> Michal Vaško  writes:
> 
> >> Michal Vaško  wrote:
> >> > > > Michal Vaško  wrote:
> >> > > > > > Michal Vaško  wrote:
> >> > > > > > > Hello,
> >> > > > > > > > I would like to get some input for a use-case I came across, 
> >> > > > > > > > which
> >> > > > > > > > to>
> >> > > > > > > > me does not seem to have any consistent rules that can be 
> >> > > > > > > > applied.
> >> > > > > > > > module mod_b {
> >> > > > > > > namespace "x:example:mod_b";
> >> > > > > > > prefix "mb";
> >> > > > > > > > grouping mylist_wrapper {
> >> > > > > > > list mylist {
> >> > > > > > > key "name";
> >> > > > > > > unique "value";
> >> > > > > > > leaf name {
> >> > > > > > > type string;
> >> > > > > > > }
> >> > > > > > > leaf value {
> >> > > > > > > type uint32;
> >> > > > > > > }
> >> > > > > > > }
> >> > > > > > > }
> >> > > > > > > > list mylist2 {
> >> > > > > > > key "a";
> >> > > > > > > leaf a {
> >> > > > > > > type string;
> >> > > > > > > }
> >> > > > > > > leaf b {
> >> > > > > > > type string;
> >> > > > > > > }
> >> > > > > > > }
> >> > > > > > > }
> >> > > > > > > > > module mod_a {
> >> > > > > > > namespace "x:example:mod_a";
> >> > > > > > > prefix "ma";
> >> > > > > > > > import mod_b { prefix "mb"; }
> >> > > > > > > > container root {
> >> > > > > > > uses mb:mylist_wrapper;
> >> > > > > > > }
> >> > > > > > > > augment /mb:mylist2 {
> >> > > > > > > leaf c {
> >> > > > > > > type string;
> >> > > > > > > }
> >> > > > > > > }
> >> > > > > > > > deviation /mb:mylist2 {
> >> > > > > > > deviate add {
> >> > > > > > > unique "mb:b c";
> >> > > > > > > }
> >> > > > > > > }
> >> > > > > > > }
> >> > > > > > > > The focus is on the "unique" statements and how to resolve
> >> > > > > > > non-prefixed identifiers. RFC 7950 says that the argument is a 
> >> > > > > > > "list
> >> > > > > > > of schema node identifiers"[1], which use "current module" for
> >> > > > > > > non-prefixed identifiers[2]. I have asked on this mailing list 
> >> > > > > > > a few
> >> > > > > > > years back what current module means and the answer I got was 
> >> > > > > > > the> >
> >> > > > > > > > module where the statement is defined.
> >> > > > > > > > So let's get to the examples. As they are written, the 
> >> > > > > > > > unique in
> >> > > > > > > "mylist" should be wrong because the node "value" belongs to 
> >> > > > > > > the
> >> > > > > > > module "mod_a" when the grouping is instantiated there, but 
> >> > > > > > > unique
> >> > > > > > > is>
> >> > > > > > > defined in the module "mod_b".
> >> > > > > > > > But even if we use the other understanding of current module 
> >> > > > > > > > and
> >> > > > > > > interpret is as the module of the context node of the statement
> >> > > > > > > (corresponds to the "current()" XPath function), then the other
> >> > > > > > > "unique" in the deviation cannot be resolved. It is 
> >> > > > > > > referencing node
> >> > > > > > > "c", which belongs to the module "mod_a" (added by an augment) 
> >> > > > > > > but
> >> > > > > > > the
> >> > > > > > > current module would then be "mod_b".
> >> > > > > > > > To summarize, if strictly following the specs, the "unique" 
> >> > > > > > > > in the
> >> > > > > > > "mylist" should probably reference "value" with a prefix, but 
> >> > > > > > > that
> >> > > > > > > is>
> >> > > > > > > not possible because "mod_a" is not even imported and it 
> >> > > > > > > generally
> >> > > > > > > does not make sense. But then I cannot think of any consistent 
> >> > > > > > > rule
> >> > > > > > > to
> >> > > > > > > successfully resolve both "unique" statements in this example. 
> >> > > > > > > Can
> >> > > > > > > anyone help me with this, please?
> >> > > > > > > > Compare with this:
> >> > > > > > > >  grouping mylist_wrapper {
> >> > > > > >  list mylist {
> >> > > > > >  key "name";
> >> > > > > >  unique "value";
> >> > > > > >  must "value > 42";
> >> > > > > >  leaf name {
> >> > > > > >  type string;
> >> > > > > >  }
> >> > > > > >  leaf value {
> >> > > > > >  type uint32;
> >> > > > > >  }
> >> > > > > >  }
> >> > > > > >  }
> >> > > > > > > > I think the rules for the prefixes in "unique" should be the 
> >> > > > > > > > same
> >> > > > > > > > as
> >> > > > > > for "must".  So I think that the correct syntax is to not use any
> >> > > > > > prefix in "unique".
> >> > > > > > > > And the deviation that adds a unique statement look correct.
> >> > > > > > Thanks for the reply but I do not think you have answered my
> >> > > > > question. Please formulate a formal rule how to assign 

Re: [netmod] Must offline-validation of alone be valid?

[Jan Lindblad]

Kent, all,

> Of course, some will point to Section 5.1.3:
> 
>However,  MUST always be a valid configuration data tree,
>as defined in Section 8.1 of [RFC7950] 
> .
> 
> But it has to be obvious that this is a bug.  For instance,
> 
>   - YANG defines a leaf is of type union { uint8 | variable }
>   -  defines the leaf having value “MAX_FOOBAR” 
> with a template that defines MAX_FOOBAR=1000.
>   - so,  would be syntactically valid but
> semantically invalid.

I must confess I raised my eyebrows a little when I saw this. Well, I have 
often heard server implementors pick some of their least favorite sentences out 
of an RFC and say that "this is obviously a bug". Still, it's quite another 
thing when something like that is coming from someone so deeply knowledgeable 
and immersed in IETF and the WG as Kent. 

Kent, may I ask that you clarify if you do mean what you said, and if you do, 
if that would be a statement from a contributor or chair?

In my opinion, if the statement above in section 5.1.3 (and you will find 
similar language in 7950) collides with the template example you gave, may I 
suggest the possibility that there could be something wrong with that example 
rather than the RFCs?

/jan

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

Re: [netmod] Resolving schema node identifier

[Ladislav Lhotka]

Michal Vaško  writes:

>> Michal Vaško  wrote:
>> > > > Michal Vaško  wrote:
>> > > > > > Michal Vaško  wrote:
>> > > > > > > Hello,
>> > > > > > > > I would like to get some input for a use-case I came across, 
>> > > > > > > > which
>> > > > > > > > to>
>> > > > > > > > me does not seem to have any consistent rules that can be 
>> > > > > > > > applied.
>> > > > > > > > module mod_b {
>> > > > > > > namespace "x:example:mod_b";
>> > > > > > > prefix "mb";
>> > > > > > > > grouping mylist_wrapper {
>> > > > > > > list mylist {
>> > > > > > > key "name";
>> > > > > > > unique "value";
>> > > > > > > leaf name {
>> > > > > > > type string;
>> > > > > > > }
>> > > > > > > leaf value {
>> > > > > > > type uint32;
>> > > > > > > }
>> > > > > > > }
>> > > > > > > }
>> > > > > > > > list mylist2 {
>> > > > > > > key "a";
>> > > > > > > leaf a {
>> > > > > > > type string;
>> > > > > > > }
>> > > > > > > leaf b {
>> > > > > > > type string;
>> > > > > > > }
>> > > > > > > }
>> > > > > > > }
>> > > > > > > > > module mod_a {
>> > > > > > > namespace "x:example:mod_a";
>> > > > > > > prefix "ma";
>> > > > > > > > import mod_b { prefix "mb"; }
>> > > > > > > > container root {
>> > > > > > > uses mb:mylist_wrapper;
>> > > > > > > }
>> > > > > > > > augment /mb:mylist2 {
>> > > > > > > leaf c {
>> > > > > > > type string;
>> > > > > > > }
>> > > > > > > }
>> > > > > > > > deviation /mb:mylist2 {
>> > > > > > > deviate add {
>> > > > > > > unique "mb:b c";
>> > > > > > > }
>> > > > > > > }
>> > > > > > > }
>> > > > > > > > The focus is on the "unique" statements and how to resolve
>> > > > > > > non-prefixed identifiers. RFC 7950 says that the argument is a 
>> > > > > > > "list
>> > > > > > > of schema node identifiers"[1], which use "current module" for
>> > > > > > > non-prefixed identifiers[2]. I have asked on this mailing list a 
>> > > > > > > few
>> > > > > > > years back what current module means and the answer I got was 
>> > > > > > > the> >
>> > > > > > > > module where the statement is defined.
>> > > > > > > > So let's get to the examples. As they are written, the unique 
>> > > > > > > > in
>> > > > > > > "mylist" should be wrong because the node "value" belongs to the
>> > > > > > > module "mod_a" when the grouping is instantiated there, but 
>> > > > > > > unique
>> > > > > > > is>
>> > > > > > > defined in the module "mod_b".
>> > > > > > > > But even if we use the other understanding of current module 
>> > > > > > > > and
>> > > > > > > interpret is as the module of the context node of the statement
>> > > > > > > (corresponds to the "current()" XPath function), then the other
>> > > > > > > "unique" in the deviation cannot be resolved. It is referencing 
>> > > > > > > node
>> > > > > > > "c", which belongs to the module "mod_a" (added by an augment) 
>> > > > > > > but
>> > > > > > > the
>> > > > > > > current module would then be "mod_b".
>> > > > > > > > To summarize, if strictly following the specs, the "unique" in 
>> > > > > > > > the
>> > > > > > > "mylist" should probably reference "value" with a prefix, but 
>> > > > > > > that
>> > > > > > > is>
>> > > > > > > not possible because "mod_a" is not even imported and it 
>> > > > > > > generally
>> > > > > > > does not make sense. But then I cannot think of any consistent 
>> > > > > > > rule
>> > > > > > > to
>> > > > > > > successfully resolve both "unique" statements in this example. 
>> > > > > > > Can
>> > > > > > > anyone help me with this, please?
>> > > > > > > > Compare with this:
>> > > > > > > >  grouping mylist_wrapper {
>> > > > > >  list mylist {
>> > > > > >  key "name";
>> > > > > >  unique "value";
>> > > > > >  must "value > 42";
>> > > > > >  leaf name {
>> > > > > >  type string;
>> > > > > >  }
>> > > > > >  leaf value {
>> > > > > >  type uint32;
>> > > > > >  }
>> > > > > >  }
>> > > > > >  }
>> > > > > > > > I think the rules for the prefixes in "unique" should be the 
>> > > > > > > > same
>> > > > > > > > as
>> > > > > > for "must".  So I think that the correct syntax is to not use any
>> > > > > > prefix in "unique".
>> > > > > > > > And the deviation that adds a unique statement look correct.
>> > > > > > Thanks for the reply but I do not think you have answered my
>> > > > > question. Please formulate a formal rule how to assign modules to
>> > > > > non-prefixed identifiers, whether they be in "unique", "must", or 
>> > > > > any>
>> > > > > other statement with identifiers. That is what I need to implement 
>> > > > > it>
>> > > > > properly and I am simply not able to 

Re: [netmod] Resolving schema node identifier

[Michal Vaško]

> Michal Vaško  wrote:
> > > > Michal Vaško  wrote:
> > > > > > Michal Vaško  wrote:
> > > > > > > Hello,
> > > > > > > > I would like to get some input for a use-case I came across, 
> > > > > > > > which
> > > > > > > > to>
> > > > > > > > me does not seem to have any consistent rules that can be 
> > > > > > > > applied.
> > > > > > > > module mod_b {
> > > > > > > namespace "x:example:mod_b";
> > > > > > > prefix "mb";
> > > > > > > > grouping mylist_wrapper {
> > > > > > > list mylist {
> > > > > > > key "name";
> > > > > > > unique "value";
> > > > > > > leaf name {
> > > > > > > type string;
> > > > > > > }
> > > > > > > leaf value {
> > > > > > > type uint32;
> > > > > > > }
> > > > > > > }
> > > > > > > }
> > > > > > > > list mylist2 {
> > > > > > > key "a";
> > > > > > > leaf a {
> > > > > > > type string;
> > > > > > > }
> > > > > > > leaf b {
> > > > > > > type string;
> > > > > > > }
> > > > > > > }
> > > > > > > }
> > > > > > > > > module mod_a {
> > > > > > > namespace "x:example:mod_a";
> > > > > > > prefix "ma";
> > > > > > > > import mod_b { prefix "mb"; }
> > > > > > > > container root {
> > > > > > > uses mb:mylist_wrapper;
> > > > > > > }
> > > > > > > > augment /mb:mylist2 {
> > > > > > > leaf c {
> > > > > > > type string;
> > > > > > > }
> > > > > > > }
> > > > > > > > deviation /mb:mylist2 {
> > > > > > > deviate add {
> > > > > > > unique "mb:b c";
> > > > > > > }
> > > > > > > }
> > > > > > > }
> > > > > > > > The focus is on the "unique" statements and how to resolve
> > > > > > > non-prefixed identifiers. RFC 7950 says that the argument is a 
> > > > > > > "list
> > > > > > > of schema node identifiers"[1], which use "current module" for
> > > > > > > non-prefixed identifiers[2]. I have asked on this mailing list a 
> > > > > > > few
> > > > > > > years back what current module means and the answer I got was 
> > > > > > > the> >
> > > > > > > > module where the statement is defined.
> > > > > > > > So let's get to the examples. As they are written, the unique in
> > > > > > > "mylist" should be wrong because the node "value" belongs to the
> > > > > > > module "mod_a" when the grouping is instantiated there, but unique
> > > > > > > is>
> > > > > > > defined in the module "mod_b".
> > > > > > > > But even if we use the other understanding of current module and
> > > > > > > interpret is as the module of the context node of the statement
> > > > > > > (corresponds to the "current()" XPath function), then the other
> > > > > > > "unique" in the deviation cannot be resolved. It is referencing 
> > > > > > > node
> > > > > > > "c", which belongs to the module "mod_a" (added by an augment) but
> > > > > > > the
> > > > > > > current module would then be "mod_b".
> > > > > > > > To summarize, if strictly following the specs, the "unique" in 
> > > > > > > > the
> > > > > > > "mylist" should probably reference "value" with a prefix, but that
> > > > > > > is>
> > > > > > > not possible because "mod_a" is not even imported and it generally
> > > > > > > does not make sense. But then I cannot think of any consistent 
> > > > > > > rule
> > > > > > > to
> > > > > > > successfully resolve both "unique" statements in this example. Can
> > > > > > > anyone help me with this, please?
> > > > > > > > Compare with this:
> > > > > > > >  grouping mylist_wrapper {
> > > > > >  list mylist {
> > > > > >  key "name";
> > > > > >  unique "value";
> > > > > >  must "value > 42";
> > > > > >  leaf name {
> > > > > >  type string;
> > > > > >  }
> > > > > >  leaf value {
> > > > > >  type uint32;
> > > > > >  }
> > > > > >  }
> > > > > >  }
> > > > > > > > I think the rules for the prefixes in "unique" should be the 
> > > > > > > > same
> > > > > > > > as
> > > > > > for "must".  So I think that the correct syntax is to not use any
> > > > > > prefix in "unique".
> > > > > > > > And the deviation that adds a unique statement look correct.
> > > > > > Thanks for the reply but I do not think you have answered my
> > > > > question. Please formulate a formal rule how to assign modules to
> > > > > non-prefixed identifiers, whether they be in "unique", "must", or any>
> > > > > other statement with identifiers. That is what I need to implement it>
> > > > > properly and I am simply not able to come up with any that would be
> > > > > consistent and compliant with the specification.
> > > > > > > Interpret the unique argument the same way as an XPath 
> > > > > > > expression, and
> > > > apply (from 6.4.1):
> > > > > > >o  Names without a namespace prefix 

Re: [netmod] Must offline-validation of alone be valid?

[Martin Björklund]

Hi,

Kent Watsen  wrote:
> Hi Andy,

> > I cannot find any RFC text that says system-injected config is
> > special, especially since
> > server implementations exist that treat these edits as just another
> > client
> > (although probably a 'root' user client).
> 
> Very true (and Juergen’s point as well).  I’ve seen this done before.
> Unhappy results.

Can you elaborate on this, or send a pointer if it has been documented
somewhere?

I will also add a +1 to letting the system "act as a client" and put
data into running.  This is what we do in our current project.

A few other comments.

The name "system" for this new proposed datastore is perhaps not the
best, since RFC 8342 already defines this term, and associated
semantics.

If the new proposed datastore is supposed to add static data like
"built-in profiles and policies", it is rather limited, compared to
"system config" as defined in RFC 8342.  The reason is that system
config can be injected at various levels in the config hierarchy;
specifically also under user-defined list entries.   And if this is
indeed the use case you (as in all proponents of the proposal) have in
mind, I think the solution with adding this to  works.  (But
I am curious to hear your experience of this).


> 
> 
> As a co-author, I know this was the intention of RFC 8342, which is
> supported by, for instance:
> 
> 
> Section 4.1:
> 
>o  Several implementations have proprietary mechanisms that allow
>   clients to store inactive data in .  Inactive data is
>   conceptually removed before validation.
> 
>o  Some implementations have proprietary mechanisms that allow
>   clients to define configuration templates in .  These
>   templates are expanded automatically by the system, and the
>   resulting configuration is applied internally.

Right, and in both cases, the idea was that  contains all
data needed for the transformation into .  So a client that
wants to do "offline" validation would need the data + the
transformation algorithms.  But no additional data.


/martin



> 
> Section 5:
> 
>  // subject to validation
> 
> Section 5.1.4:
> 
> is tightly coupled to .  Whenever data is written
>to , the server MUST also immediately update and validate
>.
> 
> 
> 
> 
> 
> Of course, some will point to Section 5.1.3:
> 
>However,  MUST always be a valid configuration data tree,
>as defined in Section 8.1 of [RFC7950]
>.
> 
> But it has to be obvious that this is a bug.  For instance,
> 
>   - YANG defines a leaf is of type union { uint8 | variable }
>   -  defines the leaf having value “MAX_FOOBAR” 
> with a template that defines MAX_FOOBAR=1000.
>   - so,  would be syntactically valid but
> semantically invalid.
> 
> Or a more egregious example:
> 
>   - YANG defines a "max-elements" value “MAX_FOOBAR”
>- how is this possible when RFC 7950 says max-elements
>   Is a positive integer or the string “unbounded”?
>- so now we’re into YANG-next territory as far as
>  templates are concerned, but hang with me a little
>  while longer…
>   -  has a template that defines MAX_FOOBAR=3
>   - how coulda server validate if ’s list contained less
> than max-elements?  Worse, what if the result of another 
> template added more elements to the list?
> 
> 
> I may have taken off the flame suit too early  ;)
> 
> K.
> 
> 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Resolving schema node identifier

[Martin Björklund]

Michal Vaško  wrote:
> > > Michal Vaško  wrote:
> > > > > Michal Vaško  wrote:
> > > > > > Hello,
> > > > > > > I would like to get some input for a use-case I came across, which
> > > > > > > to>
> > > > > > > me does not seem to have any consistent rules that can be applied.
> > > > > > > module mod_b {
> > > > > > namespace "x:example:mod_b";
> > > > > > prefix "mb";
> > > > > > > grouping mylist_wrapper {
> > > > > > list mylist {
> > > > > > key "name";
> > > > > > unique "value";
> > > > > > leaf name {
> > > > > > type string;
> > > > > > }
> > > > > > leaf value {
> > > > > > type uint32;
> > > > > > }
> > > > > > }
> > > > > > }
> > > > > > > list mylist2 {
> > > > > > key "a";
> > > > > > leaf a {
> > > > > > type string;
> > > > > > }
> > > > > > leaf b {
> > > > > > type string;
> > > > > > }
> > > > > > }
> > > > > > }
> > > > > > > > module mod_a {
> > > > > > namespace "x:example:mod_a";
> > > > > > prefix "ma";
> > > > > > > import mod_b { prefix "mb"; }
> > > > > > > container root {
> > > > > > uses mb:mylist_wrapper;
> > > > > > }
> > > > > > > augment /mb:mylist2 {
> > > > > > leaf c {
> > > > > > type string;
> > > > > > }
> > > > > > }
> > > > > > > deviation /mb:mylist2 {
> > > > > > deviate add {
> > > > > > unique "mb:b c";
> > > > > > }
> > > > > > }
> > > > > > }
> > > > > > > The focus is on the "unique" statements and how to resolve
> > > > > > non-prefixed identifiers. RFC 7950 says that the argument is a "list
> > > > > > of schema node identifiers"[1], which use "current module" for
> > > > > > non-prefixed identifiers[2]. I have asked on this mailing list a few
> > > > > > years back what current module means and the answer I got was the> >
> > > > > > > module where the statement is defined.
> > > > > > > So let's get to the examples. As they are written, the unique in
> > > > > > "mylist" should be wrong because the node "value" belongs to the
> > > > > > module "mod_a" when the grouping is instantiated there, but unique
> > > > > > is>
> > > > > > defined in the module "mod_b".
> > > > > > > But even if we use the other understanding of current module and
> > > > > > interpret is as the module of the context node of the statement
> > > > > > (corresponds to the "current()" XPath function), then the other
> > > > > > "unique" in the deviation cannot be resolved. It is referencing node
> > > > > > "c", which belongs to the module "mod_a" (added by an augment) but
> > > > > > the
> > > > > > current module would then be "mod_b".
> > > > > > > To summarize, if strictly following the specs, the "unique" in the
> > > > > > "mylist" should probably reference "value" with a prefix, but that
> > > > > > is>
> > > > > > not possible because "mod_a" is not even imported and it generally
> > > > > > does not make sense. But then I cannot think of any consistent rule
> > > > > > to
> > > > > > successfully resolve both "unique" statements in this example. Can
> > > > > > anyone help me with this, please?
> > > > > > > Compare with this:
> > > > > > >  grouping mylist_wrapper {
> > > > >  list mylist {
> > > > >  key "name";
> > > > >  unique "value";
> > > > >  must "value > 42";
> > > > >  leaf name {
> > > > >  type string;
> > > > >  }
> > > > >  leaf value {
> > > > >  type uint32;
> > > > >  }
> > > > >  }
> > > > >  }
> > > > > > > I think the rules for the prefixes in "unique" should be the same
> > > > > > > as
> > > > > for "must".  So I think that the correct syntax is to not use any
> > > > > prefix in "unique".
> > > > > > > And the deviation that adds a unique statement look correct.
> > > > > Thanks for the reply but I do not think you have answered my
> > > > question. Please formulate a formal rule how to assign modules to
> > > > non-prefixed identifiers, whether they be in "unique", "must", or any>
> > > > other statement with identifiers. That is what I need to implement it>
> > > > properly and I am simply not able to come up with any that would be
> > > > consistent and compliant with the specification.
> > > 
> > > Interpret the unique argument the same way as an XPath expression, and
> > > apply (from 6.4.1):
> > > 
> > >o  Names without a namespace prefix belong to the same namespace as
> > >   the identifier of the current node.  Inside a grouping, that
> > >   namespace is affected by where the grouping is used
> > > 
> > > So "value" in the unique statement will refer to "value" in "mod_a"
> > > when the grouping is used in "mod_a".
> > 
> > I see. Okay, this should be possible to implement, thanks.
> 
> 

Re: [netmod] Resolving schema node identifier

[Ladislav Lhotka]

On 14. 12. 21 12:03, Michal Vaško wrote:

Michal Vaško  wrote:

Michal Vaško  wrote:

Hello,

I would like to get some input for a use-case I came across, which to>
me does not seem to have any consistent rules that can be applied.
module mod_b {

 namespace "x:example:mod_b";
 prefix "mb";

 grouping mylist_wrapper {

 list mylist {
 key "name";
 unique "value";
 leaf name {
 type string;
 }
 leaf value {
 type uint32;
 }
 }
 }

 list mylist2 {

 key "a";
 leaf a {
 type string;
 }
 leaf b {
 type string;
 }
 }
}

module mod_a {

 namespace "x:example:mod_a";
 prefix "ma";

 import mod_b { prefix "mb"; }
 container root {

 uses mb:mylist_wrapper;
 }

 augment /mb:mylist2 {

 leaf c {
 type string;
 }
 }

 deviation /mb:mylist2 {

 deviate add {
 unique "mb:b c";
 }
 }
}

The focus is on the "unique" statements and how to resolve

non-prefixed identifiers. RFC 7950 says that the argument is a "list
of schema node identifiers"[1], which use "current module" for
non-prefixed identifiers[2]. I have asked on this mailing list a few
years back what current module means and the answer I got was the> > > module 
where the statement is defined.

So let's get to the examples. As they are written, the unique in

"mylist" should be wrong because the node "value" belongs to the
module "mod_a" when the grouping is instantiated there, but unique is>
defined in the module "mod_b".

But even if we use the other understanding of current module and

interpret is as the module of the context node of the statement
(corresponds to the "current()" XPath function), then the other
"unique" in the deviation cannot be resolved. It is referencing node
"c", which belongs to the module "mod_a" (added by an augment) but the
current module would then be "mod_b".

To summarize, if strictly following the specs, the "unique" in the

"mylist" should probably reference "value" with a prefix, but that is>
not possible because "mod_a" is not even imported and it generally
does not make sense. But then I cannot think of any consistent rule to
successfully resolve both "unique" statements in this example. Can
anyone help me with this, please?

Compare with this:
  grouping mylist_wrapper {

  list mylist {
  key "name";
  unique "value";
  must "value > 42";
  leaf name {
  type string;
  }
  leaf value {
  type uint32;
  }
  }
  }

I think the rules for the prefixes in "unique" should be the same as

for "must".  So I think that the correct syntax is to not use any
prefix in "unique".

And the deviation that adds a unique statement look correct.

Thanks for the reply but I do not think you have answered my

question. Please formulate a formal rule how to assign modules to
non-prefixed identifiers, whether they be in "unique", "must", or any> other 
statement with identifiers. That is what I need to implement it> properly and I am simply not able to 
come up with any that would be
consistent and compliant with the specification.


Interpret the unique argument the same way as an XPath expression, and
apply (from 6.4.1):

o  Names without a namespace prefix belong to the same namespace as
   the identifier of the current node.  Inside a grouping, that
   namespace is affected by where the grouping is used

So "value" in the unique statement will refer to "value" in "mod_a"
when the grouping is used in "mod_a".


I see. Okay, this should be possible to implement, thanks.


I was too hasty with the reply, this is not working because of the "unique" in the deviation I have in the example. What is the 
"current node" in that case? I suppose that can only be "mylist2", so the namespace will be that of "mod_b". But this 
is wrong, the "c" node belongs to "mod_a", so the "unique" in the deviation would be wrong.


Yes, this is unclear. I guess the only chance is to define the current 
node to be the (anonymous) root of the module "mod_a". A similar 
situation can happen inside a refine statement.


Lada




/martin


/martin

Finally, I am asking because I am trying to implement this correctly

in yanglint. I have also tried to test these examples with pyang,> > > which, 
however, seems to not have any consistent rules applied because
it loads these examples without warnings. No warnings are printed even
if the "unique" in the deviation is changed to "b c", which is
definitely wrong since node "b" belongs to "mod_b" and node "c"
belongs to "mod_a".

Thanks,

Michal

[1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3> > > [2] 
https://datatracker.ietf.org/doc/html/rfc7950#section-6.5

Re: [netmod] Resolving schema node identifier

[Michal Vaško]

> > Michal Vaško  wrote:
> > > > Michal Vaško  wrote:
> > > > > Hello,
> > > > > > I would like to get some input for a use-case I came across, which 
> > > > > > to>
> > > > > > me does not seem to have any consistent rules that can be applied.
> > > > > > module mod_b {
> > > > > namespace "x:example:mod_b";
> > > > > prefix "mb";
> > > > > > grouping mylist_wrapper {
> > > > > list mylist {
> > > > > key "name";
> > > > > unique "value";
> > > > > leaf name {
> > > > > type string;
> > > > > }
> > > > > leaf value {
> > > > > type uint32;
> > > > > }
> > > > > }
> > > > > }
> > > > > > list mylist2 {
> > > > > key "a";
> > > > > leaf a {
> > > > > type string;
> > > > > }
> > > > > leaf b {
> > > > > type string;
> > > > > }
> > > > > }
> > > > > }
> > > > > > > module mod_a {
> > > > > namespace "x:example:mod_a";
> > > > > prefix "ma";
> > > > > > import mod_b { prefix "mb"; }
> > > > > > container root {
> > > > > uses mb:mylist_wrapper;
> > > > > }
> > > > > > augment /mb:mylist2 {
> > > > > leaf c {
> > > > > type string;
> > > > > }
> > > > > }
> > > > > > deviation /mb:mylist2 {
> > > > > deviate add {
> > > > > unique "mb:b c";
> > > > > }
> > > > > }
> > > > > }
> > > > > > The focus is on the "unique" statements and how to resolve
> > > > > non-prefixed identifiers. RFC 7950 says that the argument is a "list
> > > > > of schema node identifiers"[1], which use "current module" for
> > > > > non-prefixed identifiers[2]. I have asked on this mailing list a few
> > > > > years back what current module means and the answer I got was the> > 
> > > > > > module where the statement is defined.
> > > > > > So let's get to the examples. As they are written, the unique in
> > > > > "mylist" should be wrong because the node "value" belongs to the
> > > > > module "mod_a" when the grouping is instantiated there, but unique is>
> > > > > defined in the module "mod_b".
> > > > > > But even if we use the other understanding of current module and
> > > > > interpret is as the module of the context node of the statement
> > > > > (corresponds to the "current()" XPath function), then the other
> > > > > "unique" in the deviation cannot be resolved. It is referencing node
> > > > > "c", which belongs to the module "mod_a" (added by an augment) but the
> > > > > current module would then be "mod_b".
> > > > > > To summarize, if strictly following the specs, the "unique" in the
> > > > > "mylist" should probably reference "value" with a prefix, but that is>
> > > > > not possible because "mod_a" is not even imported and it generally
> > > > > does not make sense. But then I cannot think of any consistent rule to
> > > > > successfully resolve both "unique" statements in this example. Can
> > > > > anyone help me with this, please?
> > > > > > Compare with this:
> > > > > >  grouping mylist_wrapper {
> > > >  list mylist {
> > > >  key "name";
> > > >  unique "value";
> > > >  must "value > 42";
> > > >  leaf name {
> > > >  type string;
> > > >  }
> > > >  leaf value {
> > > >  type uint32;
> > > >  }
> > > >  }
> > > >  }
> > > > > > I think the rules for the prefixes in "unique" should be the same as
> > > > for "must".  So I think that the correct syntax is to not use any
> > > > prefix in "unique".
> > > > > > And the deviation that adds a unique statement look correct.
> > > > Thanks for the reply but I do not think you have answered my
> > > question. Please formulate a formal rule how to assign modules to
> > > non-prefixed identifiers, whether they be in "unique", "must", or any> 
> > > other statement with identifiers. That is what I need to implement it> 
> > > properly and I am simply not able to come up with any that would be
> > > consistent and compliant with the specification.
> > 
> > Interpret the unique argument the same way as an XPath expression, and
> > apply (from 6.4.1):
> > 
> >o  Names without a namespace prefix belong to the same namespace as
> >   the identifier of the current node.  Inside a grouping, that
> >   namespace is affected by where the grouping is used
> > 
> > So "value" in the unique statement will refer to "value" in "mod_a"
> > when the grouping is used in "mod_a".
> 
> I see. Okay, this should be possible to implement, thanks.

I was too hasty with the reply, this is not working because of the "unique" in 
the deviation I have in the example. What is the "current node" in that case? I 
suppose that can only be "mylist2", so the namespace will be that of "mod_b". 
But this is wrong, the "c" node belongs to "mod_a", so 

Re: [netmod] Resolving schema node identifier

[Michal Vaško]

> Michal Vaško  wrote:
> > > Michal Vaško  wrote:
> > > > Hello,
> > > > > I would like to get some input for a use-case I came across, which to>
> > > > > me does not seem to have any consistent rules that can be applied.
> > > > > module mod_b {
> > > > namespace "x:example:mod_b";
> > > > prefix "mb";
> > > > > grouping mylist_wrapper {
> > > > list mylist {
> > > > key "name";
> > > > unique "value";
> > > > leaf name {
> > > > type string;
> > > > }
> > > > leaf value {
> > > > type uint32;
> > > > }
> > > > }
> > > > }
> > > > > list mylist2 {
> > > > key "a";
> > > > leaf a {
> > > > type string;
> > > > }
> > > > leaf b {
> > > > type string;
> > > > }
> > > > }
> > > > }
> > > > > > module mod_a {
> > > > namespace "x:example:mod_a";
> > > > prefix "ma";
> > > > > import mod_b { prefix "mb"; }
> > > > > container root {
> > > > uses mb:mylist_wrapper;
> > > > }
> > > > > augment /mb:mylist2 {
> > > > leaf c {
> > > > type string;
> > > > }
> > > > }
> > > > > deviation /mb:mylist2 {
> > > > deviate add {
> > > > unique "mb:b c";
> > > > }
> > > > }
> > > > }
> > > > > The focus is on the "unique" statements and how to resolve
> > > > non-prefixed identifiers. RFC 7950 says that the argument is a "list
> > > > of schema node identifiers"[1], which use "current module" for
> > > > non-prefixed identifiers[2]. I have asked on this mailing list a few
> > > > years back what current module means and the answer I got was the> > > 
> > > > module where the statement is defined.
> > > > > So let's get to the examples. As they are written, the unique in
> > > > "mylist" should be wrong because the node "value" belongs to the
> > > > module "mod_a" when the grouping is instantiated there, but unique is>
> > > > defined in the module "mod_b".
> > > > > But even if we use the other understanding of current module and
> > > > interpret is as the module of the context node of the statement
> > > > (corresponds to the "current()" XPath function), then the other
> > > > "unique" in the deviation cannot be resolved. It is referencing node
> > > > "c", which belongs to the module "mod_a" (added by an augment) but the
> > > > current module would then be "mod_b".
> > > > > To summarize, if strictly following the specs, the "unique" in the
> > > > "mylist" should probably reference "value" with a prefix, but that is>
> > > > not possible because "mod_a" is not even imported and it generally
> > > > does not make sense. But then I cannot think of any consistent rule to
> > > > successfully resolve both "unique" statements in this example. Can
> > > > anyone help me with this, please?
> > > > > Compare with this:
> > > > >  grouping mylist_wrapper {
> > >  list mylist {
> > >  key "name";
> > >  unique "value";
> > >  must "value > 42";
> > >  leaf name {
> > >  type string;
> > >  }
> > >  leaf value {
> > >  type uint32;
> > >  }
> > >  }
> > >  }
> > > > > I think the rules for the prefixes in "unique" should be the same as
> > > for "must".  So I think that the correct syntax is to not use any
> > > prefix in "unique".
> > > > > And the deviation that adds a unique statement look correct.
> > > Thanks for the reply but I do not think you have answered my
> > question. Please formulate a formal rule how to assign modules to
> > non-prefixed identifiers, whether they be in "unique", "must", or any> 
> > other statement with identifiers. That is what I need to implement it> 
> > properly and I am simply not able to come up with any that would be
> > consistent and compliant with the specification.
> 
> Interpret the unique argument the same way as an XPath expression, and
> apply (from 6.4.1):
> 
>o  Names without a namespace prefix belong to the same namespace as
>   the identifier of the current node.  Inside a grouping, that
>   namespace is affected by where the grouping is used
> 
> So "value" in the unique statement will refer to "value" in "mod_a"
> when the grouping is used in "mod_a".

I see. Okay, this should be possible to implement, thanks.

> /martin
> 
> > > > /martin
> > > > > > Finally, I am asking because I am trying to implement this correctly
> > > > in yanglint. I have also tried to test these examples with pyang,> > > 
> > > > which, however, seems to not have any consistent rules applied because
> > > > it loads these examples without warnings. No warnings are printed even
> > > > if the "unique" in the deviation is changed to "b c", which is
> > > > definitely wrong since node "b" belongs to "mod_b" and node "c"
> > > > belongs to "mod_a".
> > 

Re: [netmod] Resolving schema node identifier

[Martin Björklund]

Michal Vaško  wrote:
> > Michal Vaško  wrote:
> > > Hello,
> > > > I would like to get some input for a use-case I came across, which to>
> > > > me does not seem to have any consistent rules that can be applied.
> > > > module mod_b {
> > > namespace "x:example:mod_b";
> > > prefix "mb";
> > > > grouping mylist_wrapper {
> > > list mylist {
> > > key "name";
> > > unique "value";
> > > leaf name {
> > > type string;
> > > }
> > > leaf value {
> > > type uint32;
> > > }
> > > }
> > > }
> > > > list mylist2 {
> > > key "a";
> > > leaf a {
> > > type string;
> > > }
> > > leaf b {
> > > type string;
> > > }
> > > }
> > > }
> > > > > module mod_a {
> > > namespace "x:example:mod_a";
> > > prefix "ma";
> > > > import mod_b { prefix "mb"; }
> > > > container root {
> > > uses mb:mylist_wrapper;
> > > }
> > > > augment /mb:mylist2 {
> > > leaf c {
> > > type string;
> > > }
> > > }
> > > > deviation /mb:mylist2 {
> > > deviate add {
> > > unique "mb:b c";
> > > }
> > > }
> > > }
> > > > The focus is on the "unique" statements and how to resolve
> > > non-prefixed identifiers. RFC 7950 says that the argument is a "list
> > > of schema node identifiers"[1], which use "current module" for
> > > non-prefixed identifiers[2]. I have asked on this mailing list a few
> > > years back what current module means and the answer I got was the
> > > module where the statement is defined.
> > > > So let's get to the examples. As they are written, the unique in
> > > "mylist" should be wrong because the node "value" belongs to the
> > > module "mod_a" when the grouping is instantiated there, but unique is>
> > > defined in the module "mod_b".
> > > > But even if we use the other understanding of current module and
> > > interpret is as the module of the context node of the statement
> > > (corresponds to the "current()" XPath function), then the other
> > > "unique" in the deviation cannot be resolved. It is referencing node
> > > "c", which belongs to the module "mod_a" (added by an augment) but the
> > > current module would then be "mod_b".
> > > > To summarize, if strictly following the specs, the "unique" in the
> > > "mylist" should probably reference "value" with a prefix, but that is>
> > > not possible because "mod_a" is not even imported and it generally
> > > does not make sense. But then I cannot think of any consistent rule to
> > > successfully resolve both "unique" statements in this example. Can
> > > anyone help me with this, please?
> > 
> > Compare with this:
> > 
> >  grouping mylist_wrapper {
> >  list mylist {
> >  key "name";
> >  unique "value";
> >  must "value > 42";
> >  leaf name {
> >  type string;
> >  }
> >  leaf value {
> >  type uint32;
> >  }
> >  }
> >  }
> > 
> > I think the rules for the prefixes in "unique" should be the same as
> > for "must".  So I think that the correct syntax is to not use any
> > prefix in "unique".
> > 
> > And the deviation that adds a unique statement look correct.
> 
> Thanks for the reply but I do not think you have answered my
> question. Please formulate a formal rule how to assign modules to
> non-prefixed identifiers, whether they be in "unique", "must", or any
> other statement with identifiers. That is what I need to implement it
> properly and I am simply not able to come up with any that would be
> consistent and compliant with the specification.

Interpret the unique argument the same way as an XPath expression, and
apply (from 6.4.1):

   o  Names without a namespace prefix belong to the same namespace as
  the identifier of the current node.  Inside a grouping, that
  namespace is affected by where the grouping is used

So "value" in the unique statement will refer to "value" in "mod_a"
when the grouping is used in "mod_a".


/martin

> 
> > /martin
> > 
> > > Finally, I am asking because I am trying to implement this correctly
> > > in yanglint. I have also tried to test these examples with pyang,
> > > which, however, seems to not have any consistent rules applied because
> > > it loads these examples without warnings. No warnings are printed even
> > > if the "unique" in the deviation is changed to "b c", which is
> > > definitely wrong since node "b" belongs to "mod_b" and node "c"
> > > belongs to "mod_a".
> > > > Thanks,
> > > Michal
> > > > [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3
> > > [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5
> > > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > 

Re: [netmod] Resolving schema node identifier

[Michal Vaško]

> Michal Vaško  wrote:
> > Hello,
> > > I would like to get some input for a use-case I came across, which to> me 
> > > does not seem to have any consistent rules that can be applied.
> > > module mod_b {
> > namespace "x:example:mod_b";
> > prefix "mb";
> > > grouping mylist_wrapper {
> > list mylist {
> > key "name";
> > unique "value";
> > leaf name {
> > type string;
> > }
> > leaf value {
> > type uint32;
> > }
> > }
> > }
> > > list mylist2 {
> > key "a";
> > leaf a {
> > type string;
> > }
> > leaf b {
> > type string;
> > }
> > }
> > }
> > > > module mod_a {
> > namespace "x:example:mod_a";
> > prefix "ma";
> > > import mod_b { prefix "mb"; }
> > > container root {
> > uses mb:mylist_wrapper;
> > }
> > > augment /mb:mylist2 {
> > leaf c {
> > type string;
> > }
> > }
> > > deviation /mb:mylist2 {
> > deviate add {
> > unique "mb:b c";
> > }
> > }
> > }
> > > The focus is on the "unique" statements and how to resolve
> > non-prefixed identifiers. RFC 7950 says that the argument is a "list
> > of schema node identifiers"[1], which use "current module" for
> > non-prefixed identifiers[2]. I have asked on this mailing list a few
> > years back what current module means and the answer I got was the
> > module where the statement is defined.
> > > So let's get to the examples. As they are written, the unique in
> > "mylist" should be wrong because the node "value" belongs to the
> > module "mod_a" when the grouping is instantiated there, but unique is> 
> > defined in the module "mod_b".
> > > But even if we use the other understanding of current module and
> > interpret is as the module of the context node of the statement
> > (corresponds to the "current()" XPath function), then the other
> > "unique" in the deviation cannot be resolved. It is referencing node
> > "c", which belongs to the module "mod_a" (added by an augment) but the
> > current module would then be "mod_b".
> > > To summarize, if strictly following the specs, the "unique" in the
> > "mylist" should probably reference "value" with a prefix, but that is> not 
> > possible because "mod_a" is not even imported and it generally
> > does not make sense. But then I cannot think of any consistent rule to
> > successfully resolve both "unique" statements in this example. Can
> > anyone help me with this, please?
> 
> Compare with this:
> 
>  grouping mylist_wrapper {
>  list mylist {
>  key "name";
>  unique "value";
>  must "value > 42";
>  leaf name {
>  type string;
>  }
>  leaf value {
>  type uint32;
>  }
>  }
>  }
> 
> I think the rules for the prefixes in "unique" should be the same as
> for "must".  So I think that the correct syntax is to not use any
> prefix in "unique".
> 
> And the deviation that adds a unique statement look correct.

Thanks for the reply but I do not think you have answered my question. Please 
formulate a formal rule how to assign modules to non-prefixed identifiers, 
whether they be in "unique", "must", or any other statement with identifiers. 
That is what I need to implement it properly and I am simply not able to come 
up with any that would be consistent and compliant with the specification.

> /martin
> 
> > Finally, I am asking because I am trying to implement this correctly
> > in yanglint. I have also tried to test these examples with pyang,
> > which, however, seems to not have any consistent rules applied because
> > it loads these examples without warnings. No warnings are printed even
> > if the "unique" in the deviation is changed to "b c", which is
> > definitely wrong since node "b" belongs to "mod_b" and node "c"
> > belongs to "mod_a".
> > > Thanks,
> > Michal
> > > [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3
> > [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5
> > > ___
> > 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] Resolving schema node identifier

[Martin Björklund]

Hi,

Michal Vaško  wrote:
> Hello,
> 
> I would like to get some input for a use-case I came across, which to
> me does not seem to have any consistent rules that can be applied.
> 
> module mod_b {
> namespace "x:example:mod_b";
> prefix "mb";
> 
> grouping mylist_wrapper {
> list mylist {
> key "name";
> unique "value";
> leaf name {
> type string;
> }
> leaf value {
> type uint32;
> }
> }
> }
> 
> list mylist2 {
> key "a";
> leaf a {
> type string;
> }
> leaf b {
> type string;
> }
> }
> }
> 
> 
> module mod_a {
> namespace "x:example:mod_a";
> prefix "ma";
> 
> import mod_b { prefix "mb"; }
> 
> container root {
> uses mb:mylist_wrapper;
> }
> 
> augment /mb:mylist2 {
> leaf c {
> type string;
> }
> }
> 
> deviation /mb:mylist2 {
> deviate add {
> unique "mb:b c";
> }
> }
> }
> 
> The focus is on the "unique" statements and how to resolve
> non-prefixed identifiers. RFC 7950 says that the argument is a "list
> of schema node identifiers"[1], which use "current module" for
> non-prefixed identifiers[2]. I have asked on this mailing list a few
> years back what current module means and the answer I got was the
> module where the statement is defined.
> 
> So let's get to the examples. As they are written, the unique in
> "mylist" should be wrong because the node "value" belongs to the
> module "mod_a" when the grouping is instantiated there, but unique is
> defined in the module "mod_b".
> 
> But even if we use the other understanding of current module and
> interpret is as the module of the context node of the statement
> (corresponds to the "current()" XPath function), then the other
> "unique" in the deviation cannot be resolved. It is referencing node
> "c", which belongs to the module "mod_a" (added by an augment) but the
> current module would then be "mod_b".
> 
> To summarize, if strictly following the specs, the "unique" in the
> "mylist" should probably reference "value" with a prefix, but that is
> not possible because "mod_a" is not even imported and it generally
> does not make sense. But then I cannot think of any consistent rule to
> successfully resolve both "unique" statements in this example. Can
> anyone help me with this, please?

Compare with this:

 grouping mylist_wrapper {
 list mylist {
 key "name";
 unique "value";
 must "value > 42";
 leaf name {
 type string;
 }
 leaf value {
 type uint32;
 }
 }
 }

I think the rules for the prefixes in "unique" should be the same as
for "must".  So I think that the correct syntax is to not use any
prefix in "unique".

And the deviation that adds a unique statement look correct.


/martin

> Finally, I am asking because I am trying to implement this correctly
> in yanglint. I have also tried to test these examples with pyang,
> which, however, seems to not have any consistent rules applied because
> it loads these examples without warnings. No warnings are printed even
> if the "unique" in the deviation is changed to "b c", which is
> definitely wrong since node "b" belongs to "mod_b" and node "c"
> belongs to "mod_a".
> 
> Thanks,
> Michal
> 
> [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3
> [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5
> 
> ___
> 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] Resolving schema node identifier

[Michal Vaško]

Hello,

I would like to get some input for a use-case I came across, which to me does 
not seem to have any consistent rules that can be applied.

module mod_b {
namespace "x:example:mod_b";
prefix "mb";

grouping mylist_wrapper {
list mylist {
key "name";
unique "value";
leaf name {
type string;
}
leaf value {
type uint32;
}
}
}

list mylist2 {
key "a";
leaf a {
type string;
}
leaf b {
type string;
}
}
}


module mod_a {
namespace "x:example:mod_a";
prefix "ma";

import mod_b { prefix "mb"; }

container root {
uses mb:mylist_wrapper;
}

augment /mb:mylist2 {
leaf c {
type string;
}
}

deviation /mb:mylist2 {
deviate add {
unique "mb:b c";
}
}
}

The focus is on the "unique" statements and how to resolve non-prefixed 
identifiers. RFC 7950 says that the argument is a "list of schema node 
identifiers"[1], which use "current module" for non-prefixed identifiers[2]. I 
have asked on this mailing list a few years back what current module means and 
the answer I got was the module where the statement is defined.

So let's get to the examples. As they are written, the unique in "mylist" 
should be wrong because the node "value" belongs to the module "mod_a" when the 
grouping is instantiated there, but unique is defined in the module "mod_b".

But even if we use the other understanding of current module and interpret is 
as the module of the context node of the statement (corresponds to the 
"current()" XPath function), then the other "unique" in the deviation cannot be 
resolved. It is referencing node "c", which belongs to the module "mod_a" 
(added by an augment) but the current module would then be "mod_b".

To summarize, if strictly following the specs, the "unique" in the "mylist" 
should probably reference "value" with a prefix, but that is not possible 
because "mod_a" is not even imported and it generally does not make sense. But 
then I cannot think of any consistent rule to successfully resolve both 
"unique" statements in this example. Can anyone help me with this, please?

Finally, I am asking because I am trying to implement this correctly in 
yanglint. I have also tried to test these examples with pyang, which, however, 
seems to not have any consistent rules applied because it loads these examples 
without warnings. No warnings are printed even if the "unique" in the deviation 
is changed to "b c", which is definitely wrong since node "b" belongs to 
"mod_b" and node "c" belongs to "mod_a".

Thanks,
Michal

[1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3
[2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5

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

Re: [netmod] Must offline-validation of alone be valid?

[Jürgen Schönwälder]

On Mon, Dec 13, 2021 at 11:44:31PM +, Kent Watsen wrote:
> Juergen/Andy,
> 
> 
> > Option #3
> > 
> > There is a client on the system that makes changes to running just
> > like any other remote clients can make changes to running. System
> > generate config that is not editable explicit config in running goes
> > straight into the applied config in operational. This does not require
> > a system datastore (in fact something like a system datastore may
> > exist as the _logic_ of the system client, the good old example we had
> > is allocting an unused uid for an account that, once allocated, is
> > maintained in running).
> > 
> 
> Juergen, you mentioned this before.  I don’t recall if there were any 
> responses, but how would this solution address the various concerns that have 
> been raised? 
>

Well, while doing the NMDA work, we already acknowledged that there
are proprietary extensions (like templates or inactive nodes) and
hence we moved validation to . Since people felt it was kind
of hopeless to standardize templates, we accepted that there is vendor
specific magic applied to the config from  to become
. So from this perspective, merging in some system config is
not making things any worse, we already broke the ability to validate
a copy of  in an interoperable way in the NMDA work.

If we accept that there is system configuration one can rely on, then
this system configuration obviously flows into . Whether it
is possible to standardize this, I do not know, we even failed with
inactive in the past.

That said, I am not convinced by the proposed with-system parameter.
If you retrieve , then you should get  and not
something that happens to  later down the pipeline. If people
want offline validation, then they either retrieve  and work
with that or they have to implement the vendor's magic for merging
system configuration, for dealing with inactive nodes, for expanding
templates, and whatever comes next. This is bad news for everybody who
wants to do validation of config _before_ it is shipped to 
since these folks have to implement vendor specific logic. This is
unfortunate but I believe we started accepting this with NMDA and we
accepted it because this is what implementations apparently do...

I still believe that good data model design can avoid many of the
situations where people believe they need to depend on system
configuration. The interface example presented at IETF 112 is a weak
example since we rely on lazy name bindings for interfaces, a
description configured for an interface "foo" is applied to an
interface "foo" if there is one, otherwise it is not applied. You do
not need to know whether the system supplies a "foo" interface to
validate the config. But then I am sure there are examples where non
lazy bindings exist, perhaps hidden deep in some MUST expressions.

/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] too long lines from IANA module inclusion

[Benoit Claise]

Dear all,

`pyang` and I think `yanglint` also know how to extract folded
 and  elements.

Just a correction; pyang doesn't extract anything, but rfcstrip does,
and it supports folded artwork, and in the latest greatest 1.3 release
it even reconizes the proper RFC8792-defined magic strings ;-)
Do we have a couple of IETF drafts with long too long lines, next to 
https://datatracker.ietf.org/doc/draft-richardson-anima-rfc8366bis/ ?
I would like to make sure that the yangcatalog.org extracts the YANG 
module(s) correctly.

Note: the yangcatalog.org uses xym.

Regards, Benoit

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