Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

[mohamed.boucadair]

Hi all, 

FWIW, a new version that reflects the comments heard so far is available 
online: 

URL:
https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-boucadair-netmod-iana-registries/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-boucadair-netmod-iana-registries
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-boucadair-netmod-iana-registries-01

Cheers,
Med

> -Message d'origine-
> De : Jürgen Schönwälder 
> Envoyé : jeudi 24 mars 2022 12:52
> À : Qin Wu 
> Cc : BOUCADAIR Mohamed INNOV/NET ;
> netmod@ietf.org
> Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-
> netmod-iana-registries-00.txt
> 
> On Thu, Mar 24, 2022 at 11:23:39AM +, Qin Wu wrote:
> > >-邮件原件-
> > >发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen
> Sch?nw?lder
> > >发送时间: 2022年3月24日 18:56
> > >收件人: mohamed.boucad...@orange.com
> > >抄送: netmod@ietf.org
> > >主题: Re: [netmod] TR: New Version Notification for
> > >draft-boucadair-netmod-iana-registries-00.txt
> >
> > >On Thu, Mar 24, 2022 at 10:44:42AM +,
> mohamed.boucad...@orange.com wrote:
> > >> > It seems that later on you are actually changing what RFC 8407
> > >> > says although I am not sure I understand the reasoning. RFC 8407
> > >> > recommends to use enums if there is a single naming authority
> > >> > allocating values and thus ensuring uniqness of values. I am not
> > >> > sure in which sense the DOTS decision to use enums is not inline
> > >> > with what RFC 8407 says. DOTS may have decided to go with enums
> > >> > for space reasons and then this decision implies that values have
> > >> > to be centrally allocated. Note that there are IANA registries
> > >> > that allow distributed allocation of values and for thoses cases
> > >> > the RFC 8407 recommendation to use identities still applies I
> think.
> > >>
> > >> [Med] I was referring to this part:
> > >>
> > >>If extensibility of enumerated values is required, then the
> > >>"identityref" data type SHOULD be used instead of an enumeration
> or
> > >>other built-in type.
> > >>
> >
> > >But why do you think this statement of RFC 8407 needs any changes or
> different interpretations?
> >
> > [Qin Wu] If my understanding is correct, Authors of document
> > containing YANG data model face dilemma choices now, i.e.,whether
> > 1.change enum into identities which avoid updating the module defining
> the enum in the future 2. Or stick to use enum and separate all enum
> types into IANA-Maintained YANG Modules, which also avoid updating the
> module, in addition, another benefit is to make sure the same registry
> maintenance for the module that get updated.
> > For the second choice, here is one related discussion raised by Lada
> > https://mailarchive.ietf.org/arch/msg/netmod/AILS-FptdNxMWFgSHiSjbwGc6
> > tM/
> > both seems to work.
> >
> 
> I am writing about IANA maintained modules, not about why one should use
> IANA maintained modules.
> 
> /js
> 
> --
> Jürgen Schönwälder  Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[Kent Watsen]

> 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. 
> 
> 
> OK with me.
> A timestamp could be added in the future if it is really important enough.


LastModified is drop-dead simple to do and achieves equivalency, no more 
justification is needed.

The same rules apply:

- ETag is a MUST, LastModified is a MAY
- root-node is a MUST, inner-nodes is a MAY

Kent 

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

[Kent Watsen]

Hi Jan,

> On Mar 24, 2022, at 4:37 PM, Jan Lindblad  wrote:
> 
> f this isn't obvious, here's an example:
> 1. Client A sends an edit to the server If-Unmodified-Since t0. Successful. 
> Receives a Last-Modified timestamp t1.
> 2. Client B sends a an edit to the server. Last-Modified timestamp on server 
> is now t2.
> 3. Client A sends an edit to the server without If-Unmodified-Since. It just 
> sets one tiny little leaf off in one corner. Successful. Received a 
> Last-Modified timestamp t3.
> 4. Client A sends an edit to the server If-Unmodified-Since t3. Successful, 
> but clobbers Client B's edit, leading to a misconfiguration, which opens a 
> security hole.
> 
> This is because the If-Unmodified-Since uses less than or equal in its test. 
> The ETag mechanism is not susceptible to this issue, as it uses an equality 
> test.

I don't think this example is valid.   Skipping past the obvious programming 
error, the equivalency you're trying to make applies to Etags too.

1. Client A sends an edit to the server If-Match e0. Successful. Receives a 
ETag e1.
2. Client B sends a an edit to the server. ETag on server is now e2.
3. Client A sends an edit to the server without If-Match. It just sets one tiny 
little leaf off in one corner. Successful. Received a ETag e3.
4. Client A sends an edit to the server If-Match e3. Successful, but clobbers 
Client B's edit, leading to a misconfiguration, which opens a security hole.


Kent // contributor




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

[Andy Bierman]

On Thu, Mar 24, 2022 at 1:52 PM Balázs Lengyel 
wrote:

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

OK with me.
A timestamp could be added in the future if it is really important enough.

In fact, it would be a good idea to break from ETag completely, because
that is tied
to the representation, which is not what is needed here.

We call a "transaction-id" a "config-id" once it is applied to a datastore.
The internal uint64 ID is global, not per datastore.
The "config-id" attribute is added to the  element in certain cases.
(It is useful to expose the config-id in , NV-store, etc)



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

I would say universal transaction-ids (same in each protocol) is a SHOULD,
not a MUST.


> Regards Balazs
>

Andy


>
>
> *From:* Jan Lindblad 
> *Sent:* Thursday, 24 March, 2022 21:38
> *To:* Andy Bierman ; Balázs Lengyel <
> balazs.leng...@ericsson.com>; 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 mult

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-Since

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

[Jan Lindblad]

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-Since is what set me going with this whole draft, so obviously I 
value that mechanism highly. The fact that it works with timestamps worries me 
a bit, however. 

First, the resolution is pretty low, 1s. It is quite possible that a server 
could process more than one edit/POST in the same second, in which case this 
mechanism might indicate no change has taken place when in fact it has.

Secondly, while the idea with timestamps and "unmodified since" is very 
convenient, it's also quite brittle. If a client ever sends an edit request to 
a server without using the If-Unmodified-Since, it may miss an update made by 
another client. The ETag mecha

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 include it in my mail, but we actually have one more rule:
“Top level statements in aug

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

[Andy Bierman]

On Thu, Mar 24, 2022 at 10:14 AM Balázs Lengyel 
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.




> Balazs
>

Andy


>
>
> *From:* maqiufang (A) 
> *Sent:* Thursday, 24 March, 2022 15:23
> *To:* Andy Bierman 
> *Cc:* Balázs Lengyel ; Kent Watsen <
> kent+i...@watsen.net>; 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 
> *Cc:* NetMod WG 
> *Subject:* Re: [netmod] Alternative approach to
> draft-ma-netmod-immutable-flag-00
>
>
>
>
>
>
>
> On Wed, Mar 23, 2022 at 3:06 PM Balázs Lengyel <
> balazs.leng...@ericsson.com> wrote:
>
>
>
>
>
> *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 <
> 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

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

[tom petch]

From: netmod  on behalf of Jürgen Schönwälder 

Sent: 22 March 2022 07:11

So we have the following options:

a) Leave revision-date to be defined in ietf-yang-revisions.

b) Define revision-date in ietf-yang-types.

c) Define a date-no-zone type (derived from the date type) which does
   not have the optional time zone offset.



Yes, I like c) for its simplicity and its adequacy

Tom Petch


I am leaning towards option c), having a generic type for a date
without a time zone is the most general type we can provide. If
additional specific revision date semantics are necessary, they can be
provided in ietf-yang-revisions. (Looking at the definition of the
type revision-identifier in RFC 8525, this is really date-no-zone.)

/js

On Tue, Mar 15, 2022 at 08:42:31AM -0700, Andy Bierman wrote:
> On Tue, Mar 15, 2022 at 6:01 AM Jürgen Schönwälder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> > On Mon, Mar 14, 2022 at 05:21:01PM -0700, Andy Bierman wrote:
> > > On Mon, Mar 14, 2022 at 4:34 PM Kent Watsen 
> > wrote:
> > >
> > > > All,
> > > >
> > > > 1) If you provided WGLC comments on this draft, please review the -12
> > diff
> > > > <
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-12.txt> to
> > > > ensure that the updates made are good.
> > > >
> > > > 2) Juergen notes below that he also removed the "revision-identifier"
> > > > typedef, as it is better
> > > > defined in the YANG versioning module.  Any objections?
> > > >
> > > >
> > > Sorry for the late comment.
> > > I think Juergen listed one option as "rename to revision-date and leave
> > it
> > > in this module".
> > > I support this option.
> > >
> > > There is no chance that the revision date format will be changing any
> > time
> > > soon.
> > > This is useful for general applications because revision date is widely
> > > used.
> > >
> >
> > The ietf-yang-library module (RFC 8525) currently uses its own
> > definition of revision-identifier. While this module could adopt a
> > common definition, the value of such a change is minor.
> >
> > The question where we place the definition of revision-date is likely
> > a matter of which role we expect the versioning work to play in the
> > future. I am relatively neutral on the placement.
> >
> >
> Not that important I guess.
> One would think the "date" typedef already in the draft would be useful,
> but it isn't, and therefore not used.
> There is no typedef for the pattern -MM-DD.
>
> /js
> >
>
> Andy
>
>
> >
> > --
> > Jürgen Schönwälder  Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> >

--
Jürgen Schönwälder  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

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

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] 
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

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

[Andy Bierman]

On Thu, Mar 24, 2022 at 7:22 AM maqiufang (A)  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] *On Behalf Of *Andy
> Bierman
> *Sent:* Thursday, March 24, 2022 7:14 AM
> *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 3:06 PM Balázs Lengyel <
> balazs.leng...@ericsson.com> wrote:
>
>
>
>
>
> *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 <
> 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  *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
> 

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

[maqiufang (A)]

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 
Cc: NetMod WG 
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


Andy

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

Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

[Jürgen Schönwälder]

On Thu, Mar 24, 2022 at 11:23:39AM +, Qin Wu wrote:
> >-邮件原件-
> >发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen Sch?nw?lder
> >发送时间: 2022年3月24日 18:56
> >收件人: mohamed.boucad...@orange.com
> >抄送: netmod@ietf.org
> >主题: Re: [netmod] TR: New Version Notification for 
> >draft-boucadair-netmod-iana-registries-00.txt
> 
> >On Thu, Mar 24, 2022 at 10:44:42AM +, mohamed.boucad...@orange.com wrote:
> >> > It seems that later on you are actually changing what RFC 8407 says 
> >> > although I am not sure I understand the reasoning. RFC 8407 
> >> > recommends to use enums if there is a single naming authority 
> >> > allocating values and thus ensuring uniqness of values. I am not 
> >> > sure in which sense the DOTS decision to use enums is not inline 
> >> > with what RFC 8407 says. DOTS may have decided to go with enums for 
> >> > space reasons and then this decision implies that values have to be 
> >> > centrally allocated. Note that there are IANA registries that allow 
> >> > distributed allocation of values and for thoses cases the RFC 8407 
> >> > recommendation to use identities still applies I think.
> >> 
> >> [Med] I was referring to this part: 
> >> 
> >>If extensibility of enumerated values is required, then the
> >>"identityref" data type SHOULD be used instead of an enumeration or
> >>other built-in type.
> >>
> 
> >But why do you think this statement of RFC 8407 needs any changes or 
> >different interpretations? 
> 
> [Qin Wu] If my understanding is correct, Authors of document containing YANG 
> data model face dilemma choices now, i.e.,whether 
> 1.change enum into identities which avoid updating the module defining the 
> enum in the future
> 2. Or stick to use enum and separate all enum types into IANA-Maintained YANG 
> Modules, which also avoid updating the module, in addition, another benefit 
> is to make sure the same registry maintenance for the module that get updated.
> For the second choice, here is one related discussion raised by Lada
> https://mailarchive.ietf.org/arch/msg/netmod/AILS-FptdNxMWFgSHiSjbwGc6tM/
> both seems to work.
>

I am writing about IANA maintained modules, not about why one should
use IANA maintained modules.

/js

-- 
Jürgen Schönwälder  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

[mohamed.boucadair]

Re-,

Agree with Qin. This is one of the usual comments from yangdoctors. 

The proposed clarification in draft-boucadair-netmod-iana-registries makes 
explicit that, for IANA-maintained modules, designers should make a decision 
based solely on their specific context. 

Cheers,
Med

> -Message d'origine-
> De : Qin Wu 
> Envoyé : jeudi 24 mars 2022 12:24
> À : Jürgen Schönwälder ; BOUCADAIR
> Mohamed INNOV/NET 
> Cc : netmod@ietf.org
> Objet : RE: [netmod] TR: New Version Notification for draft-boucadair-
> netmod-iana-registries-00.txt
> 
> >-邮件原件-
> >发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen Sch?nw?lder
> >发送时间: 2022年3月24日 18:56
> >收件人: mohamed.boucad...@orange.com
> >抄送: netmod@ietf.org
> >主题: Re: [netmod] TR: New Version Notification for
> >draft-boucadair-netmod-iana-registries-00.txt
> 
> >On Thu, Mar 24, 2022 at 10:44:42AM +, mohamed.boucad...@orange.com
> wrote:
> >> > It seems that later on you are actually changing what RFC 8407 says
> >> > although I am not sure I understand the reasoning. RFC 8407
> >> > recommends to use enums if there is a single naming authority
> >> > allocating values and thus ensuring uniqness of values. I am not
> >> > sure in which sense the DOTS decision to use enums is not inline
> >> > with what RFC 8407 says. DOTS may have decided to go with enums for
> >> > space reasons and then this decision implies that values have to be
> >> > centrally allocated. Note that there are IANA registries that allow
> >> > distributed allocation of values and for thoses cases the RFC 8407
> >> > recommendation to use identities still applies I think.
> >>
> >> [Med] I was referring to this part:
> >>
> >>If extensibility of enumerated values is required, then the
> >>"identityref" data type SHOULD be used instead of an enumeration
> or
> >>other built-in type.
> >>
> 
> >But why do you think this statement of RFC 8407 needs any changes or
> different interpretations?
> 
> [Qin Wu] If my understanding is correct, Authors of document containing
> YANG data model face dilemma choices now, i.e.,whether 1.change enum
> into identities which avoid updating the module defining the enum in the
> future 2. Or stick to use enum and separate all enum types into IANA-
> Maintained YANG Modules, which also avoid updating the module, in
> addition, another benefit is to make sure the same registry maintenance
> for the module that get updated.
> For the second choice, here is one related discussion raised by Lada
> https://mailarchive.ietf.org/arch/msg/netmod/AILS-
> FptdNxMWFgSHiSjbwGc6tM/
> both seems to work.
> 


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

[Qin Wu]

>-邮件原件-
>发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen Sch?nw?lder
>发送时间: 2022年3月24日 18:56
>收件人: mohamed.boucad...@orange.com
>抄送: netmod@ietf.org
>主题: Re: [netmod] TR: New Version Notification for 
>draft-boucadair-netmod-iana-registries-00.txt

>On Thu, Mar 24, 2022 at 10:44:42AM +, mohamed.boucad...@orange.com wrote:
>> > It seems that later on you are actually changing what RFC 8407 says 
>> > although I am not sure I understand the reasoning. RFC 8407 
>> > recommends to use enums if there is a single naming authority 
>> > allocating values and thus ensuring uniqness of values. I am not 
>> > sure in which sense the DOTS decision to use enums is not inline 
>> > with what RFC 8407 says. DOTS may have decided to go with enums for 
>> > space reasons and then this decision implies that values have to be 
>> > centrally allocated. Note that there are IANA registries that allow 
>> > distributed allocation of values and for thoses cases the RFC 8407 
>> > recommendation to use identities still applies I think.
>> 
>> [Med] I was referring to this part: 
>> 
>>If extensibility of enumerated values is required, then the
>>"identityref" data type SHOULD be used instead of an enumeration or
>>other built-in type.
>>

>But why do you think this statement of RFC 8407 needs any changes or different 
>interpretations? 

[Qin Wu] If my understanding is correct, Authors of document containing YANG 
data model face dilemma choices now, i.e.,whether 
1.change enum into identities which avoid updating the module defining the enum 
in the future
2. Or stick to use enum and separate all enum types into IANA-Maintained YANG 
Modules, which also avoid updating the module, in addition, another benefit is 
to make sure the same registry maintenance for the module that get updated.
For the second choice, here is one related discussion raised by Lada
https://mailarchive.ietf.org/arch/msg/netmod/AILS-FptdNxMWFgSHiSjbwGc6tM/
both seems to work.

>An enum implies that allocations can only be done by updating the module 
>defining the enum. If a WG goes for an enum because of efficiency concerns, 
>then the WG accepts that new allocations require an update of the module 
>defining the enum.  If you
>want multiple parties to allocate values, then the price is the overhead of 
>using identities.

>The good old middle ground are numbers spaces where some of the space is 
>allocated for distributed allocations (and sometimes these allocations than 
>include things like enterprise IDs to reduce the likelyhood for collisions) 
>but then the YANG equivalent 
>for this is not just a plain enum.

/js

-- 
Jürgen Schönwälder  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

Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

[Jürgen Schönwälder]

On Thu, Mar 24, 2022 at 10:44:42AM +, mohamed.boucad...@orange.com wrote:
> > It seems that later on you are actually changing what RFC 8407 says
> > although I am not sure I understand the reasoning. RFC 8407 recommends
> > to use enums if there is a single naming authority allocating values and
> > thus ensuring uniqness of values. I am not sure in which sense the DOTS
> > decision to use enums is not inline with what RFC 8407 says. DOTS may
> > have decided to go with enums for space reasons and then this decision
> > implies that values have to be centrally allocated. Note that there are
> > IANA registries that allow distributed allocation of values and for
> > thoses cases the RFC 8407 recommendation to use identities still applies
> > I think.
> 
> [Med] I was referring to this part: 
> 
>If extensibility of enumerated values is required, then the
>"identityref" data type SHOULD be used instead of an enumeration or
>other built-in type.
>

But why do you think this statement of RFC 8407 needs any changes or
different interpretations? An enum implies that allocations can only
be done by updating the module defining the enum. If a WG goes for an
enum because of efficiency concerns, then the WG accepts that new
allocations require an update of the module defining the enum.  If you
want multiple parties to allocate values, then the price is the
overhead of using identities.

The good old middle ground are numbers spaces where some of the space
is allocated for distributed allocations (and sometimes these
allocations than include things like enterprise IDs to reduce the
likelyhood for collisions) but then the YANG equivalent for this is
not just a plain enum.

/js

-- 
Jürgen Schönwälder  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

[mohamed.boucadair]

Hi Jürgen, 

Thank you for the feedback. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Jürgen Schönwälder 
> Envoyé : jeudi 24 mars 2022 11:27
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : netmod@ietf.org
> Objet : Re: [netmod] TR: New Version Notification for draft-boucadair-
> netmod-iana-registries-00.txt
> 
> Hi,
> 
> the document says that it updates RFC 8407.

[Med] yes, it is more "extends" than "amends" (as per 
https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag) except for 
one point I'm not sure yet about. See next please. 


 I assume that the intended
> semantic here is that this document augments what is being said in RFC
> 8407 but it does not change anything said in RFC 8407.

[Med] It relaxes a reco from 8407: 

   This recommendation takes precedence over the behavior in
   Section 4.11.1 of [RFC8407] for IANA-maintained modules because the
   extensibility concern is not applicable for such modules.

 I like the
> recommendation given in other places of being explicit about what
> "updates" means.

[Med] Agree. 

> 
> OLD
> 
>This document updates RFC 8407.
> 
> NEW
> 
>This document updates RFC 8407 by providing additional guidelines
>for IANA maintained modules. It does not change anything written
>in RFC 8407.
> 

[Med] Thanks. Went now for: 

This document updates RFC 8407 by providing additional guidelines
for IANA-maintained modules.

I may add or not the last sentence depending whether we consider that we are 
amending Section 4.11.1 of [RFC8407]. That is covered in your point below: 

> It seems that later on you are actually changing what RFC 8407 says
> although I am not sure I understand the reasoning. RFC 8407 recommends
> to use enums if there is a single naming authority allocating values and
> thus ensuring uniqness of values. I am not sure in which sense the DOTS
> decision to use enums is not inline with what RFC 8407 says. DOTS may
> have decided to go with enums for space reasons and then this decision
> implies that values have to be centrally allocated. Note that there are
> IANA registries that allow distributed allocation of values and for
> thoses cases the RFC 8407 recommendation to use identities still applies
> I think.

[Med] I was referring to this part: 

   If extensibility of enumerated values is required, then the
   "identityref" data type SHOULD be used instead of an enumeration or
   other built-in type.


> 
> /js
> 
> PS: I liked the word 'inexorability' but I am not sure that making me
> smile was the intention of the authors. ;-)

[Med] :-)


> 
> On Thu, Mar 24, 2022 at 09:47:16AM +, mohamed.boucad...@orange.com
> wrote:
> > Hi all,
> >
> > We had in alto wg a discussion about consistent use of IANA-maintained
> modules. This document provides some guidelines that I hope will ensure
> some consistency about how we are interacting with IANA registries. The
> goal is avoid transforming YANG modules (if not maintained by IANA) as
> another source of information, which are likely to be out of sync.
> >
> > Some more details/context are provided in the I-D.
> >
> > Comments and suggestions are appreciated.
> >
> > Cheers,
> > Med
> >
> > -Message d'origine-
> > De : internet-dra...@ietf.org  Envoyé :
> > jeudi 24 mars 2022 10:41 À : BOUCADAIR Mohamed INNOV/NET
> >  Objet : New Version Notification for
> > draft-boucadair-netmod-iana-registries-00.txt
> >
> >
> > A new version of I-D, draft-boucadair-netmod-iana-registries-00.txt
> > has been successfully submitted by Mohamed Boucadair and posted to the
> IETF repository.
> >
> > Name:   draft-boucadair-netmod-iana-registries
> > Revision:   00
> > Title:  Recommendations for Creating IANA-Maintained YANG
> Modules
> > Document date:  2022-03-24
> > Group:  Individual Submission
> > Pages:  5
> > URL:https://www.ietf.org/archive/id/draft-boucadair-
> netmod-iana-registries-00.txt
> > Status: https://datatracker.ietf.org/doc/draft-boucadair-
> netmod-iana-registries/
> > Htmlized:   https://datatracker.ietf.org/doc/html/draft-boucadair-
> netmod-iana-registries
> >
> >
> > Abstract:
> >This document provides a set of guidelines for YANG module authors
> >related to the design of IANA-maintained modules.  These guidelines
> >are meant to leverage existing IANA registries and use YANG as just
> >another format to present the content of these registries.
> >
> >This document updates RFC 8407.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
> >
> > __
> > ___
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et l

Re: [netmod] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

[Jürgen Schönwälder]

Hi,

the document says that it updates RFC 8407. I assume that the intended
semantic here is that this document augments what is being said in RFC
8407 but it does not change anything said in RFC 8407. I like the
recommendation given in other places of being explicit about what
"updates" means.

OLD

   This document updates RFC 8407.

NEW

   This document updates RFC 8407 by providing additional guidelines
   for IANA maintained modules. It does not change anything written
   in RFC 8407.

It seems that later on you are actually changing what RFC 8407 says
although I am not sure I understand the reasoning. RFC 8407 recommends
to use enums if there is a single naming authority allocating values
and thus ensuring uniqness of values. I am not sure in which sense the
DOTS decision to use enums is not inline with what RFC 8407 says. DOTS
may have decided to go with enums for space reasons and then this
decision implies that values have to be centrally allocated. Note that
there are IANA registries that allow distributed allocation of values
and for thoses cases the RFC 8407 recommendation to use identities
still applies I think.

/js

PS: I liked the word 'inexorability' but I am not sure that making me
smile was the intention of the authors. ;-)

On Thu, Mar 24, 2022 at 09:47:16AM +, mohamed.boucad...@orange.com wrote:
> Hi all, 
> 
> We had in alto wg a discussion about consistent use of IANA-maintained 
> modules. This document provides some guidelines that I hope will ensure some 
> consistency about how we are interacting with IANA registries. The goal is 
> avoid transforming YANG modules (if not maintained by IANA) as another source 
> of information, which are likely to be out of sync. 
> 
> Some more details/context are provided in the I-D. 
> 
> Comments and suggestions are appreciated. 
> 
> Cheers,
> Med
> 
> -Message d'origine-
> De : internet-dra...@ietf.org  
> Envoyé : jeudi 24 mars 2022 10:41
> À : BOUCADAIR Mohamed INNOV/NET 
> Objet : New Version Notification for 
> draft-boucadair-netmod-iana-registries-00.txt
> 
> 
> A new version of I-D, draft-boucadair-netmod-iana-registries-00.txt
> has been successfully submitted by Mohamed Boucadair and posted to the IETF 
> repository.
> 
> Name: draft-boucadair-netmod-iana-registries
> Revision: 00
> Title:Recommendations for Creating IANA-Maintained YANG 
> Modules
> Document date:2022-03-24
> Group:Individual Submission
> Pages:5
> URL:
> https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-boucadair-netmod-iana-registries/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-boucadair-netmod-iana-registries
> 
> 
> Abstract:
>This document provides a set of guidelines for YANG module authors
>related to the design of IANA-maintained modules.  These guidelines
>are meant to leverage existing IANA registries and use YANG as just
>another format to present the content of these registries.
> 
>This document updates RFC 8407.
> 
>   
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Jürgen Schönwälder  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] TR: New Version Notification for draft-boucadair-netmod-iana-registries-00.txt

[mohamed.boucadair]

Hi all, 

We had in alto wg a discussion about consistent use of IANA-maintained modules. 
This document provides some guidelines that I hope will ensure some consistency 
about how we are interacting with IANA registries. The goal is avoid 
transforming YANG modules (if not maintained by IANA) as another source of 
information, which are likely to be out of sync. 

Some more details/context are provided in the I-D. 

Comments and suggestions are appreciated. 

Cheers,
Med

-Message d'origine-
De : internet-dra...@ietf.org  
Envoyé : jeudi 24 mars 2022 10:41
À : BOUCADAIR Mohamed INNOV/NET 
Objet : New Version Notification for 
draft-boucadair-netmod-iana-registries-00.txt


A new version of I-D, draft-boucadair-netmod-iana-registries-00.txt
has been successfully submitted by Mohamed Boucadair and posted to the IETF 
repository.

Name:   draft-boucadair-netmod-iana-registries
Revision:   00
Title:  Recommendations for Creating IANA-Maintained YANG Modules
Document date:  2022-03-24
Group:  Individual Submission
Pages:  5
URL:
https://www.ietf.org/archive/id/draft-boucadair-netmod-iana-registries-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-boucadair-netmod-iana-registries/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-boucadair-netmod-iana-registries


Abstract:
   This document provides a set of guidelines for YANG module authors
   related to the design of IANA-maintained modules.  These guidelines
   are meant to leverage existing IANA registries and use YANG as just
   another format to present the content of these registries.

   This document updates RFC 8407.


  


The IETF Secretariat



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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