Re: [Netconf] Anyone want just Configured Subscriptions?

[Martin Bjorklund <[e-mail]>]

"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>), 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.  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.


> > 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.


/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