Re: [netmod] IPR poll for draft-ma-netmod-immutable-flag-09

[Balázs Lengyel]

Hi, chairs, all
No, I am not aware of any IPR that applies to this draft.
Best Regards,
Balazs

From: Kent Watsen 
Sent: Monday, 12 February, 2024 23:50
To: maqiufang (A) ; Qin Wu ; Balázs 
Lengyel ; Hongwei Li 
Cc: netmod@ietf.org
Subject: IPR poll for draft-ma-netmod-immutable-flag-09

Authors, Contributors, WG,

As a prerequisite for the adoption on this document:

   YANG Metadata Annotation for Immutable Flag
   
https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-09

   Are you aware of any IPR that applies to draft identified above?

Please state either:

   "No, I'm not aware of any IPR that applies to this draft”
   or
   "Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

   "Yes, the IPR has been disclosed in compliance with IETF IPR 
rules”
   or
   "No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

FWIW, currently, no IPR is filed for this draft: 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ma-netmod-immutable-flag

Thanks.
Kent (and Lou)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning: Key Issues #2 and #3 - revision labels

[Balázs Lengyel]

Hello,

As the 3GPP YANG code master (wow   ) I would like to discuss Key Issue #3: 
Why do we need YANG Semver (vs. SemVer 2.0.0)?

In 3GPP we are developing multiple releases in parallel or at lest partly 
overlapping. Each release has its own branch and 2 sometimes 3 are actively 
developed. While we try to keep the branches in sync this is not always 
possible. In case of error corrections we sometimes do need to use 
non-backwards compatible updates on these branches.

This means that the basic Semver revision numbering would not work for us. We 
absolutely need YANG-Semver.
Regards Balazs

From: netmod  On Behalf Of Andy Bierman
Sent: Monday, 24 July, 2023 04:05
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: Key Issues #2 and #3 - revision labels



On Sun, Jul 23, 2023 at 6:52 PM Balázs Lengyel 
mailto:40ericsson@dmarc.ietf.org>>
 wrote:
Hello,
While  I fully agree with Jason’s comments, I would like to state both as an 
Ericsson guy and as a 3GPP delegate that for us Key issue 2 (multiple label 
schemes) is not important. The only important point is that it should be 
settled fast and thus not delay the acceptance of the versioning RFCs.

I would like this email answered about this issue.
https://mailarchive.ietf.org/arch/browse/netmod/?q=about%20revision%20label

There is no justification for more than 1 scheme and it does not work either.

Regards Balazs

Andy


From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Jason Sterne (Nokia)
Sent: Wednesday, 19 July, 2023 14:19
To: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: [netmod] YANG Versioning: Key Issues #2 and #3 - revision labels

Hi all,

The weekly call group thought it would be good to provide an advance look at 
Key Issues #2 and #3 before the IETF117 NETMOD meeting.

For now on the list let’s continue the focus on K1 but we’ll start in on K2 & 
K3 (if there is time) at IETF117.

Key Issue #2: Single v/s multiple revision label schemes
---
Recap of revision-label-scheme:

-Extension defined in YANG module versioning document.

-Takes a mandatory parameter defining the scheme used, it is an 
identity derived from revision-label-scheme-base

-Extension MUST be used if there is a revision label statement in the 
(sub)module

-The YANG Semver document defines the scheme yang-semver
(note – the current YANG revision date is not considered a revision label / 
label scheme)


-Example:

rev:revision-label-scheme "yangver:yang-semver";

Pros of revision-label-scheme:

-YANG Semver deemed too restrictive by some

-This provides flexibility to e.g. have vendor specific schemes which 
allow for infinite branching where the versions have no semantic meaning

-Consistent framework for adding other schemes


Cons of revision-label-scheme

-Flexibility comes with cost of added complexity, e.g. what if a module 
changes from scheme A to scheme B

-YANG Semver is sufficient for IETF and many vendors

-If some entity wants their own scheme they could just do it using 
their own separate extension (outside of any “framework”)

Impact of removing revision-label-scheme

-We would rename revision-label e.g. to yangsemver-label

-If a vendor wants a new versioning scheme, a proprietary extension 
would need to be added by that vendor (including augmentations of yang library, 
packages, etc)

-The current IETF documents would be simpler

-Cost/effort to make the changes to the documents


Key Issue #3: Why do we need YANG Semver (vs. SemVer 2.0.0)?
---
SemVer 2.0.0:

-Linear (no branching)

-Simpler in construction

o   Major

o   Minor

o   Patch

-1.0.0, 1.0.1, 1.1.0, 2.0.0, …

o   If a new feature is needed in 1.0.1, a 1.2.0 would need to be minted that 
incorporates the features of 1.1.0

-Widely liked by the industry, but only works well when updating at the 
head (fine for open source, not acceptable for operators)

YANG Semver:

-Support for limited branching (maintenance of released code)

-Supports SemVer 2.0.0 rules

-MAJOR.MINOR.PATCH_MODIFIER

o   _compatible

o   _non_compatible

Example:
1.0.0
|
1.0.1 -- 1.0.2_non_compatible
|
1.1.0
|
2.0.0
A feature (or an NBC change can be backported)

Why YANG Semver:

-Given that module versioning allows branching, the labeling scheme 
must also support branching

-YANG Semver is a compromise between power and simplicity

o   Encourage “mostly” single track development with modifiers the exception

o   Retains support for some updates to older versions

-Sufficient for  SDOs and vendors

-Industry is familiar with Semver – tried to stay close to it

Jason (he/him)

__

Re: [netmod] Regarding IPR on draft-ma-netmod-immutable-flag-08

[Balázs Lengyel]

No, I'm not aware of any IPR that applies to this draft (on 
draft-ma-netmod-immutable-flag-08).
Regards Balazs

From: Kent Watsen 
Sent: Friday, 25 August, 2023 23:32
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Regarding IPR on draft-ma-netmod-immutable-flag-08

Hi Balazs,

Can you response to this IPR poll please?

FWIW, your response to this poll is not indicative of your support for the 
draft, which is what the adoption poll is for.

Kent



On Aug 22, 2023, at 9:46 AM, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:

Authors, Contributors, WG,

As a prerequisite for the adoption on this document:

   Are you aware of any IPR that applies to draft identified above?

Please state either:

   "No, I'm not aware of any IPR that applies to this draft”
   or
   "Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

   "Yes, the IPR has been disclosed in compliance with IETF IPR 
rules”
   or
   "No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

Thanks.
Kent (as co-chair)


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

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

[netmod] YANG module updates based on Errata

[Balázs Lengyel]

Hello,
If a YANG module in an RFC is updated by errata (e.g. 
https://www.rfc-editor.org/errata/rfc6470) is an official updated IETF  YANG 
module published somewhere?
At the moment I don't find an official update for 
ietf-netconf-notification.yang, thus the only thing my company can do is to 
create and use an unofficial update to the IETF module. That is nasty as a 
vendor should not change IETF modules. But is there any better solution?


LONG TERM: my preference would be that the errata should include the updated 
module which should be published  on the IETF github. (A full bis updated would 
be preferred, but unlikely to happen.)

Regards Balazs
P.S. Sorry if this was discussed, but I don't remember.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning: Key Issues #2 and #3 - revision labels

[Balázs Lengyel]

Hello,
While  I fully agree with Jason's comments, I would like to state both as an 
Ericsson guy and as a 3GPP delegate that for us Key issue 2 (multiple label 
schemes) is not important. The only important point is that it should be 
settled fast and thus not delay the acceptance of the versioning RFCs.
Regards Balazs

From: netmod  On Behalf Of Jason Sterne (Nokia)
Sent: Wednesday, 19 July, 2023 14:19
To: netmod@ietf.org
Subject: [netmod] YANG Versioning: Key Issues #2 and #3 - revision labels

Hi all,

The weekly call group thought it would be good to provide an advance look at 
Key Issues #2 and #3 before the IETF117 NETMOD meeting.

For now on the list let's continue the focus on K1 but we'll start in on K2 & 
K3 (if there is time) at IETF117.

Key Issue #2: Single v/s multiple revision label schemes
---
Recap of revision-label-scheme:

-Extension defined in YANG module versioning document.

-Takes a mandatory parameter defining the scheme used, it is an 
identity derived from revision-label-scheme-base

-Extension MUST be used if there is a revision label statement in the 
(sub)module

-The YANG Semver document defines the scheme yang-semver
(note - the current YANG revision date is not considered a revision label / 
label scheme)


-Example:

rev:revision-label-scheme "yangver:yang-semver";

Pros of revision-label-scheme:

-YANG Semver deemed too restrictive by some

-This provides flexibility to e.g. have vendor specific schemes which 
allow for infinite branching where the versions have no semantic meaning

-Consistent framework for adding other schemes


Cons of revision-label-scheme

-Flexibility comes with cost of added complexity, e.g. what if a module 
changes from scheme A to scheme B

-YANG Semver is sufficient for IETF and many vendors

-If some entity wants their own scheme they could just do it using 
their own separate extension (outside of any "framework")

Impact of removing revision-label-scheme

-We would rename revision-label e.g. to yangsemver-label

-If a vendor wants a new versioning scheme, a proprietary extension 
would need to be added by that vendor (including augmentations of yang library, 
packages, etc)

-The current IETF documents would be simpler

-Cost/effort to make the changes to the documents


Key Issue #3: Why do we need YANG Semver (vs. SemVer 2.0.0)?
---
SemVer 2.0.0:

-Linear (no branching)

-Simpler in construction

o   Major

o   Minor

o   Patch

-1.0.0, 1.0.1, 1.1.0, 2.0.0, ...

o   If a new feature is needed in 1.0.1, a 1.2.0 would need to be minted that 
incorporates the features of 1.1.0

-Widely liked by the industry, but only works well when updating at the 
head (fine for open source, not acceptable for operators)

YANG Semver:

-Support for limited branching (maintenance of released code)

-Supports SemVer 2.0.0 rules

-MAJOR.MINOR.PATCH_MODIFIER

o   _compatible

o   _non_compatible

Example:
1.0.0
|
1.0.1 -- 1.0.2_non_compatible
|
1.1.0
|
2.0.0
A feature (or an NBC change can be backported)

Why YANG Semver:

-Given that module versioning allows branching, the labeling scheme 
must also support branching

-YANG Semver is a compromise between power and simplicity

o   Encourage "mostly" single track development with modifiers the exception

o   Retains support for some updates to older versions

-Sufficient for  SDOs and vendors

-Industry is familiar with Semver - tried to stay close to it

Jason (he/him)

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

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Balázs Lengyel]

Hello Andy,
I assume you are referring to the sentence “A new module revision MAY contain 
NBC changes” from the versioning draft.
IMHO the authors agree that NBC changes are bad. They should be allowed but 
discouraged.
Would a sentence like
“A new module revision MAY but SHOULD NOT contain NBC changes … ”
be OK ?
I think the MAY part is also needed< because that is what we are introducing as 
new compared to 7950.
be agreeable?
Regards Balazs

From: Andy Bierman 
Sent: Sunday, 23 July, 2023 17:26
To: Balázs Lengyel 
Cc: Martin Björklund ; netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 
1.0 & YANG 1.1 or not?



On Sun, Jul 23, 2023 at 5:08 PM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:
Hello Andy,
In 3GPP we have endless debates about what is a bugfix. If the functionality 
will not work it is a bugfix. If it works in a bad way it is or maybe not a 
bugfix. If it works just in an ugly way is it a bugfix?
Conclusion: it is not possible to define clear criteria about what is a bug and 
what is an improvement.


It is easy to change MAY to SHOULD NOT in the versioning draft.

IMO changing MUST NOT to MAY is unacceptable.
The versioning draft is attempting to completely toss out all of the YANG 
update rules.
Changing the normative text to SHOULD NOT instead of MAY does not require any 
specification of a bugfix.


Regards Balazs


Andy


From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Andy Bierman
Sent: Wednesday, 19 July, 2023 10:13
To: Martin Björklund mailto:mbj%2bi...@4668.se>>
Cc: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 
1.0 & YANG 1.1 or not?



On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund 
mailto:mbj%2bi...@4668.se>> wrote:
What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules


This is the approach I also suggested on the mailing list.

- As it works today; the IETF *has* published bugfixed modules that break the
  rules.  (and many vendors do this as well)
- (Possibly) Introduce rev:non-backwards-compatible

This would allow 6991bis to update date-and-time to follow the updated
semantics for RFC3339 timestamps (which imo is the only reasonable
thing to do - the consuequences of this change is handled by SEDATE).


The important thing in each case is to consider
the expected impact on the real world and real deployments.

IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC 
change.
But this is not the same thing as changing the rules in a new document to shift 
the
implementation burden to the client.

This is only an IETF issue and the burden should be on a WG to convince the 
IESG and IETF
that making the NBC change is a bugfix and should be allowed as a special case.



/martin

Andy


"Jason Sterne (Nokia)" mailto:jason.ste...@nokia.com>> 
wrote:
> Hi all,
>
> At the request of the NETMOD chairs, and on behalf of the YANG Versioning 
> weekly call group, here's a summary of Key Issue #1 for the versioning work 
> (i.e. for the Module Versioning and YANG Semver WGLC).
>
> We'd like to suggest that the WG has a strong focus on deciding on this 
> specific issue first. Then we'll move on to tackle other key issues. The idea 
> is to try and avoid getting tangled in a web of multiple intertwined issues.
>
> Key Issue #1 is the following:  Allow NBC changes in YANG 1.0 & YANG 1.1 or 
> not?
>
> For now please avoid debating other issues in this thread (e.g. multiple vs 
> single label schemes, whether YANG semver is a good scheme, etc). Let's focus 
> on K1 and work towards a WG decision.
>
> ###
> K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
>
> Option 1 - Update RFC7950 to Allow NBC Changes
> ---
> - Module Versioning modifies 7950 to allow NBC changes
> - guidance that NBC changes SHOULD NOT be done (impact to user base)
> - rev:non-backwards-compatible is a YANG extension
> - introduction in published YANG does not impact current tooling (ignored 
> until recognized)
> PROS:
> - address fundamental requirement of this versioning work (requirements doc)
> - allows gradual adoption in the industry. YANG authors can immeditately 
> start publishing with the new extensions.
> - move faster to produce modules in the IETF (accept some errors/iteration)
> - address the liaison from external standards bodies in a reasonable timeframe
> - authors believe work is ready
> - broad vendor support
> - rough alignment with OpenConfig (use YANG 1.0 + OC Semver)
> CONS:
> - perception that we're "cheating" by not bumping our own spec's version
> - Not fundamentally mandatory for

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Balázs Lengyel]

Hello,
I am writing this as
- Balazs Lengyel one of the authors, but also as
- an Ericsson guy and also as
- a delegate of 3GPP, which requested a better versioning scheme in a reasonably
 fast timeline.  3GPP represents both vendors and operators, so in this last
 role I am sitting on both side of the fence.
 I strongly support option 1 - modifying 7950 to allow NBC changes and
 introducing something like Semver.
- We need this soon and the other alternatives will take a longer time.
- we need it for the current YANG models too, not just for YANG 1.2 or 2 models
- We are already today doing backwards incompatible updates. We would like to 
have
 that aligned with IETF.
 - as one of the authors I believe the work is ready and reasonably good
- I believe adapting the tooling for a few new extensions is much less work
 than adapting to a new YANG version
 Option 2 will take a long time to specify, implement and roll out. During this 
time
 other non-standard solutions will proliferate; messy solutions, like just
 ignoring the current RFC7950 rules, will be used more and more.
 Option 3 just ignores the real world.
 NBC changes are happening. There are SDOs that value speed over final quality
 and role out a new version of the modules every few months. These can not
 live without some NBC changes.
 A more fine grained versioning system is required.

Regards Balazs

From: netmod  On Behalf Of Andy Bierman
Sent: Thursday, 20 July, 2023 18:52
To: Jason Sterne (Nokia) 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 
1.0 & YANG 1.1 or not?



On Wed, Jul 19, 2023 at 1:13 PM Jason Sterne (Nokia) 
mailto:jason.ste...@nokia.com>> wrote:
We considered this approach as well in the weekly calls but in the end felt 
that was just dodging the problem. We have a set of “MUST” rules that we know 
need to occasionally be broken. Shouldn’t we officialize this so our behavior 
and documents match?  (i.e. SHOULD NOT instead of MUST)?

It isn’t just an IETF issue. These same exceptions occur in vendor models, 
3GPP, etc. There are times when making the NBC change is the reasonable way to 
go.


https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning#name-updating-a-yang-module-with

I do not support these changes in any version of YANG.
The advice to the community is non-specific and obviously not backward 
compatible with RFC 7950.
The new advice is that any change at all in a YANG module is now allowed.
Instead of normative rules, RFC 7950 simply advises whether the optional 
'non-backwards-compatible' extension could be applied or not.
This is not a good change, especially on top of YANG 1.1.

I could see if specific MUST NOT rules were changed to SHOULD NOT instead.
A blank check using the current "MAY" (3.1, para 2)  is not a good idea.


Jason

Andy


From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: Wednesday, July 19, 2023 1:13 PM
To: Martin Björklund mailto:mbj%2bi...@4668.se>>
Cc: Jason Sterne (Nokia) 
mailto:jason.ste...@nokia.com>>; 
netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 
1.0 & YANG 1.1 or not?


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL 
nok.it/ext
 for additional information.




On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund 
mailto:mbj%2bi...@4668.se>> wrote:
What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules


This is the approach I also suggested on the mailing list.

- As it works today; the IETF *has* published bugfixed modules that break the
  rules.  (and many vendors do this as well)
- (Possibly) Introduce rev:non-backwards-compatible

This would allow 6991bis to update date-and-time to follow the updated
semantics for RFC3339 timestamps (which imo is the only reasonable
thing to do - the consuequences of this change is handled by SEDATE).


The important thing in each case is to consider
the expected impact on the real world and real deployments.

IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC 
change.
But this is not the same thing as changing the rules in a new document to shift 
the
implementation burden to the client.

This is only an IETF issue and the burden should be on a WG to convince the 
IESG and IETF
that making the NBC change is a bugfix and should be allowed as a special case.



/martin

Andy


"Jason Sterne (Nokia)" mailto:jason.ste...@nokia.com>> 
wrote:
> Hi all,
>
> At the request of the NETMOD chairs, and on behalf of the YANG Versioning 
> weekly call group, here's a summary of Key Issue #1 for the versioning work 
> (i.e. for the Module Versioning and YANG Semver WGLC).
>
> We'd like to suggest that the WG has a strong focus on deciding on this 
> 

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Balázs Lengyel]

Hello Andy,
In 3GPP we have endless debates about what is a bugfix. If the functionality 
will not work it is a bugfix. If it works in a bad way it is or maybe not a 
bugfix. If it works just in an ugly way is it a bugfix?
Conclusion: it is not possible to define clear criteria about what is a bug and 
what is an improvement.
Regards Balazs

From: netmod  On Behalf Of Andy Bierman
Sent: Wednesday, 19 July, 2023 10:13
To: Martin Björklund 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 
1.0 & YANG 1.1 or not?



On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund 
mailto:mbj%2bi...@4668.se>> wrote:
What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules


This is the approach I also suggested on the mailing list.

- As it works today; the IETF *has* published bugfixed modules that break the
  rules.  (and many vendors do this as well)
- (Possibly) Introduce rev:non-backwards-compatible

This would allow 6991bis to update date-and-time to follow the updated
semantics for RFC3339 timestamps (which imo is the only reasonable
thing to do - the consuequences of this change is handled by SEDATE).


The important thing in each case is to consider
the expected impact on the real world and real deployments.

IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC 
change.
But this is not the same thing as changing the rules in a new document to shift 
the
implementation burden to the client.

This is only an IETF issue and the burden should be on a WG to convince the 
IESG and IETF
that making the NBC change is a bugfix and should be allowed as a special case.



/martin

Andy


"Jason Sterne (Nokia)" mailto:jason.ste...@nokia.com>> 
wrote:
> Hi all,
>
> At the request of the NETMOD chairs, and on behalf of the YANG Versioning 
> weekly call group, here's a summary of Key Issue #1 for the versioning work 
> (i.e. for the Module Versioning and YANG Semver WGLC).
>
> We'd like to suggest that the WG has a strong focus on deciding on this 
> specific issue first. Then we'll move on to tackle other key issues. The idea 
> is to try and avoid getting tangled in a web of multiple intertwined issues.
>
> Key Issue #1 is the following:  Allow NBC changes in YANG 1.0 & YANG 1.1 or 
> not?
>
> For now please avoid debating other issues in this thread (e.g. multiple vs 
> single label schemes, whether YANG semver is a good scheme, etc). Let's focus 
> on K1 and work towards a WG decision.
>
> ###
> K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
>
> Option 1 - Update RFC7950 to Allow NBC Changes
> ---
> - Module Versioning modifies 7950 to allow NBC changes
> - guidance that NBC changes SHOULD NOT be done (impact to user base)
> - rev:non-backwards-compatible is a YANG extension
> - introduction in published YANG does not impact current tooling (ignored 
> until recognized)
> PROS:
> - address fundamental requirement of this versioning work (requirements doc)
> - allows gradual adoption in the industry. YANG authors can immeditately 
> start publishing with the new extensions.
> - move faster to produce modules in the IETF (accept some errors/iteration)
> - address the liaison from external standards bodies in a reasonable timeframe
> - authors believe work is ready
> - broad vendor support
> - rough alignment with OpenConfig (use YANG 1.0 + OC Semver)
> CONS:
> - perception that we're "cheating" by not bumping our own spec's version
> - Not fundamentally mandatory for clients or servers using YANG (mandatory 
> for YANG claiming conformance to Module Versioning).
>
> Option 2 - RFC7950-bis: Publish a new version of the YANG language to allow 
> NBC changes
> ---
> - NBC changes only allowed in a new (future) version of YANG
> - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0)
> - Content = Module Versioning + YANG Semver + very limited YANG NEXT items
> - rev:non-backwards-compatible tag is a language keyword
> - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't 
> been updated
> - TBD how to handle small NBC changes in IETF in the short term (i.e. non 
> conformance to 7950)?
> - RFC6991 bis - change the use/meaning of ip-address (or change datetime)
>   - YANG date-and-time (because of SEDATE date string changes)
>
> PROS:
> - address fundamental requirement of this versioning work (requirements doc)
> - clear delineation of changes in the YANG language
> - consistent with philosophy that version number changes for significant 
> changes in a spec (avoids concern that YANG is changing without bumping the 
> version of YANG)
> - can do this with mandatory YANG keywords which helps increase conformance 
> to the new rules
> CONS:
> - difficult to roll out in the industry. Tools need upgrading before they 
> won't error on 

Re: [netmod] IPR Poll on draft-ietf-netmod-yang-semver-09

[Balázs Lengyel]

"No, I'm not aware of any IPR that applies to this draft"
Balazs

-Original Message-
From: Kent Watsen  
Sent: Tuesday, 17 January, 2023 00:00
To: netmod@ietf.org
Cc: Joe Clarke (jclarke) ; Rob Wilton (rwilton) 
; Reshad Rahman ; Balázs 
Lengyel ; Jason Sterne (Nokia) 
; Benoit Claise 
Subject: IPR Poll on draft-ietf-netmod-yang-semver-09

[NOTE: A response is needed from all listed in this message's "To" line, the 
authors and contributors listed in the draft]


Authors, Contributors, WG,

In preparation for a WGLC Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 
3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropriate. 
If you are listed as a document author or contributor please answer the above 
by responding to this email regardless of whether or not you are aware of any 
relevant IPR. This document will not advance to the next stage until a response 
has been received from each author.

If you are on the WG email list or attend WG meetings but are not listed as an 
author or contributor, we remind you of your obligations under the IETF IPR 
rules which encourages you to notify the IETF if you are aware of IPR of others 
on an IETF contribution, or to refrain from participating in any contribution 
or discussion related to your undisclosed IPR. For more information, please see 
the RFCs listed above and 
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent and Lou

PS Please include all listed in the headers of this message in your response.

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

[netmod] Balazs comments on draft-ietf-netmod-system-config-00

[Balázs Lengyel]

Hello,
Some comment on draft-ietf-netmod-system-config-00.

General:
I support this work, I see it as important.

I think this draft should be dependent on the immutable draft. I see limited 
value of system-configuration if there is no way to protect It from client 
modification.

Ch 1)
Why is explicit copying bad?  Why do we need resolve-system parameter?  the You 
should motivate that.

Ch 1.4)
edit-config and edit-data cannot be used towards the startup datastore. 
Copy-config can.


" If the target
   datastore of the / or  is
   "candidate", the server's copy referenced nodes from  to the
   target datastore is delayed until a  or  operation
   takes place."
This means that  the device has to remember that resolve-system was used. Is 
this fact visible for other clients? What if someone overrides items that were 
planned for resolve-system?
Other clients (not the one that used the resolve-system) will be confused.
What happens if I have a must statement including a "count () <= max" on list 
items. Another client might create max number of list entries. This could 
prevent the device from adding new list-entries based on resolve-system.
IMHO delaying the copy is a bad idea.

1.5.2)  IMHO we should have the same capability in Netconf too.

2) Define what does it mean if a part of system configuration is not active/ 
not applied? In which datastore is it visible? If I explicitly copy a 
conditionally-active item into  (while its condition is still not met) 
does it become active?


3)  3.1) The headers seem strange. I would consider changing them. #Ch3  is  
about Static Characteristics of what?
Regards Balazs
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-yang-module-versioning-05: NBC Changes

[Balázs Lengyel]

Hello Andy,
Found this older email.
The draft discourages, but allows NBC changes , including in standard modules 
(and that is needed, IETF has already made NBC changes).
Other SDOs ORAN, 3GPP and others have much faster release cycles, so they have 
more chance to deprecate or obsolete  YANG nodes thereby doing NBC changes.
Vendors, with even faster cycles, will have even more cases where they 
deprecate, obsolete, remove data nodes.

Yes, NBC changes are bad, but sometimes needed. The draft encourages to keep 
changes BC, but allows NBC.
This is a significant departure from RFC 7950, just as you say, but the idea in 
RFC7950 that NBC changes can be fully avoided was unrealistic to begin with.

Regards Balazs

From: netmod  On Behalf Of Andy Bierman
Sent: Tuesday, 14 June, 2022 20:35
To: NetMod WG 
Subject: [netmod] draft-ietf-netmod-yang-module-versioning-05: NBC Changes

Hi,

The draft-05 version has expired and is no longer on the NETMOD WG WEB page.

Sec 3.1 includes this text:


   Where pragmatic, updates to YANG modules SHOULD be backwards-

   compatible, following the definition in Section 
3.1.1.


This is a significant departure from RFC 7950.

There are normal "lifecycle" changes that can occur to YANG-based APIs
that are currently classified as NBC changes in 7950, sec 11.
They are often related to the release train. Maybe this concept is
common enough to standardize.

For example, we often introduce a leaf with a default of 'disabled'
because we mandate that ALL new features or behavior changes MUST
require the client to opt-in.  But after a year or two, we may change that
default to 'enabled' in a new release train.  Then if the feature is deprecated
 at the end of the lifecycle, the default may get changed back to 'disabled'
in a new release train.  BC compatibility is ALWAYS maintained within
a release train.

Given that RFCs take so long to publish, it seems unlikely that
we would ever be in a position to make a "real" NBC change
in the middle of a release train, such that all of the client code
already deployed will break immediately when the upgrade is done.
We can NEVER just remove the old version.

It is hard to imagine a situation where breaking real deployments
is a better option than introducing a new identifier, so old clients
and new clients can coexist.


Andy

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

[netmod] YANG Semver - text proposal for derived version

[Balázs Lengyel]

Hello,
See my proposal for text change for 
https://github.com/netmod-wg/yang-ver-dt/issues/163.
Regards Balazs

-Original Appointment-
From: NETMOD Working Group 
Sent: Friday, 27 August, 2021 14:31
To: NETMOD Working Group; Wubo (lana); Balázs Lengyel; Per Andersson 
(perander); Scott Mansfield; Joe Clarke (jclarke); netmod@ietf.org
Subject: FW: NETMOD YANG Version Discussions (continuing)
When: Tuesday, 11 October, 2022 09:00-10:00 America/New_York.
Where: https://ietf.webex.com/ietf/j.php?MTID=me2c6491ebcc37b8127c1244d244d2754

In case anyone is missing the updated invite.

Rob


-Original Appointment-
From: NETMOD Working Group 
Sent: 27 August 2021 13:31
To: NETMOD Working Group; netmod@ietf.org
Subject: NETMOD YANG Version Discussions (continuing)
When: Occurs every Tuesday effective 16/11/2021 from 09:00 to 10:00 
America/New_York.
Where: https://ietf.webex.com/ietf/j.php?MTID=me2c6491ebcc37b8127c1244d244d2754



NETMOD Working Group changed the Webex meeting information.




When it's time, join the Webex meeting here.



Occurs every Tuesday effective Tuesday, November 16, 2021 from 9:00 AM to 10:00 
AM, (UTC-05:00) Eastern Time (US & Canada)
9:00 AM  |  (UTC-05:00) Eastern Time (US & Canada)  |  1 hr



Join 
meeting<https://ietf.webex.com/ietf/j.php?MTID=me2c6491ebcc37b8127c1244d244d2754>


More ways to join:

Join from the meeting link
https://ietf.webex.com/ietf/j.php?MTID=me2c6491ebcc37b8127c1244d244d2754



Join by meeting number

Meeting number (access code): 161 096 5630

Meeting password: semver?



Tap to join from a mobile device (attendees only)
+1-650-479-3208,,1610965630## 
Call-in toll number (US/Canada)


Join by phone
1-650-479-3208 Call-in toll number (US/Canada)
Global call-in 
numbers<https://ietf.webex.com/ietf/globalcallin.php?MTID=m06b7356bd54c5bd0512adcd69a95f5cf>



Join from a video system or application
Dial 1610965...@ietf.webex.com<%20sip:1610965...@ietf.webex.com>
You can also dial 173.243.2.68 and enter your meeting number.



Need help? Go to https://help.webex.com


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

Re: [netmod] Answer to ORAN liason

[Balázs Lengyel]

You are right it should have 2022-Q4. Updated text below:
---
From Group:   IETF / netmod
From Contacts:  Jürgen Schönwälder 
j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>,
 Thomas Nadeau tnad...@lucidvision.com<mailto:tnad...@lucidvision.com> Lou 
Berger mailto:lber...@labn.net>>
Joel Jaeggli joe...@bogus.com<mailto:joe...@bogus.com> Kent Watsen 
mailto:kent+i...@watsen.net>>

To Group:  O-RAN-WG10
To Contact: Jiajin Gao, 
jacqueline.s.beau...@ericsson.com<mailto:jacqueline.s.beau...@ericsson.com>
Purpose: Information

The IETF netmod WG will progress the
- draft-ietf-netmod-yang-module-versioning
- draft-ietf-netmod-yang-semver
independently from the draft-ietf-netmod-yang-packages, 
draft-ietf-netmod-yang-ver-selection and 
draft-ietf-netmod-yang-schema-comparison.

The final, approved RFC version of the first two drafts can be estimated to be 
ready 2022-Q4 to 2023 Q1.

-


From: Sterne, Jason (Nokia - CA/Ottawa) 
Sent: Thursday, 28 July, 2022 19:57
To: Balázs Lengyel ; 'netmod@ietf.org' 

Subject: RE: Answer to ORAN liason

Thanks Balazs. Agree the key message is the de-coupling of those two drafts 
from the remaining 3.

I'm not sure if you intended 2022-Q2 but that Q is over 

We need to roll the per-element tags into the draft and still have some LC 
comments we haven't replied to (and it is summer vact period). I think we're 
still a good number of months away from RFC. Q4 this year is best case IMO.

Jason

From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Balázs Lengyel
Sent: Thursday, July 28, 2022 2:52 AM
To: 'netmod@ietf.org' mailto:netmod@ietf.org>>
Subject: [netmod] Answer to ORAN liason

Hello,
I propose we send the following statement to ORAN as an answer to their liaison 
statement available at: https://datatracker.ietf.org/liaison/1785/
---
From Group:   IETF / netmod
From Contacts:  Jürgen Schönwälder 
j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>,
 Thomas Nadeau tnad...@lucidvision.com<mailto:tnad...@lucidvision.com> Lou 
Berger mailto:lber...@labn.net>>
Joel Jaeggli joe...@bogus.com<mailto:joe...@bogus.com> Kent Watsen 
mailto:kent+i...@watsen.net>>

To Group:  O-RAN-WG10
To Contact: Jiajin Gao, 
jacqueline.s.beau...@ericsson.com<mailto:jacqueline.s.beau...@ericsson.com>
Purpose: Information

The IETF netmod WG will progress the
- draft-ietf-netmod-yang-module-versioning
- draft-ietf-netmod-yang-semver
independently from the draft-ietf-netmod-yang-packages, 
draft-ietf-netmod-yang-ver-selection and 
draft-ietf-netmod-yang-schema-comparison.

The final, approved RFC version of the first two drafts can be estimated to be 
ready 2022-Q2 to 2023 Q1.

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

[netmod] Answer to ORAN liason

[Balázs Lengyel]

Hello,
I propose we send the following statement to ORAN as an answer to their liaison 
statement available at: https://datatracker.ietf.org/liaison/1785/
---
>From Group:   IETF / netmod
>From Contacts:  Jürgen Schönwälder 
>j.schoenwael...@jacobs-university.de,
> Thomas Nadeau tnad...@lucidvision.com Lou 
>Berger 
Joel Jaeggli joe...@bogus.com Kent Watsen 


To Group:  O-RAN-WG10
To Contact: Jiajin Gao, jacqueline.s.beau...@ericsson.com
Purpose: Information

The IETF netmod WG will progress the
- draft-ietf-netmod-yang-module-versioning
- draft-ietf-netmod-yang-semver
independently from the draft-ietf-netmod-yang-packages, 
draft-ietf-netmod-yang-ver-selection and 
draft-ietf-netmod-yang-schema-comparison.

The final, approved RFC version of the first two drafts can be estimated to be 
ready 2022-Q2 to 2023 Q1.

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

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Balázs Lengyel]

-Original Message-
From: netmod  On Behalf Of Jan Lindblad
Sent: Tuesday, 19 April, 2022 10:26
To: Balázs Lengyel 
Cc: netmod@ietf.org; Qin Wu 
Subject: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

Balázs, Qin, WG,

>> - for each extension statement the following should be described  + 
>> Changing this extension statement is a backwards-compatible change 
>> yes/no/editorial-only
> [Qin Wu] Can you provide an example for this issue or reference document, I 
> can not find any guideline in RFC7950.
> 
> BALAZS: It is the first question you get from a customer at any model 
> update/upgrade: are the changes backwards compatible?
> The modeler and the customer needs to understand whether a change in the 
> extension statements is backwards compatible or not. 
> The new YANG versioning drafts also require this knowledge.
> E.g. 
> Removing the nacm:default-deny-all extension from a leaf is backwards 
> compatible as all earlier operations will still work Adding the 
> nacm:default-deny-all extension to a leaf is not  backwards compatible as 
> writing to the leaf might not work anymore.

This is a great example of why backwards compatibility is a really hard subject.

A manager relying on nacm:default-deny-all might not be injecting the right 
NACM rules to make the managed system secure after the version change. While 
all management operations will succeed, the change opens up a security hole for 
managers unaware of the change. I believe such a change should not be described 
as backwards compatible.

My point is that while in the YANG versioning design team are working to define 
hard and fast rules for what constitutes backwards compatibility, reality is a 
few magnitudes more complex than any viable rule set.

Best Regards,
/jan

BALAZS2: Practically any change can cause operational problems if  a client 
depends on it, still not saying anything about it will be a problem. Even if we 
only consider RFC7950  terminology: Is it allowed to change this extension: 
yes, no, in what manner? This should be stated.
IMHO this is a great example of why we cannot consider all secondary effects of 
a change when considering compatibility. If we do, no change will be 
compatible. We should say allowed (compatible) changes are the ones that allow 
existing operations to succeed.

___
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] WGLC on draft-ietf-netmod-node-tags-06

[Balázs Lengyel]

>- for each extension statement the following should be described
>   + Changing this extension statement is a backwards-compatible change 
> yes/no/editorial-only
[Qin Wu] Can you provide an example for this issue or reference document, I can 
not find any guideline in RFC7950.

BALAZS: It is the first question you get from a customer at any model 
update/upgrade: are the changes backwards compatible?
The modeler and the customer needs to understand whether a change in the 
extension statements is backwards compatible or not. 
The new YANG versioning drafts also require this knowledge.
E.g. 
Removing the nacm:default-deny-all extension from a leaf is backwards 
compatible as all earlier operations will still work
Adding the nacm:default-deny-all extension to a leaf is not  backwards 
compatible as writing to the leaf might not work anymore.

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

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Balázs Lengyel]

Hello,
Sorry for the late comments as I am not very familiar with the topic, but some 
questions:
- What makes a tag "self-describing" ? Unless this "self-describing" has a 
specific meaning, it would be easier not use it. I personally would prefer 
instead of "self-describing  data object tags" some simpler name like "data 
properties".
- In the YANG module I found the sentence: " The argument 'tag' is of type 
'tag' "  Where is the "type tag" defined ?  If you mean from RFC 8819 indicate 
that e.g. by using the yang prefix: tags:tag.
- Reserved Tags: As I understand other SDOs may register their own prefix with 
IANA in which case the list of :reserved for future use" is not the correct 
characterization.
- tags can be associated with "data-objects" - RFC7950 does not use the 
terminology "data object". Please call this "data nodes" or "data node 
instances" and define in the terminology section if you use it. 
- is the tag (property) inherited down the containment hierarchy? If a 
container is marked with a tag, do all its contained leaves inherit the tag ? 
- for each extension statement the following should be described
   +  It can be a substatement of which parent statement, with what cardinality?
+ Can it have substatements
   + Changing this extension statement is a backwards-compatible change 
yes/no/editorial-only
   + Define the type as yang type. Is the list of possible values closed or can 
any string be used that fulfills the type-tag
- Security considerations calls these tags met-data. While from a broader 
perspective that may be true, these tags are not metadata according to RFC 
7952. Avoid using this terminology or clarify this.
- "name" is not a very good name for a leaf containing an 
node-instance-identifier. 
-IMHO module ietf-data-object-tags-state should augment ietf-module-tags-state 
not ietf-module-tags
- Why does ietf-data-object-tags-state redefine the extensions? Duplication is 
bad.
- Shoudn't there be an editor's note about replacing  with the RFC number?
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Qin Wu
Sent: Monday, 11 April, 2022 15:43
To: Jürgen Schönwälder 
Cc: netmod@ietf.org
Subject: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

Hi, Jurgen:
-邮件原件-
发件人: Jürgen Schönwälder [mailto:j.schoenwael...@jacobs-university.de]
发送时间: 2022年4月11日 20:18
收件人: Qin Wu 
抄送: Kent Watsen ; netmod@ietf.org
主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

On Mon, Apr 11, 2022 at 11:52:10AM +, Qin Wu wrote:
> >I have not read the document in detail yet but I find the notion of 
> >data objects and subobjects confusing. I also do not know what "massive" 
> >data object collections are or why both objects and subobjects can be 
> >modeled as YANG data nodes, or what the purpose of this statement is.
> 
> [Qin Wu] massive data collection might consume large amount of network 
> bandwidth resource and computation resource. the data node tag help us 
> capture characteristics data (e.g., KPI data) and greatly reduce the data to 
> exported to the collectors.
> Take example-module-A as an example:
>module example-module-A {
>  //...
>  container top {
>list X {
>  leaf foo {
>  }
>  leaf bar {
>  }
>}
>  }
>  // ...
>}
> The top level node will be seen as data object while leaf foo and leaf bar 
> will be seen as subobject, the top level node will be tagged with Object tag, 
> the child node will be tagged with other tag such as metric tag or metric 
> type tags.
> Note that the notion of data objects and subobjects is only used in the usage 
> example in section 3. Do you think it is confusing to introduce new 
> terminologies, if yes, I will see how to fix this.

I strongly disagree with introducing new terminology. The notion of a data 
object or a subobject does not exist in YANG. All the YANG model does is to 
associate tags with yang-node-identifiers. That's it and I think the document 
should restrict itself to explain that.
[Qin Wu] Fair point, I will remove these new terms. Thanks!
My comment was actually more about words like "massive" being a purely 
subjective term. Marketing people may use them but in technical writing or even 
scientific writing, they have no real meaning. 
[Qin Wu] Thanks for pointing this out, I didn't realize this is an issue before 
you flag this, what I emphasize large amount of data you need to collect, maybe 
should choose the better term, thanks.
If you are worried about scalability (and I would), then the question to ask 
may be whether a single flat list is scalable to large numbers of tags, i.e., 
how many queries do I need to find all relevant tags and how do the queries 
scale.
[Qin Wu] Again those tags defined in this draft are used to classify the data, 
the number of standard tag defined in this draft is not too many. At the schema 
level, I think the scale is not a problem, since the tag at the schema level 

[netmod] Difference between current() and "."

[Balázs Lengyel]

Hello Xpath experts,
What is the difference between the meaning of
Current()
And "." Single dot
In YANG-Xpath ?

must ". <= 10"


must "current() <= 10"

Are these the same?
Regards Balazs
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Balazs Review of draft-ma-netmod-with-system-02

[Balázs Lengyel]

See BALAZS3 below.
regards Balazs

From: Jan Lindblad 
Sent: Wednesday, 30 March, 2022 16:12
To: Balázs Lengyel ; maqiufang (A) 

Cc: NetMod WG 
Subject: Re: [netmod] Balazs Review of draft-ma-netmod-with-system-02

Hello Balázs, Qiufang,

I've added some comments below as JANL.

Hi, Balazs,
Thanks for your thorough review and valuable comments!
To be brief, I will incorporate some of them to the update, but I think there 
are still a couple of comments that need further discussion, like:

·Terminology to differentiate between the same(-path) data nodes in 
different datastores(e.g., system and running).
BALAZS2: MY best idea is to ALWAYS say:
   The “interface data node in ”
   “/running/interfaces/interface/name”  - so prefix the datastore 
name to the path

JANL: Actually, I think this notation is rather confusing. How about 
:running:/interfaces/interface/name ?
BALAZS3:OK, I tried to follow the Restconf notation, but I am ok with your 
proposal.



·Should “copy-config” operation also be augmented to support 
“resolve-system” parameter?
BALAZS2: IMO yes. If you copy a complete configuration from a file to running, 
you will still need parts of  to make the new content of  
valid.

JANL: I think this makes sense.


·The potential NBC issue behind this principle: If the "resolve-system" 
parameter is not given by the client, the server MUST NOT modify  in 
any way not specified by the client.
BALAZS2: I very strongly oppose this restriction because it is: a bad idea, 
unenforceable, NBC and would be a problem for other SDOs.

JANL: I could accept watering down MUST NOT to SHOULD NOT.
BALAZS3: Sorry, I know system-set data has its problems, but my arguments still 
stand.


·Will the update of  be reflected into ? If not, will 
this cause an invalid  datastore?
BALAZS2: I see this similar as an upgrade problem. Following RFC7950 section 11 
rules: During an upgrade you may obsolete a schema node, this remove it, or you 
may add a default value. Both changes may make an existing configuration 
invalid. System configuration should also be changed only very carefully 
because it may cause an invalid configuration, in which case the change to 
system-configuration probably should be rejected / not-allowed.

JANL: At system upgrade, I think autoconfig (system modifying its own 
configuration) is acceptable. Such changes could be seen as actions made by a 
system-internal client.

Automatic updates in running is a tricky problem. E.g. will you remove 
configuration of an interface if the HW is removed? There might be a lot of 
data nodes configured based on it. There might be leafrefs pointing at the 
interface.

JANL: As many of you know, I'm not particularly happy about such changes (I 
prefer the configuration to be left intact, but the oper state to change to 
down/hardware-missing, etc) but if someone insists, these situations too could 
be seen as management operations executed over a different protocol (the 
operator-manipulates-the-hardware-protocol). In this case the system-internal 
client making config updates is responsible for ensuring running stays valid at 
all times.
BALAZS3:  I see this similar to an upgrade. At time of an upgrade or 
system-config changes you may need to adjust your configuration. E.g. confd 
does that. IMHO changing the system-configuration is just as serious matter as 
an upgrade. It should happen rarely and be done carefully. I don’t have a 
strong opinion about this yet, but I feel we should describe whatever should be 
happening.

In section 1) we indicate automatically updating the interfaces depending on HW 
changes.  I would REALLY ! like a detailed description of this use-case. 
That would help me understand our plans better.
As I understand
when an interface is plugged in
- it will be automatically  created in  with list-entry, name, type.
-  will NOT be updated automatically
The client might copy over the created :system:/interfaces/interface into 

The client may use resolve-system property to implicitly copy over the 
:system:/interfaces/interface into 

Can a client set a different type to 
:running:/interfaces/interface[name=if0]/type then what is automatically set in 
:system:/interfaces/interface[name=if0]/type ?
- If yes, that might lead to confusion, misconfiguration (might use an 
operationalState leaf to indicate this)
- if no, this is a constraint between 2 datastores that needs to be cleanly 
explained in the draft and specified in the model
One idea for this would be to introduce a new value for the immutable flag (in 
the other draft) for the schema node “system-defined-value” meaning that the 
value in  and/or  MUST be the same as the value in  
(if system datastore is supported) otherwise the same as in  (if 
that system datastore is not supported but operational is) or the same as a 
system defined value documented in an implementation specific manner (if 
neither system nor o

Re: [netmod] Balazs Review of draft-ma-netmod-with-system-02

[Balázs Lengyel]

Hello Quifang,
See comments as BALAZS2 below.
Regards Balazs

From: maqiufang (A) 
Sent: Tuesday, 29 March, 2022 08:10
To: Balázs Lengyel 
Cc: NetMod WG 
Subject: RE: [netmod] Balazs Review of draft-ma-netmod-with-system-02

Hi, Balazs,
Thanks for your thorough review and valuable comments!
To be brief, I will incorporate some of them to the update, but I think there 
are still a couple of comments that need further discussion, like:

  *   Terminology to differentiate between the same(-path) data nodes in 
different datastores(e.g., system and running).
BALAZS2: MY best idea is to ALWAYS say:
   The "interface data node in "
   "/running/interfaces/interface/name"  - so prefix the datastore 
name to the path

  *   Should "copy-config" operation also be augmented to support 
"resolve-system" parameter?
BALAZS2: IMO yes. If you copy a complete configuration from a file to running, 
you will still need parts of  to make the new content of  
valid.

  *   The potential NBC issue behind this principle: If the "resolve-system" 
parameter is not given by the client, the server MUST NOT modify  in 
any way not specified by the client.
BALAZS2: I very strongly oppose this restriction because it is: a bad idea, 
unenforceable, NBC and would be a problem for other SDOs.

  *   Will the update of  be reflected into ? If not, will 
this cause an invalid  datastore?
BALAZS2: I see this similar as an upgrade problem. Following RFC7950 section 11 
rules: During an upgrade you may obsolete a schema node, this remove it, or you 
may add a default value. Both changes may make an existing configuration 
invalid. System configuration should also be changed only very carefully 
because it may cause an invalid configuration, in which case the change to 
system-configuration probably should be rejected / not-allowed.
Automatic updates in running is a tricky problem. E.g. will you remove 
configuration of an interface if the HW is removed? There might be a lot of 
data nodes configured based on it. There might be leafrefs pointing at the 
interface.


Please also see my detailed reply inline.

Best Regards,
Qiufang
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Balázs Lengyel
Sent: Thursday, March 24, 2022 2:47 AM
To: 'netmod@ietf.org' mailto:netmod@ietf.org>>
Subject: [netmod] Balazs Review of draft-ma-netmod-with-system-02

Hello,
I did a detailed review of the system draft. My comments questions are below.
Regards Balazs

===

General)
I think this work is important and valuable, but it needs quite a lot 
improvements.

The term system-configuration is used confusingly. Does
system-configuration reside in the  datastore only or can it
reside in the  datastore too? If system-configuration is copied by
the client (+) into the  datastore is it
still system-configuration? It is set by the client this time not the system.
[Qiufang] Yes, I agree.
System configuration is provided by the device in  datastore, though I 
think it may also be present in  with origin="system".
If it is copied/pasted into , the copied configuration in  
should not be called as "system configuration".
But I think it's okay to say something like "copy system configuration into 
", the object to be copied is system configuration which is defined in 
.
BALAZS2: So the definition of system-config is:
System configuration:  Configuration that is provided by the system itself. It 
is the configuration that is stored in the  datastore or the 
configuration data stored in the  datastore with origin=system.
This means that
Some terminology is needed to indicate that you mean a specific data node
IN A SPECIFIC DATASTORE. The same data node (according to the path in the
data tree) in different datastores need to be referenced separately.
[Qiufang]Cross-datastores references is not the intention here.
Any suggestions to make it clear or what does the terminology looks like in 
your mind?

Does the solution allow conditional system configuration?
(E.g.,  if the client creates an OSPF interface the system inserts a child leaf 
into it)
[Qiufang] Yes, it does. System configurations which are provided and activated 
based on specific conditions being met in a system, it is defined as 
"Conditionally-Active system configuration".
https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system-02.txt#section-2.2
 describes this kind of system configuration.

1.1) If system shares the same schema as running that would force it to
populate mandatory nodes.  That might be a problem.
State that mandatory or min-elements might not be enforced in .
[Qiufang] I think that mandatory or min/max-elements nodes should be enforced 
in . There should be no exceptions.
What's the problem that you think might happen?
1.3) "client may overwrite values of configurations defined in "
However i

Re: [netmod] [CCAMP][TEAS][NETMOD] Efficiency issues with YANG model data in integration

[Balázs Lengyel]

Hello,
There have been a number of SDOs and other groups that were requiring 
object-oriented constructs in YANG. However we were out-voted.

Myself I am trying to map 3GPP objects to YANG (3gpp TS 32.160 section 6.2 
https://www.3gpp.org/ftp/Specs/archive/32_series/32.160/32160-h30.zip).  I am 
trying to find a balance between mimicking object-orientation and keeping YANG 
readable. It is not always easy. 

I know that there are similar efforts in ITU and other organizations. Scott may 
have a full list of such efforts.
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Robert Varga
Sent: Friday, 25 March, 2022 23:17
To: tom petch ; yuchaode 
; 'netmod@ietf.org' 
Cc: Fatai Zhang 
Subject: Re: [netmod] [CCAMP][TEAS][NETMOD] Efficiency issues with YANG model 
data in integration

On 17/03/2022 17:32, tom petch wrote:
> 
> When the data definition language that we know as YANG was being 
> specified, the question did arise of how object-oriented it should be 
> and the consensus was that it should not be.  Seeking to retrofit such 
> a concept might be a bit like finding late in the day that the class 
> definitions that have been chosen do not go high up enough the tree:-(
> 
> An interesting idea but I am not sure how feasible it will prove to be.

RFC6095 might be a starting point for that sort of work. I am not sure anybody 
ever implement that, though.

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

Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

[Balázs Lengyel]

Hello Jan,
I don’t see a specific need for timestamps, so I can accept your arguments 
against it. Just add a sentence about it somewhere into the draft. It can be an 
appendix.

Common/Uniform ETAGs for multiple interfaces is only important if you actually 
use multiple interfaces. That actually happens when troubleshooters use a big 
OSS system to do most of the work, but also use a thin client or the CLI to 
check a few things during the process. So yes uniform Etags are important.
Regards Balazs

From: Jan Lindblad 
Sent: Thursday, 24 March, 2022 21:38
To: Andy Bierman ; Balázs Lengyel 
; Kent Watsen 
Cc: netmod@ietf.org
Subject: Re: [netmod] Common etag, timestamp on all interfaces 
(draft-lindblad-netconf-transaction-id)

Andy, Balazs, Kent,

Thanks for your very good questions. Comments inline.
I assume that the etag defined in your I-D is the same as the one defined in 
Restconf. Does or should your draft include a statement like:
“The etag values maintained by the server are protocol/interface independent. 
If requested the same etag values will be visible on all interface including 
Restconf, Netconf, CLI etc.”

While it makes sense that a server would use the same values across protocols, 
I'm unsure if it's needed and, if we do, if we could state it in a 
NETCONF-specific draft.
BALAZS2: I see it as a VERY important advantage of the whole 
YANG/Netconf/Restconf ecosystem that the separate protocols (practically 
including the CLI and possibly a gui too) are just views of the same central 
configuration datastore. So IMO this is important and should be stated.
As an implementor, I think it makes great sense to use the same underlaying 
mechanism for all mgmt interfaces.

I could imagine some implementors planning to lean on the wire representation 
to compute hashes over the data as their ETag implementation. That would not be 
possible under this requirement, but ruling out that particular idea would not 
be problematic, imo.

Long ago, I pondered this question for a while, but then I wasn't able to think 
of a use case where a client would benefit from a guarantee that all interfaces 
have common ETags, so I left it out in order to not produce a CLR. I'm not 
against adding this requirement if we can think of a reasonable reason why. 
Adding a requirement for CLI+GUI sounds hard in practice, though.
I strongly support this approach.
It applies to the entire server API, including notifications.
E.g., a client should be able to reuse code for processing NETCONF 
notifications,
even if the protocol is RESTCONF or the new YANG-Push over UDP.

The RESTCONF mechanisms adapted from HTTP should be extended to be
protocol-independent.  Our goal should be code to the YANG models, NOT the 
protocols.

Yes, I certainly like that.
Restconf also includes timestamps. What was your reason to exclude them from 
your I-D ? IMHO if the server maintains timestamps they would be 
protocol/interface independent just as etags, so the task is to make them 
available on Netconf too (and maybe the CLI).
I agree and have mentioned before.  LastModified either needs to be added, or 
justified why not added, to get my adoption support.
I'm not against having Last-Modified in there. In fact, it was in the draft 
initially. Here's the justification why I removed it :-)

+ When I started the cost/benefit analysis for what I proposed, I soon found 
that it's not unimportant how many and how large ETag attributes are added to 
the payload. Having two mechanisms (i.e. both ETag and Last-Modified) doing 
pretty much the same thing started to look expensive in performance.
+ Since it's essential that the time stamp would have to be the same on all 
touched elements, all the components/subsystems/subagents involved would still 
have to be fed the exact time from the central management agent.
+ Then there's one or two more things with If-Unmodified-Since that I discuss 
below.

I agree. They both need to be supported in RESTCONF.

RESTCONF has a SHOULD for the (single) datastore root level and MAY for the 
deeper levels.

A timestamp can be applied to multiple servers, unlike the ETag values.

I don't think this analysis is correct. A client connecting with 15 servers in 
a network wide transaction would surely receive several differing timestamps. 
The times may be fairly close if NTP is running fine, latency is low, network 
and cpu load is even and the servers are running similar code, but they will 
rarely all be the same even with the low 1s Last-Modified resolution. If you 
allow clients to set the ETag in the request (which is trivial to allow), then 
the tags could be exactly the same across all servers (and known to the client 
before the request is even sent to the servers, allowing request pipelining).


Typical usage is for the client to track its own polling timestamps,
and use If-Modified-Since to retrieve data only if needed.
The same timestamp can also be used with If-Unmodified-Since for edits.

If-Unmodified

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

[Balázs Lengyel]

See as BALAZS3, below!

From: Andy Bierman 
Sent: Thursday, 24 March, 2022 18:48
To: Balázs Lengyel 
Cc: maqiufang (A) ; Kent Watsen 
; NETMOD Group 
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00



On Thu, Mar 24, 2022 at 10:14 AM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:
As mentioned earlier immutable is not enough for predefined NACM rules
because the client may always
insert a rule(-list) before the immutable rule(s) that will make the immutable
rules ineffective. The problem is that the rule(-sets) are a user ordered list
where the order matters. It is not enough to protect the individual rule(sets)
the order would also need protection.


The NMDA solution would be to simply list the effective rule-lists in 
.
The server rule-list will always be first in  and not even exist 
in .

I think a standard solution has a higher bar than our proprietary extensions.
The interactions with NACM need to be properly handled.

IMO a proper solution would be an update to NACM itself.
The reason nacm:default-deny-write and nacm:default-deny-all work,
even though they are optional extensions, is because they are mandatory 
extensions
if NACM is supported.

A nacm:static-data extension would be similar to the other 2 extensions.
They are short-hand automatic NACM rules.
NACM itself explains how they are handled so there is no conflict with 
user-provided rule-lists.

BALAZS3: For me it is not really important whether we define the static-data or 
immutable extension in a new draft/RFC or whether we put it into a new version 
or NACM. Whichever is easier to get standardized.

From: maqiufang (A) 
mailto:40huawei@dmarc.ietf.org>>
Sent: Thursday, 24 March, 2022 15:23
To: Andy Bierman mailto:a...@yumaworks.com>>
Cc: Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>>; Kent Watsen 
mailto:kent%2bi...@watsen.net>>; NETMOD Group 
mailto:netmod@ietf.org>>
Subject: RE: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi, Andy, Balazs,

I can see your points in some of the use cases.
But as Kent mentioned, the motivation of this work is that we have some 
system-defined instance which are read-only to clients.
And there may be some cases where a list/leaf-list data node may exist in 
multiple instances with different control rules.

To be specific, An instance-level annotation could be useful in following use 
cases:

a)  The system generates some QoS templates when QoS functionality is 
enabled, and some of the generated templates are read-only, while others are 
free to be updated by the clients.

b) The system predefines some list/leaf-list instances which are read-only 
for clients(the clients cannot update or delete them, like predefined NACM 
rules), but the clients is free to add/update/delete their own defined 
instances.

While YANG-extension can be useful for a schema-level immutability.
I am thinking that, maybe we need both to complete the solution?

Best Regards,
Qiufang

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Andy Bierman
Sent: Thursday, March 24, 2022 7:14 AM
To: Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00



On Wed, Mar 23, 2022 at 3:06 PM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:


From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: Wednesday, 23 March, 2022 22:32
To: Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00



On Wed, Mar 23, 2022 at 2:16 PM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:
Hello Andy,
I also propose an extension. (see my mail Review of 
draft-ma-netmod-immutable-flag-00)
In Ericsson we saw no need for exceptions, but do see the need for applying it 
to descendant nodes. Typically we need to protect a full subtree.

Why do you need the exceptions? Could you provide some use-case examples ?

I think create/delete-only and modify-only access modes are used the most, 
after no-access.
BALAZS: How is a modify-only data-node different from a mandatory data-node? It 
must be there but can be changed. It get’s an initial value somehow.

Mandatory=true requires the system to provide a value.
Modify-only allows the system to decide when an instance is created.


BALAZS: Any examples when would a create/delete only data node be used?

Sometimes developers do not want to write complex instrumentation that supports
modification of resources.  Instead a user has to delete the old entry and 
create a new
one with (potentially) different parameters.



Applying to descendant nodes may be better, or may require more work to
undo the extension used in an ancestor node. This impacts the extension usage 
within a grouping.

BALAZS2: I did not in

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

[Balázs Lengyel]

As mentioned earlier immutable is not enough for predefined NACM rules
because the client may always
insert a rule(-list) before the immutable rule(s) that will make the immutable
rules ineffective. The problem is that the rule(-sets) are a user ordered list
where the order matters. It is not enough to protect the individual rule(sets)
the order would also need protection.
Balazs

From: maqiufang (A) 
Sent: Thursday, 24 March, 2022 15:23
To: Andy Bierman 
Cc: Balázs Lengyel ; Kent Watsen 
; NETMOD Group 
Subject: RE: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi, Andy, Balazs,

I can see your points in some of the use cases.
But as Kent mentioned, the motivation of this work is that we have some 
system-defined instance which are read-only to clients.
And there may be some cases where a list/leaf-list data node may exist in 
multiple instances with different control rules.

To be specific, An instance-level annotation could be useful in following use 
cases:

a)  The system generates some QoS templates when QoS functionality is 
enabled, and some of the generated templates are read-only, while others are 
free to be updated by the clients.

b) The system predefines some list/leaf-list instances which are read-only 
for clients(the clients cannot update or delete them, like predefined NACM 
rules), but the clients is free to add/update/delete their own defined 
instances.

While YANG-extension can be useful for a schema-level immutability.
I am thinking that, maybe we need both to complete the solution?

Best Regards,
Qiufang

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Andy Bierman
Sent: Thursday, March 24, 2022 7:14 AM
To: Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00



On Wed, Mar 23, 2022 at 3:06 PM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:


From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: Wednesday, 23 March, 2022 22:32
To: Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00



On Wed, Mar 23, 2022 at 2:16 PM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:
Hello Andy,
I also propose an extension. (see my mail Review of 
draft-ma-netmod-immutable-flag-00)
In Ericsson we saw no need for exceptions, but do see the need for applying it 
to descendant nodes. Typically we need to protect a full subtree.

Why do you need the exceptions? Could you provide some use-case examples ?

I think create/delete-only and modify-only access modes are used the most, 
after no-access.
BALAZS: How is a modify-only data-node different from a mandatory data-node? It 
must be there but can be changed. It get’s an initial value somehow.

Mandatory=true requires the system to provide a value.
Modify-only allows the system to decide when an instance is created.


BALAZS: Any examples when would a create/delete only data node be used?

Sometimes developers do not want to write complex instrumentation that supports
modification of resources.  Instead a user has to delete the old entry and 
create a new
one with (potentially) different parameters.



Applying to descendant nodes may be better, or may require more work to
undo the extension used in an ancestor node. This impacts the extension usage 
within a grouping.

BALAZS2: I did not include it in my mail, but we actually have one more rule:
“Top level statements in augment or groupings do NOT inherit
   the static-data value from containing nodes, they default to
   static-data false.”


This seems complicated to users and developers to track how the final schema 
tree was derived.

The 'static-data' extension seems fine to me.
We have to support 'user-write' anyways, so it is better if it is not too close 
to this extension.
Things that seem the same, but are NOT the same cause the most support tickets.


Regards Balazs

Andy

Andy




From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Andy Bierman
Sent: Wednesday, 23 March, 2022 21:10
To: NetMod WG mailto:netmod@ietf.org>>
Subject: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi,

IMO the problem should be viewed as a refinement to the
access control policy of the device.  A standard mechanism
such as a YANG extension would be better than a growing
mix of proprietary solutions.

We have such a YANG extension called "user-write" that is widely deployed.
A simple boolean is not fine enough granularity, so a bits type is
needed instead to allow control of create, update, and delete access operations.


https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-876c03f0bc610d95=1=c875257

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

[Balázs Lengyel]

Hello,
So it seems we agree, that a schema level immutable property based on yang 
extensions is needed. (I am not commenting on the other parts just now.)
Regards Balazs

From: Andy Bierman 
Sent: Thursday, 24 March, 2022 16:13
To: maqiufang (A) 
Cc: Balázs Lengyel ; Kent Watsen 
; NETMOD Group 
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00



On Thu, Mar 24, 2022 at 7:22 AM maqiufang (A) 
mailto:maqiufa...@huawei.com>> wrote:
Hi, Andy, Balazs,

I can see your points in some of the use cases.
But as Kent mentioned, the motivation of this work is that we have some 
system-defined instance which are read-only to clients.
And there may be some cases where a list/leaf-list data node may exist in 
multiple instances with different control rules.

To be specific, An instance-level annotation could be useful in following use 
cases:

a)   The system generates some QoS templates when QoS functionality is 
enabled, and some of the generated templates are read-only, while others are 
free to be updated by the clients.

b)   The system predefines some list/leaf-list instances which are 
read-only for clients(the clients cannot update or delete them, like predefined 
NACM rules), but the clients is free to add/update/delete their own defined 
instances.

While YANG-extension can be useful for a schema-level immutability.
I am thinking that, maybe we need both to complete the solution?

IMO the instance-level is not interesting and should not be standardized.
The only common usage seems to be a simple boolean flag.
It looks like access control to me because it is access control.
If an operator created NACM rules allowing client access to a static node,
then the NACM config would be ignored and the operator would be confused.
This problem exists no matter what external (AND PURELY OPTIONAL) statement is 
used.



Best Regards,
Qiufang

Andy


From: netmod [mailto:netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>] 
On Behalf Of Andy Bierman
Sent: Thursday, March 24, 2022 7:14 AM
To: Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00



On Wed, Mar 23, 2022 at 3:06 PM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:


From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: Wednesday, 23 March, 2022 22:32
To: Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00



On Wed, Mar 23, 2022 at 2:16 PM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:
Hello Andy,
I also propose an extension. (see my mail Review of 
draft-ma-netmod-immutable-flag-00)
In Ericsson we saw no need for exceptions, but do see the need for applying it 
to descendant nodes. Typically we need to protect a full subtree.

Why do you need the exceptions? Could you provide some use-case examples ?

I think create/delete-only and modify-only access modes are used the most, 
after no-access.
BALAZS: How is a modify-only data-node different from a mandatory data-node? It 
must be there but can be changed. It get’s an initial value somehow.

Mandatory=true requires the system to provide a value.
Modify-only allows the system to decide when an instance is created.


BALAZS: Any examples when would a create/delete only data node be used?

Sometimes developers do not want to write complex instrumentation that supports
modification of resources.  Instead a user has to delete the old entry and 
create a new
one with (potentially) different parameters.



Applying to descendant nodes may be better, or may require more work to
undo the extension used in an ancestor node. This impacts the extension usage 
within a grouping.

BALAZS2: I did not include it in my mail, but we actually have one more rule:
“Top level statements in augment or groupings do NOT inherit
   the static-data value from containing nodes, they default to
   static-data false.”


This seems complicated to users and developers to track how the final schema 
tree was derived.

The 'static-data' extension seems fine to me.
We have to support 'user-write' anyways, so it is better if it is not too close 
to this extension.
Things that seem the same, but are NOT the same cause the most support tickets.


Regards Balazs

Andy

Andy




From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Andy Bierman
Sent: Wednesday, 23 March, 2022 21:10
To: NetMod WG mailto:netmod@ietf.org>>
Subject: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi,

IMO the problem should be viewed as a refinement to the
access control policy of the device.  A standard mechanism
such as a YANG extension would be better than a growing
mix of proprietary solutions.

We have such a YANG extension called "user-write" that is wide

Re: [netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

[Balázs Lengyel]

From: Kent Watsen 
Sent: Thursday, 24 March, 2022 00:05
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Common etag, timestamp on all interfaces 
(draft-lindblad-netconf-transaction-id)




I assume that the etag defined in your I-D is the same as the one defined in 
Restconf. Does or should your draft include a statement like:
“The etag values maintained by the server are protocol/interface independent. 
If requested the same etag values will be visible on all interface including 
Restconf, Netconf, CLI etc.”

While it makes sense that a server would use the same values across protocols, 
I'm unsure if it's needed and, if we do, if we could state it in a 
NETCONF-specific draft.
BALAZS2: I see it as a VERY important advantage of the whole 
YANG/Netconf/Restconf ecosystem that the separate protocols (practically 
including the CLI and possibly a gui too) are just views of the same central 
configuration datastore. So IMO this is important and should be stated.


Restconf also includes timestamps. What was your reason to exclude them from 
your I-D ? IMHO if the server maintains timestamps they would be 
protocol/interface independent just as etags, so the task is to make them 
available on Netconf too (and maybe the CLI).

I agree and have mentioned before.  LastModified either needs to be added, or 
justified why not added, to get my adoption support.



Regards Balazs

Kent // contributor


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

[netmod] Common etag, timestamp on all interfaces (draft-lindblad-netconf-transaction-id)

[Balázs Lengyel]

Hello Jan,
I assume that the etag defined in your I-D is the same as the one defined in 
Restconf. Does or should your draft include a statement like:
"The etag values maintained by the server are protocol/interface independent. 
If requested the same etag values will be visible on all interface including 
Restconf, Netconf, CLI etc."

Restconf also includes timestamps. What was your reason to exclude them from 
your I-D ? IMHO if the server maintains timestamps they would be 
protocol/interface independent just as etags, so the task is to make them 
available on Netconf too (and maybe the CLI).
Regards Balazs
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

[Balázs Lengyel]

Hello Kent, Andy,
I see more problems with an access control based immutable solution.
- user-dependency as Kent mentioned
- it is always possible to insert a new rule(set) at the beginning of the NACM 
list that overrides other rules. We would need to ensure that these rules stay 
the first
- there is a need to protect the access control rules protecting immutable data 
nodes; then rules to protect the rules that protect the rules that protect ...
- access control can be switched off
- access control does not work for emergency sessions
- access control rules that reference different part of the systems are MUCH 
more difficult to understand than a yang-extension statement immutable. 
Especially if you have an access control list with many (hundreds of) rules
Regards Balazs

From: netmod  On Behalf Of Kent Watsen
Sent: Wednesday, 23 March, 2022 23:07
To: Andy Bierman 
Cc: netmod@ietf.org
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi Andy,

The draft allows individual data instance nodes (e.g., in a list) to be flagged 
as immutable:



   The following terms are defined in this document:



   immutable:  A metadata annotation indicating the immutability of a

  data node.  An immutable data node is read-only to clients.  Note

  that "immutable" is used to annotate instances of YANG data nodes

  rather than schema nodes.  For instance, a "list" data node may

  exist in multiple instances in the data tree, "immutable" can

  annotate some of the instances as read-only, while others are not.


If it were not for that, then an access-control refinement seems appropriate, 
because then it would have to be user-specific, whereas this draft enables 
user-independant immutability.

As for *why* this draft enables individual data instance nodes to be flagged as 
immutable (a question asked in other recent review comments), please note that 
this work came out of the "with-system" work after a number of folks (myself 
included) noted that the concept was independent of a  datastore.  For 
instance, I defined a similar mechanism in a past life to handle objects 
published from a host-system to logical-systems (LNEs).

The most common example for such a need is with interfaces, e.g., the 
host-system publishes "eth-3.1.2" to a logical-system, where it is unable to 
delete it (whereas it is deletable in the host-system's config).  That said 
(playing devil's advocate), I wonder if, in this example, the interfaces, when 
published to a logical-system, should be published to the  datastore 
(because they're effectively a system-defined resource then, from the LNE's 
POV) and hence pickup their immutability that way.

Kent // contributor

On Mar 23, 2022, at 4:09 PM, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:

Hi,

IMO the problem should be viewed as a refinement to the
access control policy of the device.  A standard mechanism
such as a YANG extension would be better than a growing
mix of proprietary solutions.

We have such a YANG extension called "user-write" that is widely deployed.
A simple boolean is not fine enough granularity, so a bits type is
needed instead to allow control of create, update, and delete access operations.


https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write


Andy

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

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

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

[Balázs Lengyel]

From: Andy Bierman 
Sent: Wednesday, 23 March, 2022 22:32
To: Balázs Lengyel 
Cc: NetMod WG 
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00



On Wed, Mar 23, 2022 at 2:16 PM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:
Hello Andy,
I also propose an extension. (see my mail Review of 
draft-ma-netmod-immutable-flag-00)
In Ericsson we saw no need for exceptions, but do see the need for applying it 
to descendant nodes. Typically we need to protect a full subtree.

Why do you need the exceptions? Could you provide some use-case examples ?

I think create/delete-only and modify-only access modes are used the most, 
after no-access.
BALAZS: How is a modify-only data-node different from a mandatory data-node? It 
must be there but can be changed. It get’s an initial value somehow.
BALAZS: Any examples when would a create/delete only data node be used?

Applying to descendant nodes may be better, or may require more work to
undo the extension used in an ancestor node. This impacts the extension usage 
within a grouping.

BALAZS2: I did not include it in my mail, but we actually have one more rule:
“Top level statements in augment or groupings do NOT inherit
   the static-data value from containing nodes, they default to
   static-data false.”


Regards Balazs

Andy


From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Andy Bierman
Sent: Wednesday, 23 March, 2022 21:10
To: NetMod WG mailto:netmod@ietf.org>>
Subject: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi,

IMO the problem should be viewed as a refinement to the
access control policy of the device.  A standard mechanism
such as a YANG extension would be better than a growing
mix of proprietary solutions.

We have such a YANG extension called "user-write" that is widely deployed.
A simple boolean is not fine enough granularity, so a bits type is
needed instead to allow control of create, update, and delete access operations.


https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-876c03f0bc610d95=1=c875257e-41f5-45d6-a9e9-871e5ebb4243=https%3A%2F%2Fwww.yumaworks.com%2Fpub%2Flatest%2Fyangauto%2Fyumapro-yangauto-guide.html%23ncx-user-write>


Andy

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

Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

[Balázs Lengyel]

Hello Andy,
I also propose an extension. (see my mail Review of 
draft-ma-netmod-immutable-flag-00)
In Ericsson we saw no need for exceptions, but do see the need for applying it 
to descendant nodes. Typically we need to protect a full subtree.

Why do you need the exceptions? Could you provide some use-case examples ?
Regards Balazs

From: netmod  On Behalf Of Andy Bierman
Sent: Wednesday, 23 March, 2022 21:10
To: NetMod WG 
Subject: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi,

IMO the problem should be viewed as a refinement to the
access control policy of the device.  A standard mechanism
such as a YANG extension would be better than a growing
mix of proprietary solutions.

We have such a YANG extension called "user-write" that is widely deployed.
A simple boolean is not fine enough granularity, so a bits type is
needed instead to allow control of create, update, and delete access operations.


https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write


Andy

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

[netmod] Review of draft-ma-netmod-immutable-flag-00

[Balázs Lengyel]

Hello,
I did a review of the immutable draft. My comments questions are below.
Regards Balazs

General)
I think this work is important and valuable, but it needs quite a lot 
improvements.

Why is immutable connected to instances. IMO it should be a schema property.
If we connect it to instances it is hard/impossible to specify "it is 
prohibited to create a
new container, list entry of leaf-list value". That is clearly needed for the
capability-check use-case. Maybe allow it on both schema and instance ?

If we make this a schema property it can be documented in a transparent manner
with a YANG extension statement. If it is handled as instance connected metadata
the client cannot know a-priori whether a data node is or is not immutable. 
This information
is only available in runtime. System integrators, OSS developers will have a 
problem.

As immutability is connected to instance (now) this raises the question how
stable this property is?
- We don't say anything; the server can keep it stable or make the data node
immutable every odd second and writable every even second
- The property should be relatively stable in an unspecified manner
- The property shall be set when the data node is created and the property
should not change till the data node is deleted/replaced
- Can the immutable property be set on just some interfaces e.g. the
leaf is readOnly on the CLI but writable on Netconf ?
If we make immutable a schema-property, the problem will not arise.

IMO it would be important to list the use-cases we want to solve. I provide 3 
below.


Ch 1)
I don't like paragraph 2. Someone could say just declare the interface name
config=false which is a quite usual solution.

I would rather change the first and second paragraphs to:

"YANG [RFC7950] is a data modeling language used to model both state
and configuration data, based on the "config" statement. However there is data
that should not be modifiable by the client, but still needs to be declared
as config true. Some examples of this problem are presented below:

Interfaces are represented as list entries. The list schema node must be
defined as config=true as many of its child leaves need to be configurable by
the client. However the interface name and type values are set by the system,
based on the hardware actually present in the device, and must not be modified
by clients. The natural solution would be to declare the name (which is the
list's key) and the type as config=false. However according to the rules of
YANG the key leaf for a configuration list must also be config=true. Thus the
leaf /interfaces/interface/name is config true even if it might not be
writable in some systems.

System capabilities might be represented as system-set data nodes in the model.
Configurable data nodes might need constraints specified as "when", "must" or
"path" statements to ensure that configuration is set according to the system's
capabilities. E.g.,
- a timer can support the values 1,5,8 seconds. This is defined in the
leaf-list 'supported-timer-values'.
- When the configurable 'interface-timer' leaf is set it should be ensured that
one of the supported values is used. The natural solution would be to make the
'interface-timer' a leaf-ref pointing at the 'supported-timer-values'.
However, this is not possible as 'supported-timer-values' must be readOnly thus
config=false while 'interface-timer' must be writable thus config=true.
According to the rules of YANG it is not allowed to put a constraint between
config true and false schema nodes.

If configuration is created by the system (e.g., copied from the 
datastore to the  datastore it might need to be protected. In some
cases there is a need to ensure that system-originated configuration shall
not be altered even after it is copied over to the  datastore."


Ch 2)
"Create an immutable data node with a same value initially set by
  the system if it doesn't exist in the datastore, e.g., explicitly
  configure a system generated interface name in ;"
IMO this is not needed because
- If the data already exists in the  datastore it cannot be
created according to Netconf rules.
- If it does not exist in the  datastore there is nothing that could
be immutable as immutable is linked to the instances.
The above is independent of what is defined in 

Until now we never
had any constraints between 2 datastores like:
you can update datastore1 if datastore2 contains something.
I don't think we want to introduce that either.

"Comment: Should we allow the client delete an "immutable" system
   instantiated node in  ?"
Once a data node is instantiated there is no record where it came from.
https://datatracker.ietf.org/doc/html/rfc8342#section-5.3.4 states that origin
is only maintained in the  datastore. Unless we want to introduce
it into . So the even the question is wrong as we don't know which
data is system instantiated.

Servers MUST reject any attempt to the "create", "delete" and
   "update" access operations on 

[netmod] Balazs Review of draft-ma-netmod-with-system-02

[Balázs Lengyel]

Hello,
I did a detailed review of the system draft. My comments questions are below.
Regards Balazs

===

General)
I think this work is important and valuable, but it needs quite a lot 
improvements.

The term system-configuration is used confusingly. Does
system-configuration reside in the  datastore only or can it
reside in the  datastore too? If system-configuration is copied by
the client (+) into the  datastore is it
still system-configuration? It is set by the client this time not the system.

Some terminology is needed to indicate that you mean a specific data node
IN A SPECIFIC DATASTORE. The same data node (according to the path in the
data tree) in different datastores need to be referenced separately.

Does the solution allow conditional system configuration?
(E.g.,  if the client creates an OSPF interface the system inserts a child leaf 
into it)

1.1) If system shares the same schema as running that would force it to
populate mandatory nodes.  That might be a problem.
State that mandatory or min-elements might not be enforced in .

1.3) "client may overwrite values of configurations defined in "
However it also states: The contents of  datastore are read-only
These seem to contradict. Please clarify.

1.4) Shoudn't copy-config also be effected? Copy-config
might also need system configured items. It should be mentioned that the same
"resolution" is also needed after a node-restart.

What does populate mean? Is it the same as "copy from system to running" ? If
yes please use that terminology. Populate is not as specific.

2) In the subchapters (and later) you use the terms provided, activated, 
applied. I am not
sure what this means. Is a not yet applied item present in the 
datastore or only when it is applied? If I do a get-data on 
will I receive not-applied data nodes?

What is the difference between an applied and an activated data node and an
applied but not activated data node?

I would rather see terminology like:
- is present in the  datastore
- is not yet present in the  datastore, but the system will create it
in the  datastore when a condition is fulfilled.

How is it defined for specific schema nodes which kind of system-data it is ?
Free English text?
Is it needed to define this formally or is it enough if the server knows this?

2.2) Isn't the best example for this, when the functionality is licensed and
the license key is inserted?

3.1)  is also read-only so why is that better to store
deletable data ? Did you mean that system-config originated data cannot be
delete even if it is copied over to running? Is that true both for explicit
NBI originated copy and copy due to resolve-system?

3.2) If something was populated/copied over to running/candidate will/should
any changed system values be copied over again thereby updating the
running/candidate datastores?
Can this result in the running becoming invalid?

4.1)  You write
"The client may reference nodes defined in , overwrite values
   of configurations defined in "
IMHO the data nodes in  and  are 2 different things even
if they reside on the same path in the data tree. You need to find
terminology to differentiate between the same(-path) data nodes in different
datastores. The current terminology is confusing, I need to guess which
datastore you mean. I think this guessing process might hide problems.
Do you mean here: "The client may reference nodes defined in  if they 
are
copied into / as a result of an explicit copy or
resolve-system parameter." For me referencing a data node in running and
referencing a data node in  (even if they share the same address in
the data tree) are 2 separate things. I don't think you want to create a
reference that point between datastores.
Do you mean here: "overwrite values of the data nodes that were created by
copying from the  datastore."

" MAY overwrite and/or extend " this means that the
data nodes in system are modified although they are readOnly.
Is this what you mean? Clarify!

"Note that only  aware clients copy
   referenced system nodes from "
How does the server know if the client is system-aware? It would be better to
state something like:
'In order for the system configuration to affect validation the client needs to
either use the resolve-system parameter or explicitly copy system configuration
into running'

Last para: The server has no way to know if the client is system aware. Once
the data nodes are copied into  there is no need to say more.

4.2
"If the "resolve-system" parameter is not given by the client, the server
   MUST NOT modify  in any way not specified by the client."
I very strongly OBJECT.
- It is a bad idea.
- This is a big NBC change to Netconf/YANG.
- Other SDOs (3GPP, O-RAN) depend on the capability to modify . They
have data nodes where it is stated that list entries are not created by the 
client.
- This would need a revision 2 of YANG.
- It is also unenforceable. It would be possible to work 

Re: [netmod] Regarding IPR on Regarding IPR on draft-ietf-netmod-yang-semver-06

[Balázs Lengyel]

"No, I'm not aware of any IPR that applies to this draft"

Regards, Balazs

-Original Message-
From: Benoit Claise  
Sent: Tuesday, 1 February, 2022 08:16
To: Lou Berger ; jcla...@cisco.com; rwil...@cisco.com; 
res...@yahoo.com; Balázs Lengyel ; 
jason.ste...@nokia.com
Cc: NetMod WG ; NetMod WG Chairs 
Subject: Re: Regarding IPR on Regarding IPR on draft-ietf-netmod-yang-semver-06

"No, I'm not aware of any IPR that applies to this draft"

Regards, Benoit

On 1/31/2022 10:57 PM, Lou Berger wrote:
>
>
> Authors, Contributors, WG,
>
> As part of WG Last Call:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules 
> (see RFCs 3669, 5378 and 8179 for more details)?
>
> If yes to the above, please state either:
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>
> If you answer no, please provide any additional details you think 
> appropriate. If you are listed as a document author or contributor 
> please answer the above by responding to this email regardless of 
> whether or not you are aware of any relevant IPR. This document will 
> not advance to the next stage until a response has been received from 
> each author.
>
> NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
>
> If you are on the WG email list or attend WG meetings but are not 
> listed as an author or contributor, we remind you of your obligations 
> under the IETF IPR rules which encourages you to notify the IETF if 
> you are aware of IPR of others on an IETF contribution, or to refrain 
> from participating in any contribution or discussion related to your 
> undisclosed IPR. For more information, please see the RFCs listed 
> above and 
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
> Thank you,
> Lou (Co-Chair)
>
> PS Please include all listed in the headers of this message in your 
> response.
>
>
> .
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Regarding IPR on draft-ietf-netmod-yang-module-versioning-05

[Balázs Lengyel]

"No, I'm not aware of any IPR that applies to this draft"

Thanks,
Balazs

-Original Message-
From: Rob Wilton (rwilton)  
Sent: Tuesday, 1 February, 2022 15:05
To: Lou Berger ; Joe Clarke (jclarke) ; 
res...@yahoo.com; Balázs Lengyel ; 
jason.ste...@nokia.com
Cc: NetMod WG ; NetMod WG Chairs 
Subject: RE: Regarding IPR on draft-ietf-netmod-yang-module-versioning-05

"No, I'm not aware of any IPR that applies to this draft"

Thanks,
Rob


-Original Message-
From: Lou Berger  
Sent: 31 January 2022 21:54
To: Joe Clarke (jclarke) ; res...@yahoo.com; Rob Wilton 
(rwilton) ; balazs.leng...@ericsson.com; 
jason.ste...@nokia.com
Cc: NetMod WG ; NetMod WG Chairs 
Subject: Regarding IPR on draft-ietf-netmod-yang-module-versioning-05



Authors, Contributors, WG,

As part of WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Lou (Co-Chair)

PS Please include all listed in the headers of this message in your
response.


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

[netmod] Printable or visible string in YANG

[Balázs Lengyel]

Hello,

Is there a way in YANG to restrict a string to printable or visible
characters? (Something like SNMP DisplayString)

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

[Balázs Lengyel]

Accepted, last comment. Balazs

-Original Message-
From: Benjamin Kaduk  
Sent: 2021. október 7., csütörtök 23:45
To: Balázs Lengyel 
Cc: The IESG ; Benoit Claise ;
draft-ietf-netmod-yang-instance-file-for...@ietf.org;
netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen 
Subject: Re: Benjamin Kaduk's No Objection on
draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

Hi Balázs,

Replies inline as well (where needed)

On Thu, Oct 07, 2021 at 10:43:28AM +, Balázs Lengyel wrote:
> --
> COMMENT:
> --
> Section 2
> 
>Two formats are specified based on the XML and JSON YANG encodings.
>Later, as other YANG encodings (e.g., CBOR) are defined, further
>instance data formats may be specified.
> 
> I don't remember seeing a clear description of the specifics of these 
> two specified formats.  (I assume it's just "use the XML/JSON encoding 
> for YANG structures", but I don't remember that stated anywhere.)
> BALAZS: I added references to the relevant RFCs (7950, 7951, 8791) As the
model starts with a YAN structure, I included YANG Data Structure Extensions
RFC8791 too.

I was hoping for a statement like "The file formats are achieved by applying
the respective XML and JSON encoding rules for the YANG structure included
in this document."
BALAZS2: OK
Thanks for all the replies and updates,

Ben


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] John Scudder's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

[Balázs Lengyel]

Hello John,
Thank you for the review. I used your comments to improve the draft. See my
detailed answers below as BALAZS:
Regards Balazs

-Original Message-
From: netmod  On Behalf Of John Scudder via
Datatracker
Sent: 2021. október 7., csütörtök 15:39
To: The IESG 
Cc: netmod-cha...@ietf.org;
draft-ietf-netmod-yang-instance-file-for...@ietf.org; netmod@ietf.org
Subject: [netmod] John Scudder's No Objection on
draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

John Scudder has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-20: No Objection

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format
/



--
COMMENT:
--

Thanks for your work on this spec. Thanks also to Kent Watsen for his hard
work shepherding it.

I have some comments below which I hope may be helpful.

1. Section 1, nit, s/In Appendix C describes/Appendix C describes/ (delete
the
"in")
BALAZS: OK, will be updated

2. Section 1.4:

   A YANG instance data set is created at a specific point of time.  If
   the data changes afterwards, this is not represented in the instance
   data set anymore.  The current values may be retrieved at run-time

I think "anymore" should be cut, for several reasons, the most important of
which is that it seems to be objectively wrong. The cut would be the minimal
fix, but did you mean something more like this? "If the data changes
afterwards, the instance data will no longer represent the current data,
unless it is updated."
BALAZS: OK, will be updated with the additional text. 

3. Section 2, nit, s/constrains MAY be violated/constraints MAY be violated/
BALAZS: OK, will be updated

4. Section 2.1: I was amazed that the "external method" option, which is
essentially the "simply don't bother" option, was acceptable to the WG and
other reviewers. To my eye, the URI method option seems functionally just as
good (it keeps the content of the file itself small) while providing a
stronger (though still not very strong) assurance that the schema will
actually be available.
   Was "external method" discussed in the WG? Or am I simply in the rough
for even thinking it surprising?
BALAZS:  People stated that when instance files are used repeatedly (a new
file
generated every few seconds) in a closed, well defined environment,
the
content-schema may already be known. In this case it is not
necessary to
include it in the file.

5. Appendix C: I'm inclined to agree with the shepherd's recommendation to
remove this entire section
(https://mailarchive.ietf.org/arch/msg/netmod/5DfEi8swOmLEPykBpFICJK6398s/)
since readability is problematic and it doesn't seem to add to the usability
of the spec. Since it is, as it says, only a non-normative appendix I don't
insist, but I strongly encourage you to consider trimming or rewriting it.
BALAZS: We will consider it. Some editorial updates, trimming done.


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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

[Balázs Lengyel]

Hello Benjamin,
Thank you for the thorough review. I used your comments to improve the draft. 
See my detailed answers below as BALAZS:
Regards Balazs

-Original Message-
From: Benjamin Kaduk via Datatracker  
Sent: 2021. október 7., csütörtök 6:55
To: The IESG 
Cc: draft-ietf-netmod-yang-instance-file-for...@ietf.org; 
netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen ; 
kent+i...@watsen.net
Subject: Benjamin Kaduk's No Objection on 
draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-20: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/



--
COMMENT:
--

Should we register media-types for the file formats being specified?

Section 2

   Two formats are specified based on the XML and JSON YANG encodings.
   Later, as other YANG encodings (e.g., CBOR) are defined, further
   instance data formats may be specified.

I don't remember seeing a clear description of the specifics of these two 
specified formats.  (I assume it's just "use the XML/JSON encoding for YANG 
structures", but I don't remember that stated anywhere.)
BALAZS: I added references to the relevant RFCs (7950, 7951, 8791) As the model 
starts with a YAN structure, I included YANG Data Structure Extensions RFC8791 
too.

   The name of the instance data file SHOULD be of the form:

  instance-data-set-name ['@' ( revision-date / timestamp ) ]
 ( '.xml' / '.json' )

This looks (almost?  Not sure about '@' vs. "@".) like valid ABNF.  Do we want 
to say that and reference RFC 5234 for the interpretation of the symbols?
BALAZS: reference to ABNF added. Changed to double quotes.

   If the leaf "name" is present in the instance data header, its value
   SHOULD be used for the "instance-data-set-name".  If the "revision-
   date" is present in the filename it MUST conform to the format of the
   revision-date leaf in the YANG model.  [...]

This seems unenforcable, and contrary to the Unix ethos.  Why is it necessary 
to try to have consistency betwen the contents of the file and its name in the 
file system, as opposed to letting the type and contents of a file speak for 
itself regardless of the name in the file system?
BALAZS: We use the convention of RFC7950: to use the name of the top YANG 
construct 
in the filename (there the module name here the structure name). 
In practice this convention proved very useful. (There already exist some 
implementations of the YANG instance data).
A similar rule for YANG modules is enforced by many tools e.g., pyang and 
confdc.

   Metadata, information about the data set itself SHOULD be included in
   the instance data set.  Some metadata items are defined in the YANG
   module "ietf-yang-instance-data", but other items MAY be used.

   Metadata MUST include:

  -  Version of the YANG Instance Data format

Doesn't the latter (MUST) effectively make the former (SHOULD) also into a 
"MUST"?
BALAZS: Yes, I will change it to MUST. The format-version is a MUST either as a 
default value 
(not actually present according to YANG rules) or as an explicitly specified 
value. 
The other metadata items are only recommended (SHOULD).

Also, if this is actually mandatory, shouldn't that be reflected in the YANG 
module?
BALAZS: IN the YANG module leaf format-version has a default value. That means 
that 
either the default value or some explicitly set vale is always usable for the 
user of the file. 
Added text to clarify this.

Section 2.1.2

   import-only dependencies MAY be excluded from the leaf-list.  If they
   are excluded then the consumer of the instance data set has to apply
   the YANG language rules to resolve the imports.  An example of the

Do we want to say something like "Accordingly, recipients of the instance data 
set must be prepared to perform this processing, absent prior knowledge about 
the files they will be processing"?
BALAZS: According to YANG rules the "implemented" module that is specified in 
the content schema MAY have used an 
  Import-by-revision statement in which case the revision date of the imported 
module is fixed/specified in that YANG module.
If import-by-revision was not used, any revision of the imported module is 
usable, which in practice for most tools means the
   latest available revision. 
IMHO which revision of an imported module to use should be and 

Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

[Balázs Lengyel]

Thanks, I will change it to double quotes.
Regards Balazs

-Original Message-
From: Carsten Bormann  
Sent: 2021. október 7., csütörtök 7:37
To: Benjamin Kaduk 
Cc: The IESG ; netmod-cha...@ietf.org; 
draft-ietf-netmod-yang-instance-file-for...@ietf.org; netmod@ietf.org
Subject: Re: [netmod] Benjamin Kaduk's No Objection on 
draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

On 7. Oct 2021, at 06:54, Benjamin Kaduk via Datatracker  
wrote:
> 
> instance-data-set-name ['@' ( revision-date / timestamp ) ]
> ( '.xml' / '.json' )
> 
> This looks (almost?  Not sure about '@' vs. "@".) like valid ABNF.  Do 
> we want to say that and reference RFC 5234 for the interpretation of 
> the symbols?

JFYI, single quotes are not used in ABNF.

'.xml' / '.json’

…would need to be:

%s”.xml” / %s”.json”

…as per RFC 7405 to avoid accidentally allowing .XMl and .jsOn.

(Please excuse the smartquotes.)

Grüße, Carsten


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Zaheduzzaman Sarker's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

[Balázs Lengyel]

Hello Zahed,
Thanks for the comments. I will update with the new text.
Regards Balazs

-Original Message-
From: Zaheduzzaman Sarker  
Sent: 2021. október 6., szerda 17:43
To: Balázs Lengyel ; The IESG 
Cc: netmod-cha...@ietf.org; 
draft-ietf-netmod-yang-instance-file-for...@ietf.org; netmod@ietf.org
Subject: Re: [netmod] Zaheduzzaman Sarker's No Objection on 
draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)



On 2021-10-06, 17:32, "Balázs Lengyel"  wrote:

Hello Zahed, 
Please see answers below as BALAZS2.
Regards Balazs

-Original Message-
From: Zaheduzzaman Sarker  
Sent: 2021. október 6., szerda 16:00
To: Balázs Lengyel ; The IESG 
Cc: netmod-cha...@ietf.org; 
draft-ietf-netmod-yang-instance-file-for...@ietf.org; netmod@ietf.org
Subject: Re: [netmod] Zaheduzzaman Sarker's No Objection on 
draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)



On 2021-10-06, 10:53, "Balázs Lengyel"  wrote:

Hello Zaheduzzaman,
Thank you for the review. 
See detailed replies as "BALAZS:" below.
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Zaheduzzaman Sarker 
via
Datatracker
Sent: 2021. október 6., szerda 8:02
To: The IESG 
Cc: netmod-cha...@ietf.org;
draft-ietf-netmod-yang-instance-file-for...@ietf.org; netmod@ietf.org
Subject: [netmod] Zaheduzzaman Sarker's No Objection on
draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-20: No Objection

When responding, please keep the subject line intact and reply to all 
email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format
/



--
COMMENT:
--

Thanks for the efforts on this document.

I have following comments, by addressing them I believe will improve the
document quality

- Section 2.1 : Should it not say if the "content-schema" node exists 
then
one of the methods MUST be used? as I see the specification of content
schema is a SHOULD, hence may not be included for whatever reason.
BALAZS: In accordance with your comment the SHOULD will be changed to 
MUST.
However, that still allows " External Method: Do not include the
"content-schema" node;"
People stated that when instance files are used repeatedly (a new file
generated every few seconds) in a closed, well defined environment,  the
content-schema may already be known. In this case it is not necessary to
include it in the file.

I don't think we are on the same page here. I am basically saying in the 
context of this specification's section 2, the addition of content-schema is a 
SHOULD, hence one implementation can actually skip it. But then in 2.1, as the 
text describes the assumption seems to be the content-schema is always present 
(like a MUST). I am not asking to change the SHOULD to MUST in section 2, but 
to acknowledge the fact that section 2.1 is only applicable when there is 
"content-schema".
BALAZS2:  I see your point. I am trying to find the correct 
wording/documentation for it.
 Today Section 2.1 in -20 includes:
One of the following methods MUST be used:
 Inline method: ...
  Simplified-Inline method: 
  URI method: ...

  External Method: Do not include the "content-schema" node; the
  user needs to obtain the information through external documents.

My idea was that the External method indicates that the content-schema 
might NOT be present in the instance-date-set.

If you think that's not clear, I could reword it to: 


  To properly understand and use an instance data set, the user needs
   to know the content-schema.  The content schema can be either 
  specified in external documents or within the instance data set. 
  In the latter case one of the following methods MUST be used:

  Inline method: Include the needed information as part of the
  instance data set.

  Simplified-Inline method: Include the needed information as part
  of the instance data set; short specification, only the modul

Re: [netmod] Zaheduzzaman Sarker's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

[Balázs Lengyel]

Hello Zahed, 
Please see answers below as BALAZS2.
Regards Balazs

-Original Message-
From: Zaheduzzaman Sarker  
Sent: 2021. október 6., szerda 16:00
To: Balázs Lengyel ; The IESG 
Cc: netmod-cha...@ietf.org; 
draft-ietf-netmod-yang-instance-file-for...@ietf.org; netmod@ietf.org
Subject: Re: [netmod] Zaheduzzaman Sarker's No Objection on 
draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)



On 2021-10-06, 10:53, "Balázs Lengyel"  wrote:

Hello Zaheduzzaman,
Thank you for the review. 
See detailed replies as "BALAZS:" below.
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Zaheduzzaman Sarker via
Datatracker
Sent: 2021. október 6., szerda 8:02
To: The IESG 
Cc: netmod-cha...@ietf.org;
draft-ietf-netmod-yang-instance-file-for...@ietf.org; netmod@ietf.org
Subject: [netmod] Zaheduzzaman Sarker's No Objection on
draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-20: No Objection

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format
/



--
COMMENT:
--

Thanks for the efforts on this document.

I have following comments, by addressing them I believe will improve the
document quality

- Section 2.1 : Should it not say if the "content-schema" node exists then
one of the methods MUST be used? as I see the specification of content
schema is a SHOULD, hence may not be included for whatever reason.
BALAZS: In accordance with your comment the SHOULD will be changed to MUST.
However, that still allows " External Method: Do not include the
"content-schema" node;"
People stated that when instance files are used repeatedly (a new file
generated every few seconds) in a closed, well defined environment,  the
content-schema may already be known. In this case it is not necessary to
include it in the file.

I don't think we are on the same page here. I am basically saying in the 
context of this specification's section 2, the addition of content-schema is a 
SHOULD, hence one implementation can actually skip it. But then in 2.1, as the 
text describes the assumption seems to be the content-schema is always present 
(like a MUST). I am not asking to change the SHOULD to MUST in section 2, but 
to acknowledge the fact that section 2.1 is only applicable when there is 
"content-schema".
BALAZS2:  I see your point. I am trying to find the correct 
wording/documentation for it.
 Today Section 2.1 in -20 includes:
One of the following methods MUST be used:
 Inline method: ...
  Simplified-Inline method: 
  URI method: ...

  External Method: Do not include the "content-schema" node; the
  user needs to obtain the information through external documents.

My idea was that the External method indicates that the content-schema might 
NOT be present in the instance-date-set.

If you think that's not clear, I could reword it to: 


  To properly understand and use an instance data set, the user needs
   to know the content-schema.  The content schema can be either 
  specified in external documents or within the instance data set. 
  In the latter case one of the following methods MUST be used:

  Inline method: Include the needed information as part of the
  instance data set.

  Simplified-Inline method: Include the needed information as part
  of the instance data set; short specification, only the module
  name and revision-date is used.

  URI method: Include a URI that references another YANG instance
  data file.  This instance data file will use the same content-
  schema as the referenced YANG instance data file.  (if you don't
  want to repeat the info again and again)

Please decide which is better!
---

- Section 4 : it says

Instance data files may contain sensitive data.

  OK, but what should be taken into consideration when putting the sensitive
  data in the data file. It feels like there should be more information
  provided to the user of the specification for actually materialize the
  statement made here.
 

Re: [netmod] Roman Danyliw's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

[Balázs Lengyel]

Hello Roman,
Thank you for the thorough review. I used your comments to improve the draft. 
See my detailed answers below as BALAZS:
Regards Balazs

-Original Message-
From: Roman Danyliw via Datatracker  
Sent: 2021. október 5., kedd 22:45
To: The IESG 
Cc: draft-ietf-netmod-yang-instance-file-for...@ietf.org; 
netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen ; 
kent+i...@watsen.net
Subject: Roman Danyliw's No Objection on 
draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-20: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/



--
COMMENT:
--

** Section 2.
instance-data-set-name ['@' ( revision-date / timestamp ) ]
 ( '.xml' / '.json' )

A syntax for an instance data file name is specified with normative language. 
However, this format is not explained is cited.
BALAZS: The syntax is ABNF. It will be stated and referenced.

** Section 2. Editorial.
OLD
If the leaf "name" is present in the instance data header, its value
   SHOULD be used for the "instance-data-set-name"

NEW
If the leaf "name" is present in the instance data header, its value
   SHOULD be used for the "instance-data-set-name" in the filename.
BALAZS: OK, will be updated.

** Section 2.

Description of the instance data set.  The description SHOULD
 contain information whether and how the data can change during
 the lifetime of the server

I found this definition of the description confusing as Figure 1 – 3 don’t seem 
to describe “whether and how the data” will change.
BALAZS: Good catch. The information will be added to the examples.

** Section 2.1.1.  Per “The inline-yang-library anydata data node carries 
instance data (conforming to ietf-yang-library@2019-01-04)”, please provide a 
reference to “ietf-yang-library@2019-01-04”.
BALAZS: OK,  will be updated.

** Section 4.  Please note the risk of using same-schema-as-file, especially if 
these configs are not integrity protected or received from outside sources. 
Per https://, there are the risks of loading remote content.  Section 7 of
RFC3986 is a good reference.  Per file://, there are things list directory 
traversal.
BALAZS: OK, will be added to security considerations.

** Section 4.  Per “The header part is not security sensitive with one possible 
exception … the URI method”, I’m not sure that such a strong statement can be 
made given the lack of application context.  For example, the description leaf 
in the header could include sensitive information, say ‘Latest test router 
config for new super secret Aqua-Violet flying car project’.  This text needs 
to either have a caution that that this header is "unprotected so do not put in 
sensitive information unless this file is protected", or clarify that more in 
the header than the URI could be sensitive.
BALAZS: OK,  will be updated.

** Section 4.  Thanks for the language trying to create equivalency between the 
protections of the file and the YANG store that would house it on a live 
system.  Recommend making this text clear to say this applies to both at rest 
and in motion data.

OLD
The same kind of handling should be applied, that would be
   needed for the result of a read operation returning the same data.

NEW (roughly)
The same kind of handling should be applied to this file at rest and in transit 
that would be needed for the result of a read operation returning the same 
data.  These in-transit protection mechanisms will also mitigate integrity 
issues when transporting the file.
BALAZS: OK,  will be updated.


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Éric Vyncke's No Objection on draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

[Balázs Lengyel]

Hello Eric,
See some more answers as BALAZS2.
Regards Balazs

-Original Message-
From: Eric Vyncke (evyncke)  
Sent: 2021. október 5., kedd 23:19
To: Balázs Lengyel ; The IESG ; 
Benoit Claise 
Cc: netmod-cha...@ietf.org; Kent Watsen ; 
draft-ietf-netmod-yang-instance-file-for...@ietf.org; netmod@ietf.org
Subject: Re: Éric Vyncke's No Objection on 
draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

Hello Balázs,

Thank you for your quick reply and your actions. My comments are non-blocking 
anyway ;-) see my replies prefixed with EV>

Regards

-éric

On 05/10/2021, 18:10, "iesg on behalf of Balázs Lengyel" 
 wrote:

Hello Eric,
Thank you for the thorough review. I used many of your comments to improve 
the draft. See my detailed answers below as BALAZS:
Regards Balazs

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: 2021. október 5., kedd 13:27
To: The IESG 
Cc: draft-ietf-netmod-yang-instance-file-for...@ietf.org; 
netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen ; 
kent+i...@watsen.net
Subject: Éric Vyncke's No Objection on 
draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-19: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/



--
COMMENT:
--

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be 
appreciated even if only for my own education), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Generic comment about the use of the word "file" (which means an object in 
a file system for me) rather than something more generic (no suggestion to offer
though) ?
BALAZS: In most cases we do actually mean an object in a file system. 
In some cases not: In UC6 Allowing YANG instance data to be carried within  
other IPC message formats. 
This is the exact reason while we differentiate between an 
instance-data-set and an instance-data-file. 
An instance-data-set may be contained in a file, but may be transferred in 
a protocol message.

EV> indeed, so, should the title be updated s/file/data set/ ?
BALAZS2: I am reluctant to change the title this late in the process. Although 
your suggestion is reasonable, people might more easily recognize what an 
instance-data-file is than an what an instance-data-set means.

-- Section 1 --
The first 2 sentences are quite repetitive.
BALAZS: The first sentence states that we need such data off-lie
The second sentence states that this offline data may be needed in 3 
different phases design, implementation or even later after the server and the 
YANG module is up and running, I just don't have access to it.
Reworded to clarify this.

EV> thanks

Is it about "offline delivery" or "exchange" ? At this point of reading the 
document, it is still unclear in my mind what it is about... The rest of the 
I-D made it clear.
BALAZS: The draft is only about defining a format for YANG instance data. 
Naturally once you have a data format it could be used both to deliver the 
information offline in a file or to exchange information using the format in an 
protocol message.
Most use-cases mentioned are about Offline delivery.
.

Unclear which UC is either implemented or potential (even with the 
appendix); could also add forward references to the appendix UC). Should the
implementation(s) be referenced if they are public ?
BALAZS:  As stated in section 1. Use cases are listed only as examples. 
This draft is only about defining a format for YANG Instance Data.
I know UC1,2,3 are already implemented by more than one company, but as 
this draft is only about the format, I don't think we should reference the 
implementations. 
Also, UC1 is already utilized in 2 other internet drafts.

EV> nice to know, next time, you may want to have an 'implementation status' 
section (to be removed by the RFC editor).

-- Section 1.1 --
Unsure why a "data set" should be named? The choice of words does not seem 
the best fit (even though if I have no suggestions).
BALAZS: Specific data sets need to be ide

Re: [netmod] Zaheduzzaman Sarker's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

[Balázs Lengyel]

Hello Zaheduzzaman,
Thank you for the review. 
See detailed replies as "BALAZS:" below.
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Zaheduzzaman Sarker via
Datatracker
Sent: 2021. október 6., szerda 8:02
To: The IESG 
Cc: netmod-cha...@ietf.org;
draft-ietf-netmod-yang-instance-file-for...@ietf.org; netmod@ietf.org
Subject: [netmod] Zaheduzzaman Sarker's No Objection on
draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-20: No Objection

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format
/



--
COMMENT:
--

Thanks for the efforts on this document.

I have following comments, by addressing them I believe will improve the
document quality

- Section 2.1 : Should it not say if the "content-schema" node exists then
one of the methods MUST be used? as I see the specification of content
schema is a SHOULD, hence may not be included for whatever reason.
BALAZS: In accordance with your comment the SHOULD will be changed to MUST.
However, that still allows " External Method: Do not include the
"content-schema" node;"
People stated that when instance files are used repeatedly (a new file
generated every few seconds) in a closed, well defined environment,  the
content-schema may already be known. In this case it is not necessary to
include it in the file.

- Section 4 : it says

Instance data files may contain sensitive data.

  OK, but what should be taken into consideration when putting the sensitive
  data in the data file. It feels like there should be more information
  provided to the user of the specification for actually materialize the
  statement made here.
BALAZS: Instance data files may be used in many different use-cases. 
Whether the data within is sensitive is completely dependent on the content
schema applicable to the use-case.
The draft contains:
" The security sensitivity of the instance data in the content part is
   completely dependent on the content schema."
Any suggestions about what else we could say?


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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Reply to Lars Eggert's comments on draft-ietf-netmod-yang-instance-file-format-19

[Balázs Lengyel]

Hello,
This is our reply to Lar's Eggert's comments. The original comments can be 
read at 
https://datatracker.ietf.org/iesg/agenda/documents/#draft-ietf-netmod-yang-instance-file-format_lars-eggert.
Thanks for the review. I used most of your suggestions to improve the draft.
See detailed replies as "BALAZS:" below.
Regards Balazs

=
All comments below are about very minor potential issues that you may choose 
to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3.2. , paragraph 4, nit:
> ance data; the instance data itself is is contained only in the 
> 'content-data
> ^
Possible typo: you repeated a word.
BALAZS: Will be corrected.

Section 3.2. , paragraph 5, nit:
> ove if the module gets changed // in anyway during reviews or RFC editor 
> proc
>   ^
Did you mean "in any way"?
BALAZS: Yes, will be corrected.

Section 3.2. , paragraph 19, nit:
>  data file needs to be handled in a secure way as mentioned below. The secur
>^^^
Consider replacing this phrase with the adverb "securely" to avoid wordiness.
BALAZS: Will be corrected.

Section 5.2. , paragraph 1, nit:
>  v08 - v09 * Removed reference to similar to get reply * Introduced artwork
>^
Typo. Did you mean "too similar to"?
BALAZS: Earlier the format was described as similar to the response of aNETCONF 
get operation. Updated it to make it more understandable.

These URLs in the document did not return content:
 * https://datatracker.ietf.org/wg/netmodf/






smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Éric Vyncke's No Objection on draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

[Balázs Lengyel]

Hello Eric,
Thank you for the thorough review. I used many of your comments to improve the 
draft. See my detailed answers below as BALAZS:
Regards Balazs

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: 2021. október 5., kedd 13:27
To: The IESG 
Cc: draft-ietf-netmod-yang-instance-file-for...@ietf.org; 
netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen ; 
kent+i...@watsen.net
Subject: Éric Vyncke's No Objection on 
draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-19: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/



--
COMMENT:
--

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be 
appreciated even if only for my own education), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Generic comment about the use of the word "file" (which means an object in a 
file system for me) rather than something more generic (no suggestion to offer
though) ?
BALAZS: In most cases we do actually mean an object in a file system. 
In some cases not: In UC6 Allowing YANG instance data to be carried within  
other IPC message formats. 
This is the exact reason while we differentiate between an instance-data-set 
and an instance-data-file. 
An instance-data-set may be contained in a file, but may be transferred in a 
protocol message.

-- Section 1 --
The first 2 sentences are quite repetitive.
BALAZS: The first sentence states that we need such data off-lie
The second sentence states that this offline data may be needed in 3 different 
phases design, implementation or even later after the server and the YANG 
module is up and running, I just don't have access to it.
Reworded to clarify this.

Is it about "offline delivery" or "exchange" ? At this point of reading the 
document, it is still unclear in my mind what it is about... The rest of the 
I-D made it clear.
BALAZS: The draft is only about defining a format for YANG instance data. 
Naturally once you have a data format it could be used both to deliver the 
information offline in a file or to exchange information using the format in an 
protocol message.
Most use-cases mentioned are about Offline delivery.
.

Unclear which UC is either implemented or potential (even with the appendix); 
could also add forward references to the appendix UC). Should the
implementation(s) be referenced if they are public ?
BALAZS:  As stated in section 1. Use cases are listed only as examples. This 
draft is only about defining a format for YANG Instance Data.
I know UC1,2,3 are already implemented by more than one company, but as this 
draft is only about the format, I don't think we should reference the 
implementations. 
Also, UC1 is already utilized in 2 other internet drafts.

-- Section 1.1 --
Unsure why a "data set" should be named? The choice of words does not seem the 
best fit (even though if I have no suggestions).
BALAZS: Specific data sets need to be identified. What is it about? When was it 
prepared? 
 I want a way to identify the specific data set. So, we give it a name (and a 
revision/timestamp).  This is why its named.
Any better suggestion?

-- Section 2 --
Like some other ADs, I wonder why "The context data part MUST... except" is not 
a "SHOULD" as there are exceptions.

What is the expected behaviour when the timestamp in the filename does not 
match the meta data ?
BALAZS: We are following RFC7950 in which YANG related file names are 
recommended with a SHOULD but not prescribed with a MUST.
Some people wanted to use separate timestamps when the instance-data-set is 
created and when it is put into an instance-data-file.
This draft does not prescribe an expected behavior of the tools, it just 
defines the format.

-- Section 2.1 --
There is a "SHOULD" so when are exceptions/deviations acceptable ?
BALAZS: Based on your and Murray's comments, this will be changed to MUST.

The description of "simplified" is really too simple ;-)
BALAZS: Added  "only the module name and revision-date is used "

I would also appreciate that the order of the list matches the following 
sub-sections order.
BALAZS: OK, updated.

Thank you for using RFC 8792.

-- Section 4 --
Did the authors think about adding the party creating the file and adding an 
optional signature 

Re: [netmod] yang-instance-file include-defaults leaf

[Balázs Lengyel]

See below as BALAZS4

 

From: Andy Bierman  
Sent: 2021. szeptember 10., péntek 4:57
To: Balázs Lengyel 
Cc: Rob Wilton (rwilton) ; NetMod WG 
Subject: Re: [netmod] yang-instance-file include-defaults leaf

 

 

 

On Thu, Sep 9, 2021 at 6:19 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

Hello Andy,

See below as BALAZS3.

 

From: Andy Bierman mailto:a...@yumaworks.com> > 
Sent: 2021. augusztus 25., szerda 18:29
To: Balázs Lengyel mailto:balazs.leng...@ericsson.com> >
Cc: Rob Wilton (rwilton) mailto:rwil...@cisco.com> >; 
NetMod WG mailto:netmod@ietf.org> >
Subject: Re: [netmod] yang-instance-file include-defaults leaf

 

Hi,

 

Here is the latest text. It is inconsistent with RFC 6243, section 3.

IMO the subsections should be cited instead of the copy-and-change approach.

BALAZS3: The 6243 sections contain parts about “data retrieval” “capabilities” 
or “conceptual data nodes set by the server”

These parts are not relevant for many of the instance data use cases, so I 
would like to stick with including text here.

 

 

 

I guess I do not understand why the "with-defaults" leaf or at leaf 
"with-defaults-mode" typedef

cannot be used. IMO this is bad practice.  Applications that already know how 
to deal

with defaults according to RFC 6243 should be supported.

 

 

 leaf includes-defaults {

 type ncwd:with-defaults-mode;

 }

 

I do not see any text in this typedef that is server-specific.

Andy

BALAZS4:  While I generally agree that duplication is a bad practice, I avoided 
using ncwd:with-defaults-mode because:

*It references  <https://datatracker.ietf.org/doc/html/rfc6243> RFC 
6243;  <https://datatracker.ietf.org/doc/html/rfc6243#section-3> Section 3 
which is full of inappropriate references (server, data retrieval, capabilities)
*The typedef’s description is "Possible modes to report default data." 
However, in a number of use cases (e.g., UC2 Preloading default configuration 
data, UC7, U8) the data is not reported.
*report-all-tagged description contains “XML attribute” which is 
incorrect if we use JSON encoding
*I prefer to use the 2119 term SHALL, SHALL NOT in the enum 
descriptions.
Is this acceptable?
 

 

   leaf includes-defaults {
 type enumeration {
   enum report-all {
 value 1;
 description
   "All data nodes SHOULD be included independent of
 any default values.";
 
AB: should follow 6243, 3.1
   }
   enum trim {
 value 2;
 description
   "Data nodes that have a default defined and where
 the actual value is the default value SHOULD
 NOT be included.";
 
AB: should follow 6243, section 3.2
   }
   enum explicit {
 value 3;
 description
   "Data nodes that have a default defined and where
 the actual value is the default value SHOULD NOT be
 included. However, if the actual value was set by
 a NETCONF client or other management application
 by the way of an explicit management operation the
 data node SHOULD be included.";
 
AB: should follow 6243, section 3.3
   }
 }
 description
   "As instance-data-sets MAY contain incomplete data sets,
 thus any data node MAY be absent.
 
 Providing the instance-data-set intends to contain a
 full data set, this leaf specifies whether the data set
 includes data nodes that have a default defined and
 where the actual value is the same as the default value.
 
 Data nodes that have no default values should always
 be included.
 Data nodes that have a default value, but the actual
 value is not equal to the schema defined default
 should always be included.";
 
 
AB: The last paragraph should be removed or changed. Why are these nodes 
special?
Nodes that are actually present and do not contain the YANG default
are not relevant to this object.
BALAZS3: OK
 
 reference
   "RFC 6243 <https://datatracker.ietf.org/doc/html/rfc6243> : 
With-defaults Capability for NETCONF";
   }

 

The best way to indicate a representation of a YANG default in the data set is 
to include

the "default" attribute in each default node. 
https://datatracker.ietf.org/doc/html/rfc6243#section-6

This actually works for explicit mode and leaf-lists (unlike the current 
solution).

BALAZS3: OK. Added report-all-tagged enum to includes-defaults leaf.

Here is the current proposed text:



leaf includes-defaults {

  type enumeration {

enu

Re: [netmod] Unknown idnits error

[Balázs Lengyel]

AFAIK I did not copy any old material. Balazs

-Original Message-
From: Carsten Bormann  
Sent: 2021. szeptember 9., csütörtök 23:25
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Unknown idnits error

On 2021-09-09, at 19:12, Balázs Lengyel 
 wrote:
> 
> Couldn't figure out when the document was first submitted -- there may
>  comments or warnings related to the use of a disclaimer for pre-RFC5378
>  work that could not be issued because of this.

My experience is that this message is caused by hiccups of the idnits tool in 
retrieving metadata.

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ 
certainly has no problems figuring that out.

(The question is whether you are copying from/evolving from material that was 
submitted before RFC 5378 went into force, in which case you might need a 
different ipr= attribute.  Most likely your text is not that old!  So this is a 
red herring.)

Grüße, Carsten


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Unknown idnits error

[Balázs Lengyel]

Sadly to...@ietf.org <mailto:to...@ietf.org>  returns with “Unknown To address”

Balazs

 

From: Balázs Lengyel 
Sent: 2021. szeptember 9., csütörtök 23:17
To: Mahesh Jethanandani 
Cc: netmod@ietf.org
Subject: RE: [netmod] Unknown idnits error

 

I got this warning while running the web based idnits tool. 
https://tools.ietf.org/tools/idnits/

It might indicate some real problem, but it is impossible to understand from 
the failure message, what it is.

Regards Balazs

 

From: Mahesh Jethanandani mailto:mjethanand...@gmail.com> > 
Sent: 2021. szeptember 9., csütörtök 20:15
To: Balázs Lengyel mailto:balazs.leng...@ericsson.com> >
Cc: netmod@ietf.org <mailto:netmod@ietf.org> 
Subject: Re: [netmod] Unknown idnits error

 

I assume that this is during the submit process, and that you are not running 
this offline. Submit a report to to...@ietf.org <mailto:to...@ietf.org>  and 
have them look at it.

 

On Sep 9, 2021, at 10:12 AM, Balázs Lengyel 
mailto:balazs.lengyel=40ericsson@dmarc.ietf.org> > wrote:

 

Hello,

I am trying to check/submit a new version of my 
draft-ietf-netmod-yang-instance-file-format-18.
 
The previous version did not have any idnits errors or warnings. Now suddenly I 
get: 
 
== Couldn't figure out when the document was first submitted -- there may
 comments or warnings related to the use of a disclaimer for pre-RFC5378
 work that could not be issued because of this.  Please check the Legal
 Provisions document at  <https://trustee.ietf.org/license-info> 
https://trustee.ietf.org/license-info to determine
 if you need the pre-RFC5378 disclaimer.
I did not change any boilerplate info. Why do I get this warning and how to get 
rid of it?
 
I use xml2rfc. My draft includes:
 


 
Help, Balazs
 

 

-- 

Balazs LengyelSenior Specialist   
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email:  
<mailto:balazs.leng...@ericsson.com> balazs.leng...@ericsson.com

 

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

 

Mahesh Jethanandani

mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> 

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Unknown idnits error

[Balázs Lengyel]

I got this warning while running the web based idnits tool. 
https://tools.ietf.org/tools/idnits/

It might indicate some real problem, but it is impossible to understand from 
the failure message, what it is.

Regards Balazs

 

From: Mahesh Jethanandani  
Sent: 2021. szeptember 9., csütörtök 20:15
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Unknown idnits error

 

I assume that this is during the submit process, and that you are not running 
this offline. Submit a report to to...@ietf.org <mailto:to...@ietf.org>  and 
have them look at it.





On Sep 9, 2021, at 10:12 AM, Balázs Lengyel 
mailto:balazs.lengyel=40ericsson@dmarc.ietf.org> > wrote:

 

Hello,

I am trying to check/submit a new version of my 
draft-ietf-netmod-yang-instance-file-format-18.
 
The previous version did not have any idnits errors or warnings. Now suddenly I 
get: 
 
== Couldn't figure out when the document was first submitted -- there may
 comments or warnings related to the use of a disclaimer for pre-RFC5378
 work that could not be issued because of this.  Please check the Legal
 Provisions document at  <https://trustee.ietf.org/license-info> 
https://trustee.ietf.org/license-info to determine
 if you need the pre-RFC5378 disclaimer.
I did not change any boilerplate info. Why do I get this warning and how to get 
rid of it?
 
I use xml2rfc. My draft includes:
 


 
Help, Balazs
 

 

-- 

Balazs LengyelSenior Specialist   
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email:  
<mailto:balazs.leng...@ericsson.com> balazs.leng...@ericsson.com

 

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

 

Mahesh Jethanandani

mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> 

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Unknown idnits error

[Balázs Lengyel]

Hello,

I am trying to check/submit a new version of my
draft-ietf-netmod-yang-instance-file-format-18.
 
The previous version did not have any idnits errors or warnings. Now
suddenly I get: 
 
== Couldn't figure out when the document was first submitted -- there may
 comments or warnings related to the use of a disclaimer for pre-RFC5378
 work that could not be issued because of this.  Please check the Legal
 Provisions document at https://trustee.ietf.org/license-info to
determine
 if you need the pre-RFC5378 disclaimer.
I did not change any boilerplate info. Why do I get this warning and how to
get rid of it?
 
I use xml2rfc. My draft includes:
 


 
Help, Balazs
 

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-instance-file include-defaults leaf

[Balázs Lengyel]

Hello Andy,

See below as BALAZS3.

 

From: Andy Bierman  
Sent: 2021. augusztus 25., szerda 18:29
To: Balázs Lengyel 
Cc: Rob Wilton (rwilton) ; NetMod WG 
Subject: Re: [netmod] yang-instance-file include-defaults leaf

 

Hi,

 

Here is the latest text. It is inconsistent with RFC 6243, section 3.

IMO the subsections should be cited instead of the copy-and-change approach.

BALAZS3: The 6243 sections contain parts about “data retrieval” “capabilities” 
or “conceptual data nodes set by the server”

These parts are not relevant for many of the instance data use cases, so I 
would like to stick with including text here.

 

   leaf includes-defaults {
 type enumeration {
   enum report-all {
 value 1;
 description
   "All data nodes SHOULD be included independent of
 any default values.";
 
AB: should follow 6243, 3.1
   }
   enum trim {
 value 2;
 description
   "Data nodes that have a default defined and where
 the actual value is the default value SHOULD
 NOT be included.";
 
AB: should follow 6243, section 3.2
   }
   enum explicit {
 value 3;
 description
   "Data nodes that have a default defined and where
 the actual value is the default value SHOULD NOT be
 included. However, if the actual value was set by
 a NETCONF client or other management application
 by the way of an explicit management operation the
 data node SHOULD be included.";
 
AB: should follow 6243, section 3.3
   }
 }
 description
   "As instance-data-sets MAY contain incomplete data sets,
 thus any data node MAY be absent.
 
 Providing the instance-data-set intends to contain a
 full data set, this leaf specifies whether the data set
 includes data nodes that have a default defined and
 where the actual value is the same as the default value.
 
 Data nodes that have no default values should always
 be included.
 Data nodes that have a default value, but the actual
 value is not equal to the schema defined default
 should always be included.";
 
 
AB: The last paragraph should be removed or changed. Why are these nodes 
special?
Nodes that are actually present and do not contain the YANG default
are not relevant to this object.
BALAZS3: OK
 
 reference
   "RFC 6243 <https://datatracker.ietf.org/doc/html/rfc6243> : 
With-defaults Capability for NETCONF";
   }

 

The best way to indicate a representation of a YANG default in the data set is 
to include

the "default" attribute in each default node. 
https://datatracker.ietf.org/doc/html/rfc6243#section-6

This actually works for explicit mode and leaf-lists (unlike the current 
solution).

BALAZS3: OK. Added report-all-tagged enum to includes-defaults leaf.

Here is the current proposed text:



leaf includes-defaults {

  type enumeration {

enum report-all {

  value 1;

  description

"All data nodes SHALL be included independent of

  any default values, if the data node 

  is covered by the instance-data-set.";

}

enum report-all-tagged  {

  value 2;

  description

"All data nodes SHALL be included independent of

  any default values if the data node 

  is covered by the instance-data-set.

  Any nodes considered to be default data SHALL

  contain a 'default' attribute set to 'true'";

}

enum trim {

  value 3;

  description

"Data nodes that have a default defined and where

  the actual value is equal to the schema default  

  value SHALL NOT be included.";

}

enum explicit {

  value 4;

  description

"Data nodes where the actual value is equal to the 

  schema default value SHALL NOT be included. 

  However, if the actual value was set by a NETCONF 

  client or other management application by the way 

  of an explicit management operation, the data node 

  SHALL be included, if the data node is covered by 

  the instance-data-set.";

}

  }

  description

"An instance-data-set may contain or exclude default 

  data. This leaf indicates whether default data is 

  included. 

  

  As instance-data-sets MAY contain incomplete data 

 

Re: [netmod] yang-instance-file include-defaults leaf

[Balázs Lengyel]

Hello Andy,

See below as BALAZS2.

 

From: Andy Bierman  
Sent: 2021. augusztus 24., kedd 13:35
To: Balázs Lengyel 
Cc: Rob Wilton (rwilton) ; NetMod WG 
Subject: Re: [netmod] yang-instance-file include-defaults leaf

 

 

 

On Tue, Aug 24, 2021 at 1:41 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

Hello Andy,

In the -17 I removed the default value for includes-defaults as you proposed.

 

I am not sure I understand the rest of the comments as instance-file-format 
does not use the concept of “basic-mode”. It has a single leaf to indicate what 
is the situation with defaults in the specific instance-data-set.

As this is not a live server request/reply situation we do not want to specify 
a basic and additional modes, we just want to specify the handling used for 
this specific instance data set.

 

 

The draft as written does not actually provide the same utility as 
.

(Without the "default" attribute the "explicit" mode is not actually supported.)

 

The "with-defaults" mechanism works exactly the same no matter what

the XML representation is used for.  The mode used to write the data will

correspond to the basic-mode with the same name.

BALAZS2: I will add the report-all-tagged mode to the leaf includes-defaults. 
This will include the usage of default attribute in the instance data. Will 
that make the attribute acceptable for you ?

 

Regards Balazs

 

Andy

 

 

From: Andy Bierman mailto:a...@yumaworks.com> > 
Sent: 2021. augusztus 23., hétfő 18:58
To: Balázs Lengyel mailto:balazs.leng...@ericsson.com> >
Cc: Rob Wilton (rwilton) mailto:rwil...@cisco.com> >; 
NetMod WG mailto:netmod@ietf.org> >
Subject: Re: [netmod] yang-instance-file include-defaults leaf

 

 

 

On Mon, Aug 23, 2021 at 5:17 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

Hello Rob,

I think this won’t fly. 

In sections 1.2 and 2 we state:

“Instance data files MAY contain partial data sets.”
Which is important for many use-cases.  This means you cannot say that a 
default value will or must be included, as they might be omitted because they 
are not part of the partial data set.
In a way it is difficult to separate between leaves that are missing because
-They are not part of the partial data-set
-They are omitted because they have the default value and one of the 
trim or explicit options is used
If this becomes important the report-all options shall be used.
 

 

 

I thought we already agreed there cannot be a default or there is no way to

represent "no defaults added".

 

Note that "report-all" is not useful if basic-mode=explicit, since a leaf 
reporting the YANG default

could be set by the client.  Only report-all-tagged will clearly identify 
defaults in this case.

 

Also note that if basic-mode=report-all then there will be no defaults ever 
reported.

This mode means the server does not consider any node to be a default and 
always returns

every node (if with-defaults used or not).

 

This is the reason I used the SHOULD word.
Regards Balazs

 

Andy

 

 

From: Rob Wilton (rwilton) mailto:rwil...@cisco.com> > 
Sent: 2021. augusztus 23., hétfő 12:27
To: Balázs Lengyel mailto:balazs.leng...@ericsson.com> >; Andy Bierman mailto:a...@yumaworks.com> >; NetMod WG mailto:netmod@ietf.org> >
Subject: RE: [netmod] yang-instance-file include-defaults leaf

 

Hi Balazs, Andy, Netmod,

 

Sorry for the delayed response.  I would still like to strength the description 
of the defaults.  E.g., RFC 6243 uses MUSTs rather than SHOULDs.

 

Hence, I have generated some proposed alternative descriptions, that are 
somewhat stricter, but also more generically focussed only on the default 
values.

 

With these definitions, I think that we could define the “include-defaults” 
default value to be “explicit”, since if the leaf if not included, then I think 
that this effectively what the meaning would be anyway.

 

 

In particular, I would propose changing the descriptions as follows:

 

   leaf includes-defaults {

 type enumeration {

   enum report-all {

 value 1;

 description

   "All data nodes SHOULD be included independent of

 any default values.";

   }

   enum trim {

 value 2;

 description

   "Data nodes that have a default defined and where

 the actual value is the default value SHOULD

 NOT be included.";

   }

   enum explicit {

 value 3;

 description

   "Data nodes that have a default defined and where

 the actual value is the default value SHOULD NOT be

 included. However, if the actual value was set by

 a NETCONF client or other man

Re: [netmod] yang-instance-file include-defaults leaf

[Balázs Lengyel]

Hello Andy,

In the -17 I removed the default value for includes-defaults as you proposed.

 

I am not sure I understand the rest of the comments as instance-file-format 
does not use the concept of “basic-mode”. It has a single leaf to indicate what 
is the situation with defaults in the specific instance-data-set.

As this is not a live server request/reply situation we do not want to specify 
a basic and additional modes, we just want to specify the handling used for 
this specific instance data set.

 

Regards Balazs

 

From: Andy Bierman  
Sent: 2021. augusztus 23., hétfő 18:58
To: Balázs Lengyel 
Cc: Rob Wilton (rwilton) ; NetMod WG 
Subject: Re: [netmod] yang-instance-file include-defaults leaf

 

 

 

On Mon, Aug 23, 2021 at 5:17 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

Hello Rob,

I think this won’t fly. 

In sections 1.2 and 2 we state:

“Instance data files MAY contain partial data sets.”
Which is important for many use-cases.  This means you cannot say that a 
default value will or must be included, as they might be omitted because they 
are not part of the partial data set.
In a way it is difficult to separate between leaves that are missing because
-They are not part of the partial data-set
-They are omitted because they have the default value and one of the 
trim or explicit options is used
If this becomes important the report-all options shall be used.
 

 

 

I thought we already agreed there cannot be a default or there is no way to

represent "no defaults added".

 

Note that "report-all" is not useful if basic-mode=explicit, since a leaf 
reporting the YANG default

could be set by the client.  Only report-all-tagged will clearly identify 
defaults in this case.

 

Also note that if basic-mode=report-all then there will be no defaults ever 
reported.

This mode means the server does not consider any node to be a default and 
always returns

every node (if with-defaults used or not).

 

This is the reason I used the SHOULD word.
Regards Balazs

 

Andy

 

 

From: Rob Wilton (rwilton) mailto:rwil...@cisco.com> > 
Sent: 2021. augusztus 23., hétfő 12:27
To: Balázs Lengyel mailto:balazs.leng...@ericsson.com> >; Andy Bierman mailto:a...@yumaworks.com> >; NetMod WG mailto:netmod@ietf.org> >
Subject: RE: [netmod] yang-instance-file include-defaults leaf

 

Hi Balazs, Andy, Netmod,

 

Sorry for the delayed response.  I would still like to strength the description 
of the defaults.  E.g., RFC 6243 uses MUSTs rather than SHOULDs.

 

Hence, I have generated some proposed alternative descriptions, that are 
somewhat stricter, but also more generically focussed only on the default 
values.

 

With these definitions, I think that we could define the “include-defaults” 
default value to be “explicit”, since if the leaf if not included, then I think 
that this effectively what the meaning would be anyway.

 

 

In particular, I would propose changing the descriptions as follows:

 

   leaf includes-defaults {

 type enumeration {

   enum report-all {

 value 1;

 description

   "All data nodes SHOULD be included independent of

 any default values.";

   }

   enum trim {

 value 2;

 description

   "Data nodes that have a default defined and where

 the actual value is the default value SHOULD

 NOT be included.";

   }

   enum explicit {

 value 3;

 description

   "Data nodes that have a default defined and where

 the actual value is the default value SHOULD NOT be

 included. However, if the actual value was set by

 a NETCONF client or other management application

 by the way of an explicit management operation the

 data node SHOULD be included.";

   }

 }

  

Proposed:

 

   leaf includes-defaults {

 type enumeration {

   enum report-all {

 value 1;

 description

   "The instance data set includes all data nodes,

including those that contain the schema default.”;

   }

   enum trim {

 value 2;

 description

   "The instance data set excludes all data nodes

that contain the schema default.";

   }

   enum explicit {

 value 3;

 description

   "The instance data set may include some data nodes

that match the schema default and may exclude some

data nodes that match the schema default.”;

   }

 }

 description

   "This leaf provides an indication of 

Re: [netmod] yang-instance-file include-defaults leaf

[Balázs Lengyel]

Hello Rob,

I think this won’t fly. 

In sections 1.2 and 2 we state:

“Instance data files MAY contain partial data sets.”
Which is important for many use-cases.  This means you cannot say that a 
default value will or must be included, as they might be omitted because they 
are not part of the partial data set.
In a way it is difficult to separate between leaves that are missing because
-They are not part of the partial data-set
-They are omitted because they have the default value and one of the 
trim or explicit options is used
If this becomes important the report-all options shall be used.
 
This is the reason I used the SHOULD word.
Regards Balazs

 

From: Rob Wilton (rwilton)  
Sent: 2021. augusztus 23., hétfő 12:27
To: Balázs Lengyel ; Andy Bierman 
; NetMod WG 
Subject: RE: [netmod] yang-instance-file include-defaults leaf

 

Hi Balazs, Andy, Netmod,

 

Sorry for the delayed response.  I would still like to strength the description 
of the defaults.  E.g., RFC 6243 uses MUSTs rather than SHOULDs.

 

Hence, I have generated some proposed alternative descriptions, that are 
somewhat stricter, but also more generically focussed only on the default 
values.

 

With these definitions, I think that we could define the “include-defaults” 
default value to be “explicit”, since if the leaf if not included, then I think 
that this effectively what the meaning would be anyway.

 

 

In particular, I would propose changing the descriptions as follows:

 

   leaf includes-defaults {

 type enumeration {

   enum report-all {

 value 1;

 description

   "All data nodes SHOULD be included independent of

 any default values.";

   }

   enum trim {

 value 2;

 description

   "Data nodes that have a default defined and where

 the actual value is the default value SHOULD

 NOT be included.";

   }

   enum explicit {

 value 3;

 description

   "Data nodes that have a default defined and where

 the actual value is the default value SHOULD NOT be

 included. However, if the actual value was set by

 a NETCONF client or other management application

 by the way of an explicit management operation the

 data node SHOULD be included.";

   }

 }

  

Proposed:

 

   leaf includes-defaults {

 type enumeration {

   enum report-all {

 value 1;

 description

   "The instance data set includes all data nodes,

including those that contain the schema default.”;

   }

   enum trim {

 value 2;

 description

   "The instance data set excludes all data nodes

that contain the schema default.";

   }

   enum explicit {

 value 3;

 description

   "The instance data set may include some data nodes

that match the schema default and may exclude some

data nodes that match the schema default.”;

   }

 }

 description

   "This leaf provides an indication of how default data

is presented within an instance data set, modelled on

RFC 6243.

 

Interpretation of the use of defaults depends on the

context of what the instance data set represents.

 

E.g., if the instance data set represents configuration,

Then include-defaults aligns to the meaning of the

default-handling basic modes in RFC 6243.  If the

instance data set represents operational data from the 

operational state datastore [RFC 8342], then

include-defaults aligns to the definition of that

datastore in RFC 8342.”;

 

Would text along these lines work?

 

Thanks,

Rob

 

 

From: Balázs Lengyel mailto:balazs.leng...@ericsson.com> > 
Sent: 28 July 2021 23:08
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com> >; Andy 
Bierman mailto:a...@yumaworks.com> >
Cc: NetMod WG mailto:netmod@ietf.org> >
Subject: RE: [netmod] yang-instance-file include-defaults leaf

 

Hello Rob,

Removing the “default trim;” will address Andy’s comment.

 

Your in-use-values is very specific to one of the use-cases: 
reading/documenting operational values. It is not useful for the other 
use-cases. I think the “documenting operational datastore” use-case could be 
handled by indicating the includes-defaults=report-all. Case (i) would contain 
the value case (ii) will not.

Regards Balazs

 

From: Rob Wilton (rwilton) mailto:rwil...@cisco.com> > 
Sent: 2021. július 27., kedd 17

Re: [netmod] system configuration sync mechanism

[Balázs Lengyel]

Hello,

Sorry for going back to the basics, but IMHO it is needed here. So as I see 
understand the problem:

The purpose of the draft and some principles should be clearly stated. In my 
view: 

 

P1) “There is a need to validate configuration data against data created by the 
system.”

 

We also have some principles:

P2) We want the running datastore to contain exactly what the operator has 
written there

 

>From this it flows that 

P3) the running/intended configuration MAY become invalid if the system-data 
changes. 

But

P4) rfc8342#section-5.3.4 MUST always be valid

 

P3 and P4 contradict each other. The only way to resolve this IMHO is to say 
that system-data changes only at upgrade. If the upgrade can’t end up with a 
valid configuration (after whatever processing) then it MUST fail.

 

IMHO

If we move the system-data into a separate datastore that does not help. When I 
update the running configuration the validation will depend on system-data 
either in the system or in the intended datastore. Debugging a configuration 
distributed over multiple datastores is difficult.

IMHO we should just introduce a new datatype beside config=true and 
config=false, let’s call it system-data or read-only-config=true.

System-data would be the same type as config=true except it is not writable by 
Netconf/Restconf/CLI/SNMP, etc. only by the system itself.

This would allow us to define and populate system-data in both running/intended 
datastores. It would be visible in the same context. 

System-data would be static, the operator would not be able to modify it, so 
impact on netconf/Restconf operations would be trivial.

 

As I see it this is the same problem that we discussed in 
https://github.com/netmod-wg/yang-next/issues/41.

 

I know this is a radical change, but I think using a new YANG extension to 
create a read-only config=true datatype is a much cleaner solution. One which 
some companies have already implemented.

If I misunderstood your intent, then sorry.

 

Regards Balazs

 

From: netmod  On Behalf Of maqiufang (A)
Sent: 2021. július 31., szombat 14:33
To: Kent Watsen ; netmod@ietf.org
Subject: Re: [netmod] system configuration sync mechanism

 

Hi, Kent, 

Thanks for helping me revive this thread, which is exactly what I want to do.:)

There was not a very fully discussion due to time constraints, but we did see 
some valuable points here, thank you everyone for sharing your views.

 

Regarding option2,  I am still unsure how will things go if there is no 
(I think it was raised by Balazs, hopefully Balazs can also add 
something here)? Should  be implemented along with ?

 

Option 3 is still unclear, e.g., whether the  is copied into  
automatically or manually? If auto-copy is not a good idea because it violates 
the definition of , whether manual-copy is performed towards part or 
all of the system configurations created in ?

Should we copy the entire  into ? Or should there be as few 
system configuration data items in  as possible?

Anyway, I agree that option3 may still incur a failed validation of  
when the operators reference the system configuration which is produced through 
the expansion of the system-defined templates.

If the existing mechanism(e.g., edit-config)is sufficient to define referenced 
system data item in , it seems that the flow marked in option3 from 
 to  can be removed, then it looks no difference between 
option1 and option3.

 

Best Regards,

Qiufang Ma

 

From: netmod [  mailto:netmod-boun...@ietf.org] 
On Behalf Of Kent Watsen
Sent: Thursday, July 29, 2021 1:09 AM
To:   netmod@ietf.org
Subject: Re: [netmod] system configuration sync mechanism

 

WG,

 

Regarding yesterday’s  datastore presentation, there seemed to be 
support for "Option #2”, which is to have  merge into .

 

It was noted that this then would mean that client-validation of  
would necessitate understanding how the merge works, to expand templates, 
resolve leafrefs, etc.

 

My thoughts are, so?   

 

Firstly, a client that doesn’t understand that there may be some  
defined configuration will, for the most part, be none the wiser.   The client 
*will* discover  configuration in , but this is already 
the case today.  One new thing is that  should use “origin:system” 
for configuration originating from the  datastore.  This last point 
might surprise clients…as the definition of “with-origin” doesn’t state that 
clients must ignore any unrecognized “origin” identities: 
https://datatracker.ietf.org/doc/html/rfc8527#section-3.2.2.

 

Secondly, no shared object defined in  will be activated until 
client-supplied config references it.  But any client able to do this already 
knows how  merges into  and is accounting for it.

 

Thoughts?

 

Kent

 

 

On Jul 16, 2021, at 6:24 AM, maqiufang (A) mailto:maqiufa...@huawei.com> > wrote:

 

Hi, Kent,

Please see my reply inline.

 

From: Kent Watsen [ 

[netmod] Comments on draft-ma-netconf-with-system-02

[Balázs Lengyel]

Hello,

MAJOR: 

The purpose of the draft (the purpose of creating a new datastore) should be
clearly stated. In my view:

“There is a need to validate configuration data against data created by the
system.”

 

What is the purpose of system-configuration

Use-case A)The system sets some values because it knows what they shall
be. In this case the client must not be allowed to modify these values. We
want to check configuration data against these values.  E.g., AcmeHomeRouter
has 5 interfaces called eth0, eth1, eth,2, eth3 and WAN. The client should
not try to add or remove interfaces to this set.

Use-case B)The system provides initial values for something that can be
configured in many ways. In this case the client is free to modify the
system-defined values. E.g., an initial set of NACM rules is provided. In
this case any constraints based on the system data are very weak, as the
user can change the system-data itself.

 

Use-case a) is very interesting and we actually implemented non-standard
support for it. I would welcome it in an RFC. 

I, myself tried to address this in
https://github.com/netmod-wg/yang-next/issues/41

Use-case b) IMHO does not require any special support. I will just load the
initial configuration as a last step of a reset, upgrade etc. 

 

 

Can a client remove or change a system-configuration data-node that is
automatically or manually copied to running/intended?  In use-case A) NO. In
use case B) yes.

Allowing some modifications, but not others is IMHO misleading and not
acceptable. Assuming that additions are OK while delete is not could be
incorrect if, the absence of some data node is important for the network
node.

 

 

 

 

Ch.2.2) “ should also immediately reset to its factory default
state.”

What is this state? It is undefined. I would rather say:  should be
reloaded or recreated.

Factory-reset may or may not remove results of an upgrade.

 

Ch.3)

“Update  with the system configuration change“
The auto-update should either be allowed to modify running or not, but this
idea of allowing create but not allowing delete is wrong. You may easily
have a “must” or “when” statement that checks that something does not exist,
in which case the current proposed behavior can lead to invalid
configuration. Also, the current behavior does not state whether a “case” in
a choice statement can be added? If you add one “case” the other is deleted.
So, can I add a “case”?
 
Ch 3.1 )
“If there exists any conflict, the configuration in the  should
succeed.”
It is hard to define what is a conflict. E.g. If the user deletes a data
node, but it comes back when loading system, how do we know if this is a
conflict because the user deleted it or if this is a new node that we can be
freely loaded into running/intended./intended. IMHO one more reason why
system-data must not be modified in running/intended; then we don’t have
this conflict. 
 
CH.3.2) Allowing a delete and then automatically reloading it is a very bad
idea. It is misleading for the user that a data node is in place after a
successful delete. Also, after delete, it is reloaded; so, between a
successful delete and the reloading there is a short interval where the data
node is not present? Dangerous.
 
Why don’t we have a auto-reload after merge?  Either allow
Netconf/CLI/Restconf to modify such system data or not. A mixed approach is
not acceptable. 
 
Ch 5.3.2) So if I have a model
Container aaa {
  Presence aaa;
  Leaf bbb {}
}
Where bbb is system data, but aaa is not then  the following 2 operations
might lead to different results ? IMHO that is not acceptable:
-Delete bbb
-Replace aaa with an empty aaa container
 

Regards Balazs

 

P.S. I am partly new to the topic, so sorry if I repeat some questions.

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-instance-file include-defaults leaf

[Balázs Lengyel]

Hello Rob,

Removing the “default trim;” will address Andy’s comment.

 

Your in-use-values is very specific to one of the use-cases: 
reading/documenting operational values. It is not useful for the other 
use-cases. I think the “documenting operational datastore” use-case could be 
handled by indicating the includes-defaults=report-all. Case (i) would contain 
the value case (ii) will not.

Regards Balazs

 

From: Rob Wilton (rwilton)  
Sent: 2021. július 27., kedd 17:38
To: Andy Bierman ; Balázs Lengyel 

Cc: NetMod WG 
Subject: RE: [netmod] yang-instance-file include-defaults leaf

 

Hi Andy, Balazs,

 

So, the reason that I want a flag to indicate whether default values are in use 
is because of this definition of operational in RFC 8342:

 

   Requests to retrieve nodes from  always return the value

   in use if the node exists, regardless of any default value specified

   in the YANG module.  If no value is returned for a given node, then

   this implies that the node is not used by the device.

 

It was written this way because otherwise a consumer of operational data cannot 
differentiate between:

(i)   This value is not present because it matches the default 
value specified in the YANG module, and

(ii)  This value is not present because the server has failed to 
return it for some reason (e.g., perhaps the daemon that would have provided 
this value is down or not available, or perhaps it is a bug, or perhaps it is 
not implemented and is a missing deviation).

 

So, I think that in some cases, the absence of a data node does not necessarily 
mean that the default value is in effect, and I wanted the instance-data 
document to be able to contain and correctly report this data.

 

I think that this behaviour could be captured by a single leaf.  Another way of 
articulating this would be:

 

leaf in-use-values {

  type boolean;

  default false;

  description

“Only if set to true, the absence of a value in the

 instance data for a given data node implies that the

node is not used rather than implicitly taking the

 default value specified by any corresponding

‘default’ statement specified in the YANG schema.”;

}

 

With this, I’m not sure whether we need the “includes-default” leaf currently 
specified in the draft, but if we do, then I would think that leaf should be 
entirely optional, i.e., without the default “trim”.

 

Regards,
Rob

 

 

From: Andy Bierman mailto:a...@yumaworks.com> > 
Sent: 10 July 2021 17:41
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com> >
Cc: NetMod WG mailto:netmod@ietf.org> >; Balázs Lengyel 
mailto:balazs.leng...@ericsson.com> >
Subject: Re: [netmod] yang-instance-file include-defaults leaf

 

 

 

On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) mailto:rwil...@cisco.com> > wrote:

Andy,

 

Yes, when I suggested this, I was thinking that a boolean flag might be 
sufficient.  My point being that automatically filtering out default values 
isn’t always the right thing to do.

 

 

 

The solution is simple.

Get rid of the inappropriate "default trim" statement.

 

If the leaf is present then it identifies the basic-mode that was used to 
include defaults.

If not then the information is either not known, not applicable, or defaults 
were not added.

 

The "default" statement is a bug because there is no default basic-mode.

All of the basic-modes are in use in deployments and no camp has ever

been able to convince the others that theirs is right.

 

 

Andy

 

E.g., something along these lines:

 

leaf exclude-defaults {

  type boolean;

  default true;

  description

“Can be used to reduce the size of the content data file.

 

  When unset or set to true, data nodes that have a default defined and

  where the actual value is the default value are excluded from the content

  data.

 

  When set to false, data nodes with default value are not filtered, and

  may appear in the content data.”

}

 

Would this satisfy your concern?

 

Regards,
Rob

 

 

From: netmod mailto:netmod-boun...@ietf.org> > On 
Behalf Of Andy Bierman
Sent: 08 July 2021 18:16
To: NetMod WG mailto:netmod@ietf.org> >
Subject: [netmod] yang-instance-file include-defaults leaf

 

Hi,

 

The module has this object:

 

leaf includes-defaults {
   type enumeration {
 enum report-all {
   value 1;
   description
 "All data nodes SHOULD be included independent of
   any default values.";
 }
 enum trim {
   value 2;
   description
 "Data nodes that have a default defined and where
   the actual value is the default value SHOULD
   NOT be included.";
 }
 enum explicit {
   value 3;
   description
 "Data nodes that have 

Re: [netmod] yang-instance-file include-defaults leaf

[Balázs Lengyel]

Hello Andy,

I will remove the “default trim; “

Balazs

 

From: Andy Bierman  
Sent: 2021. július 27., kedd 19:00
To: Rob Wilton (rwilton) 
Cc: Balázs Lengyel ; NetMod WG 
Subject: Re: [netmod] yang-instance-file include-defaults leaf

 

Hi,

 

None of this addresses my point that a default value of "trim" is not 
appropriate.

Simply remove the default-stmt so that a missing leaf instance means that

no information is provided, rather than meaning defaults were added for 
basic-mode=trim.

 

 

Andy

 

 

On Tue, Jul 27, 2021 at 8:38 AM Rob Wilton (rwilton) mailto:rwil...@cisco.com> > wrote:

Hi Andy, Balazs,

 

So, the reason that I want a flag to indicate whether default values are in use 
is because of this definition of operational in RFC 8342:

 

   Requests to retrieve nodes from  always return the value

   in use if the node exists, regardless of any default value specified

   in the YANG module.  If no value is returned for a given node, then

   this implies that the node is not used by the device.

 

It was written this way because otherwise a consumer of operational data cannot 
differentiate between:

(i)  This value is not present because it matches the default 
value specified in the YANG module, and

(ii)This value is not present because the server has failed to 
return it for some reason (e.g., perhaps the daemon that would have provided 
this value is down or not available, or perhaps it is a bug, or perhaps it is 
not implemented and is a missing deviation).

 

So, I think that in some cases, the absence of a data node does not necessarily 
mean that the default value is in effect, and I wanted the instance-data 
document to be able to contain and correctly report this data.

 

I think that this behaviour could be captured by a single leaf.  Another way of 
articulating this would be:

 

leaf in-use-values {

  type boolean;

  default false;

  description

“Only if set to true, the absence of a value in the

 instance data for a given data node implies that the

node is not used rather than implicitly taking the

 default value specified by any corresponding

‘default’ statement specified in the YANG schema.”;

}

 

With this, I’m not sure whether we need the “includes-default” leaf currently 
specified in the draft, but if we do, then I would think that leaf should be 
entirely optional, i.e., without the default “trim”.

 

Regards,
Rob

 

 

From: Andy Bierman mailto:a...@yumaworks.com> > 
Sent: 10 July 2021 17:41
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com> >
Cc: NetMod WG mailto:netmod@ietf.org> >; Balázs Lengyel 
mailto:balazs.leng...@ericsson.com> >
Subject: Re: [netmod] yang-instance-file include-defaults leaf

 

 

 

On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) mailto:rwil...@cisco.com> > wrote:

Andy,

 

Yes, when I suggested this, I was thinking that a boolean flag might be 
sufficient.  My point being that automatically filtering out default values 
isn’t always the right thing to do.

 

 

 

The solution is simple.

Get rid of the inappropriate "default trim" statement.

 

If the leaf is present then it identifies the basic-mode that was used to 
include defaults.

If not then the information is either not known, not applicable, or defaults 
were not added.

 

The "default" statement is a bug because there is no default basic-mode.

All of the basic-modes are in use in deployments and no camp has ever

been able to convince the others that theirs is right.

 

 

Andy

 

E.g., something along these lines:

 

leaf exclude-defaults {

  type boolean;

  default true;

  description

“Can be used to reduce the size of the content data file.

 

  When unset or set to true, data nodes that have a default defined and

  where the actual value is the default value are excluded from the content

  data.

 

  When set to false, data nodes with default value are not filtered, and

  may appear in the content data.”

}

 

Would this satisfy your concern?

 

Regards,
Rob

 

 

From: netmod mailto:netmod-boun...@ietf.org> > On 
Behalf Of Andy Bierman
Sent: 08 July 2021 18:16
To: NetMod WG mailto:netmod@ietf.org> >
Subject: [netmod] yang-instance-file include-defaults leaf

 

Hi,

 

The module has this object:

 

leaf includes-defaults {
   type enumeration {
 enum report-all {
   value 1;
   description
 "All data nodes SHOULD be included independent of
   any default values.";
 }
 enum trim {
   value 2;
   description
 "Data nodes that have a default defined and where
   the actual value is the default value SHOULD
   NOT be included.";
 }
 enum explicit {
   value 3;
   description
 "Data 

Re: [netmod] yang-instance-file include-defaults leaf

[Balázs Lengyel]

Hello Andy,

Looking through the use-cases I think the producer will always know whether it 
includes default values or not. This is the case if the instance data set is 
produced by the server e.g. in UC4, UC5,  or if it created by some design 
activity UC1, UC2, UC3, UC8. (UC6 and UC7 are so broad and loosely defined it 
is hard to say much about them.)

 

Once the producer knows whether defaults are included or not it can set the 
include-defaults accordingly, so the default value for include-defaults is not 
so important. However, I chose trim as the default because:

*   during the WGLC the draft explicitly stated that defaults SHOULD NOT be 
included and the WG was happy/ok with that
*   IMHO It is better to have short files, 

 

Note, I used the term producer, as IMHO the above is true in all cases whether 
the server produces the file or some design activity creates the server.

Regards Balazs

 

From: netmod  On Behalf Of Andy Bierman
Sent: 2021. július 8., csütörtök 19:16
To: NetMod WG 
Subject: [netmod] yang-instance-file include-defaults leaf

 

Hi,

 

The module has this object:

 

leaf includes-defaults {
   type enumeration {
 enum report-all {
   value 1;
   description
 "All data nodes SHOULD be included independent of
   any default values.";
 }
 enum trim {
   value 2;
   description
 "Data nodes that have a default defined and where
   the actual value is the default value SHOULD
   NOT be included.";
 }
 enum explicit {
   value 3;
   description
 "Data nodes that have a default defined and where
   the actual value is the default value SHOULD NOT be
   included. However, if the actual value was set by
   a NETCONF client or other management application
   by the way of an explicit management operation the
   data node SHOULD be included.";
 }
   }
   default trim;
 

The draft is extremely server-centric, like most IETF standards, but this

leaf is too server-centric to ignore.

 

Consider the possibility that the source of the file is NOT a NETCONF server.

This data may not be known so the default of "trim" may not be correct.

 

IMO this leaf is noise because any tool that knows the schema will also

know the YANG defaults.  The solution is incomplete anyway because

the presence of a leaf that has a YANG default is not enough.

The  "report-all-tagged" mode must be used to identify defaults.

IMO this leaf should be removed, but at least add an enum called "unknown".

 

 

Andy

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-15.txt

[Balázs Lengyel]

Hello Rob,
I included all comments from the AD review and associated mails. I stored an
updated version of the draft.
Thanks for all the comments.
Regards Balazs

-Original Message-
From: netmod  On Behalf Of internet-dra...@ietf.org
Sent: 2021. július 9., péntek 12:37
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action:
draft-ietf-netmod-yang-instance-file-format-15.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : YANG Instance Data File Format
Authors : Balazs Lengyel
  Benoit Claise
Filename: draft-ietf-netmod-yang-instance-file-format-15.txt
Pages   : 28
Date: 2021-07-09

Abstract:
   There is a need to document data defined in YANG models at design,
   implementation time or when a live server is unavailable.  This
   document specifies a standard file format for YANG instance data,
   which follows the syntax and semantics of existing YANG models, and
   annotates it with metadata.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format
/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-f
ormat-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-forma
t-15


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

Only https and file schemes will be mentioned in the draft.
Balazs

-Original Message-
From: netmod  On Behalf Of tom petch
Sent: 2021. július 9., péntek 10:58
To: Rob Wilton (rwilton) ; Juergen Schoenwaelder

Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of
draft-ietf-netmod-yang-instance-file-format

From: netmod  on behalf of Juergen Schoenwaelder

Sent: 08 July 2021 11:13

On Thu, Jul 08, 2021 at 09:30:27AM +, Rob Wilton (rwilton) wrote:
> It is perhaps worth noting that the NETCONF copy-config allows for the
configuration to be specified using any URI, but the server capabilities
announce which URI schemes are supported.
>
> Hence, I think that it is okay for the YANG model to use URI, but I think
the draft, and data node description should constrain the URI schemes that
allowed (perhaps file:// and https://).  This would allow support for future
URI schemes to be added in a future revision of the YANG instance data
module, if required.
>

I think it is not "allowed" but "mandatory to implement". We should allow
implementations to support an ftps:// scheme as long as there is a common
baseline.


I am confused.  Is ftps: intended to be an existing scheme or a hypothetical
one that may appear in the future.  I do not see it in the IANA registry
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-1

sftp: appears as a provisional entry in the IANA registry but AFACT did not
get specified.  I recall a debate about ftps: v sftp:  I favoured the former
but lost but then I did not see any further work on either.

Tom Petch

/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

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

Hello Andy,

In the name of simplification, I will add the following to the URI method:

 

Referenced files using  "inline" or the "simplified-inline" methods MUST be 
supported. 

Referenced files using the "URI method" MAY be supported.

 

This means the tool does not need to be prepared for chains or loops. I think 
chains and loops are something we should discourage. 

(Referenced files using the “external Method” make no sense anyway. If I don’t 
tell you the schema of the referenced file, there is no sense in referencing 
them)

Regards Balazs

 

From: netmod  On Behalf Of Balázs Lengyel
Sent: 2021. július 9., péntek 9:39
To: Andy Bierman ; Rob Wilton (rwilton) 
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

 

Hello Andy,

See below.

Balazs

 

From: Andy Bierman mailto:a...@yumaworks.com> > 
Sent: 2021. július 8., csütörtök 18:55
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com> >
Cc: Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de> >; Balázs Lengyel 
mailto:balazs.leng...@ericsson.com> >; 
netmod@ietf.org <mailto:netmod@ietf.org> ; Benoit Claise 
mailto:benoit.cla...@huawei.com> >
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

 

 

 

On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) mailto:rwil...@cisco.com> > wrote:

Hi Juergen,

I believe that having the simple form is worth the extra complexity.

 

 

I believe it is the only option that does not have too much complexity.

 

The inline form seems to imply that the NMDA version of the YANG library is 
used.

Only 1 module set is ever shown, but of course the actual schema allows

for much more complex instances than that, which the reader must support.

 

Does this mean NMDA must be used or else a YANG data file cannot be saved?

So the reader is expected to look for the 'current' /yang-library and then the 
'deprecated' /modules-state?

And then fish the anydata for whatever non-standard solution is in use?

The procedures should be explained better so there is a better chance of 
interoperability.

BALAZS: No NMDA is not required. If it would there would be a clear statement 
about it. Even in section 2.2.1.  Documentation of server capabilities the new 
(NMDA compatible) yang-library is used, but the simple (non- NMDA) 
modules-state branch.

 

For the URI method, the reader must check for a broken chain of reference and 
loops.

The draft should say the uri references across N files MUST NOT create a loop

(similar language is in YANG wrt import loops).

BALAZS: Someone (don.t know who) asked for longer reference chains. However, I 
don’t see them as a common use-case. IMHO the most common use-case for the URI 
method will be, when the consumer knows the content-schema apriori, it only 
needs a reference to check that the schema is what it expected.

 

For conformance purposes, I think YANG features are appropriate.

IMO simplified-inline is mandatory-to-implement but the rest should 

be optional. This way a tool can claim conformance and also the standard

will provide a minimum level of interoperability.

BALAZS: There are very different views about the preferred/required methods. 
Also the needs of different use-cases are different. That’s why we need all 3.

 

 

Andy

 

 

 

 

I think that you are right to be concerned that it should not expand into a 
separate parallel format.  Overtime, I would like the simple form to be able to 
use revision labels instead of revision dates, but beyond this I think that it 
should just be a flat list of modules that defines the schema.  If a subset of 
features, or datastores, or import-only modules are needed then the YANG 
library version (or URIs) can and should be used.

 

This can be done with augment if and when the versioning draft reaches RFC

 

Another example of where I expect it to be useful is in YANG packages.  Looking 
at the examples at the end of 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, then 
some of those files (which currently aren't defining any schema, but should) 
would almost double in size if they represented the schema inline using YANG 
library, which I think would make the files harder for humans to read/parse.  
Using URIs could help mitigate this, but then we would need to find a place to 
publish the file containing the YANG package schema (presumably somewhere in 
IANA), and it not obvious to me that adding the dependency on the URL is really 
as helpful.

Regards,
Rob


> -Original Message-
> From: Juergen Schoenwaelder  <mailto:j.schoenwael...@jacobs-university.de> >
> Sent: 08 July 2021 11:35
> To: Balázs Lengyel  <mailto:balazs.leng...@ericsson.com> >
> Cc: Andy Bierman mailto:a...@yumaworks.com> >; Rob 
> Wilton (rwilton)
> mailto:rwil...@cisco.com> >; netmod@ietf.org 
> &l

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

Hello Andy,

See below.

Balazs

 

From: Andy Bierman  
Sent: 2021. július 8., csütörtök 18:55
To: Rob Wilton (rwilton) 
Cc: Juergen Schoenwaelder ; Balázs 
Lengyel ; netmod@ietf.org; Benoit Claise 

Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

 

 

 

On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) mailto:rwil...@cisco.com> > wrote:

Hi Juergen,

I believe that having the simple form is worth the extra complexity.

 

 

I believe it is the only option that does not have too much complexity.

 

The inline form seems to imply that the NMDA version of the YANG library is 
used.

Only 1 module set is ever shown, but of course the actual schema allows

for much more complex instances than that, which the reader must support.

 

Does this mean NMDA must be used or else a YANG data file cannot be saved?

So the reader is expected to look for the 'current' /yang-library and then the 
'deprecated' /modules-state?

And then fish the anydata for whatever non-standard solution is in use?

The procedures should be explained better so there is a better chance of 
interoperability.

BALAZS: No NMDA is not required. If it would there would be a clear statement 
about it. Even in section 2.2.1.  Documentation of server capabilities the new 
(NMDA compatible) yang-library is used, but the simple (non- NMDA) 
modules-state branch.

 

For the URI method, the reader must check for a broken chain of reference and 
loops.

The draft should say the uri references across N files MUST NOT create a loop

(similar language is in YANG wrt import loops).

BALAZS: Someone (don.t know who) asked for longer reference chains. However, I 
don’t see them as a common use-case. IMHO the most common use-case for the URI 
method will be, when the consumer knows the content-schema apriori, it only 
needs a reference to check that the schema is what it expected.

 

For conformance purposes, I think YANG features are appropriate.

IMO simplified-inline is mandatory-to-implement but the rest should 

be optional. This way a tool can claim conformance and also the standard

will provide a minimum level of interoperability.

BALAZS: There are very different views about the preferred/required methods. 
Also the needs of different use-cases are different. That’s why we need all 3.

 

 

Andy

 

 

 

 

I think that you are right to be concerned that it should not expand into a 
separate parallel format.  Overtime, I would like the simple form to be able to 
use revision labels instead of revision dates, but beyond this I think that it 
should just be a flat list of modules that defines the schema.  If a subset of 
features, or datastores, or import-only modules are needed then the YANG 
library version (or URIs) can and should be used.

 

This can be done with augment if and when the versioning draft reaches RFC

 

Another example of where I expect it to be useful is in YANG packages.  Looking 
at the examples at the end of 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, then 
some of those files (which currently aren't defining any schema, but should) 
would almost double in size if they represented the schema inline using YANG 
library, which I think would make the files harder for humans to read/parse.  
Using URIs could help mitigate this, but then we would need to find a place to 
publish the file containing the YANG package schema (presumably somewhere in 
IANA), and it not obvious to me that adding the dependency on the URL is really 
as helpful.

Regards,
Rob


> -Original Message-
> From: Juergen Schoenwaelder  <mailto:j.schoenwael...@jacobs-university.de> >
> Sent: 08 July 2021 11:35
> To: Balázs Lengyel  <mailto:balazs.leng...@ericsson.com> >
> Cc: Andy Bierman mailto:a...@yumaworks.com> >; Rob 
> Wilton (rwilton)
> mailto:rwil...@cisco.com> >; netmod@ietf.org 
> <mailto:netmod@ietf.org> ; Benoit Claise
> mailto:benoit.cla...@huawei.com> >
> Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> The question I asked is "how much simpler is it and does that saving
> justify the introduction of a new rather limited format (that may risk
> to grow over time and become a second citizen)".
> 
> So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports
> from ietf-yang-types (at the time of publication that resolves to
> ietf-yang-types@2013-07-15. So the YANG Library instance data would
> roughly look this (please correct what I messed up, I am writing this
> by hand):
> 
> 
>   
> m
> 
>   ietf-netconf-acm
>   2018-02-14
>   uri1
> 
> 
>   ietf-yang-types
>   uri2
>   
> 
>   
>   
> s
> m
>   
>   
> running
> s
>   
> 
> 
> Yes, this is a bit longer, but it also conveys more information

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

Hello,
A single line is enough.
As long as ietf-yang-types is change in a backward compatible way, I don't
care which version of yang-types is imported. Also, we only use a single
type 'yang:xpath1.0' from yang-types. The rules for this type  are described
by W3C and not changing. 
Balazs

-Original Message-
From: Rob Wilton (rwilton)  
Sent: 2021. július 8., csütörtök 15:49
To: Balázs Lengyel ; Juergen Schoenwaelder

Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise

Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format

Hi Balazs,

Would your inline schema not also need to specify the ietf-yang-types
dependency?

E.g., should it be:
ietf-netconf-acm@2018-02-14
ietf-yang-types@2013-07-15

Thanks,
Rob


> -Original Message-
> From: Balázs Lengyel 
> Sent: 08 July 2021 12:48
> To: Rob Wilton (rwilton) ; Juergen Schoenwaelder 
> 
> Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise 
> 
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hello,
> I would like to keep simplified inline. If I ask my developers (not 
> experts) which one do they want? I am pretty sure they opt for the 
> shorter/simpler one.
> 
> ietf-netconf-acm@2018-02-14
> 
> OR
> 
> 
>   
> m
> 
>   ietf-netconf-acm
>   2018-02-14
>   uri1
> 
> 
>   ietf-yang-types
>   uri2
>   
> 
>   
>   
> s
> m
>   
>   
> running
> s
>   
> 
> 
> Regards Balazs
> 
> -----Original Message-
> From: Rob Wilton (rwilton) 
> Sent: 2021. július 8., csütörtök 12:59
> To: Juergen Schoenwaelder ; 
> Balázs Lengyel 
> Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise 
> 
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hi Juergen,
> 
> I believe that having the simple form is worth the extra complexity.
> 
> I think that you are right to be concerned that it should not expand 
> into a separate parallel format.  Overtime, I would like the simple 
> form to be able to use revision labels instead of revision dates, but 
> beyond this I think that it should just be a flat list of modules that 
> defines the schema.  If a subset of features, or datastores, or 
> import-only modules are needed then the YANG library version (or URIs) can
and should be used.
> 
> Another example of where I expect it to be useful is in YANG packages.
> Looking at the examples at the end of
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, 
> then some of those files (which currently aren't defining any schema, 
> but should) would almost double in size if they represented the schema 
> inline using YANG library, which I think would make the files harder 
> for humans to read/parse.
> Using URIs could help mitigate this, but then we would need to find a 
> place to publish the file containing the YANG package schema 
> (presumably somewhere in IANA), and it not obvious to me that adding 
> the dependency on the URL is really as helpful.
> 
> Regards,
> Rob
> 
> 
> > -Original Message-
> > From: Juergen Schoenwaelder 
> > Sent: 08 July 2021 11:35
> > To: Balázs Lengyel 
> > Cc: Andy Bierman ; Rob Wilton (rwilton) 
> > ; netmod@ietf.org; Benoit Claise 
> > 
> > Subject: Re: AD review of 
> > draft-ietf-netmod-yang-instance-file-format
> >
> > The question I asked is "how much simpler is it and does that saving 
> > justify the introduction of a new rather limited format (that may 
> > risk to grow over time and become a second citizen)".
> >
> > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports 
> > from ietf-yang-types (at the time of publication that resolves to 
> > ietf-yang-types@2013-07-15. So the YANG Library instance data would 
> > roughly look this (please correct what I messed up, I am writing 
> > this by hand):
> >
> > 
> >   
> > m
> > 
> >   ietf-netconf-acm
> >   2018-02-14
> >   uri1
> > 
> > 
> >   ietf-yang-types
> >   uri2
> >   
> > 
> >   
> >   
> > s
> > m
> >   
> >   
> > running
> > s
> >   
> > 
> >
> > Yes, this is a bit longer, but it also conveys more information 
> > (note that your datastore leaf in the header would likely not be 
> > needed anymore).
> >
> > I am concerned that we start creating another format to define 
> > schemas that is very limited and people later come with extension 
> > proposals to address some of the limits and at the end we have 

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

Hello,
I would like to keep simplified inline. If I ask my developers (not experts)
which one do they want? I am pretty sure they opt for the shorter/simpler
one.
 
ietf-netconf-acm@2018-02-14

OR


  
m

  ietf-netconf-acm
  2018-02-14
  uri1


  ietf-yang-types
  uri2
  

  
  
s
m
  
  
running
s
  


Regards Balazs

-Original Message-
From: Rob Wilton (rwilton)  
Sent: 2021. július 8., csütörtök 12:59
To: Juergen Schoenwaelder ; Balázs
Lengyel 
Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise

Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format

Hi Juergen,

I believe that having the simple form is worth the extra complexity.

I think that you are right to be concerned that it should not expand into a
separate parallel format.  Overtime, I would like the simple form to be able
to use revision labels instead of revision dates, but beyond this I think
that it should just be a flat list of modules that defines the schema.  If a
subset of features, or datastores, or import-only modules are needed then
the YANG library version (or URIs) can and should be used.

Another example of where I expect it to be useful is in YANG packages.
Looking at the examples at the end of
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, then
some of those files (which currently aren't defining any schema, but should)
would almost double in size if they represented the schema inline using YANG
library, which I think would make the files harder for humans to read/parse.
Using URIs could help mitigate this, but then we would need to find a place
to publish the file containing the YANG package schema (presumably somewhere
in IANA), and it not obvious to me that adding the dependency on the URL is
really as helpful.

Regards,
Rob


> -Original Message-
> From: Juergen Schoenwaelder 
> Sent: 08 July 2021 11:35
> To: Balázs Lengyel 
> Cc: Andy Bierman ; Rob Wilton (rwilton) 
> ; netmod@ietf.org; Benoit Claise 
> 
> Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> The question I asked is "how much simpler is it and does that saving 
> justify the introduction of a new rather limited format (that may risk 
> to grow over time and become a second citizen)".
> 
> So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports 
> from ietf-yang-types (at the time of publication that resolves to 
> ietf-yang-types@2013-07-15. So the YANG Library instance data would 
> roughly look this (please correct what I messed up, I am writing this 
> by hand):
> 
> 
>   
> m
> 
>   ietf-netconf-acm
>   2018-02-14
>   uri1
> 
> 
>   ietf-yang-types
>   uri2
>   
> 
>   
>   
> s
> m
>   
>   
> running
> s
>   
> 
> 
> Yes, this is a bit longer, but it also conveys more information (note 
> that your datastore leaf in the header would likely not be needed 
> anymore).
> 
> I am concerned that we start creating another format to define schemas 
> that is very limited and people later come with extension proposals to 
> address some of the limits and at the end we have multiple formats to 
> maintain and deal with. So the question is whether people think this 
> is worth it. (Note that the felt overhead goes down with every 
> additional module used by your instance file, so the example above is 
> really the most extreme case. And if you have many modules defining 
> NACM rules, then you put the above into a separate file and use the 
> URI to point to the schema, no?
> 
> /js
> 
> On Thu, Jul 08, 2021 at 09:27:52AM +, Balázs Lengyel wrote:
> > Hello Jurgen,
> > Inline:
> > This complex form of inline was requested and not objected earlier 
> > by
> other
> > reviewers.
> > Based on Rob's and others' proposal inline will be simplified to use 
> > only
> > ietf-yang-library@2019-01-04 as you suggest.
> >
> > Simplified inline:
> > In Ericsson we already use simplified inline a lot, it is the most 
> > common format.
> > If you are providing data only for one or a few YANG modules and 
> > don't
> have,
> >
> > don't care about features/deviations it is the easiest, shortest 
> > method to use.
> >  Our most common use-case is to provide preconfigured access control
> rules
> > for new nodes.
> > When a YANG modeler designs a new module, he immediately provides a
> set of
> > NACM rules
> > for the readOnly and the SystemAdmin roles/groups.
> > In this case you only need to specify "ietf-neconf-acm@2012-02-22" 
> > No deviations, no features to indicate.
> > Regards Balazs
> >
>

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

Hello Jurgen,
Inline:
This complex form of inline was requested and not objected earlier by other
reviewers. 
Based on Rob's and others' proposal inline will be simplified to use only
ietf-yang-library@2019-01-04 as you suggest.

Simplified inline:
In Ericsson we already use simplified inline a lot, it is the most common
format. 
If you are providing data only for one or a few YANG modules and don't have,

don't care about features/deviations it is the easiest, shortest method to
use.
 Our most common use-case is to provide preconfigured access control rules
for new nodes. 
When a YANG modeler designs a new module, he immediately provides a set of
NACM rules 
for the readOnly and the SystemAdmin roles/groups.
In this case you only need to specify "ietf-neconf-acm@2012-02-22" No
deviations, no features to indicate.
Regards Balazs

Regards Balazs

-Original Message-
From: Juergen Schoenwaelder  
Sent: 2021. július 7., szerda 21:26
To: Andy Bierman 
Cc: Balázs Lengyel ; Rob Wilton (rwilton)
; netmod@ietf.org; Benoit Claise

Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote:
> 
> > Inline method is needed, if you want to indicate that the file was 
> > generated by someone who uses some YANG modules with deviations and 
> > some features are not-supported. There is no way to indicate 
> > feature-support and deviations with the simplified-inline method.
> 
> The Inline anydata solution is very heavyweight.
> Before the YANG library there was a simple URI that is easier to use 
> and takes up much less storage.
>

The inline content schema is super generic since it supports an open ended
set of schema defining modules. While you can use it with say
ietf-yang-library@2019-01-04, you can use anything else as well. In other
words, two implementations supporting inline content schema may not
interoperate. I do not think there is a schema format that is mandatory to
implement for inline content schema.

So here is my assessment of what we have in terms of interoperability:

- Simplified-Inline comes with notable restrictions, interoperable
- Inline is an open ended content schema, not necessarily interoperable
- URI method pushes the problem to another instance file, interoperable
- External is by desing not interoperable

On the server side, we have YANG Library. Perhaps RFC 8525 has some
complexity that is useful for supporting large servers with multiple
datastores and not needed for small instance files (I understand that an
instance file is always tied to a single datastore?).

To me, it feels that reusing RFC 8525 design is actually a good thing. Being
able to dump a live server datastore into an instance file seems like a very
valid use case to me and ideally this is possible without having to rewrite
the schema part. Well, you could go and trim unused datastore schemas and
from there unused module sets etc but that can all be done by an external
tool trimming the schema part, i.e., it does not need to be done by a tool
that just dumps a server datastore.

What is the actual value of simplified inline? How much do you really save
compared to the simplest equivalent RFC 8525 representation? And does that
saving justify to start engineering another schema specification format?

I guess my choice would have been to just have

   +-- content-schema
   |  +-- (content-schema-spec)?
   | +--: (yang-library)
   | +--: (uri)

but others obviously want much more choice (but lets note that everything
sits in a choice, so everything is extensible in case other schema
definition formats are out there).

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103
<https://protect2.fireeye.com/v1/url?k=fe85c8e6-a11ef1cd-fe85887d-866038973a
15-19e5dad375af0063=1=3637406d-f774-4073-80ee-a743e9bc=https%3A%2F
%2Fwww.jacobs-university.de%2F>


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

See inline, Balazs

 

From: Andy Bierman  
Sent: 2021. július 7., szerda 20:50
To: Balázs Lengyel 
Cc: Juergen Schoenwaelder ; Rob Wilton 
(rwilton) ; netmod@ietf.org; Benoit Claise 

Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

 

Hi,

 

I have some questions about the same-schema-as-file leaf:

 

   leaf same-schema-as-file {
 type inet:uri;
 description
   "A reference to another YANG instance data file.
This instance data file uses the same
content schema as the referenced file.";
   }

 

The type is an unconstrained URI.

Is this the intent?

The tool that writes the file can pick any scheme - any valid URI at all.

The reader must support every known URI scheme in existence? Is that the intent 
here?

BALAZS: As the number of URI schemes is growing with new URI schemes introduced 
from time to time, that is clearly impossible. On the other hand, we don’t want 
to constrain URI schemes. This draft is not about selecting the best URI 
schemes for referencing a file, it only about providing a common format for 
metadata about instance files. The set of usable/used URI schemes will have to 
be communicated using some other method. You could ask a similar question: does 
a Netconf client need to be prepared for any YANG model? No just for the ones 
he is interested in.

 

Sec. 4 contains this line:

 

The header part is not security sensitive.
 

Is this really true if a URI is present in this leaf that contains a username 
and password

in cleartext? 

BALAZS: Clear text passwords are not the intention. Shall I  add a statement 
about this to the security considerations?

 

Andy

 

 

On Wed, Jul 7, 2021 at 1:01 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

Hello Andy,

There are many different use-cases for instance-data-files, each with slightly 
different requirements. 

 

Inline method is needed, if you want to indicate that the file was generated by 
someone who uses some YANG modules with deviations and some features are 
not-supported. There is no way to indicate feature-support and deviations with 
the simplified-inline method.

 

The URL method was requested for the use-case when you generate 
instance-data-sets repeatedly e.g. every minute with the same schema. You don’t 
want to include the content-schema in every file, so you just include a single 
URL reference. (Note the content schema may be a longer piece of text, not just 
a single YANG module+revision)

Regards Balazs

 

From: Andy Bierman mailto:a...@yumaworks.com> > 
Sent: 2021. július 6., kedd 21:28
To: Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de> >; Andy Bierman 
mailto:a...@yumaworks.com> >; Rob Wilton (rwilton) 
mailto:rwil...@cisco.com> >; Balázs Lengyel 
mailto:balazs.leng...@ericsson.com> >; 
netmod@ietf.org <mailto:netmod@ietf.org> ; Benoit Claise 
mailto:benoit.cla...@huawei.com> >
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

 

 

 

On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de> > wrote:

On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de 
> <mailto:j.schoenwael...@jacobs-university.de> > wrote:
> 
> > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> > >
> > > IMO the 4 separate ways to identify the schema are 3 too many, but that
> > > is what the WG wants.  It seems obvious that any reader of the file
> > > has to implement all 4 methods and any writer of the file is free to pick
> > > just one.
> > > So the feature does not really help.
> > >
> >
> > The feature statements declare that implementation won't work
> > together. Back in a day, the IETF was all about interoperability (and
> > implementation costs). Nowadays we seem to be fine if implementations
> > declare that they won't work together. Well, still slightly better
> > than having implementations fail arbitrarity.
> >
> >
> 
> This is a text file stored on a USB stick.
> There is no client or server. Just readers and writers.
> So how does a YANG feature work here?
> The reader is supposed to know how to find out if this feature is set
> before opening the file?
>
> I don't see how server capabilities discovery is relevant to a
> YANG instance file.
> The reader code will simply attempt to read the file and fail if it
> encounters
> a format that is not implemented.

I assumed that the features are carried in the instance file, i.e.,
the file declares that it uses way X to announce the schema and then
the parser can fail with a suitable error message. If the featur

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

Hello,

*   Inline is needed because you might want to specify dozens of YANG 
modules with all their features and deviations. That is a lot of information,  
so yes it will take some effort to read and understand it; real life nodes do 
contain many YAMs, features, deviations. 
*   Simplified-inline is needed, because it is self-contained and often an 
instance data set only contains info for 1 or 2 YANG modules without deviations 
or feature issues
*   URL is required because it is self-describing at least via reference. 
It might describe big, complicated schemas with a single URI. Most useful when 
many files with the same complex schema are processed. 
*   External method is needed because in many environments the schema is 
already known, so it does not need to be included

 

The workgroup has agreed that all 4 methods are needed for some use-cases. We 
can restart that debate, but I hope not.

 

Regards Balazs

 

From: Andy Bierman  
Sent: 2021. július 7., szerda 20:12
To: Balázs Lengyel 
Cc: Juergen Schoenwaelder ; Rob Wilton 
(rwilton) ; netmod@ietf.org; Benoit Claise 

Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

 

 

 

On Wed, Jul 7, 2021 at 1:01 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

Hello Andy,

There are many different use-cases for instance-data-files, each with slightly 
different requirements. 

 

 

I don't agree that the solution requires 3 ways to do the same thing.

Well, 4 if you count External which means Proprietary and Not Standard At All.

 

Inline method is needed, if you want to indicate that the file was generated by 
someone who uses some YANG modules with deviations and some features are 
not-supported. There is no way to indicate feature-support and deviations with 
the simplified-inline method.

 

 

The Inline anydata solution is very heavyweight.

Before the YANG library there was a simple URI that is easier to use

and takes up much less storage.

 

 

The URL method was requested for the use-case when you generate 
instance-data-sets repeatedly e.g. every minute with the same schema. You don’t 
want to include the content-schema in every file, so you just include a single 
URL reference. (Note the content schema may be a longer piece of text, not just 
a single YANG module+revision)

 

The solution is very complex and it will not get implemented correctly, or at 
all.

IMO this damages interoperability and prevents some companies from using the 
solution

at all, because a reader tool has so much complexity to implement.  The 
real-world result

will be tools that can only read the files they wrote (not written by another 
tool).

 

 

Regards Balazs

 

 

Andy

 

From: Andy Bierman mailto:a...@yumaworks.com> > 
Sent: 2021. július 6., kedd 21:28
To: Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de> >; Andy Bierman 
mailto:a...@yumaworks.com> >; Rob Wilton (rwilton) 
mailto:rwil...@cisco.com> >; Balázs Lengyel 
mailto:balazs.leng...@ericsson.com> >; 
netmod@ietf.org <mailto:netmod@ietf.org> ; Benoit Claise 
mailto:benoit.cla...@huawei.com> >
Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

 

 

 

On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de> > wrote:

On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de 
> <mailto:j.schoenwael...@jacobs-university.de> > wrote:
> 
> > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> > >
> > > IMO the 4 separate ways to identify the schema are 3 too many, but that
> > > is what the WG wants.  It seems obvious that any reader of the file
> > > has to implement all 4 methods and any writer of the file is free to pick
> > > just one.
> > > So the feature does not really help.
> > >
> >
> > The feature statements declare that implementation won't work
> > together. Back in a day, the IETF was all about interoperability (and
> > implementation costs). Nowadays we seem to be fine if implementations
> > declare that they won't work together. Well, still slightly better
> > than having implementations fail arbitrarity.
> >
> >
> 
> This is a text file stored on a USB stick.
> There is no client or server. Just readers and writers.
> So how does a YANG feature work here?
> The reader is supposed to know how to find out if this feature is set
> before opening the file?
>
> I don't see how server capabilities discovery is relevant to a
> YANG instance file.
> The reader code will simply attempt to read the file and fail if it
> encounters
> a format that is not implemented.

I assumed that the features are carried in the 

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

Hello Andy,

There are many different use-cases for instance-data-files, each with slightly 
different requirements. 

 

Inline method is needed, if you want to indicate that the file was generated by 
someone who uses some YANG modules with deviations and some features are 
not-supported. There is no way to indicate feature-support and deviations with 
the simplified-inline method.

 

The URL method was requested for the use-case when you generate 
instance-data-sets repeatedly e.g. every minute with the same schema. You don’t 
want to include the content-schema in every file, so you just include a single 
URL reference. (Note the content schema may be a longer piece of text, not just 
a single YANG module+revision)

Regards Balazs

 

From: Andy Bierman  
Sent: 2021. július 6., kedd 21:28
To: Juergen Schoenwaelder ; Andy Bierman 
; Rob Wilton (rwilton) ; Balázs Lengyel 
; netmod@ietf.org; Benoit Claise 

Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format

 

 

 

On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de> > wrote:

On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de 
> <mailto:j.schoenwael...@jacobs-university.de> > wrote:
> 
> > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> > >
> > > IMO the 4 separate ways to identify the schema are 3 too many, but that
> > > is what the WG wants.  It seems obvious that any reader of the file
> > > has to implement all 4 methods and any writer of the file is free to pick
> > > just one.
> > > So the feature does not really help.
> > >
> >
> > The feature statements declare that implementation won't work
> > together. Back in a day, the IETF was all about interoperability (and
> > implementation costs). Nowadays we seem to be fine if implementations
> > declare that they won't work together. Well, still slightly better
> > than having implementations fail arbitrarity.
> >
> >
> 
> This is a text file stored on a USB stick.
> There is no client or server. Just readers and writers.
> So how does a YANG feature work here?
> The reader is supposed to know how to find out if this feature is set
> before opening the file?
>
> I don't see how server capabilities discovery is relevant to a
> YANG instance file.
> The reader code will simply attempt to read the file and fail if it
> encounters
> a format that is not implemented.

I assumed that the features are carried in the instance file, i.e.,
the file declares that it uses way X to announce the schema and then
the parser can fail with a suitable error message. If the features are
not carried in the file, then they indeed seem to be useless.

Perhaps there are Y different ways to announce the features of the
instance file as well, I did not check. ;-)

 

Now you made re-read the entire draft :-(

I cannot find any text how the reader knows if this feature is set before 
reading the

file and finding out.

 

I do not see any significant use-case for the Inline method and none for the 
Uri method.

Nor do I see any reason why the Simplified-Inline method should not be mandatory

to use and always present.

 

If the use-case is offline server validation then the YANG library details need 
to be known.

The entire YANG library for the server (or relevant parts) are recorded in the 
Inline method.

Except it is complicated to store the info about how to interpret YANG schema by

reading instance files and guessing what the "anydata" contains.

 

I actually prefer a simple string based on RFC 6020 URI method, since it can

be easily integrated into the Simplified Inline form and can be parsed without 
guessing

anything about the contents of anydata.

 

https://datatracker.ietf.org/doc/html/rfc6020#section-5.6.4

 

e,g,

 

OLD:

 case simplified-inline {
   leaf-list module {
  type module-with-revision-date;

  ...

}

  }

 

NEW:

 

 case simplified-inline {
   leaf-list module {
  type union {

   type module-with-revision-date;

   type string;

   }

   ...

}

  }

 

Example module leaf-list entry:

 

   
ietf-interfaces?revision=2018-02-20=if-mib,arbitrary-names=acme-deviations

 

 

IMO Simplified Inline SHOULD be the only format, and the other methods can be 
removed.

 

 

/js

 

 

Andy

 

 


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/ 
<https

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

Hello Rob,
I would be happy to simplify the draft. Just we are restarting debates which
were settled earlier. This can lead to a never-ending cycle.

So, I propose to:
- remove all mention of the revision-label
- remove the feature
- for the inline method allow just ietf-yang-library@2019-01-04 as a
_single_ file. This also means that I should remove the leaf inline-module
as there is no need for it anymore. We know the single YANG module it would
define.
Is that acceptable?
Regards Balazs

P.S. The feature was possible to use. 
It could be read from " out-of-band documentation" As indicated in the YANG
module. For some use-cases (E.g. Use Case 2: Preloading Data) when the
operator/designer is sending data to the server (not receiving it), it is
useful to know whether the inline method is supported or not.

In case the file comes from the server the feature is less useful.


-Original Message-
From: Rob Wilton (rwilton)  
Sent: 2021. július 6., kedd 17:15
To: Balázs Lengyel ; 'netmod@ietf.org'
; a...@yumaworks.com; Juergen Schoenwaelder

Cc: Benoit Claise 
Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format

Hi Balazs,

To follow up with our conversation earlier.  Andy and Juergen explicitly
copied because they may have previously commented on these issues during WG
LC.

I think that my comment regarding the "feature statement" and the
flexibility of the inline-method are closely related.  I find the definition
of the inline-content-schema to be so generic that it effectively allows
anything.  E.g., the drafts would allow me to publish a file that has an
inline-content-schema based on robs-random-schema-format@1.0.0, and it would
be very difficult for consumers of the associated instance data file to
understand the file schema.

Similarly, I find that allowing revision labels (as examples to avoid a
normative reference to the module versioning draft), makes it hard for a
generic implementation reader of a instance data file to know how to
interpret an inline schema.  I suspect that this issue could cause problems
in the IESG reviews.

Hence, my preference, for this RFC, that defines version 1 of the instance
file format, would be to more heavily constrain how the schema is allowed to
be specified in the inline-method.  Specifically, I think that it would be
better to:
 - restrict the inline schema to only be defined using
ietf-yang-library@2019-01-04
 - only allow revision-dates, not revision labels.

I would like to understand from Andy, whether he still thinks with these
restrictions whether the inline-schema method should still be under a YANG
feature statement?

If/when the revision labels draft gets standardized, and perhaps also after
YANG packages, then we could do a bis version of this document to define a
v2 of the instance file format that potentially allows YANG packages to be
used to define the schema, and potentially allows modules to be identified
using revision labels as well as revision dates.

Balazs, I'm good with most of your proposed resolutions, but have answered
one further question inline below.


> -Original Message-
> From: Balázs Lengyel 
> Sent: 05 July 2021 13:47
> To: 'netmod@ietf.org' ; Rob Wilton (rwilton) 
> 
> Cc: Benoit Claise 
> Subject: FW: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hello Rob,
> Thanks for the review.  Here are my answers below. I will also upload 
> the new version asap.
> Regards Balazs
> ---
> Hi,
> 
> Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13.
> 
> Thanks for this document, I think that it represents important useful 
> work for advancing the YANG ecosystem.
> 
> This document is in good shape, and I mostly have minor comments but 
> with a few more significant comments.
> 
> Main comments:
> 

> 
> 2.
> In the YANG Module:
>  feature inline-content-schema {
>description
>  "This feature indicates that inline content-schema
>   option is supported. Support for this feature might
>   be documented only via out-of-band documentation.";
>  }
> 
> What is the benefit of having 'inline-content-schema' as a feature?  
> It seems to potentially add complexity without any benefit, given that 
> the device originating the instance data file would effectively choose 
> whether to use the inline-content-schema, hence I suggest that it 
> might be simpler just to remove the feature definition.
> BALAZS: This was explicitly requested earlier by a reviewer (Andy ?).
> The system can declare supported/not-supported in design documentation.
> In a use-case when a client or a design department is sending data to 
> a server this is needed. E.g. in UC2, Preloading Default Configuration 
> the designer pr

[netmod] FW: AD review of draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

Hello Rob,
Thanks for the review.  Here are my answers below. I will also upload the
new version asap.
Regards Balazs
---
Hi,

Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13.

Thanks for this document, I think that it represents important useful work
for advancing the YANG ecosystem.

This document is in good shape, and I mostly have minor comments but with a
few more significant comments.

Main comments:

1.
   An instance data set MAY contain data for any number of YANG modules;
   if needed it MAY carry the complete configuration and state data for
   a server.  Default values SHOULD NOT be included.

This document recommends that default values SHOULD NOT be included, but
there are cases where they are useful, and e.g., NMDA recommends that
"in-use" values (effectively including default values) are returned.
Further, there is no way for a consumer of the file to know whether default
values are included or not.

Hence, I would recommend that the instance-data-set defines an
"includes-defaults" leaf that indicates whether default values are included
in the dataset, the leaf can default to them not being included in the
dataset.

Further, I would suggest weakening "Default values SHOULD NOT be included"
to something like:
"Default values should be excluded where they do not provide additional
useful data."
BALAZS: Section 2 states that a default attribute may be specified,
following the with-defaults capability. 
However, your proposal is better. I will include it. 
Added leaf includes-defaults.

2.
In the YANG Module:
 feature inline-content-schema {
   description
 "This feature indicates that inline content-schema
  option is supported. Support for this feature might
  be documented only via out-of-band documentation.";
 }
 
What is the benefit of having 'inline-content-schema' as a feature?  It
seems to potentially add complexity without any benefit, given that the
device originating the instance data file would effectively choose whether
to use the inline-content-schema, hence I suggest that it might be simpler
just to remove the feature definition.
BALAZS: This was explicitly requested earlier by a reviewer (Andy ?).
The system can declare supported/not-supported in design documentation.
In a use-case when a client or a design department is sending data to a
server this is needed. E.g. in UC2, Preloading Default Configuration the
designer preparing instance data, can decide to use or not use the
inline-content-schema based on this.
   
3.
In the YANG Module:

"case inline", description:
The first item is either ietf-yang-library or
some other YANG module that contains a list of
YANG modules with their name, revision-date,
supported-features, and deviations.
The usage of revision '2019-01-04' of the
'ietf-yang-library' module MUST be supported.
Using other modules, module versions MAY also
be supported.

This seems to make interop for consumers of instance data files hard, since
the schema can be defined by any arbitrary YANG module without updating this
module.  I would suggest that it is safer to limit this to the two currently
published versions of YANG library.
BALAZS:  I fully agree, however this was explicitly requested by some
reviewer earlier (Juergen ?) Shall I simplify this or not?

If additional modules are supported in future, then I think that it would be
safer to create a new version of this YANG module that documents what other
module formats can be used.


4.
In the YANG Module:
list "revision"

Is revision expected to be unique, if provided? If so, should this be
explicitly stated in the YANG module description?
BALAZS: I don't think I understand your comment. There may be multiple list
entries for revision. The 'leaf date' is a key, so it is inherently unique.
The description may or may not be unique.


5.
In the YANG Module:

Is an instance-data file allowed to contain both a revision and also a
timestamp?  If so, is there any constraints on the values.  If not, then
would it make sense to put them under a choice?
BALAZS:  It is allowed to have both. There is some recommendation text about
when to use each. However I can see some corner cases, when using both in
the same file would be useful, E.g. we want a timestamp including hour,
minutes, but we also want the history of the instance data set, including
multible revision/descriptions.
I propose to add: if both are included the timestamp, SHOULD contain
the same date as the latest revision statement.


6.
References:
- RFC 6020 needs to be normative for the IANA YANG module registration.
BALAZS: OK

Minor comments:

7. 
Abstract:

   There is a need to document data defined in YANG models when a live
   server is unavailable.  Data is 

Re: [netmod] GDPR and private data

[Balázs Lengyel]

Hello Carsten,
As I see we need a way to mark some data (schema nodes) as personal data. I am 
looking for such a mechanism. Do you see the need for that too?
The goal is to allow special handling for such data.
- Leaf aaa is general data it can be log and stored forever
- Leaf bbb is marked as personal data. It should be processed differently e.g. 
  -- not logged 
  --logged separately, and these logs must not be retained indefinitely
  -- anonymized during logging. 
  -- Shown or not on the CLI
Regards Balazs

-Original Message-
From: Carsten Bormann  
Sent: 2021. május 26., szerda 12:54
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] GDPR and private data

On 2021-05-26, at 11:49, Balázs Lengyel 
 wrote:
> 
> Hello,
> Netconf/Restconf can transfer a lot of data. Some of this data can be 
> personal/private like end-user names, personal phone records, street 
> addresses. Is there a way to marks such data as private? I am thinking about 
> something like putting a YANG extension in the data models:
>  
> extension private-data {
> description
>   "Indicates that a leaf or leaf-list contains private data.
> argument privacy-type;
>   }
>  
> Is there any standard solution for this or any proposal ? In the world of 
> GDPR we should be thinking about this.

If the objective is to prevent processing these data at all, then maybe they 
should not be sent in the first place.

If the objective is to specify what processing of these data is permitted, then 
there probably needs to be more information that can be fed into a processor so 
it can derive its authorizations.
(Obviously there is more to privacy than personal user data, but you mentioned 
GDPR…)

Indeed, this is probably not the group to invent the shape of the authorization 
data...

Grüße, Carsten



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] GDPR and private data

[Balázs Lengyel]

Hello,

Netconf/Restconf can transfer a lot of data. Some of this data can be
personal/private like end-user names, personal phone records, street
addresses. Is there a way to marks such data as private? I am thinking about
something like putting a YANG extension in the data models:

 

extension private-data {

description

  "Indicates that a leaf or leaf-list contains private data.

argument privacy-type;

  }

 

Is there any standard solution for this or any proposal ? In the world of
GDPR we should be thinking about this.

 

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Network Modeling (Concluded WG) ???

[Balázs Lengyel]

Hello,

This is what I found today on the https://tools.ietf.org/wg/netmod/

 

Netmod Status Pages 

Network Modeling (Concluded WG)

 

What? Why ?

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Compatibility of config=false data

[Balázs Lengyel]

Hello Juergen,
IMHO the server should in the order of preference:
1) ALWAYS report mandatory state data - this is the correct thing; it should 
happen most of the times
2) Report real data in some of the cases and deviate the mandatory=true 
statement to mandatory=false. - This means I deviate from the real module, but 
at least I publish a contract I adhere to
3) Never report the data and deviate the schema node to not-supported . - This 
means I strongly deviate from the real module, but at least I publish a 
contract I adhere to
4) Not deviate the module as described above, but do not report data 
5) Report fake data - I agree that this is the worst

I consider 4) and 5) to violate the YANG standard.
Regards Balazs

-Original Message-
From: Juergen Schoenwaelder  
Sent: 2021. április 21., szerda 12:32
To: Balázs Lengyel 
Cc: Andy Bierman ; Sterne, Jason (Nokia - CA/Ottawa) 
; netmod@ietf.org
Subject: Re: Compatibility of config=false data

RFC 7950 section 8:

   Several YANG statements define constraints on valid data.  These
   constraints are enforced in different ways, depending on what type of
   data the statement defines.

   o  If the constraint is defined on configuration data, it MUST be
  true in a valid configuration data tree.

   o  If the constraint is defined on state data, it MUST be true in a
  valid state data tree.

The main difference between configuration data and state data is that a server 
can keep the configuration data in a valid state by rejecting any changes that 
make the configuration data invalid. If, however, a server reports an invalid 
state data tree, then obviously the server did choose to do so and the clients 
may have to deal with it (which includes the option of the client to reject all 
state data since it is invalid, but that might not always be the best or most 
desirable option).

If there is a mandatory state leaf that the server can't implement, what should 
the server do? The worst of all possible solutions is to report a fake leaf. 
This has happened quite a bit in the history of SNMP and this is really really 
bad. Instead of reporting fake values, it is far better to not report the leaf 
so that the deviation is clear. Ideally, the server formally declare the 
deviation and all is good.

When the NMDA document was put together, the intention was to say that we want 
the state data to be as close as possible to the ground truth and we rather do 
not want systems to report fake leafs.

/js

On Wed, Apr 21, 2021 at 08:45:02AM +, Balázs Lengyel wrote:
> Hello Andy,
> 
> While NMDA states “it is possible that constraints MAY be violated under some 
> circumstances” 
> 
> * this was never declared for non-NMDA systems, so IMHO a client can 
> reasonably assume that if mandatory=true for a config=false node was declared 
> the reason is that it will always be present; otherwise it should simply be 
> mandatory=false.
> * IMHO this allowance for the operational datastore is for extra-ordinary 
> situations. In the normal case as defined in the NMDA-RFC“ 
> SHOULD conform to any constraints specified”.
> 
>  
> 
> Regards Balazs
> 
>  
> 
> From: Andy Bierman 
> Sent: 2021. április 20., kedd 20:21
> To: Juergen Schoenwaelder ; 
> Balázs Lengyel ; Sterne, Jason (Nokia - 
> CA/Ottawa) ; Andy Bierman 
> ; netmod@ietf.org
> Subject: Re: Compatibility of config=false data
> 
>  
> 
>  
> 
>  
> 
> On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder 
>  <mailto:j.schoenwael...@jacobs-university.de> > wrote:
> 
> My understanding is that a  returns the leafs that exist and that 
> are not filtered.
> 
>  
> 
> Yes -- this is what clients expect.
> 
> It is not clear that real client apps rely too much on YANG validation 
> of
> 
> the config=false nodes in .
> 
>  
> 
> The validation of server provided monitoring data was not a focus of YANG.
> 
> It may not be valid to assume every sentence that applies to 
> config=true
> 
> also applies to config=false.
> 
>  
> 
> Even the NMDA RFC ignores YANG validation of config=false nodes.
> 
> There is a paragraph that says it SHOULD be done, but it really refers
> 
> to how operational values of config=true MAY not pass validation.
> 
>  
> 
>  
> 
> /js
> 
>  
> 
> Andy
> 
>  
> 
> 
> On Tue, Apr 20, 2021 at 03:35:28PM +, Balázs Lengyel wrote:
> > Hello Juergen,
> > https://tools.ietf.org/html/rfc7950#section-7.6.5 states: 
> > 
> > If "mandatory" is "true", the behavior of the constraint depends on
> >the type of the leaf's closest ancestor node in the schema tree that
> >is not a non-presence container (see Section 7.5.1):
> >o  If no such ancestor exists in the schema t

Re: [netmod] Compatibility of config=false data

[Balázs Lengyel]

Hello Andy,

While NMDA states “it is possible that constraints MAY be violated under some 
circumstances” 

*   this was never declared for non-NMDA systems, so IMHO a client can 
reasonably assume that if mandatory=true for a config=false node was declared 
the reason is that it will always be present; otherwise it should simply be 
mandatory=false.
*   IMHO this allowance for the operational datastore is for extra-ordinary 
situations. In the normal case as defined in the NMDA-RFC“ SHOULD 
conform to any constraints specified”.

 

Regards Balazs

 

From: Andy Bierman  
Sent: 2021. április 20., kedd 20:21
To: Juergen Schoenwaelder ; Balázs 
Lengyel ; Sterne, Jason (Nokia - CA/Ottawa) 
; Andy Bierman ; netmod@ietf.org
Subject: Re: Compatibility of config=false data

 

 

 

On Tue, Apr 20, 2021 at 9:26 AM Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de> > wrote:

My understanding is that a  returns the leafs that exist and that
are not filtered.

 

Yes -- this is what clients expect.

It is not clear that real client apps rely too much on YANG validation of

the config=false nodes in .

 

The validation of server provided monitoring data was not a focus of YANG.

It may not be valid to assume every sentence that applies to config=true

also applies to config=false.

 

Even the NMDA RFC ignores YANG validation of config=false nodes.

There is a paragraph that says it SHOULD be done, but it really refers

to how operational values of config=true MAY not pass validation.

 

 

/js

 

Andy

 


On Tue, Apr 20, 2021 at 03:35:28PM +, Balázs Lengyel wrote:
> Hello Juergen,
> https://tools.ietf.org/html/rfc7950#section-7.6.5 states: 
> 
> If "mandatory" is "true", the behavior of the constraint depends on
>the type of the leaf's closest ancestor node in the schema tree that
>is not a non-presence container (see Section 7.5.1):
>o  If no such ancestor exists in the schema tree, the leaf MUST
>   exist.
>o  Otherwise, if this ancestor is a case node, the leaf MUST exist if
>   any node from the case exists in the data tree.
>o  Otherwise, the leaf MUST exist if the ancestor node exists in the
>   data tree.
> 
> Let's take the simplest example a top level leaf. If it is mandatory=true ->
> the leaf MUST exist. The above statements do not differentiate between
> config=true or config=false leaves. 
> 
> If the leaf exists, for me, it is trivial that the reply to a get/get-data
> operation MUST return it.  (assuming it is not filtered out)
> Anything else would be counter-intuitive and IMHO contradict RFC 7950.
> 
> Do you agree? 
> If not, could you please describe what does a mandatory=true statement mean
> for a config=false leaf in your interpretation?
> 
> ---
> IMHO we never stated that 
> 
> 
> Regards Balazs
> 
> -Original Message-
> From: Juergen Schoenwaelder  <mailto:j.schoenwael...@jacobs-university.de> > 
> Sent: 2021. április 14., szerda 17:08
> To: Balázs Lengyel  <mailto:balazs.leng...@ericsson.com> >
> Cc: Sterne, Jason (Nokia - CA/Ottawa)  <mailto:jason.ste...@nokia.com> >; Andy Bierman
> mailto:a...@yumaworks.com> >; netmod@ietf.org 
> <mailto:netmod@ietf.org> 
> Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13
> 
> On Wed, Apr 14, 2021 at 01:55:04PM +, Balázs Lengyel wrote:
> 
> > *   On the other hand, changing a state leaf from mandatory false to
> true means always including the leaf in a  response.
> 
> Where do you get this from?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103
> <https://protect2.fireeye.com/v1/url?k=9e758f86-c1eeb764-9e75cf1d-86073b36ea
> 28-0d304a28a3dae2f9=1=81180de4-8958-40ba-aeb8-c689e3da33e8=https%3A%2F
> %2Fwww.jacobs-university.de 
> <https://protect2.fireeye.com/v1/url?k=baf9f9a4-e562c0c5-baf9b93f-86d8a30ca42b-c249ef726e615faa=1=bc74e019-40cf-4237-b824-ce71a0cdcb90=http%3A%2F%2F2fwww.jacobs-university.de%2F>
>  %2F>



-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/ 
<https://protect2.fireeye.com/v1/url?k=7cfb0d8b-236034ea-7cfb4d10-86d8a30ca42b-e823d1eec435af45=1=bc74e019-40cf-4237-b824-ce71a0cdcb90=https%3A%2F%2Fwww.jacobs-university.de%2F>
 >



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Compatibility of config=false data

[Balázs Lengyel]

Hello Juergen,
https://tools.ietf.org/html/rfc7950#section-7.6.5 states: 

If "mandatory" is "true", the behavior of the constraint depends on
   the type of the leaf's closest ancestor node in the schema tree that
   is not a non-presence container (see Section 7.5.1):
   o  If no such ancestor exists in the schema tree, the leaf MUST
  exist.
   o  Otherwise, if this ancestor is a case node, the leaf MUST exist if
  any node from the case exists in the data tree.
   o  Otherwise, the leaf MUST exist if the ancestor node exists in the
  data tree.

Let's take the simplest example a top level leaf. If it is mandatory=true ->
the leaf MUST exist. The above statements do not differentiate between
config=true or config=false leaves. 

If the leaf exists, for me, it is trivial that the reply to a get/get-data
operation MUST return it.  (assuming it is not filtered out)
Anything else would be counter-intuitive and IMHO contradict RFC 7950.

Do you agree? 
If not, could you please describe what does a mandatory=true statement mean
for a config=false leaf in your interpretation?

---
IMHO we never stated that 


Regards Balazs

-Original Message-
From: Juergen Schoenwaelder  
Sent: 2021. április 14., szerda 17:08
To: Balázs Lengyel 
Cc: Sterne, Jason (Nokia - CA/Ottawa) ; Andy Bierman
; netmod@ietf.org
Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13

On Wed, Apr 14, 2021 at 01:55:04PM +, Balázs Lengyel wrote:

> * On the other hand, changing a state leaf from mandatory false to
true means always including the leaf in a  response.

Where do you get this from?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103
<https://protect2.fireeye.com/v1/url?k=9e758f86-c1eeb764-9e75cf1d-86073b36ea
28-0d304a28a3dae2f9=1=81180de4-8958-40ba-aeb8-c689e3da33e8=https%3A%2F
%2Fwww.jacobs-university.de%2F>


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13

[Balázs Lengyel]

Hello Andy,

I remember when we wrote these rules, we were concentrating on config and did 
not spend much time considering state data.

 

There are rules that are good for config but not for state. E.g.

*   RFC7950 does not allow changing the mandatory statement from false to 
true; as this could make a valid configuration that does not include an 
optional leaf invalid.
*   On the other hand, changing a state leaf from mandatory false to true 
means always including the leaf in a  response. That should be a 
compatible change. 

Do you agree, that at least in some cases different compatibility rules for 
state and configuration data makes sense?

Regards Balazs

 

From: netmod  On Behalf Of Sterne, Jason (Nokia - 
CA/Ottawa)
Sent: 2021. április 13., kedd 20:30
To: Andy Bierman 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13

 

Hi Andy,

 

Thx for taking a look.

 

Yes - agree with the "orderly" comment. That was very brief shorthand for the 
minutes. By "remove" it could even just mean marking as "obsolete" (with 
deprecated as an optional intermediate step).

 

We aren't trying to redefine the rules for config. But it is worth considering 
whether some of those aren't really good for state.  Implementations may be 
ignoring some of those rules for state because they don't really fit.

 

Jason 

 

From: Andy Bierman mailto:a...@yumaworks.com> > 
Sent: Tuesday, April 13, 2021 2:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) mailto:jason.ste...@nokia.com> >
Cc: netmod@ietf.org  
Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13

 

 

 

On Tue, Apr 13, 2021 at 7:12 AM Sterne, Jason (Nokia - CA/Ottawa) 
mailto:jason.ste...@nokia.com> > wrote:

YANG Versioning Weekly Call Minutes - 2021-04-13

 

Primary discussion was around the BC/NBC rules for state.

 

Value space for config false:

- more informative if you actually remove the enum from the model if it isn't 
used anymore (vs leaving it in and servers just not returning it)

- a server implementation should deviate if it doesn't return something ever 
(schema should try to accurately define the API)

- standard module -> remove the item if it isn't part of the API anymore

 

 

I assume you mean to use the status-stmt to transition from current -> 
deprecated -> obsolete

in an orderly fashion. Especially since sec 11 is very clear:

 

   Obsolete definitions MUST NOT be removed from published modules,
   since their identifiers may still be referenced by other modules.

 

 

 

- NMDA operational DS has a copy of config true, so increased value space in 
config automatically casues increased value space in "state" (operational)

- a config true MTU in the operational DS and a dedicated config false 
"oper-mtu" leaf should have the same rules for increasing value space

 

Maybe a better formulation of the state rules is to take the 7950 rules and 
apply minimal text changes. Rob will take a stab at this.

 

7950:

   o  A "must" statement may be removed or its constraint relaxed.

   

Adjusted 7950 text:

   o  A "must" statement may be added, removed, or changed

  

 

7950:

   o  A "range", "length", or "pattern" statement may expand the allowed

  value space.

Adjusted 7950:

   o  A "range", "length", or "pattern" statement may expand or reduce the 
allowed

  value space.

 

 

I strongly object to this WG creating an "adjusted YANG 1.1" standard.

IMO there is no need or WG consensus to create any sort of replacement for RFC 
7950.

 

If YANG 1.1 needs non-backward-compatible changes  (which it doesn't IMO) then 
a new

YANG 2.0 RFC must be written to accomplish that.

 

It is possible to introduce support for NBC changes in a way that does not 
change YANG 1.1

at all. E.g.:

 

Rule 1 of 1:

  - If any change is made that violates a MUST or MUST NOT provision of RFC 
7950,

sec. 11, then the major revision number in the semver string MUST be 
incremented.

 

 

 

 

Jason

 

Andy

 

 

--

Weekly webex call details:

Meeting number (access code): 171 069 0374 

Meeting password: semver?

Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, August 
24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Canada) 

9:00 am  |  (UTC-04:00) Eastern Time (US & Canada)  |  1 hr 

https://ietf.webex.com/ietf/j.php?MTID=ma7627a2ae7b770537cff5f5b89293c70

Tap to join from a mobile device (attendees only)

+1-650-479-3208,,1710690374## Call-in toll number (US/Canada)

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



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Shepherd review on draft-ietf-netmod-yang-instance-file-format-10

[Balázs Lengyel]

Hello Kent,

Thanks for the thorough review and sorry for my absence and hence the earlier 
slow response.

See answer below as BALAZS4. Removed already agreed parts.

What is the next step?

Regards Balazs

 

From: Kent Watsen  
Sent: 2021. április 2., péntek 2:20
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Shepherd review on 
draft-ietf-netmod-yang-instance-file-format-10

 

Please see below for responses.  (One question pending)

 

Kent // shepherd



On Mar 23, 2021, at 6:01 PM, Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

 

Hello Kent,

I am resuming my work on draft-ietf-netmod-yang-instance-file-format. 

Regards Balazs

 

 

From: Kent Watsen mailto:kent+i...@watsen.net> > 
Sent: 2020. április 9., csütörtök 22:11
To: Balázs Lengyel mailto:balazs.leng...@ericsson.com> >
Cc: netmod@ietf.org <mailto:netmod@ietf.org> 
Subject: Re: [netmod] Shepherd review on 
draft-ietf-netmod-yang-instance-file-format-10

 

Hi Balazs,

 

BTW, I assume that you wish to publish this as-is and follow-up later with an 
update to adjust for the “semver” work - correct?

K.

 

BALAZS4:  Yes, correct. 

Semver will take time and may undergo changes, so it would be too early to 
adapt this draft/RFC to it. However, two items already deal with Semver:

1.  The instance data files themselves will not have a Semver revision as 
the concept of compatibility is not defined for instance data.
2.  The YANG module ietf-yang-instance-data already includes:

 “... If other methods

(e.g., revision-label) are defined to identify

individual module revisions those MAY be used

instead of using a revision date.”

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] FW: New Version Notification for draft-ietf-netmod-yang-instance-file-format-13.txt

[Balázs Lengyel]

Hello,
Updated according to shepherd's review.
Regards Balazs

-Original Message-
From: internet-dra...@ietf.org  
Sent: 2021. március 29., hétfő 16:27
To: Balázs Lengyel ; Benoit Claise 

Subject: New Version Notification for 
draft-ietf-netmod-yang-instance-file-format-13.txt


A new version of I-D, draft-ietf-netmod-yang-instance-file-format-13.txt
has been successfully submitted by Balazs Lengyel and posted to the IETF 
repository.

Name:   draft-ietf-netmod-yang-instance-file-format
Revision:   13
Title:  YANG Instance Data File Format
Document date:  2021-03-29
Group:  netmod
Pages:  28
URL:
https://www.ietf.org/archive/id/draft-ietf-netmod-yang-instance-file-format-13.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format
Htmlized:   
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-13
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-13

Abstract:
   There is a need to document data defined in YANG models when a live
   server is unavailable.  Data is often needed at design or
   implementation time or needed when a live running server is
   unavailable.  This document specifies a standard file format for YANG
   instance data, which follows the syntax and semantics of existing
   YANG models, and annotates it with metadata.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Liaison statement to ORAN - v2

[Balázs Lengyel]

Hello, 

Based on discussion here is version2 of the proposed liaison text:

 

Liaison text v2:

 

IETF NETMOD working group requests ORAN to avoid using deviations as part of 
its specification. When ORAN plans to reuse specifications from other standard 
bodies or industry groups it should not remove or change functionality.  If 
variations are needed compared to a base model, ORAN should ask the original 
group to include feature statements in the original YANG module.

 

As documented in https://tools.ietf.org/html/rfc7950#section-7.20.3  “... 
deviations MUST never be part of a published standard, since they are the 
mechanism for learning how implementations vary from the standards.”

As documented in  
<https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1> 
https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1 
the usage of deviations would prevent:

*   Vendors to claim conformance to both ORAN and 3GPP specifications 
(which are in some cases used as a base for the ORAN YANG models)
*   Vendors to implement their own deviations for the same YANG schema nodes
*

Note: The problems with deviations exists even if YANG modules are used without 
using YANG packages.

 

 

Regards Balazs

 

From: netmod  On Behalf Of Jan Lindblad (jlindbla)
Sent: 2020. november 19., csütörtök 11:00
To: Balázs Lengyel 
Cc: Robert Petersen ; Jacqueline Beaulac S 
; netmod@ietf.org
Subject: Re: [netmod] Liaison statement to ORAN

 

Balázs, 

 

+1

I think this is an important message to O-RAN, and I know similar ideas have 
been up for discussions in other SDOs as well. I think your proposed way of 
conveying the message is good.  

 

Best Regards,

/jan

 





On 18 Nov 2020, at 09:09, Balázs Lengyel 
mailto:balazs.lengyel=40ericsson@dmarc.ietf.org> > wrote:

 

Hello,

In connection to the draft  
<https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01> 
https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01 I propose to 
send a liaison statement from IETF Netmod to ORAN.

 

The issue: 3GPP is standardizing a good number of YANG modules as part of the 
3gpp TS 28.541 and 28.623 ( 
<https://protect2.fireeye.com/v1/url?k=de649d27-81ffa5c5-de64ddbc-86073b36ea28-bd22f142f9b85dd6=1=5a78b7c7-b77b-4866-87e7-f206e86f6f2b=https%3A%2F%2Fforge.3gpp.org%2Frep%2Fsa5%2FMnS%2Ftree%2FRel17-draft%2Fyang-models>
 https://forge.3gpp.org/rep/sa5/MnS/tree/Rel17-draft/yang-models). 

ORAN plans to re-use this models, but possibly refine them in some ways. They 
are considering using deviations to do this. 

E.g. change config=true schemas node to config=false. This creates problems as 
documented in  
<https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01%23section-5.8.1>
 https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1

 

-   Deviations by an SDO (standard defining organization) prevent 
implementations from reporting their own deviations for the same nodes.

-   Deviations by an SDO prevent implementations from conforming to the 
standards specified by both SDOs.

 

To avoid these problems I propose to send the following text to ORAN:

 

“IETF NETMOD working group requests ORAN to avoid using deviations as part of 
its specification. As documented in  
<https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01%23section-5.8.1>
 https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1 
the usage of deviations would prevent:

*   Vendors to implement their own deviations for the same YANG schema nodes
*   Vendors to claim conformance to both ORAN and 3GPP specifications which 
are in some cases used as a base for the ORAN YANG models

Note: These problems with deviations exists even if YANG modules are used 
without using YANG packages.

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist   
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email:  
<mailto:balazs.leng...@ericsson.com> balazs.leng...@ericsson.com

 

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Liaison statement to ORAN

[Balázs Lengyel]

Hello Mahesh,

I heard many discussions about this, but I can’t supply you with a specific 
example just now. I will ask if my colleagues working in ORAN can help.

Regards Balazs

 

From: Mahesh Jethanandani  
Sent: 2020. november 18., szerda 19:02
To: Balázs Lengyel 
Cc: netmod@ietf.org; Robert Petersen ; Jacqueline 
Beaulac S 
Subject: Re: [netmod] Liaison statement to ORAN

 

Hi Balazs,

 

Do you have an example of where O-RAN is trying to deviate a 3GPP model? I 
would agree that for O-RAN to deviate a model would be a problem, and that it 
should be left to vendors to decide if they want to deviate the 3GPP model.





On Nov 18, 2020, at 12:09 AM, Balázs Lengyel 
mailto:balazs.lengyel=40ericsson@dmarc.ietf.org> > wrote:

 

Hello,

In connection to the draft  
<https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01> 
https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01 I propose to 
send a liaison statement from IETF Netmod to ORAN.

 

The issue: 3GPP is standardizing a good number of YANG modules as part of the 
3gpp TS 28.541 and 28.623 ( 
<https://protect2.fireeye.com/v1/url?k=f08a6b09-af11524a-f08a2b92-861fcb972bfc-d3713e17a0e10674=1=c0b7de7e-d7ca-4671-b5cc-cecfc1b188d5=https%3A%2F%2Fforge.3gpp.org%2Frep%2Fsa5%2FMnS%2Ftree%2FRel17-draft%2Fyang-models>
 https://forge.3gpp.org/rep/sa5/MnS/tree/Rel17-draft/yang-models). 

ORAN plans to re-use this models, but possibly refine them in some ways. They 
are considering using deviations to do this. 

E.g. change config=true schemas node to config=false. This creates problems as 
documented in  
<https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01%23section-5.8.1>
 https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1

 

-   Deviations by an SDO (standard defining organization) prevent 
implementations from reporting their own deviations for the same nodes.

-   Deviations by an SDO prevent implementations from conforming to the 
standards specified by both SDOs.

 

To avoid these problems I propose to send the following text to ORAN:

 

“IETF NETMOD working group requests ORAN to avoid using deviations as part of 
its specification. As documented in  
<https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01%23section-5.8.1>
 https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1 
the usage of deviations would prevent:

*   Vendors to implement their own deviations for the same YANG schema nodes
*   Vendors to claim conformance to both ORAN and 3GPP specifications which 
are in some cases used as a base for the ORAN YANG models

Note: These problems with deviations exists even if YANG modules are used 
without using YANG packages.

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist   
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email:  
<mailto:balazs.leng...@ericsson.com> balazs.leng...@ericsson.com

 

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

 

Mahesh Jethanandani

mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> 

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Liaison statement to ORAN

[Balázs Lengyel]

Hello,

In connection to the draft
https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01 I propose to
send a liaison statement from IETF Netmod to ORAN.

 

The issue: 3GPP is standardizing a good number of YANG modules as part of
the 3gpp TS 28.541 and 28.623
(https://forge.3gpp.org/rep/sa5/MnS/tree/Rel17-draft/yang-models). 

ORAN plans to re-use this models, but possibly refine them in some ways.
They are considering using deviations to do this. 

E.g. change config=true schemas node to config=false. This creates problems
as documented in
https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1
 

 

-   Deviations by an SDO (standard defining organization) prevent
implementations from reporting their own deviations for the same nodes.

-   Deviations by an SDO prevent implementations from conforming to the
standards specified by both SDOs.

 

To avoid these problems I propose to send the following text to ORAN:

 

“IETF NETMOD working group requests ORAN to avoid using deviations as part
of its specification. As documented in
https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1
  the usage of deviations would prevent:

*   Vendors to implement their own deviations for the same YANG schema
nodes
*   Vendors to claim conformance to both ORAN and 3GPP specifications
which are in some cases used as a base for the ORAN YANG models

Note: These problems with deviations exists even if YANG modules are used
without using YANG packages.

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Module-name + revision-label identifies a YANG module version

[Balázs Lengyel]

Hello,

I added a new issue about draft-ietf-netmod-yang-module-versioning at
https://github.com/netmod-wg/yang-ver-dt/issues/58.

A specific revision-label identifies a specific version (variant) of the
module. If two files contain YANG modules with the same module name and the
same revision-label in their latest revision statement, then the two modules
MUST be the same (except for possible white space at the end of each line.)

This requirement should be stated in the draft.

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] status-description (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Balázs Lengyel]

Hello,
While status-description is not a critical part of this work, it is still 
useful, does not harm and is such a small addition, I do not understand why 
Martin objects.

So why is status-description good:
Sometimes additional information is needed about deprecation, obsolescence: 
- is the item still fully functional?
- when will its functionality be removed?
- when will the schema node itself be removed?
- is there a replacement or workaround that could/should be used instead of 
deprecated/obsolete item?
The text can be used by tools. Using a separate statement to provide this 
information is a method to separate the main description from this status 
specific description. 
In most cases both in the CLI and on NMS GUIs only the description is 
displayed. 
However there is a possibility  to display the status information too.

In a way it is similar why we have separate description, contact, reference, 
organization statements under module. 
All these are just text, they could all be pushed under a single description 
statement. Tools can't act on these automatically, still it is good to separate 
them.

Regards Balazs

-Original Message-
From: netmod  On Behalf Of Sterne, Jason (Nokia - 
CA/Ottawa)
Sent: 2020. április 29., szerda 23:38
To: Reshad Rahman (rrahman) ; Martin 
Björklund ; netmod@ietf.org
Subject: Re: [netmod] status-description (WAS Re: mbj review of 
draft-verdt-netmod-yang-module-versioning-01)

I think we could wait until YANG 2.0 to add a description to the status.

Without a status description, an intelligent "YANG diff" of the models would 
produce this:
a) new status deprecated statement
b) change to a description

With a status description we'd identify this:
a) new status deprecated statement
b) new status description

In both cases it is (a) that identifies the most clear information.

In both cases (b) provides no additional information that can be acted upon in 
an automated fashion. The tool could only flag that (b) occurred in both cases 
and a human would then have to go look at it.

If the only change between two versions of a module was a status description 
change, then again a human would have to take a look. If we add some sort of 
"nbc" tag to the leaf for tooling, then it also doesn't matter which 
description changed.

Jason


> -Original Message-
> From: netmod  On Behalf Of Reshad Rahman
> (rrahman)
> Sent: Friday, March 27, 2020 5:43 PM
> To: Martin Björklund ; netmod@ietf.org
> Subject: [netmod] rev:status-description (WAS Re: mbj review of 
> draft-verdt-
> netmod-yang-module-versioning-01)
> 
> Hi,
> 
> https://github.com/netmod-wg/yang-ver-dt/issues/51
> 
> o  3.4
> 
>  leaf imperial-temperature {
>type int64;
>units "degrees Fahrenheit";
>status deprecated {
>  rev:status-description
>"Imperial measurements are being phased out in favor
> of their metric equivalents.  Use metric-temperature
> instead.";
>}
>description
>  "Temperature in degrees Fahrenheit.";
>  }
> 
>   I don't think rev:status-description is necessary / worth it.  This
>   can easily be written with the normal description statement instead:
> 
>  leaf imperial-temperature {
>type int64;
>units "degrees Fahrenheit";
>status deprecated;
>description
>"Imperial measurements are being phased out in favor
> of their metric equivalents.  Use metric-temperature
> instead.
> 
> Temperature in degrees Fahrenheit.";
>  }
> 
> While rev:status-description isn't strictly necessary, without it we'd 
> have to modify the node's description as you pointed out. That'd make 
> tooling more
> difficult: is the description change BC or NBC? Also, a user looking 
> at a diff would need to go through the description change. Use of  
> rev:status- description makes this easier to handle.
> 
> Regards,
> Reshad.
> 
> 
> 
> On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
>  rrahman=40cisco@dmarc.ietf.org> wrote:
> 
> Hi Martin,
> 
> We've opened issues to track your review comments (see below). 
> Will kick off separate therads for each issue.
> 
> https://github.com/netmod-wg/yang-ver-
> dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
> 
> Regards,
> Reshad.
> 
> On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
>  wrote:
> 
> Hi,
> 
> Here are my review comments of
> draft-verdt-netmod-yang-module-versioning-01.
> 
> 
> 
> o  3.1.1
> 
> o  In statements that have any data definition statements as
>substatements, those data definition substatements MAY be
>

Re: [netmod] YANG action not allowed at root?

[Balázs Lengyel]

Hello Jason,

I was the original advocate of actions.

At that point I had to fight to get actions into YANG at all. So I had to 
emphasize why they are different, why they are better. Replacing rpcs would 
have been a no go from the start.

Also some people might have an aversion towards having 2 ways to do the same 
thing.

In my world we avoid top level actions/rpcs altogether, so it was not important 
for me.

But truly, these are not really strong arguments against top level actions.

Regards Balazs

 

From: netmod  On Behalf Of Sterne, Jason (Nokia - 
CA/Ottawa)
Sent: 2020. április 30., csütörtök 17:51
To: Reshad Rahman (rrahman) ; netmod@ietf.org
Subject: Re: [netmod] YANG action not allowed at root?

 

Yes - the intent was to address the limitation that an RPC can only be at root. 
Actions can be out in a tree & nicely associated with something (e.g. instead 
of having a pile of flat RPCs with long names that encode containers like 
reset-www-xxx-yyy-zzz-entity).

 

But I don't really understand why we limited actions from being at the root. It 
prevents a strategy of implementing all operations in a server (some of which 
may be desirable at root for various reasons, some of which may be desirable in 
the tree) as actions.

 

Why not allow this?

 

   module bar {

 action do-stuff {

   input {

 leaf iterations {

   type uint8;

  }

}

 } 

   } 

   } 

 

Which could be called from NETCONF like this:

 

 

   

 

   5

 

   

 

 

 

Jason

 

From: Reshad Rahman (rrahman) mailto:rrah...@cisco.com> > 
Sent: Thursday, April 30, 2020 11:31 AM
To: Sterne, Jason (Nokia - CA/Ottawa) mailto:jason.ste...@nokia.com> >; netmod@ietf.org  
Subject: Re: [netmod] YANG action not allowed at root?

 

I don’t know the history on this but the intent is to have action tied to a 
data node.

 

https://tools.ietf.org/html/rfc7950#section-7.15

   The difference between an action and an rpc is that an action is tied

   to a node in the datastore, whereas an rpc is not.  When an action is

   invoked, the node in the datastore is specified along with the name

   of the action and the input parameters.

 

Regards,

Reshad.

 

From: netmod <  netmod-boun...@ietf.org> on 
behalf of "Sterne, Jason (Nokia - CA/Ottawa)" <  
jason.ste...@nokia.com>
Date: Thursday, April 30, 2020 at 11:08 AM
To: "  netmod@ietf.org" <  
netmod@ietf.org>
Subject: [netmod] YANG action not allowed at root?

 

Hi all,

 

I was a bit surprised to find this in section 7.15 of 7950 recently:

 

   Since an action cannot be defined at the top level of a module or in

   a "case" statement, it is an error if a grouping that contains an

   action at the top of its node hierarchy is used at the top level of a

   module or in a case definition.

 

I realize that actions can be placed down in a schema tree (i.e. sit in the 
context of a container or list), but why is it phrased that they *must* be in a 
container?

 

RPCs are limited to being at the root. I would have thought actions could be 
anywhere (root or down in the tree).

 

Jason

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Presentation on YANG and Netconf usage in 3GPP

[Balázs Lengyel]

Hello Qin,

RFC6095 never gained traction, I don’t know any toolset that supports it.

Just now I don’t expect anything from IETF. Some 3GPP constructs like
invariant, system-created, initial-value were proposed to the YANG language
development earlier, but not accepted.

 

I am trying to map the object oriented models of 3GPP into the mainstream
YANG.

Regards Balazs

 

From: Qin Wu  
Sent: 2020. április 2., csütörtök 15:12
To: Balázs Lengyel ; netmod@ietf.org
Subject: Presentation on YANG and Netconf usage in 3GPP

 

Hi, Balazs:

Thanks for the update for what 3GPP is doing related to YANG and NETCONF. I
have a few comments to your slides which I haven’t got time to raise in the
virtual interim meeting:

1.  Mapping UML to YANG may is not lossless mapping, you may loss a lot
of information, for lossless mapping, Why you don’t use complex type defined
in RFC6095?

2.  What do you expect IETF to do for the gap identified in 3GPP?

 

-Qin



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Shepherd review on draft-ietf-netmod-yang-instance-file-format-10

[Balázs Lengyel]

See below as BALAZS2. Removed previously agreed issues. Uploaded as -12.

Balazs

 

P.S. Kent, if further edits are needed, shall I do them via new uploaded 
versions, or shall I just send the update for checking to you?

 

From: Kent Watsen  
Sent: 2020. április 9., csütörtök 22:11
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Shepherd review on 
draft-ietf-netmod-yang-instance-file-format-10

 

Hi Balazs,

 

On Apr 8, 2020, at 8:06 AM, Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

 

Hello Kent,
Thanks for the review. See answers below.
I tried to address all you comments, sorry if I missed something. 
I updated the draft and uploaded a -11 version. Please check/advance it.

One question I could not settle: XML2RFC does not accept
   
Only
   
Why ? Please help.

 

Because it’s a working group document now and so uses the “ietf” prefix.  Try 
this:

 

   

BALAZS2: OK, thanks


Structural Issues:

- S5 contains an mix of important and unimportant information.   I think that 
the most important thing to state that the module defines an offline format 
that MAY contain security sensitive information, and thus safe handling is 
advised.  Maybe also say something about because the YANG module only defines a 
“structure”,  the Security Considerations doesn’t follow the template specified 
in https://tools.ietf.org/html/rfc8407#section-3.7.1).  For instance: s/is 
designed as a wrapper specifying a format and a metadata header for YANG 
instance data defined by the content-schema/specifies an offline format/
BALAZS: Most of text was required to be put there by earlier reviewers (Mostly 
Juergen and Acee Lindem) and sent to the mailing list.
I added that we do not follow the security template for YANG models.

 

Please add the reference to https://tools.ietf.org/html/rfc8407#section-3.7.1 
per above.

BALAZS2: OK

 

 - S8.1: agreed that RFC8525 is Normative, but the only place it it referenced 
is in a non-normative section…please add a ref to it from a normative section.
BALAZS: It is referenced from the YANG module which is normative.

 

You just added that reference, but not correctly:

  1) the “reference” doesn’t follow the standard format

  2) the paragraph at the top of 3.2 doesn’t also list RFC 8525

BALAZS2: OK, corrected


Editorial Issues:

 - Appendix B:
- s/For instance data/Instance data/

BALAZS: Sorry, that would make the sentence incorrect.

 

Do you mean it to be “For instance, data” then?   If “instance data” is 
supposed to be read together, maybe use a hyphen or quotes?

BALAZS2: OK, added quotes

- the syntax grammar used in S3, P8 doesn’t make sense - use ABNF?

BALAZS: 

 

Please fix the grammar.

 

BALAZS2: OK, Updated grammar.





- In S3, P8: “the semicolons and the decimal point, if present, shall be 
replaced by underscores” - why are they not escaped?

BALAZS: This is a file name. Escaping in file names does not always work 
(depending on the filesystem and tools used). This is more simple and 
understandable

 

No, this is a special case CLR and we never do this.  I see this idea has been 
in the document since -03, so it must’ve bee discussed, can you point me to the 
discussion? 

 

FWIW, my OS doesn’t even require escaping colons.  BTW, they’re “colons” (not 
semicolons).

BALAZS2: Windows doesn’t allow colons in the filename. Although it’s not 
everyone’s favorite OS, it is pretty widespread. 

For Ubuntu Linux and a bash shell the colon is allowed, but tab extension does 
not work properly.

Sorry, I don’t remember any discussion on this. Timestamps were discussed, but 
I don’t find any arguments about this substitution.

Changed semicolon->colon





- It is unclear how the "inline-content-schema” feature could ever be used.  
I.e., there are no protocol-accessible nodes in the module…

BALAZS: The system can declare in supported/not-supported in design 
documentation. E.g. in UC2, Preloading Default Configuration the designer 
preparing instance data, can decide to use or not use the inline-content-schema 
based on this.

 

When I make statements like this, please see it as an opportunity to improve 
the document.  In this case, please modify the inline-content-schema’s 
“description” statement to indicate that the feature is never supported by a 
server, and that it is intended to be enabled via out-of-band documentation.  
BTW, was this discussed by the WG?

BALAZS2: It was discussed that this inline-content-schema seems complicated, so 
it should not be mandatory. After this I introduced the feature. AFAIK no 
discussion after this.

Actually it might be supported by a server: 

*   preloading configuration data: the server may or may not be able the 
inline-content-schema. The designers preparing the instance data sets to be 
loaded onto the server may use this declaration as a design guide
*   if a server also produces instance data files (e.g. UC5  Storing 
diagnostics d

Re: [netmod] Shepherd review on draft-ietf-netmod-yang-instance-file-format-10

[Balázs Lengyel]

Hello Kent,
Thanks for the review. See answers below.
I tried to address all you comments, sorry if I missed something. 
I updated the draft and uploaded a -11 version. Please check/advance it.

One question I could not settle: XML2RFC does not accept

Only

Why ? Please help.
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Kent Watsen
Sent: 2020. március 31., kedd 3:50
To: netmod@ietf.org
Subject: Re: [netmod] Shepherd review on 
draft-ietf-netmod-yang-instance-file-format-10

[UPDATE: I just realized that I prematurely stopped the review after the YANG 
module.  Picking up where I left off…]


Structural Issues:

 - S5 contains an mix of important and unimportant information.   I think that 
the most important thing to state that the module defines an offline format 
that MAY contain security sensitive information, and thus safe handling is 
advised.  Maybe also say something about because the YANG module only defines a 
“structure”,  the Security Considerations doesn’t follow the template specified 
in https://tools.ietf.org/html/rfc8407#section-3.7.1).  For instance: s/is 
designed as a wrapper specifying a format and a metadata header for YANG 
instance data defined by the content-schema/specifies an offline format/
BALAZS: Most of text was required to be put there by earlier reviewers (Mostly 
Juergen and Acee Lindem) and sent to the mailing list.
I added that we do not follow the security template for YANG models.
  - S6.1. the full registration is not inside the .  (How could happen?)
BALAZS: Corrected
  - S8.1: I-D.ietf-netmod-yang-data-ext should be listed last, as the number it 
will be the greater than any other...
BALAZS: The order of references is decided by Xml2Rfc. In the draft-..xml it is 
the last.
  - S8.1: RFC8340 is Informative
BALAZS: OK
  - S8.1: agreed that RFC8525 is Normative, but the only place it it referenced 
is in a non-normative section…please add a ref to it from a normative section.
BALAZS: It is referenced from the YANG module which is normative.
  - S8.2: same comment as before re: floating the I-D refs to the end…
BALAZS: The order of references is decided by Xml2Rfc. In the draft-..xml it is 
the last.
  - Appendix C: remove the unnecessary “C.1” section.
BALAZS: OK

Editorial Issues:

  - Appendix B:
 - s/For instance data/Instance data/
BALAZS: Sorry, that would make the sentence incorrect.
 - “...to avoid are listed.” - listed where?  Section reference?
BALAZS: In the next list in the same chapter. Added "below".
 - In P2, how is the 2nd sentence connected to the 1st?
BALAZS: Separated them into 2 paragraphs. Instance data can be produced 
automatically or by some design activity. I was told by a previous reviewer 
that I should provide these guidelines only for the latter. However the 
guidelines are valid and important as proven by experience.
 - s/may lead to problems/may lead to the following problems:/?
BALAZS: OK
  - Appendix C:
  - Don’t put “Non-Normative” into the Section title (move to 1st sentence 
of section) 
BALAZS: OK, changed (earlier it was requested to have it in the title.)
  - s/We present/This section presents/
  - s/use cases were YANG/use cases where YANG/
  - Actually, this whole sentence is meaningless
BALAZS: removed  

I gave up reviewing Section C at C.1.1, since it’s non-normative.  Honestly, 
I'd remove the entire section but, if you want to keep it, I suggest reviewing 
it for issues…


Kent // shepherd



> On Mar 30, 2020, at 3:22 PM, Kent Watsen  wrote:
> 
> 
> As part of the Shepherd writeup, I read the entire draft and found the 
> following issues, which I’d like to see resolved before progressing the 
> document.  Most of these issues should have been caught be the WG and/or 
> Editors...
> 
> 
> Logical Issues:
> 
>  - S3, P8 defines MUSTs inside a SHOULD, a logical contradiction.
BALAZS: Changed to SHOULD
>  - In S3, P8 (the P beginning w/ "The name of”), text fails to indicate what 
> SHOULD be done if both “revision” and “timestamp” are present?
BALAZS: IMHO the preference depends on the use case, so a general guidance 
cannot be given.
>  - the syntax grammar used in S3, P8 doesn’t make sense - use ABNF?
BALAZS: 
>  - In S3, P8: “the semicolons and the decimal point, if present, shall be 
> replaced by underscores” - why are they not escaped?
BALAZS: This is a file name. Escaping in file names does not always work 
(depending on the filesystem and tools used). This is more simple and 
understandable
>  - Example 1 seems semantically invalid?  e.g., "ietf-netconf-monitoring” is 
> in "content-data" though not in "modules-state”.  Also, "module-set-id” is 
> missing 
BALAZS: OK, added. 
The original example is valid, just illogical. It follows the YANG modules 
defined in the content schema; it is allowed to have partial data sets, so some 
modules may be omitted from modules-state. However you are right this is 
illogical.
module-set-id does not 

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

[Balázs Lengyel]

I would like to allow require-instance in derived types (done in errata or
any other way) because we allow other constraints to be changed. Regularity
of YANG is very important for me. Learning YANG is difficult enough without
adding new exception cases.

Also as I consider this undefined, it is better to document whether this is
allowed or not. This is a binary decision, either/or. If setting it as a
YANG language rule is to strict, we still need a guideline at least for RFC
authors, shall we consider it a problem or not? 
Balazs

-Original Message-
From: netmod  On Behalf Of Martin Björklund
Sent: 2020. április 6., hétfő 13:38
To: j.schoenwael...@jacobs-university.de
Cc: netmod@ietf.org; rwilton=40cisco@dmarc.ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Juergen Schoenwaelder  wrote:
> On Mon, Apr 06, 2020 at 08:51:46AM +0200, Radek Krejci wrote:
> > Hi,
> > I just want to emphasis, what are the consequences of the option 1. 
> > This way, the tools are allowed to not accept require-instance in 
> > derived types, so actually schema authors SHOULD NOT use 
> > require-instance this way. Since there is at least 1 YANG model in 
> > RFC (8639 and I would expect more), which has require-instance in 
> > the derive type, errata will be needed in this case(s).
> >
> 
> RFC 7950 says in 9.9.3:
> 
>   If this statement is not present, it defaults to "true".
> 
> This means that require-instance is 'on by default'. Hence, it is 
> necessary to use what RFC 7950 calls a 'restriction' (9.9.1) to 
> effectively _remove_ what seems like a restriction (or constraint).
> (This text apparently has already been in RFC 6020.)

I think the correct fix is to change the text so that "require-instance" is
not classified as a restriction and keep the default.  Also, I think that it
would be easiest (for backwards compatibility w/ existing models) to allow
"require-inetance" to be changed in derived types.

However, this cannot imo be done in an errata.


/martin

> 
> The definition I found in RFC 8639 is this:
> 
> leaf stream {
>   type stream-ref {
> require-instance false;
>   }
>   mandatory true;
>   description
> "Indicates the event stream to be considered for
>  this subscription.";
> }
> 
> This could be changed to:
> 
> leaf stream {
>   type leafref {
>   path "/sn:streams/sn:stream/sn:name";
> require-instance false;
>   }
>   mandatory true;
>   description
> "Indicates the event stream to be considered for
>  this subscription.";
> }
> 
> What bothers me here is that I find the design of the default 
> behaviour backwards. If the default would have been
> 
>   If this statement is not present, it defaults to "false".
> 
> then require-instance could be used to add a constraint in derived 
> types but not to remove it (like the other type restrictions).
> 
> If people were to agree that the default here is wrong, can the 
> problem be fixed?  Likely not since changing the default (even in say 
> YANG 2.0) could have drastic consequences and would essentially 
> require to be always explicit about the require-instance property to 
> be on the safe side.
> 
> /js
> 
> > Regards,
> > Radek
> > 
> > 
> > Dne 03. 04. 20 v 18:55 Juergen Schoenwaelder napsal(a):
> > > I propose option 1) and add an issue on yang-next (if not already 
> > > there yet).
> > >
> > > /js
> > >
> > > On Fri, Apr 03, 2020 at 04:24:35PM +, Rob Wilton (rwilton) wrote:
> > >> For the errata, it looks like there are two choices:
> > >>
> > >> 1) We reject this errata, on the grounds that it is unclear on what
the behaviour was expected to be.  It is left unspecified as to whether
require-instance is allowed in a typedef.  We add an issue on the YANG.Next
issue tracker to sort this out in a future revision of YANG.
> > >>
> > >> 2) We agree on what the expected behaviour should be, in which case
it may be possible that this can be "Hold for document update", although it
still seems questionable whether this really fits as an errata.
> > >>
> > >> Regards,
> > >> Rob
> > >>  
> > >>
> > >>> -Original Message-
> > >>> From: netmod  On Behalf Of Ladislav 
> > >>> Lhotka
> > >>> Sent: 03 April 2020 15:52
> > >>> To: netmod@ietf.org
> > >>> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > >>>
> > >>> On Fri, 2020-04-03 at 14:01 +, Sterne, Jason (Nokia - 
> > >>> CA/Ottawa)
> > >>> wrote:
> >  Hi Martin,
> > 
> >  I believe you that the technical "value space" doesn't change, 
> >  but that leaf would suddenly accept more values than it did before
right?
> >  I'm wondering if we want to follow the "spirit" here, or stick 
> >  with the
> > >>> "value space" argument.
> > >>>
> > >>> I agree with Martin here. Moreover, if such a derived type is 
> > >>> added, it doesn't change 

[netmod] JSON encoding of events in draft-ietf-netconf-https-notif

[Balázs Lengyel]

Hello Mahesh, Kent,

I was wondering how the JSON encoding of event would look like in your
draft. (I intend to propose something similar to 3GPP so I am most
interested.)

The part below push-update or push-change-update is well defined in YANG
however the part outside is not. In Restconf
(https://trac.tools.ietf.org/html/rfc8040#section-6.4) I see the following
example:

 

{

"ietf-restconf:notification" : {

  "eventTime" : "2013-12-21T00:01:00Z",

  "example-mod:event" : {

"event-class" : "fault",

"reporting-entity" : { "card" : "Ethernet0" },

"severity" : "major"

  } } }

 

However how would the first 2 lines look here? IMHO keeping restconf as a
module name seems wrong. 

So maybe we should define it here in this draft :

{

 "json-yang-notification:notification" : {

  "eventTime" : "2013-12-21T00:01:00Z",

  "push-change-update" : {

...

  } } }

 

How to define this wrapper (the first 2 lines, I am unsure. As far as I know
it is not possible to describe this in YANG.  Maybe just some text like:

The YANG encoding of the notification SHALL be wrapped in a JSON object as
illustrated below

 

"json-yang-notification:notification" : {

  "eventTime" : "2013-12-21T00:01:00Z",

 

 

Also I would definitely need an example of a notification sent.

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

[Balázs Lengyel]

As I understand that works if you use Xml2Rfc v3 only. 
Balazs

-Original Message-
From: Carsten Bormann  
Sent: 2020. március 31., kedd 9:36
To: Kent Watsen 
Cc: Erik Auerswald ; Balázs Lengyel 
; netmod@ietf.org
Subject: Re: [netmod] rfcstrip does not work on 
https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

Oh, and you can find examples for markers=“true” in the published RFCs

rfc8650.xml
rfc8652.xml
rfc8675.xml
rfc8676.xml
rfc8681.xml
rfc8682.xml
rfc8695.xml
rfc8696.xml
rfc8748.xml

So this is no longer just a proposal, as the below draft seems to suggest.

Grüße, Carsten

> On 2020-03-31, at 09:22, Carsten Bormann  wrote:
> 
> On 2020-03-31, at 01:47, Kent Watsen  wrote:
>> 
>> I thought someone said that `xml2rfc` was going to support a “markers” 
>> attribute for the  element, but I don’t see that here yet: 
>> https://protect2.fireeye.com/v1/url?k=2558e5eb-798ceda8-2558a570-86a1150bc3ba-91f9e8a7be6cf53c=1=7c165797-25c3-4d3e-8bbc-f14b6f8c7cf7=https%3A%2F%2Fgithub.com%2Frfc-format%2Fdraft-iab-xml2rfc-v3-bis%2Fblob%2Fmaster%2Fdraft-iab-rfc7991bis.xml%23L8514.
> 
> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-10#section-3.1.22
> 
> Grüße, Carsten
> 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Where can I use ? - rfcstrip

[Balázs Lengyel]

Hello Kent, 

Sorry for not providing a clear pointer to my work. As you have already found 
it, I just include it here for reference to others: 
https://github.com/BalazsLengyel/rfcstrip 

I assume ggrep is the gnu grep ? Maybe we should make that a variable for grep 
like we have for AWK=awk

I do not see the additional ^@ at EOF.  I tested it on cygwin, which is mostly 
GNU compatible.

This is how my file ends

 

3c 2f 69 6e 73 74 61 6e 63 65 2d 64 61 74 61 2d 73 65 74 3e 00  


Regards Balazs

 

From: Kent Watsen  
Sent: 2020. március 29., vasárnap 0:18
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Where can I use   ?

 

Firstly, thank you for trying to improve our tooling!

 

It took me some time to find, for others: 
https://github.com/BalazsLengyel/rfcstrip

 

Running `rfcstrip -a` throws errors on MacOS.  My workaround fix was to ` brew 
install grep` and 's/grep/ggrep/' on line 483.

 

All The extracted files (including the two that are NOT folded) contain a ‘^@‘ 
character at the EOF.   This must be something introduced by `rfcstrip` because 
`rfcfold` does a simple file-level copy when unfolding isn't needed.

 

Kent // contributor

 





On Mar 26, 2020, at 5:45 PM, Balázs Lengyel 
mailto:balazs.lengyel=40ericsson@dmarc.ietf.org> > wrote:

 

Hello,
I created an update to rfcstrip in Github.

Revision 1.1balazs - 2020-03-26
added -a option. If it is specified, the file must be an XML2RFC
XML file.
All artworks will be extracted from it if they carry a name attribute.
Artwork unfolding will also be executed.
If the artwork contains the ,  markers
they are removed.

Regards Balazs

-Original Message-
From: Balázs Lengyel mailto:balazs.lengyel=40ericsson@dmarc.ietf.org> > 
Sent: 2020. március 26., csütörtök 11:55
To: Kent Watsen mailto:k...@watsen.net> >; Balázs Lengyel 
mailto:balazs.leng...@ericsson.com> >
Cc: netmod@ietf.org <mailto:netmod@ietf.org> 
Subject: RE: [netmod] Where can I use   ?

Hello Kent,
OK, as you are strongly opposed to it, I will remove   
in the next version.
That said, I do not really agree with you. If interested see, below.
Regards Balazs

-Original Message-
From: netmod mailto:netmod-boun...@ietf.org> > On 
Behalf Of Kent Watsen
Sent: 2020. március 25., szerda 18:25
To: Balázs Lengyel mailto:balazs.lengyel=40ericsson@dmarc.ietf.org> >
Cc: netmod@ietf.org <mailto:netmod@ietf.org> 
Subject: Re: [netmod] Where can I use   ?

Balazs,

While possible to use the markers for instance examples...

 - they’ve never been used before, AFIAK  (historical context)
BALAZS: S0 I am a revolutionary :-)  
As I understand validation of examples have always been an issue, so making 
that more simple by automating extraction would be a step in the good direction.
 - they're unneeded, as examples don’t contain copyright (per Lada’s comment)
BALAZS: I agree that copyright is a non-issue for these examples. However  is needed for another reason: easy extraction, which would make 
checking the data simpler.
 - they're disallowed by RFC 8407 for example modules (per Benoit comment)
BALAZS: strictly speaking that is about YANG examples not instance data 
examples. I also don't know/understand the reasoning behind it. A separate 
example tag would be nice, but we don't have one.
 - as a contributor, I don’t wish to birth a new convention of using the 
markers for examples.  

In order to support programmatic extraction of examples from drafts, please 
just set the “name” attribute on the  or  element in the 
XML draft. 
BALAZS: As far as I understand sourcecode is only available in XML2RFC v3.  
Name is not handled by rfcstrip or xym. (I don't have time to update the tools 
right now.) It would be nice to have an update to rfcstrip that checks every 
 and if it has a name attribute, it extracts the content into a file 
called "name".


2.48.2.  "name" Attribute

  A filename suitable for the contents (such as for extraction to a
  local file).  This attribute can be helpful for other kinds of tools
  (such as automated syntax checkers, which work by extracting the
  source code).  Note that the "name" attribute does not need to be
  unique for  elements in a document.  If multiple
   elements have the same "name" attribute, a formatter
  might assume that the elements are all fragments of a single file,
  and such a formatter can collect those fragments for later
  processing.


Kent







On Mar 24, 2020, at 11:33 AM, Balázs Lengyel 
mailto:balazs.lengyel=40ericsson@dmarc.ietf.org> > wrote:

Hello,
A reply from the rfc-editor on . It seems it is OK.
Regards Balazs

-Original Message-----
From: Alice Russo mailto:aru...@amsl.com> > 
Sent: 2020. március 24., kedd 16:00
To: Balázs Lengyel mailto:balazs.leng...@ericsson.com> >
Cc: RFC Editor mailto:rfc-edi...@rfc-editor.org> >
Subject: Re: Where can I use   ?

Greetings

[netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

[Balázs Lengyel]

Hello,

https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12 contains a
section with  .

However rfcstrip cannot extract this part. Is that a problem?

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

[Balázs Lengyel]

+1
Balazs

-Original Message-
From: netmod  On Behalf Of RFC Errata System
Sent: 2020. március 27., péntek 11:18
To: m...@tail-f.com; ibagd...@gmail.com; war...@kumari.net; joe...@bogus.com;
kent+i...@watsen.net; lber...@labn.net
Cc: netmod@ietf.org; rfc-edi...@rfc-editor.org
Subject: [netmod] [Technical Errata Reported] RFC7950 (6031)

The following errata report has been submitted for RFC7950, "The YANG 1.1
Data Modeling Language".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6031

--
Type: Technical
Reported by: Radek Krejci 

Section: 9.9.3

Original Text
-
The "require-instance" statement, which is a substatement to the "type"
statement, MAY be present if the type is "instance-identifier"
or "leafref".  It takes as an argument the string "true" or "false".
If this statement is not present, it defaults to "true".

Corrected Text
--
The "require-instance" statement, which is a substatement to the "type"
statement, MAY be present if the type is "instance-identifier", "leafref" or
a type derived from them. It takes as an argument the string "true" or
"false". If this statement is not present, it defaults to "true".

Notes
-
As discussed in
https://mailarchive.ietf.org/arch/browse/netconf/?gbt=1=p_zRKwQ6TBxTuC
DPc5wJbdZgWTc, authors expect that the require-instance statement is
available not only for leafref and instance-identifier types, but also for
all the types derived from them using typedef statement. Since no one argued
against this understanding, this errata changes the text to the same form as
in other restrictions applicable to derived types.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please use
"Reply All" to discuss whether it should be verified or rejected. When a
decision is reached, the verifying party can log in to change the status and
edit the report, if necessary. 

--
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--
Title   : The YANG 1.1 Data Modeling Language
Publication Date: August 2016
Author(s)   : M. Bjorklund, Ed.
Category: PROPOSED STANDARD
Source  : Network Modeling
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Where can I use ?

[Balázs Lengyel]

Hello,
I created an update to rfcstrip in Github.

Revision 1.1balazs - 2020-03-26
added -a option. If it is specified, the file must be an XML2RFC
XML file.
All artworks will be extracted from it if they carry a name attribute.
Artwork unfolding will also be executed.
If the artwork contains the ,  markers
they are removed.

Regards Balazs

-Original Message-
From: Balázs Lengyel  
Sent: 2020. március 26., csütörtök 11:55
To: Kent Watsen ; Balázs Lengyel 
Cc: netmod@ietf.org
Subject: RE: [netmod] Where can I use   ?

Hello Kent,
OK, as you are strongly opposed to it, I will remove   
in the next version.
That said, I do not really agree with you. If interested see, below.
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Kent Watsen
Sent: 2020. március 25., szerda 18:25
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Where can I use   ?

Balazs,

While possible to use the markers for instance examples...

  - they’ve never been used before, AFIAK  (historical context)
BALAZS: S0 I am a revolutionary :-)  
As I understand validation of examples have always been an issue, so making 
that more simple by automating extraction would be a step in the good direction.
  - they're unneeded, as examples don’t contain copyright (per Lada’s comment)
BALAZS: I agree that copyright is a non-issue for these examples. However  is needed for another reason: easy extraction, which would make 
checking the data simpler.
  - they're disallowed by RFC 8407 for example modules (per Benoit comment)
BALAZS: strictly speaking that is about YANG examples not instance data 
examples. I also don't know/understand the reasoning behind it. A separate 
example tag would be nice, but we don't have one.
  - as a contributor, I don’t wish to birth a new convention of using the 
markers for examples.  

In order to support programmatic extraction of examples from drafts, please 
just set the “name” attribute on the  or  element in the 
XML draft. 
BALAZS: As far as I understand sourcecode is only available in XML2RFC v3.  
Name is not handled by rfcstrip or xym. (I don't have time to update the tools 
right now.) It would be nice to have an update to rfcstrip that checks every 
 and if it has a name attribute, it extracts the content into a file 
called "name".


2.48.2.  "name" Attribute

   A filename suitable for the contents (such as for extraction to a
   local file).  This attribute can be helpful for other kinds of tools
   (such as automated syntax checkers, which work by extracting the
   source code).  Note that the "name" attribute does not need to be
   unique for  elements in a document.  If multiple
elements have the same "name" attribute, a formatter
   might assume that the elements are all fragments of a single file,
   and such a formatter can collect those fragments for later
   processing.


Kent




> On Mar 24, 2020, at 11:33 AM, Balázs Lengyel 
>  wrote:
> 
> Hello,
> A reply from the rfc-editor on . It seems it is OK.
> Regards Balazs
> 
> -Original Message-
> From: Alice Russo  
> Sent: 2020. március 24., kedd 16:00
> To: Balázs Lengyel 
> Cc: RFC Editor 
> Subject: Re: Where can I use   ?
> 
> Greetings,
> 
> Please see below.
> 
>> On Mar 21, 2020, at 8:30 AM, Balázs Lengyel  
>> wrote:
>> 
>> Hello,
>> Sorry if I am sending this question to the wrong person. 
>> We have a discussion in the NETMOD workgroup about when is it 
>> appropriate/allowed to use the   markings in drafts 
>> and RFCs.
>> We regularly use it to bracket the YANG modules defined. 
>> e.g. file "ietf-yang-instance-d...@2020-03-19.yang" 
>> 
> 
> Just FYI, if you are using the new XML vocabulary [1], the markers can be 
> created automatically by using markers="true"
> -- for example --
>  markers="true">
> 
>> However is it allowed to use it to bracket XML or json examples in 
>> drafts/rfcs? 
>> e.g. file read-only-acm-ru...@2020-03-19.xml
> 
> Yes, it is allowed. The markers  and  are mentioned 
> in the Trust Legal Provisions [2].
> 
> [1] 
> https://protect2.fireeye.com/v1/url?k=50261255-0cacc750-502652ce-861010bc36ff-8b3716f9fa495535=1=11f6fa43-0168-4d1f-8f5d-bffd46fff0d3=https%3A%2F%2Fwww.rfc-editor.org%2Fmaterials%2FFAQ-xml2rfcv3.html
> [2] https://trustee.ietf.org/license-info/IETF-TLP-5.htm (item 4d)
> 
> Thank you.
> RFC Editor/ar
> 
>> 
>> It is very handy that the rfcstrip tool can extract the CODE sections from a 
>> draft which facilitates checking these by external tools like yanglint. The 
>> checking is needed both for the YANG modules and the examples.
>> If you as an rfc-editor could give guidance on the issue it would be 
>> appreciated. I attached a planned draft.
>

Re: [netmod] Where can I use ?

[Balázs Lengyel]

Hello Kent,
OK, as you are strongly opposed to it, I will remove   
in the next version.
That said, I do not really agree with you. If interested see, below.
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Kent Watsen
Sent: 2020. március 25., szerda 18:25
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Where can I use   ?

Balazs,

While possible to use the markers for instance examples...

  - they’ve never been used before, AFIAK  (historical context)
BALAZS: S0 I am a revolutionary :-)  
As I understand validation of examples have always been an issue, so making 
that more simple by automating extraction would be a step in the good direction.
  - they're unneeded, as examples don’t contain copyright (per Lada’s comment)
BALAZS: I agree that copyright is a non-issue for these examples. However  is needed for another reason: easy extraction, which would make 
checking the data simpler.
  - they're disallowed by RFC 8407 for example modules (per Benoit comment)
BALAZS: strictly speaking that is about YANG examples not instance data 
examples. I also don't know/understand the reasoning behind it. A separate 
example tag would be nice, but we don't have one.
  - as a contributor, I don’t wish to birth a new convention of using the 
markers for examples.  

In order to support programmatic extraction of examples from drafts, please 
just set the “name” attribute on the  or  element in the 
XML draft. 
BALAZS: As far as I understand sourcecode is only available in XML2RFC v3.  
Name is not handled by rfcstrip or xym. (I don't have time to update the tools 
right now.) It would be nice to have an update to rfcstrip that checks every 
 and if it has a name attribute, it extracts the content into a file 
called "name".


2.48.2.  "name" Attribute

   A filename suitable for the contents (such as for extraction to a
   local file).  This attribute can be helpful for other kinds of tools
   (such as automated syntax checkers, which work by extracting the
   source code).  Note that the "name" attribute does not need to be
   unique for  elements in a document.  If multiple
elements have the same "name" attribute, a formatter
   might assume that the elements are all fragments of a single file,
   and such a formatter can collect those fragments for later
   processing.


Kent




> On Mar 24, 2020, at 11:33 AM, Balázs Lengyel 
>  wrote:
> 
> Hello,
> A reply from the rfc-editor on . It seems it is OK.
> Regards Balazs
> 
> -Original Message-
> From: Alice Russo  
> Sent: 2020. március 24., kedd 16:00
> To: Balázs Lengyel 
> Cc: RFC Editor 
> Subject: Re: Where can I use   ?
> 
> Greetings,
> 
> Please see below.
> 
>> On Mar 21, 2020, at 8:30 AM, Balázs Lengyel  
>> wrote:
>> 
>> Hello,
>> Sorry if I am sending this question to the wrong person. 
>> We have a discussion in the NETMOD workgroup about when is it 
>> appropriate/allowed to use the   markings in drafts 
>> and RFCs.
>> We regularly use it to bracket the YANG modules defined. 
>> e.g. file "ietf-yang-instance-d...@2020-03-19.yang" 
>> 
> 
> Just FYI, if you are using the new XML vocabulary [1], the markers can be 
> created automatically by using markers="true"
> -- for example --
>  markers="true">
> 
>> However is it allowed to use it to bracket XML or json examples in 
>> drafts/rfcs? 
>> e.g. file read-only-acm-ru...@2020-03-19.xml
> 
> Yes, it is allowed. The markers  and  are mentioned 
> in the Trust Legal Provisions [2].
> 
> [1] 
> https://protect2.fireeye.com/v1/url?k=50261255-0cacc750-502652ce-861010bc36ff-8b3716f9fa495535=1=11f6fa43-0168-4d1f-8f5d-bffd46fff0d3=https%3A%2F%2Fwww.rfc-editor.org%2Fmaterials%2FFAQ-xml2rfcv3.html
> [2] https://trustee.ietf.org/license-info/IETF-TLP-5.htm (item 4d)
> 
> Thank you.
> RFC Editor/ar
> 
>> 
>> It is very handy that the rfcstrip tool can extract the CODE sections from a 
>> draft which facilitates checking these by external tools like yanglint. The 
>> checking is needed both for the YANG modules and the examples.
>> If you as an rfc-editor could give guidance on the issue it would be 
>> appreciated. I attached a planned draft.
>> Best regards Balazs Lengyel 
>> 
>> -- 
>> Balazs LengyelSenior Specialist   
>> Ericsson Hungary Ltd. 
>> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
>> 
>> 
> ___
> 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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] FW: Where can I use ?

[Balázs Lengyel]

Hello,
A reply from the rfc-editor on . It seems it is OK.
Regards Balazs

-Original Message-
From: Alice Russo  
Sent: 2020. március 24., kedd 16:00
To: Balázs Lengyel 
Cc: RFC Editor 
Subject: Re: Where can I use   ?

Greetings,

Please see below.

> On Mar 21, 2020, at 8:30 AM, Balázs Lengyel  
> wrote:
> 
> Hello,
> Sorry if I am sending this question to the wrong person. 
> We have a discussion in the NETMOD workgroup about when is it 
> appropriate/allowed to use the   markings in drafts 
> and RFCs.
> We regularly use it to bracket the YANG modules defined. 
> e.g. file "ietf-yang-instance-d...@2020-03-19.yang" 
> 

Just FYI, if you are using the new XML vocabulary [1], the markers can be 
created automatically by using markers="true"
-- for example --


> However is it allowed to use it to bracket XML or json examples in 
> drafts/rfcs? 
> e.g. file read-only-acm-ru...@2020-03-19.xml

Yes, it is allowed. The markers  and  are mentioned in 
the Trust Legal Provisions [2].

[1] https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html
[2] https://trustee.ietf.org/license-info/IETF-TLP-5.htm (item 4d)

Thank you.
RFC Editor/ar

> 
> It is very handy that the rfcstrip tool can extract the CODE sections from a 
> draft which facilitates checking these by external tools like yanglint. The 
> checking is needed both for the YANG modules and the examples.
> If you as an rfc-editor could give guidance on the issue it would be 
> appreciated. I attached a planned draft.
> Best regards Balazs Lengyel 
> 
> -- 
> Balazs LengyelSenior Specialist   
> Ericsson Hungary Ltd. 
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Simple date in 6991bis-02

[Balázs Lengyel]

Thank you. I am happy with the answers. Balazs

-Original Message-
From: Juergen Schoenwaelder  
Sent: 2020. március 22., vasárnap 22:12
To: Balázs Lengyel 
Cc: 'netmod@ietf.org' 
Subject: Re: [netmod] Simple date in 6991bis-02

On Thu, Mar 19, 2020 at 11:30:17AM +, Balázs Lengyel wrote:
> Hello,
> 
> This might have been discussed earlier, but I still find it strange 
> that the
> 
> 
>typedef date {
> 
> has the timezone as a mandatory part. While I understand the issue 
> that when a day starts/ends is uncertain without the timezone, in real 
> life people practically never add the timezone to a date, and it does 
> not cause major problems. So IMHO following life we should have a 
> simple-date datatype that does not include any timezone. Actually we 
> do have that datatype just we called it revision-identifier. Really
strange.
>

I checked RFC 3339 again and it defines full-date without a timezone.
On the other hand, XML schema's definition of date seems to have an optional
timezone offset. I think following XML schema by making the timezone offset
optional is the right approach.

It might also be usefult to define time as a typedef. RFC 3339 defines
full-time with a mandatory timezone while XML schema defines time with
optional timezone. Again, I would follow XML schema here, making the
timezone offset optional for the time type as well.

> I would also consider to tighten up the pattern for 
> revision-identifier/date/date-and-time.
> 
> pattern '\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1])';
> 
> This would prohibit  2020-16-67 : months > 12 or days > 31

If we tighten the pattern, we should do this for date, date-and-time, and
revision. And then we should also tighten the revision offset, which
currently is \d{2}:\d{2}. And here things get interesting again.
RFC 3339 restricts the offset to 00-23 (hour) and 00-59 (minute). XML schema
says the hour is in 00-14 and the minute in 00-59. The spec says:

  Based on timezones currently in use, (c) could vary from
  2000-01-20T12:00:00+12:00 to 2000-01-20T12:00:00-13:00. It is,
  however, possible for this range to expand or contract in the
  future, based on local laws. Because of this, the following
  definition uses a somewhat broader range of indeterminate values:
  +14:00..-14:00.

Perhaps we should follow that approach. This would mean we have:

  typedef date {
type string {
  pattern '\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1])';
+ '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
}
  }

Looking at the description and RFC 3339 again, I noticed a real problem or
bug in our definition: RFC 6991 says:

  [...] The canonical format for
  date values with an unknown time zone (usually referring
  to the notion of local time) uses the time-offset -00:00.

This is not consistent with what RFC 3339 says in section 4.3:

   If the time in UTC is known, but the offset to local time is unknown,
   this can be represented with an offset of "-00:00".

RFC 3339 seems to be silent about the situation where neither the offset to
UTC is unknown and I strongly dislike that the two specs differ in the
definition of the -00:00 semantics. I would call this a bug and fix it but
then others may claim this is an non-backwards compatible change...

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod