On Thu, Jun 1, 2023 at 1:55 PM Kent Watsen <[email protected]> wrote:
> Hi Quifang, > > The latest update looks very good to me - IMO, ready for adoption. > > Jan, Jurgen, Andy, Rob - can you confirm that your concerns have been > addressed? > > IMO the problem statement and solution are still rough and unclear. The different behavior for each type of node made it even more unclear. There is a useful improvement to configuration automation here, but it needs more work. The problem is that sometimes the server does not allow certain edits to config=true nodes. This can cause automated (or manual) edit requests to be rejected by the server, with no way for the client to fix the edit request. The edit operations 'add', 'modify', and 'delete' need more clarification. There seem to be 3 usage modes that must be supported - The server provides the value, and the client does not provide it - The client provides a server-approved value that can not change - The client picks a value that cannot change In the example in A.2, any of the 3 modes could apply to a client creating a new interface entry. In all cases it seems the intent is to allow the client to create an immutable node, but not modify it. It can only be deleted if a mutable ancestor is being deleted. It is not clear how inherited immutable flag values work, especially in conjunction with NACM. YumaPro has supported the "user-write" extension for many years for this purpose. https://docs.yumaworks.com/en/latest/yangauto/builtin-yang-extensions.html#ncx-user-write It supports all 3 usage modes above. IMO the immutable attribute should support all 3 modes. I do not understand the purpose of the with-immutable parameter. The client can just parse the YANG modules from the server and find the nodes with an immutable field. Thanks, > Kent > > Andy > > > On May 25, 2023, at 8:16 AM, maqiufang (A) <maqiufang1= > [email protected]> wrote: > > Hi, all > This version reflects the input we've received from the mailing list. > > Thank you everyone(Jan, Rob, Kent, Jürgen, Andy, Frank et al.) for your > great comments and suggestions! > Please see if the following updates are good for you: > * Use a Boolean type for the immutable value in YANG extension and > metadata annotation > * Define a "with-immutable" parameter and state that immutable > metadata annotation is not included in a response unless a client > explicitly requests them with a "with-immutable" parameter > * reword the abstract and related introduction section to highlight > immutable flag is descriptive > * Add a new section to define immutability of interior nodes, and > merge with "Inheritance of Immutable configuration" section > * Add a new section to define what the immutable flag means for each > YANG data node > * Define the "immutable flag" term. > * Add an item in the open issues tracking: Should the "immutable" > metadata annotation also be returned for nodes described as > immutable in the YANG schema so that there is a single source of > truth. > > Thanks a lot. > > Best Regards, > Qiufang > > -----Original Message----- > From: [email protected] [mailto:[email protected] > <[email protected]>] > Sent: Thursday, May 25, 2023 4:52 PM > To: Balazs Lengyel <[email protected]>; Hongwei Li < > [email protected]>; Qin Wu <[email protected]>; Qin Wu < > [email protected]>; maqiufang (A) <[email protected]> > Subject: New Version Notification for draft-ma-netmod-immutable-flag-07.txt > > > A new version of I-D, draft-ma-netmod-immutable-flag-07.txt > has been successfully submitted by Qiufang Ma and posted to the IETF > repository. > > Name: draft-ma-netmod-immutable-flag > Revision: 07 > Title: YANG Extension and Metadata Annotation for > Immutable Flag > Document date: 2023-05-25 > Group: Individual Submission > Pages: 24 > URL: > https://www.ietf.org/archive/id/draft-ma-netmod-immutable-flag-07.txt > Status: > https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-ma-netmod-immutable-flag-07 > > Abstract: > This document defines a way to formally document existing behavior, > implemented by servers in production, on the immutability of some > configuration nodes, using a YANG "extension" and a YANG metadata > annotation, both called "immutable", which are collectively used to > flag which data nodes are immutable. > > Clients may use "immutable" statements in the YANG, and annotations > provided by the server, to know beforehand when certain otherwise > valid configuration requests will cause the server to return an > error. > > The immutable flag is descriptive, documenting existing behavior, not > proscriptive, dictating server behavior. > > > > > > The IETF Secretariat > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
