Re: [Netconf] YangPush now

[Andy Bierman <[e-mail]>]

On Sun, Jul 29, 2018 at 8:30 AM, Martin Bjorklund <[e-mail]> wrote:

> Hi,
>
> Hi think the plan to finish and publish SN + YP + netconf-notifs w/o
> support for configured subscriptions is ok.  I assume that as soon as
> these documents are sent to the IESG for publication, the WG
> immediately starts to work on configured subscriptions for netconf.
>
> However, I would have preferred to remove configured subscriptions
> from SN and YP, b/c I beleive that this would be faster (essentially
> echoing what Balazs wrote in the first email in this thread).  If we
> keep configured subscriptions in these docs, they will take additional
> time to finish b/c the text needs clarifications.
>
>
I agree


> See more inline below.
>
> Kent Watsen <[e-mail]> wrote:
> > <chair hat on>
> >
> > I think that we're iterating towards consensus.
> > From a conformance perspective:
> >
> >     Dynamic: MUST
> >     Configured: MAY (but also NOT POSSIBLE until a transport model is
> defined)
> >
> >     Notes:
> >       - Vendor-specific transport models can be used until
> >         standard-models are developed.
> >       - No mandatory-to-implement transport will exist; thus,
> >         interoperability is at risk.
>
> I don't think this is true.  This is a generic model designed to be
> used wih a variety of transports.  Even if we had one or more
> transport models ready, noone would have been mandatory.
>


This WG is very server-centric.  It shows up most often in the way that
identityref leafs are standardized.  YANG just says any identity with
matching bases
is valid, but this is no help to a client developer.

Consider the possibility that the client developer is not looking for
opportunities to rewrite the same functionality over and over, but
rather looking for opportunities to reuse the same code across all servers.
Supposedly standards make that possible.

That is possible when there is at least one mandatory-to-implement API that
is complete enough to be useful.




Andy




>
> >       - Unclear how a future *bis* could introduce a
> >         mandatory-to-implement transport.
> >
> > I *think* that this is okay. At least it seems similar to RESTCONF
> > not having a mandatory-to-implement encoding.  Any objections? -
> > speak up now!
> >
> > Assuming no objections, to close the issues discussed in Montreal,
> > we're waiting for the following updates:
> >
> >    yang-push: <unsure if any changes are needed here>
> >    sub-notif: modify config model to mandate a transport
>
> The transport leaf is already marked as mandatory.  I think this is
> good enough.
>
> >    netconf-notif: modify to only reflect netconf for dynamic
> subscriptions
>
> Agreed.
>
> >    resconf-notif: modify to only reflect restconf for dynamic
> subscriptions
> >                                 and also only regard *restconf* (not
> http/x[.y])
>
> I would prefer to wait with this docuement; it hasn't been discussed
> much, and I haven't seen a single review on the ML.
>
> >
> > or (my preference, if possible):
> >
> >    yang-push: <unsure if any changes are needed here>
> >    sub-notif: modify config model to mandate a transport…and, somehow,
> >               modified to not require a "notif" draft at
> >               all for just dynamic
> >               subscriptions (shouldn't it just be normal NC/RC behavior
> at
> >               that point, and thus nothing to define?)
>
> This is not possible, since for NETCONF, the <notification> elements
> will now be sent after an <establish-subscription>, rather than just
> <create-subscription>.  There are similar issues for RESTCONF.
>
>
> /martin
>
>
> > For folks that want these drafts to move faster, we look forward to
> > your thorough reviews.  Please note that simply writing "I support"
> > or equivalent doesn't help ensure that the text is accurate (witness
> > what happened last time with these drafts).
> >
> > There are nearly 150 pages here. Realistically, at 7.5 pages/hour (a
> > medium-to-light edit, which I hope is all that is needed at this
> > point), complete reviews might take two and a half days,
> > uninterrupted.  The chairs would like to see a few such reviews,
> > either after the updates to these drafts have been posted, or when
> > the next (and hopefully final) Last Call is issued.
> >
> > Thanks,
> > Kent
> >
> >
> > On 7/26/18, 5:15 AM, "Netconf on behalf of Robert Wilton" <
> [e-mail]<mailto:[e-mail]> on behalf of
> rwilton=[e-mail]<mailto:rwilton=40cisc
> [e-mail]>> wrote:
> >
> >
> > I basically agree with Andy.
> >
> > I appreciate from the comments that the configured subscriptions is not
> usable using standards transports yet, but it still seems that it would be
> more invasive to rip configured subscriptions out at this point in time.  I
> think as a WG we really want to get this document published otherwise it
> will be obsolete before it even has an RFC number.  We can fix up the
> configured subscriptions afterwards, and then publish a bis version that
> puts everything together.
> >
> > Thanks,
> > Rob
> >
> >
> > On 26/07/2018 04:21, Andy Bierman wrote:
> > Hi,
> >
> > IMO there is a good enough plan in place to complete the configured
> subscriptions.
> > The co-authors have done enough revisions. It is time to finish the
> drafts.
> >
> > We should let vendors experiment and also try to create a standard
> binary protocol.
> >
> >
> > Andy
> >
> >
> >
> > On Tue, Jul 24, 2018 at 4:56 PM, Eric Voit (evoit) <[e-mail]
> <mailto:[e-mail]>> wrote:
> > Hi Juergen,
> >
> > > From: Juergen Schoenwaelder, July 23, 2018 10:14 AM
> > >
> > > On Fri, Jul 20, 2018 at 06:47:48PM +0000, Eric Voit (evoit) wrote:
> > > > Hi Juergen,
> > > >
> > > > > From: Juergen Schoenwaelder, July 20, 2018 6:14 AM
> > > > >
> > > > > On Thu, Jul 19, 2018 at 09:41:00AM +0000, Eric Voit (evoit) wrote:
> > > > >
> > > > > > That is what I was hoping would be accomplished with the text:
> > > > > >
> > > > > >    The method of identifying the targeted receiver IP address,
> port, and
> > > > > >    security credentials are left up to implementers of this
> > > > > >    specification.  For implementation guidance and a YANG model
> for
> > > this
> > > > > >    function, please look to
> > > > > >    [I-D.draft-ietf-netconf-netconf-client-server].
> > > > >
> > > > > I said this is to vague for me to understand. Repeating the pointer
> > > > > does not help me to understand. If this I-D has a clear solution,
> > > > > why not put it in place?
> > > >
> > > > The recommended solution is for vendors to augment in their own
> > > leafrefs into existing vendor specific call home configurations.
> > > Alternatively, solutions can be integrated within non-YANG based
> > > configuration structures.  This is how our configured subscription
> > > implementation works.
> > > >
> > > > To clarify the recommended solution, I have updated the reference
> above
> > > to:
> > > >
> > > > The method of identifying the targeted receiver IP address, port, and
> > > security credentials are left up to implementers of this
> specification..  For
> > > implementation guidance on how a leafref might constructed to
> accomplish
> > > this function, consider the following augmentation which would need to
> be
> > > made if the necessary connection parameters are maintained with ietf-
> > > netconf-client.yang as specified by [I-D.draft-ietf-netconf-
> netconf-client-
> > > server].
> > > >
> > > >   import ietf-netconf-client { prefix ncc; }
> > > >   import ietf-subscribed-notifications { prefix sn; }
> > > >   import ietf-netconf-subscribed-notifications { prefix nsn; }
> > > >
> > > >   augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver"
> {
> > > >    when 'derived-from(../../../transport, "nsn:netconf")';
> > > >    leaf netconf-endpoint {
> > > >       type leafref {
> > > >         path "/ncc:netconf-client/ncc:initiate/ncc:netconf-
> > > server/ncc:endpoints/ncc:endpoint/ncc:name";
> > > >       }
> > > >       description
> > > >         "Points to a remote NETCONF client intended to support a
> particular
> > > configured subscription.";
> > > >     }
> > > >   }
> > >
> > > So why do we create a _standard_ that says take the other standard and
> > > then roll your own non-standard module to make them work together?
> >
> > My reading of your request was to make the current draft text less
> vague.   Hopefully providing an example augmentation based on a referenced
> standard-in-progress removes this ambiguity.
> >
> > I would hope that when the other standard is ready, it doesn't take
> something non-standard to bind them.  There are earlier threads on how this
> might be done.
> >
> > > > > > To cover this, there is the following text in Section 5 of
> > > > > > draft-ietf-netconf-
> > > > > netconf-event-notifications:
> > > > > >
> > > > > >    publisher SHOULD place the receiver into the
> > > > > >    "timeout" state after a predetermined number of either failed
> call
> > > > > >    home attempts or NETCONF sessions remotely terminated by the
> > > > > >    receiver.
> > > > > >
> > > > > >    Until NETCONF transport with a receiver has been established,
> and a
> > > > > >    "subscription-started" state change notification has been
> > > > > >    successfully sent for a configured subscription, that
> subscription's
> > > > > >    receiver MUST remain in either the "connecting" or the
> "timeout"
> > > > > >    state.
> > > > >
> > > > >     <-- call home -->
> > > > >  C: <hello>
> > > > >  S: <hello>
> > > > >  S: <notification>
> > > > >     <-- session terminated -->
> > > > >
> > > > > The server believes 'notification has been successfully sent'.  The
> > > > > other alternative would be a client that throws away notification
> > > > > messages not
> > > > > expected:
> > > > >
> > > > >     <-- call home -->
> > > > >  C: <hello>
> > > > >  S: <hello>
> > > > >  S: <notification> // -> discarded
> > > > >  S: <notification> // -> discarded
> > > > >  S: <notification> // -> discarded
> > > > >     [...]
> > > > >
> > > > > Both scenarioes are problematic.
> > > >
> > > > Agree that there are these two scenarios.
> > > >
> > > > The first scenario isn't elegant, but I don't see it as
> problematic.  Per SN,
> > > transport loss places all receivers back into their connecting state.
>  And the
> > > NETCONF-Notif text quoted above shows that multiple session
> terminations
> > > places the subscription into "timeout" so that something can figure out
> > > what is wrong.
> > > >
> > > > The second scenario requires that NETCONF Call home is successfully
> > > configured with the right credentials on both sides of the connection,
> and
> > > that the receiver's NETCONF client implementation is unable to
> terminate a
> > > session receiving unwanted notification traffic.  This is a concern,
> but an
> > > implementer at least has some protections by controlling the call home
> > > connectivity parameters tied to a specific receiver.   (See continue
> reasoning
> > > below)
> > >
> > > There is nothing in NETCONF that requires a client to terminate a
> session if
> > > the client receives an unexpected message. The control of call home
> > > parameters is no answer (first this is out of hands for the
> implementor and
> > > second the problem is likely a misconfiguration in the first place
> that leads
> > > to something not useful). I do not think your answers provide a
> solution - I
> > > am not interested in justifications.
> >
> > A solution based on the correct call home parameter configuration does
> work..  But other than that, I agree with you: the current NETCONF
> configured subscription solution does take some valid error conditions out
> of the hands of implementers, and places them in the hands of operators.
> >
> > The biggest question I see is whether implementers want to do the
> leg-work needed to building out the client capability advertisement
> capability to protect against these failure scenarios.   It would be great
> if NETCONF implementers signaled they are ready to pick this up.
> >
> > > > > This is why I suggested that there needs to be some mechanism that
> > > > > tells the server that the client is willing to receive configured
> > > > > subscriptions before the server throws <notification> messages at
> > > > > the client. You will find differnet ideas in the mailing list
> archive.
> > > >
> > > > In talking about this issue in the past, suggestions were made that
> the
> > > NETCONF client could advertise its capabilities for supporting
> configured
> > > subscriptions as part of the hello exchange.  And that can be a
> partial(*)
> > > solution to the problem.  However there was pushback to this based on
> > > NETCONF client to server implementations not typically exchanging and
> > > interpreting the results of NETCONF client asserted capabilities.
> > > >
> > > > (*) the reason it is partial is that even if the client advertises
> support for
> > > NETCONF configured subscriptions, there is still the possibility that
> > > something goes wrong with the receiver's receiving process with the
> second
> > > scenario above.  In which case you still need to have a way to
> terminate the
> > > incoming notification stream by pulling down the NETCONF session.
> Still,
> > > there are obviously benefits of client capability signaling as an
> extra layer of
> > > misconfiguration protections included.
> > >
> > > Simply pushing data to a receiver before checking that the receiver is
> willing
> > > and able to consume the data is in my view not good protocol design.
> There
> > > are cases where this is unavoidable but here we do have a client and
> server
> > > talking to each other that can do better.
> > >
> > > > Looking at what is in the v10 draft, there are some protections for
> both
> > > your scenarios above.  But certainly it is not robust.   And certainly
> having
> > > the client advertise configured receiver support would be nice, but
> this
> > > would require more development.   As based on the amount of
> > > development,  we used the design philosophy of "it is better to start
> with
> > > an 80% solution than a 120% solution :-)."
> > >
> > > There was also another proposal, namely to have the client request the
> > > start of notifications (like you would do with RC and SSE). I do not
> buy the
> > > 80% solution argument for an excuse of poor protocol design.
> >
> > The other proposal is absolutely a valid way to do this.  And as Andy
> and others have pointed out, the current dynamic <establish-subscription>
> RPC can be kicked off by such a process.
> >
> > However the call flow has more error conditions.   As a result, three
> years ago during scoping of the current suite of IETF subscription drafts,
> this proposal was determined to be out-of-scope.  This decision was not
> necessarily a bad choice as I have seen proprietary non-NETCONF configured
> subscription deployments thrive without a publisher requesting that a
> client invoke the <establish-subscription>.
> >
> > As a result of the decision several years ago, no one has proposed an
> IETF standards based call flow to invoke a client based
> <establish-subscription>.  It would be excellent if someone wanted to
> propose a draft for this.
> >
> > > > I agree that the current protection could have an improved
> description.
> > > So I have placed the following text into the NETCONF-Notif security
> > > considerations section:
> > > >
> > > > " For a configured subscription, if NETCONF call home has been
> configured
> > > with the working credentials, yet that the receiver's NETCONF client
> > > implementation is both unable to process inbound notifications and
> unable
> > > to terminate a session receiving unwanted traffic, then the receiver
> may
> > > receive unwanted event records.  To minimize this risk, a publisher
> > > implementation should use dedicated call home connectivity port numbers
> > > and credentials specific to configured subscriptions.  This will
> minimize the
> > > chance that an unplanned NETCONF receiver will receive configured
> > > subscription notifications unexpectedly."
> > >
> > > Well, I would rather fix the issue than pushing the problem ultimately
> to
> > > operators.
> >
> > Your position is a valid one for sure.   I have not yet heard of
> operator wanting to attempt these more robust configuration protection
> mechanisms yet.  And as noted above, this is not a key use case for the
> deployments I am seeing yet.
> >
> > Eric
> >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   [phone]         <https://www.jacobs-university.de/<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-
> 2Duniversity.de_&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=
> 9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=PN9cAf8_
> 9XKIE3CIKONsYfaQZNHYnom2GY-4Ru1wZpc&s=mzX6_2ZrzEpIEW1D4vVLFrCNSlKInzy2cwB
> ddGrlbhg&e=>>
> >
> >
> >
> >
> >
> > _______________________________________________
> >
> > Netconf mailing list
> >
> > [e-mail]<mailto:[e-mail]>
> >
> > https://www.ietf.org/mailman/listinfo/netconf<https://
> urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
> mailman_listinfo_netconf&d=DwMDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=PN9cAf8_
> 9XKIE3CIKONsYfaQZNHYnom2GY-4Ru1wZpc&s=9Ys6soB849hZqMrZoA-
> PCyOMrNucuiZgMhIgoT8Tsbw&e=>
> >
> >
>