Re: [Netconf] mbj's WGLC review of yang-push-17

[Martin Bjorklund <[e-mail]>]

Hi,

Alexander Clemm <[e-mail]> wrote:
> Hi Martin,
> 
> thank you for your new suggestion - I will go through the occurrences
> of "push update" to clean up / clarify which ones refer to update
> record (respectively update) versus the notification.

Ok.

> Regarding your previous comments (or replies to my responses to your
> comments), indeed I did not add responses to all replies of yours and
> in the course missed two things; my apologies; please see <ALEX3>

I have trimmed the discussion to just the open issues:

> > > > > > o  3.9
> > > > > >
> > > > > >   The text says:
> > > > > >
> > > > > >    A publisher MAY choose reject an establish-subscription request
> > which
> > > > > >    selects non-existent or access-protected data.  In addition, a
> > > > > >    publisher MAY choose to terminate a dynamic subscription or
> > suspend a
> > > > > >    configured receiver when the authorization privileges of a
> > > > > >    receiver
> > > > > >    change, or the access controls for subscribed objects change.
> > > > > >    Such a
> > > > > >    capability enables the publisher to avoid having to support a
> > > > > >    continuous, and total filtering of an entire subscription's
> > > > > >    content.
> > > > > >
> > > > > >    In these cases above, the error identity "unchanging-selection"
> > > > > >    SHOULD be returned.
> > > > > >
> > > > > >   "the cases above" refers to (i) terminating a dynamic subscription,
> > > > > >   or (ii) suspend a configured receiver.   What does it mean to
> > > > > >   "return" an error identity when a subscription is terminated, or
> > > > > >   suspended?
> > > > > >
> > > > > >   Maybe you meant that the error identity "unchanging-selection"
> > > > > >   SHOULD be sent in an "subscription-terminated" notification or
> > > > > >   "subscription-suspended" notification, respectively.
> > > > > >
> > > > > >   If so, the "unchanging-selection" identity should probably also
> > > > > >   derive from "sn:subscription-suspended-reason".
> > > > > >
> > > > >
> > > > > <ALEX> Changed this section as follows:
> > > > > "A publisher MAY choose to reject an establish-subscription
> > > > > request which selects non-existent or access-protected data. In
> > > > > addition, a publisher MAY choose to terminate a dynamic
> > > > > subscription or suspend a configured receiver when the
> > > > > authorization privileges of a receiver change, or the access
> > > > > controls for subscribed objects change.  As reason, the error identity
> > "unchanging-selection" SHOULD be returned.
> > > > > Such a capability enables the publisher to avoid having to support
> > > > > continuous and total filtering of a subscription's content for
> > > > > every update record.  It also reduces the possibility of leakage
> > > > > of access-controlled objects."
> > > > > </ALEX>
> > > >
> > > > This new text doesn't address my concern, which is the usage of the
> > > > term "return".  How can a server "return" anything when a
> > > > subscription is terminated?
> > > >
> 
> <ALEX3> Ah, ok, I overlooked this one.  So, when rejecting, we can
> return the error identity.  When the subscription is terminated, a
> notification "subscription-terminated" is sent (per the Subscribed
> Notifications draft) that can include ungaging-selection as its
> reason. I will make this explicit in -19.
>   </ALEX3>

Good.

> > > > > > o  3.11.1
> > > > > >
> > > > > >   The text says:
> > > > > >
> > > > > >    It is not
> > > > > >    required to merge pending update messages.
> > > > > >
> > > > > >   This can be read as indicating that a server MAY merge pending
> > > > > >   update messages.  I assume that it should say that pending update
> > > > > >   messages MUST NOT be merged.
> > > > >
> > > > > <ALEX> Hmm.  I am not sure I agree.  The server is not required to
> > > > > merge pending update messages - i.e. can send multiple messages
> > > > > each with a separate update record.  However, there is no reason
> > > > > to preclude that they could be combined.  So, I don't think an
> > > > > update is needed here.
> > > > > </ALEX>
> > > >
> > > > So you say that the text means that the server MAY merge pending
> > > > update messages in this case?  If so, I think you should update the
> > > > text so that this is clear.
> > > >
> 
> <ALEX3> OK, how about saying "The server MAY (but does not have to)
> merge pending update messages". </ALEX3>

Well, the term "update message" is not defined, so it shouldn't be
used.  Presumably you mean "update record".

But I still don't really understand how this is supposed to work.  The
push-code in the publisher creates an update record A and hands it
over to the transport layer, where it is queued:

   It is perfectly acceptable to have a series of "push-change-
   update" notifications (and even "push update" notifications) serially
   queued at the transport layer awaiting transmission.

Then the push-code in the publisher creates another update record B
and hands it over to the transport layer.

Are you saying that the transport layer code now can merge these two
update records into a single record?  So if record A had "create foo,
delete bar" and record B had "delete foo", there would be a single
record with "delete bar, delete foo"?

If two records are merged, what happens to the idea of using the
'patch-id' as an indication of lost records?



/martin