Re: [Netconf] Anyone want just Configured Subscriptions?

["Eric Voit (evoit)" <[e-mail]>]

> From: Martin Bjorklund, July 8, 2018 4:37 AM
> 
> "Eric Voit \(evoit\)" <evoit=[e-mail]> wrote:
> > > From: Kent Watsen, July 6, 2018 6:34 PM
> 
> [...]
> 
> > > >>  Regarding the 4th
> > > >>   bullet point following the first paragraph, I think that it is
> > > >>   sufficient to just identify that a suitable base identity must
> > > >>   be returned (i.e., lose the refs to Sections 2.4.6 and A.1).
> > > >
> > > > That is the way I initially had it.  Martin requested that these
> > > > be made explicit during his review.
> > >
> > > I don't agree.  YP is just one of potentially many (I exaggerate)
> > > layers on top of SN.
> 
> If you want to keep this error-app-tag string (I don't think it is necessary, since
> the identity is also sent in within the <error-info>), 

For NETCONF transport, the <error-info> is populated only when hints are sent.  For more on this, there is history in our December & January thread to morph the previous transport protocol agnostic error structures into something that more closely matched embedded NETCONF implementations.   E.g.,  
https://www.ietf.org/mail-archive/web/netconf/current/msg13954.html
https://www.ietf.org/mail-archive/web/netconf/current/msg13834.html 

It is true that we could changes things and always send the <error-info>.   But what we talked about then works fine.  I don't see what benefit a change buys us.

> then I think the document
> needs to clearly specify which identity to use for the different errors.
> 
> I agree with Kent that the reference to YANG push is not needed here, and
> should be removed.

Without explicitly what RPCs are permitted to have error info carried, any identity could be allowed to populate the error-app-tag or error-info.  I don't think this is what we want.

We all know that subscribed notifications has four RPCs which have error identities which need to be passed back.  But it is also true that yang-push has the resynch-subscription RPC.  This RPC two possible error identities which need to be passed back:
(1) <yang-push>:<no-such-subscription-resynch>
(2) <yang-push>:<synchronization-size>

Without the linkage to yang-push in this section, this connection is not made anywhere in the documents.

>  I do think the reference to SN is needed, and I think the
> explicit list of rpcs and base identities help.
> 
> Kent, do you think that this list is somehow incorrect or misleading?
> 
> > What other layer are you expecting?
> 
> Who knows?  I agree w/ Kent; it is a matter of getting the design right, even if
> we don't see more layers at the moment.

Other layers can easily be added.  New RPCs can easily bring along their error identities.   How this can be done is demonstrated in yang-push.

> > > We need to ensure the language allows for other layers to be defined
> > > in the future.  I imagine that there should be nothing special about
> > > YP as far as the notif drafts go.
> >
> > This does not precludes additional layers for being placed.  If an
> implementation doesn't need an RPC, it can safely ignore the identity.
> >
> > In the end, when the WG requested that we inherit embedded NETCONF and
> > RESTCONF error processing mechanisms, and this drove to the explicit
> > mappings.
> >
> > > >>   The 2nd paragraph seems to be defining a non-standard way to
> > > >>   encode identities (red flag).
> > > >
> > > > This also was at Martin's request.  It is not non-standard as it
> > > > simply describes the encoding of an error string.
> > >
> > > I see that error-app-tag is defined in RFC 6241 as a string, so
> > > maybe there is a basis for this, but note that identities are
> > > encoded differently for XML and JSON.  It seems like this draft
> > > could declare that the value must conform to type "identity"
> > > and then leverage existing encoding-specific rules.  What did Martin
> > > say?
> >
> > Per:
> > https://www.ietf.org/mail-archive/web/netconf/current/msg14345.html
> >
> >   "I think you should decide on one mechanism, and use it in both
> >   drafts (specifically, the error-app-tag handling.  BTW, *if* you
> >   decide to keep it, you need to clarify what "a string that
> >   corresponds to" means.  Maybe use the JSON encoding of identities in
> >   this case (<modname>:<identityname>))."
> >
> > This defined encoding works, and can be placed the same way into different
> types of error mechanisms.
> 
> Note my *if* above.  If we simply don't specify anything for the error-app-tag,
> both these issues are solved.

True.  But per earlier threads, what is proposed works.  And I think it a nice convention to only send error-info just when we are providing hints back.

Eric

> /martin
> 
> 
> 
> >
> > > >>   Section 10: the 1st paragraph is not a security consideration
> > > >>   (move to Section 5?).
> > > >
> > > > Moved into 5.2.
> > >
> > > Thanks.
> > >
> > >
> > > >>  The 2nd paragraph articulates a valid  concern, but it seems to
> > > >> apply to all transports (although  missing in the restconf-notif
> > > >> draft) and so should be moved  to the SN draft?
> > > >
> > > > As the mechanism for mitigating certain DDoS vectors is transport
> > > > specific, the transport drafts seemed a better place.
> > >
> > > The problem statement (1st sentence) is generic and should be moved
> > > to the SN draft.
> >
> > Section 10, paragraph 2, sentence #1 is context to set up the requirements in
> sentence 2 & 3.  So I replicated a NETCONF independent statement in SN:
> >
> > " For dynamic subscriptions, implementations need to protect against
> malicious or buggy subscribers which may send a large number "establish-
> subscription" requests, thereby using up system resources.  To cover this
> possibility operators SHOULD monitor for such cases and, if discovered, take
> remedial action to limit the resources used, such as suspending or terminating
> a subset of the subscriptions or, if the underlying transport is session based,
> terminate the  underlying transport session."
> >
> > > How to handle the issue in a generic way, if possible, should also
> > > be in the SN draft.  Here, the 2nd sentence seems transport-specific
> > > and the 3rd transport- independent.  However, I think that the 2nd
> > > or 3rd sentences could be stated better (and more generically) in
> > > the SN draft, something like this:
> > >
> > >   Operators SHOULD monitor for such cases and, if discovered,
> > >   take remedial action to limit the resources used, such as
> > >   suspending or terminating a subset of the subscriptions or,
> > >   if the underlying transport is session based, terminate the
> > >   underlying transport session.
> > >
> > >
> > > > If you are good with it staying as a transport mechanism, I will
> > > > add corresponding text to RESTCONF-Notif.
> > >
> > > I prefer a generic Security Consideration in the SN draft.
> >
> > Hopefully the text above gets us there.
> >
> > Eric
> >
> > > >>   The 3rd paragraph could be removed, since it
> > > >>   isn't for dynamic subscriptions.
> > > >
> > > > Yes.
> > > >
> > > > Eric
> > >
> > >
> > > Kent // contributor
> > >
> > >
> >
> > _______________________________________________
> > Netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf