Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

[Andy Bierman <[e-mail]>]

Hi,

This text in sec 7.5.8, para 2 is wrong:

   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.



This text in 6.4.1 is correct, which implies deleting an N container occurs
when its non-NP container
ancestor is deleted.


   If a node that exists in the accessible tree has a non-presence
   container as a child, then the non-presence container also exists in
   the tree.


This text in 7.5.7 covers the intended external behavior on an NP-container
better than the text in 7.5.8:

   If a non-presence container does not have any child nodes, the
   container may or may not be present in the XML encoding.


(BTW, why isn't this text using RFC 2119 terms like sec. 7.5.8?)


I propose that the cited text in sec. 7.5.8 be removed as a clarification.
It is a redundant (incorrect) restatement of the cited text in 7.5.7.


Andy



On Sat, Aug 20, 2016 at 1:29 AM, Juergen Schoenwaelder <
[e-mail]> wrote:

> Here is what I wrote on Thu, 16 Jun 2016 14:49:00 +0200:
>
> : It is possible that people will find more bugs while this I-D sits in
> : the RFC editor queue. My idea is to treat them pretty much in the way
> : we treat errata of published RFCs (they need to be clearly written up,
> : discussed on the list, there needs to be agreement on the bug and the
> : proposed fix). If we get pre-publication errata with consensus, I hope
> : we can address them during the editing/auth48 stage so we do not have
> : to post an RFC with already known defects. Does this make sense to
> : you?
>
> As document shepherd, I believe there is no strong agreement on the
> problem and there is no concrete proposal with strong consensus for a
> modification of the document (which is in AUTH48). In fact, there has
> been no defect description and proposed bug fix at all on the NETMOD
> mailing list.
>
> /js
>
> On Fri, Aug 19, 2016 at 07:04:10PM -0700, Mahesh Jethanandani wrote:
> > Moving the thread from netconf to netmod.
> >
> > Will the authors pull 6020bis back into the WG to reach the rough
> consensus?
> >
> > > On Aug 17, 2016, at 2:13 AM, Martin Bjorklund <[e-mail]> wrote:
> > >
> > > Hi,
> > >
> > > I have read this long ML thread twice now, and I agree with Andy that:
> > >
> > > 1)  We should not / cannot make design changes in an errata or late in
> > >    AUTH48; in order to do this we need to pull the document back to
> > >    the WG and reach (rough) consensus on the behavior (note btw that
> > >    this thread is currently in NETCONF, it really should be NETMOD).
> > >
> > > 2)  Since servers MAY delete NP-containers in some cases, clients can
> > >    easily handle NP-containers by using "merge" on them.
> > >
> > >
> > > I also agree with Jason that ideally the server should never fail on
> > > any kind of operation on an NP-container, regardless of current state
> > > and requested operation.  (But again, this is not a simple
> > > clarification of the current text.)
> > >
> > >
> > > And to answer the original question, I think the server that first got
> > > a request to create the empty NP-containers and then a request w/
> > > operation "none" is not correct when it fails with a "data-missing"
> > > error.  There is no text in 6241 or 6020 that supports this behavior.
> > >
> > >
> > > /martin
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netconf
> >
> > Mahesh Jethanandani
> > [e-mail]
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>