Re: [netconf] overview of updates and current issues

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Apr 16, 2019 at 10:44:38PM +0000, Kent Watsen wrote:
> 
> 
> > On Apr 15, 2019, at 5:34 PM, Juergen Schoenwaelder <[e-mail]> wrote:
> > 
> > Inline...
> > 
> > On Mon, Apr 15, 2019 at 09:05:30PM +0000, Kent Watsen wrote:
> >> 
> >>>> Current Issues:
> >>>> 
> >>>> 1. Regarding the "demux containers":
> >>>> 
> >>>>    Pros:
> >>>>      - now the NC/RC models look better
> >>>>      - a convenient place to have a nacm:default-deny-write
> >>>> 
> >>>>    Cons:
> >>>>      - seems overbearing for general use
> >>>> 
> >>>>  Question:
> >>>> 
> >>>>    Would it be better to revert and instead wrap each "uses"
> >>>>    statement in the NC/RC models with a container?
> >>>> 
> >>>>       Pros: maximum flexibility
> >>>>       Cons: less consistency?
> >>> 
> >>> What exactly are the demux containers? You mean the
> >>> <tcp-client-parameters> and <tls-client-parameters> containers?
> >> 
> >> Yes.  This is what what meant by:
> >> 
> >>   "Added a top-level "demux container" inside the top-level grouping.
> >>    By "demux", I'm referring to the namespace problem discussed @104."
> >> 
> >> about 10 lines above.
> >> 
> >> 
> >> 
> >>> I have no strong opinion, they may be ok although things get a bit more verbose.
> >> 
> >> On the "Cons" side, I'm calling the containers "<protocol>-<client/server>-parameters".  I question is if this is a good name in all contexts.  By removing the "demux container",  it lets the consumer decide what to call it.  This brings us to the "less consistency?" comment;  of course there would be little consistency but, do we care?
> >> 
> >> Regarding "a convenient place to have a nacm:default-deny-write", I don't see anywhere in RFC 8341 that nacm:default-deny-write can't be used in a grouping, but it will impact the parent...  If the parent has other descendents besides from the grouping, those descendents would likely be impacted too, right?   Do we care?  If we put nacm:default-deny-write under the grouping statement, then I think that it subtly enforces consumers to create their own wrapper containers (as opposed to mixing the descendents in with other nodes).   Alternately, we could float the "if-feature" statement down to each descendent of the grouping.  Not ideal, but works...?
> >> 
> > 
> > Perhaps instead of being tricky (subtly enforcing consumers to create
> > their own wrapper), why not move the nacm:default-deny-write to the
> > leafs? This seems less subtle and more robust.
> 
> Right, this was my last sentence: "Alternately, we could float the "if-feature" statement down to each descendent of the grouping.".
> 
> Okay, so it's technically possible (the nacm extension), but I feel that we're still open on if the "demux containers" should be kept or discarded.  
> 
> I'm personally leaning towards "discard", but I don't want to make the change until we have a solid decision.

I think we should discard the "demux containers" to give data model
writers the freedom to have them or not.

> > One thing that comes to mind is whether a new callhome attempt should
> > be made in situations where the previous callhome is still alive. Do
> > we want to say something about this or not?
> 
> If that happens, then something is wrong.  Either the previous attempt is "hung" (but I think there is an "idle-timeout" to catch such cases, maybe only for NC though), or it is legitimately still busy (in which case it MAY be an indication that the frequency is set too high but, in either case, it seems that a second connection wouldn't be desired).   There is currently no text stating what to do in this case.  It seems like such text might go into the same description statements discussed above:
> 
>                     "Periodically connect to the <protocol> <peer>.  The
>                      <protocol> client SHOULD close the underlying TCP
>                      connection upon completing planned activities.
> 
>                      In the case that the pervious connection is still active,
>                      establishing a new connection is NOT RECOMMENDED.

Sounds good, this provides a hint that implementers need to track and
limit call home connections.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>