Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-24: (with DISCUSS and COMMENT)

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

> From: Benjamin Kaduk, May 1, 2019 1:13 PM
> 
> On Wed, May 01, 2019 at 05:09:11PM +0000, Eric Voit (evoit) wrote:
> > > From: Benjamin Kaduk,  May 1, 2019 11:37 AM
> > >
> > > On Wed, May 01, 2019 at 05:48:45AM +0000, Eric Voit (evoit) wrote:
> > > > Hi Benjamin,
> > > >
> > > > > From: Benjamin Kaduk, April 30, 2019 5:11 PM
> > > > >
> > > > > Benjamin Kaduk has entered the following ballot position for
> > > > > draft-ietf-netconf-subscribed-notifications-24: Discuss
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > DISCUSS:
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > >
> > > > > Thanks for this document; I just have a few minor "housekeeping"
> > > > > points that should get resolved before publication.  (Please
> > > > > also note the substantive comments in the COMMENT section as
> > > > > well, particularly those relating to the transport requirements
> > > > > and security considerations.)
> > > > >
> > > > > I'm not sure that we state clearly enough what is required to
> > > > > have a specification for a transport for notifications.
> > > > > Specifically (see COMMENT), in the module we seem to say that
> > > > > the specification must indicate what the default encoding is to
> > > > > be used if not otherwise specified, but that's not enumerated as
> > > > > a requirement on such a specification
> > > anywhere I see.
> > > >
> > > > I provide more info in-line below with your comment.  But here is a
> summary...
> > > >
> > > > For dynamic subscriptions, the default encoding is normally
> > > > specified by
> > > whatever is used within the establish-subscription RPC.  So there is
> > > not a need for a default here as the subscriber has already encoded
> > > in the RPC what it wants.
> > > >
> > > > For configured subscriptions, the default (and only) encoding is
> > > > often driven by
> > > the transport selection.  And this is defined by existing transport
> > > RFCs which themselves define supported encodings (e.g., "NETCONF +
> > > XML" , "RESTCONF + JSON").
> > > >
> > > > But encodings can vary (e.g., the use of CBOR within
> > > > draft-birkholz-yang-push-
> > > coap-problemstatement).  Supporting this need is the purpose of the identity
> > > "configurable-encoding" in the YANG model.   And this identity does say that
> > > "Further details for any specific configurable encoding would be
> > > explored in a transport document based on this specification."  I
> > > guess this information could be repeated as a separate requirement
> > > in Section 5.3 if you feel this is insufficiently defined.
> > >
> > > I'm mostly concerned about the case of configured subscriptions and
> > > future extensibility.  If someone wants to make a new "QUIC + CBOR"
> > > transport, do we have a clear list of what details that specification needs to
> provide?
> > > (From my reading of this document, there should be an explicit "this
> > > is the default encoding" statement, even if there is only one
> > > encoding specified in the transport specification.)
> >
> > I have added the following statement to Section 5.3...
> > "A specific transport specification MUST identity any encoding supported.
> Where a configured subscription's transport allows different encodings, the
> specification MUST identify the default       encoding."
> >
> >
> > > > > I also think that we could
> > > > > probably require (as opposed to "highly recommend" in the
> > > > > current security
> > > > > considerations) that the transport provide message
> > > > > confidentiality and integrity protection.
> > > >
> > > > I for sure like the idea of encryption. And I absolutely like the
> > > > idea of
> > > signatures too.  However several years ago on based on work with
> > > MSDC / cloud providers desiring telemetry, there were requests for
> > > deployments where the volume of telemetry generated could overwhelm the
> CPU of the host router.
> > > And as the telemetry was being delivered within a fully protected
> > > MSDC domain/environment, these MSDC providers said they wanted *all*
> > > the router data more than they needed message confidentiality and integrity
> protection.
> > > I.e., the wanted to have more data rather than being constrained the
> > > host CPU doing functions which reduced the volume of data being delivered.
> > > >
> > > > So personally, I want low volume telemetry with full security
> > > > protections
> > > applied.  But by leaving it at "highly recommend" we don't
> > > unintentionally inhibit applicability to MSDC implementations in a
> > > protected domain.  They explicitly said they didn't want it.
> > >
> > > We do sometimes have cases where we leave an opening for people to
> > > assert that the physical security of their network provides
> > > "equivalent protection" to cryptographic confidentiality/integrity
> > > protection, if we want to try to wordsmith something.  But, given
> > > the above, I won't push very hard on this front.
> >
> > Ok, will leave as is.
> >
> > > > > I'm also unsure that I properly understand the use of the "reset"
> > > > > RPC -- if it has no effect when transit connectivity already
> > > > > exists, then what entity is going to call "reset" in the case of
> > > > > publisher timeout when
> > > trying to reach a receiver?
> > > > > Surely not the publisher itself, since that would just be
> > > > > publisher-internal functionality with no need for an external-facing RPC.
> > > >
> > > > The reset RPC of section 2.5.5 is YANG model exposed operational
> > > > knob based
> > > on the YANG 1.1 language construct "action":
> > > > https://tools.ietf.org/html/rfc7950#section-7.15
> > > >
> > > > An operational interface can call this action.  I.e., an entity
> > > > with the proper
> > > administrative privileges can access "reset".    This means a REST interface
> could
> > > be exposed upon a controller for that publisher.  And when somebody
> > > find that the subscription isn't responsive (for a variety of
> > > reasons) that REST interface can be called, and the publisher can
> > > start trying to make connections (such as RFC 8071 call home connections)
> to a receiver.
> > >
> > > Okay, thanks for helping me out here; consider this one resolved.
> > >
> > > >
> > > > > I'm also a little unclear on the mechanics of the list of
> > > > > subscriptions described in Section 3.3.  Does it provide a way
> > > > > for a low-privilege client (that can only access one or a
> > > > > handful of the
> > > > > subscriptions) to enumerate all subscriptions that exist,
> > > > > including subscriptions used by high-privilege clients?  If so,
> > > > > we may want to think about some security considerations text to
> > > > > that effect; if not, we may want to say that the access-control
> > > > > will limit which leafs are
> > > visible to some clients.
> > > >
> > > > Your functional requirements completely valid.  I believe they are
> > > > covered by a
> > > set of other YANG RFC which dictate who/what can access various
> > > elements of YANG data.  Good example documents to look at here are ones
> like:
> > > >
> > > > RFC-8341 - Network Configuration Access Control Model
> > > >
> > > > An understanding of these documents are assumed, and listed in
> > > > places like the
> > > security considerations in Section 5.4.
> > >
> > > I admit to having not fully absorbed the NACM, and given the number
> > > of documents I have left to ballot on this week, I'll take your word
> > > that it's covered well enough there.
> > >
> > > > > Finally, we have a few instances of "leaf filter-failure-hint"
> > > > > that's of type "string", providing
> > > > >              "Information describing where and/or why a provided filter
> > > > >               was unsupportable for a subscription."; I don't
> > > > > understand why it's a string as opposed to some form of
> > > > > machine-readable data.  Is it supposed to be human-readable?
> > > > > Does that
> > > bring in any internationalization considerations?
> > > >
> > > > There are many reasons why a filter might fail.  The authors
> > > > didn't believe that
> > > there was enough operational experience to sufficiently document the
> > > universe of failure types across the set of interested parties.  As
> > > a result, the option seemed to be to provide no guidance on the
> > > failure reason, or to let the vendors provide some guidance (albeit
> > > just a 'string').  So at this point with the specification, it would
> > > be up to the vendor to determine whether it is human readable, or whether
> internationalization considerations should be covered.
> > > Hopefully with enough deployments this might be revisited at a future date.
> > >
> > > We should probably think about saying something about how its syntax
> > > and semantics are implementation-specific, then -- there doesn't
> > > seem to be real guidance for how to use it, at present.
> >
> > Added text in leaf to clarify this approach...
> >
> >       leaf filter-failure-hint {
> >         type string;
> >           description
> >             "Information describing where and/or why a provided filter
> >              was unsupportable for a subscription. The syntax and
> >              semantics of this hint are implementation-specific.";
> >       }
> >
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > COMMENT:
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > >
> > > > > Section 1.3
> > > > >
> > > > >    Also note that transport specific transport drafts based on this
> > > > >    specification MUST detail the life cycle of dynamic subscriptions, as
> > > > >    well as the lifecycle of configured subscriptions (if supported).
> > > > >
> > > > > I'm not sure I understand what additional specification is
> > > > > needed for the lifecycle of configured subscriptions -- doesn't
> > > > > the previous text tightly tie their lifecycle to the presence of
> > > > > configuration in the
> > > configuration datastore?
> > > >
> > > > For the most part it does.  However there is a relationship for
> > > > exactly when to
> > > establish transport connectivity based on the state of each receiver
> > > of a configured subscription.
> > > >
> > > > As an example of what should be specified, see Section 5.2 of
> > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-
> > > > noti fications/10/ Here you can see how NETCONF call home is
> > > > invoked at the proper points in the configured subscription state
> > > > machine.
> > >
> > > Ah, thanks for the pointer.
> > >
> > > > > nit: please be consistent about "life cycle" vs. "lifecycle" throughout.
> > > >
> > > > Fixed nit to "lifecycle".
> > > >
> > > > > Section 2.1
> > > > >
> > > > >    An event stream is a named entity on a publisher which exposes a
> > > > >    continuously updating set of YANG encoded event records.
> > > > > [...]
> > > > >
> > > > > nit: I don't think "YANG encoded" is well-defined (here and
> > > > > below), in that YANG structures generate data models but can be
> > > > > encoded into various formats (like XML and JSON).
> > > >
> > > > This is true.  I made the two occurrences of "YANG encoded" into
> > > > "YANG
> > > defined".
> > > >
> > > > > Section 2.3
> > > > >
> > > > >    If the publisher supports the "dscp" feature, then a subscription
> > > > >    with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP
> > > > >    marking being placed within the IP header of any resulting
> > > > >    notification messages and subscription state change notifications.
> > > > >    Where TCP is used, a publisher which supports the "dscp" feature
> > > > >    SHOULD ensure that a subscription's notification messages are
> > > > >    returned within a single TCP transport session where all traffic
> > > > >    shares the subscription's "dscp" leaf value.  Where this cannot be
> > > > >    guaranteed, any "establish subscription" RPC request SHOULD be
> > > > >    rejected with a "dscp-unavailable" error
> > > > >
> > > > > I can't decide whether we need to be more explicit in the second
> > > > > and/or third sentences that this remains contingent on the
> > > > > subscription in question having a "dscp" leaf.
> > > >
> > > > The sentences were already long, it feels to me like it would be
> > > > more
> > > confusing to put in more words here.
> > > >
> > > > > nit: end sentence with a full stop
> > > >
> > > > Period added.
> > > >
> > > > > I share the TSV-ART reviewer's confusion about how the weighting
> > > > > (as well as
> > > > > DSCP) functionality is intended to work.
> > > >
> > > > Short answer:  Earlier versions of this draft made explicit
> > > > parallels of the
> > > weighting method to HTTP2 RFC-7450 section 5.3.2.  The operation of
> > > weighting is exactly the same HTTP2 dependency weighting.  There is
> > > additional definition of how this is supposed to work in Section 4
> > > of draft-ietf-netconf-restconf-notif (which is also currently up for review).
> > > >
> > > > Long answer: TSV-ART is absolutely correct that a publisher might
> > > > generate a
> > > lot of traffic.  In many ways, high traffic volumes would be a successful
> outcome
> > > for this work.   As a result, mitigating different dimensions of this volume risk
> has
> > > been a design goal since this effort’s inception.  And this is the
> > > reason robust QoS mechanisms were included.  This includes both DSCP and
> weighting.
> > > >
> > > > Here is a quick summary of some QoS mechanisms available in this draft...
> > > >
> > > > 1. The publisher is allowed to decline a dynamic subscription.
> > > > One of these
> > > reasons is that the incremental traffic generated by a particular
> > > incremental subscription will be too high.  There are errors back to
> > > the subscriber indicating this condition exist.
> > > > 2. A publisher can suspend any subscription for capacity reasons,
> > > > and a
> > > receiver must be able to gracefully accept this suspension.
> > > > 3. Much like with HTTP2 streams, higher priority subscriptions
> > > > intended for a
> > > particular receiver can be dequeued first from a publisher.
> > > > 4. Much like with HTTP2 streams, proportional subscription
> > > > dequeuing
> > > intended for a particular receiver can be performed a publisher.
> > > > 5. DSCP markings can be placed on subscribed data.
> > > > 6. Mechanisms for detecting and reacting to different types of
> > > > subscribed data
> > > loss have been embedded.
> > > > 7. Methods have been included to ensure a configured receiver “ok’s”
> > > > information push before subscribed data is sent. (This should
> > > > reduce one DDoS
> > > vector.) 8. Keep alive mechanisms are established for different
> > > transport types, so that subscribed data isn’t being sent when the is no
> receiver listening.
> > > >
> > > > Mechanism (4) is in question here.   As defined by draft-ietf-netconf-
> restconf-
> > > notif, this is supposed to work identically to HTTP2 RFC-7450 section 5.3.2.
> > > However there were WG members who did not want to include a
> > > functional requirement normative reference to that HTTP2 transport
> > > in this document however.  Therefore the reference to HTP2 was removed.
> > > >
> > > > In the end, I don't think we can afford to get rid of support for
> > > > (4) from the
> > > specification.   This weighting capability is quite powerful, and can easily be
> > > added to GRPC based subscription alternatives.
> > >
> > > I don't think I was trying to suggest removing the mechanism entirely.
> > > What you've written here includes a mental model of having local
> > > queues of messages that get dequeued according to a specific
> > > algorithm, and the weights influencing the rate of dequeuing across
> > > queues; that mental model (combined with the knowledge that larger
> > > weight values get more traffic
> > > faster) gives me the picture I wanted for "how it's supposed to work".
> > > Maybe we could distill that down a bit and put it in the draft, as
> > > the current text had some level of "magic occurs here", to me.
> >
> > I am hoping to leave things as they are for now.  Basically the magic that
> occurs can be gleaned from Section 4 of draft-ietf-netconf-restconf-notif.   And
> nobody in the NETCONF world is likely to implement this type of Dequeuing, so
> they shouldn't have the extra text in the base specification trip them up..
> >
> > > > > Section 2.4.2.1
> > > > >
> > > > >    Replay provides the ability to establish a subscription which is also
> > > > >    capable of passing recently generated event records.  In
> > > > > other words,
> > > > >
> > > > > nit/editorial: this language could probably be more clear about
> > > > > "recently generated" meaning "in the past", that is, records for
> > > > > events that have already happened when the subscription is established.
> > > >
> > > > Tweaked to "event records generated in the recent past"
> > > >
> > > > > Section 2.4.3
> > > > >
> > > > >    any number of times.  Dynamic subscriptions can only be modified via
> > > > >    this RPC using a transport session connecting to the subscriber.
> > > > > If
> > > > >
> > > > > nit(?): is this more readable as "connecting to" or "connecting from"
> > > > > the subscriber?  (The same wording shows up throughout the
> > > > > document, but I'll try to just comment once.)
> > > >
> > > > I expect that it should be clear enough either way.  I believe
> > > > leaving the current
> > > text should not impact implementations.
> > > >
> > > > > Section 2.4.5
> > > > >
> > > > > Is there any distinction between "killing a subscription" and
> > > > > "administratively deleting a subscription"?  It's unclear to me
> > > > > that we need the extra connotations of the word "kill", here.
> > > >
> > > > We chose to use a different RPC name so that administrative access
> > > > control
> > > permissions differences between the kill-subscription and
> > > delete-subscription would be explicit and obvious.  And once we had
> > > a new RPC name, it seemed easier for the reader to continue using the "kill"
> word for that RPC.
> > >
> > > In vacuum, "admin-delete-subscription" seems like a fine name, to
> > > me.  But this is a non-blocking comment so I'll stop pushing now.
> > >
> > > > > Section 2.4.6
> > > > >
> > > > >    As a result of this mixture, how subscription errors are
> > > > > encoded
> > > > >
> > > > > nit: "mixture" doesn't seem like the right word to me; "variety"
> > > > > or "varied population" are the first alternatives that come to
> > > > > mind, though they are not perfect either.
> > > >
> > > > Changed to 'variety'.
> > > >
> > > > > Is there some sort of "access denied" error that could result
> > > > > from
> > > > > kill- subscription RPCs?  (The table/artwork only lists
> > > > > "no-such-subscription".)
> > > >
> > > > Access denied when an RPC fails access control is part of the base
> > > > transport
> > > error types for the RPC.   I.e., transports like NETCONF and RESTCONF
> already
> > > have non-subscription-specific errors like this one already covered.
> > >
> > > Ah, of course, and we require processing of transport-level errors
> > > before these ones, so it all works out fine.
> > >
> > > > > Section 2.5
> > > > >
> > > > > It's interesting to see a slight dichotomy between dynamic and
> > > > > configured subscriptions, in that (IIUC) for dynamic
> > > > > subscriptions, a modification event un- suspends a subscription
> > > > > immediately, but for configured subscriptions the publisher
> > > > > seems to have some latitude to retain the subscription in the
> > > > > suspended state for some time before un-suspending it and
> > > > > sending the "subscription-modified" state
> > > change message.
> > > > >
> > > > >                  In this case, a separate dynamic subscription can be
> > > > >    established to retransmit the missing event records.
> > > > >
> > > > > Do you want to put in a pointer to replay-start-time here?
> > > >
> > > > I thought getting to that level of detail in the intro was
> > > > confusing for this intro
> > > section.
> > >
> > > Okay.  (Maybe a parenthetical "replay" as a search term would help
> > > without being confusing, but entirely your call.)
> >
> > I will leave as-is.
> >
> > > > > Section 2.5.1
> > > > >
> > > > >          Event records are only sent to active receivers.  Receivers of
> > > > >    a configured subscription remain active if both transport
> > > > >    connectivity can be verified to the receiver, and event records are
> > > > >    not being dropped due to a publisher buffer overflow.  [...]
> > > > >
> > > > > nit: "buffer overflow" is a technical term in security circles
> > > > > indicating a potentially exploitable security flaw; would
> > > > > "publisher buffer capacity being reached" be an acceptable
> > > > > substitute (here and
> > > below)?
> > > >
> > > > Change made
> > > >
> > > > > Section 2.7.7
> > > > >
> > > > >    This notification indicates that all of the event records prior to
> > > > >    the current time have been passed to a receiver.  It is sent before
> > > > >    any notification message containing an event record with a timestamp
> > > > >    later than (1) the "stop-time" or (2) the subscription's start time.
> > > > >
> > > > > nit(?): this text seems to imply that a notification message
> > > > > with a timestamp later than the "stop-time" might actually be
> > > > > sent, which IIUC is
> > > not the case.
> > > >
> > > > You are correct that it is not sent.  But the event record does
> > > > exist on the
> > > stream.
> > > >
> > > > I think it obvious, but if you want I could add the following
> > > > sentence to the end
> > > of the subsequent paragraph.  "If a stop-time has been exceed during
> > > replay, no subsequent event records are sent following the sending
> > > of a "replay- completed" notification."
> > >
> > > I don't think there's a need to add that sentence, but thanks for offering.
> > >
> > > >
> > > > > Section 2.9
> > > > >
> > > > > nit: the name "supports-vrf" for the feature doesn't really
> > > > > parallel the other feature names, that don't include a word like "support"
> > > > > and rather just describe the actual feature.
> > > >
> > > > This is true.  Several years ago when someone proposed this name,
> > > > there was
> > > a reason.  But I can't remember what it is right now.  So hopefully
> > > we can leave it so as not to break someone's thinking.
> > > >
> > > > > Section 3.1
> > > > >
> > > > > Is there any risk of collision in event stream names from
> > > > > vendor-specific streams?  (We don't seem to create an IANA
> > > > > registry for them, for example.)
> > > >
> > > > In theory yes.  But it has not proven to be an issue with RFC-5277
> > > > streams, so it
> > > doesn't seem worth it to do something new now.   So in this document, we
> have
> > > one IETF stream "NETCONF" defined in Section 2.1.  Hopefully it is enough to
> > > hard-code this.   We can always revisit if IETF groups want to start defining
> > > streams
> > > >
> > > > > Section 4
> > > > >
> > > > >    identity subscription-suspended-reason {
> > > > >       description
> > > > >        "Problem condition communicated to a receiver as part of a
> > > > >        'subscription-terminated' notification.";
> > > > >    }
> > > > >
> > > > >    identity subscription-terminated-reason {
> > > > >       description
> > > > >        "Problem condition communicated to a receiver as part of a
> > > > >        'subscription-terminated' notification.";
> > > > >    }
> > > > >
> > > > > Are these descriptions supposed to be the same?
> > > >
> > > > Good catch.   Fixed the 'subscription-suspended' description.
> > > >
> > > > >    identity configurable-encoding {
> > > > >      description
> > > > >        "If a transport identity derives from this identity, it means
> > > > >         that it supports configurable encodings.  An example of
> > > > > a [...]
> > > > >
> > > > > Is it intended that such future transports (or future
> > > > > encodings?) will derive from both this and the normal base identity (i.e.,
> "transport")?
> > > > > I guess I'm asking why this identity does not derive from the
> > > > > corresponding base, but that's just a style question and not
> > > > > really a protocol matter, making this question a side note.
> > > >
> > > > Yes.  Future identities can derive from configurable-encoding
> > > >
> > > > >      leaf weighting {
> > > > >        if-feature "qos";
> > > > >        type uint8 {
> > > > >           range "0 .. 255";
> > > > >        }
> > > > >        description
> > > > >          "Relative weighting for a subscription. Allows an underlying
> > > > >           transport layer perform informed load balance allocations
> > > > >           between various subscriptions";
> > > > >        reference
> > > > >          "RFC-7540, section 5.3.2";
> > > > >
> > > > > Do we want to chase the reference for readers and say that
> > > > > larger weights get more resources?
> > > >
> > > > I put in "Larger weights get more resources." as sentence two of
> > > > the
> > > description.
> > > >
> > > > >      leaf encoding {
> > > > >        when 'not(../transport) or derived-from(../transport,
> > > > >        "sn:configurable-encoding")';
> > > > >        type encoding;
> > > > >        description
> > > > >          "The type of encoding for notification messages.   For a
> > > > >          dynamic subscription, if not included as part of an establish-
> > > > >          subscription RPC, the encoding will be populated with the
> > > > >          encoding used by that RPC.  For a configured subscription, if
> > > > >          not explicitly configured the encoding with be the default
> > > > >          encoding for an underlying transport.";
> > > > >
> > > > > Where is the default encoding for an underlying transport specified?
> > > > > Section 5.3 does not seem to say that a transport specification
> > > > > must provide this information, nor does Section 1.3 (which
> > > > > mentions that transport specifications must detail the lifecycle
> > > > > of dynamic subscriptions), nor does Section 2.5.7 (that
> > > > > discusses the need for a separate model augmenting
> > > > > /subscriptions/subscription/receivers/receiver
> > > > > to provide transport details).
> > > >
> > > > For many transports, the encoding is redundant information.  The
> > > > reason is that transport RFCs themselves define supported
> > > > encodings (e.g., "NETCONF + XML" , "RESTCONF + JSON").  And WG
> > > > members who built those transport RFCs did not want to allow
> > > > operators to misconfigure anything here.  (As an aside, this
> > > > desire to significantly reduce the opportunity for misconfiguration is what
> drove the interesting 'when'
> > > > statement above.)
> > > >
> > > > But encodings can vary.  This is the purpose of the identity
> > > > "configurable-
> > > encoding" in the YANG model.   And this identity does say that "Further
> details
> > > for any specific configurable encoding would be explored in a
> > > transport document based on this specification."  I guess this
> > > information could be repeated in Section 5.3 if necessary.
> > >
> > > I think that duplication would be my preference, to get things
> > > consolidated in one place.
> >
> > Per above in the discuss, text added to 5.3.
> >
> > > > >        choice notification-message-origin {
> > > > >          if-feature "configured";
> > > > >          description
> > > > >            "Identifies the egress interface on the publisher from which
> > > > >             notification messages are to be sent.";
> > > > >
> > > > > nit: given the address-originated case, perhaps "the egress interface"
> > > > > is not quite correct anymore.
> > > >
> > > > Every alternative I come up with seems more problematic.   I believe
> readers
> > > should be able to understand based on the cases below.
> > >
> > > (I don't have any better suggestions, either.)
> > >
> > > > >                enum connecting {
> > > > >                  value 3;
> > > > >                  if-feature "configured";
> > > > >                  description
> > > > >                    "A subscription has been configured, but a
> > > > >                    'subscription-started' subscription state change
> > > > >                    notification needs to be successfully received before
> > > > >                    notification messages are sent.
> > > > >
> > > > > nit: successful receipt happens on the receiver but sending
> > > > > happens on the publisher, so there's a bit of a mismatch in the
> > > > > sentence subject here.  Perhaps we could talk about
> > > > > "successfully sent" state-changes
> > > to resolve things.
> > > >
> > > > This wording is as intended.  Basically it is highly desirable for
> > > > configured receivers will need to acknowledgement of successful
> > > > receipt of a "subscription-started" before sending event records.
> > > > This helps prevent DDOS attacks.  The mechanism for gaining an
> > > > acknowledgement varies by transport.  As an example of what we
> > > > have been thinking about here, see
> > > >
> > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-notif
> > > > /04/
> > > Section 3.1.2
> > > > Hopefully this type of mechanism will be revived in future drafts.
> > >
> > > I agree that getting explicit acknowledgment of delivery is highly
> > > desirable; my qualm here is solely about the grammar of the sentence.
> > > Does it preserve the desired meaning to replace "successfully received"
> > > with "successfully acknowledged" (or "successfully received and
> > > acknowledged")?
> >
> > I would love to have had acknowledged.  However I have heard from
> implementers that NETCONF is not as robust in this way as HTTP.  And
> acknowledged might imply things to developers they might not be able to
> deliver.
> >
> > > > >              config false;
> > > > >              mandatory true;
> > > > >              description
> > > > >                "Specifies the state of a subscription from the
> > > > >                perspective of a particular receiver.  With this info it
> > > > >                is possible to determine whether a subscriber is
> > > > >                currently generating notification messages intended for
> > > > >                that receiver.";
> > > > >
> > > > > nit: is it the subscriber that is generating messages or the publisher?
> > > >
> > > > Good catch.  Changed to publisher.
> > > >
> > > > > Section 5.3
> > > > >
> > > > >    A secure transport is highly recommended and the publisher MUST
> > > > >    ensure that the receiver has sufficient authorization to perform the
> > > > >    function they are requesting against the specific subset of content
> > > > >    involved.
> > > > >
> > > > > "secure transport" usually means that it provides message
> > > > > confidentiality, integrity protection, and source authenticity
> > > > > (akin to the
> > > mutual authentication).
> > > > > This is qualitatively different from implementing authorization
> > > > > checks, and it's surprising to see them squashed into the same sentence.
> > > >
> > > > Tweaked to "A secure transport is highly recommended.  Beyond
> > > > this, the
> > > publisher MUST".
> > > >
> > > > > Do we want to say anything about discovery for support of new
> > > > > transports, and what workflow would be used to negotiate the use
> > > > > of a new
> > > transport?
> > > >
> > > > Not at this point.
> > >
> > > Okay.
> > >
> > > > > Section 5.4
> > > > >
> > > > > I can think of a couple other considerations to mention here:
> > > > >
> > > > > - Using DNS names for receiver "name" lookup can cause situations
> where
> > > > >   the name resolves differently on the publisher and subscriber, so the
> > > > >   recipient would be different than expected.
> > > > >
> > > > > - Using the publisher's boot time for deduplication protection on
> > > > >   replayed messages introduces a dependency on accurate time.  We
> don't
> > > > >   have a great secure time story at present, so this is more of a
> > > > >   "beware of risk" situation than something we can mitigate, but it does
> > > > >   seem that an attacker that could (e.g.) spoof the NTP traffic to the
> > > > >   publisher on boot could cause it to send duplicate notifications to
> > > > >   recipients that requested historical data.
> > > >
> > > > I tweaked and inserted the two paragraphs from you...
> > > >
> > > > "Using DNS names for configured subscription receiver "name"
> > > > lookup can
> > > cause situations where the name resolves unexpectedly differently on
> > > the publisher, so the recipient would be different than expected."
> > > >
> > > > "Using the publisher's boot time for deduplication protection on
> > > > replayed
> > > messages introduces a dependency on accurate time."
> > >
> > > Can we also say something like "An attacker that can cause the
> > > publisher to use an incorrect time can induce message replay by
> > > setting the time in the past, and introduce a risk of message loss by setting
> the time in the future"?
> >
> > Text you suggest above has been inserted instead of " Using the publisher's
> boot time for deduplication protection...".
> >
> > > >
> > > > > Some other comments on what's already there (which is pretty
> > > > > good; thanks for
> > > > > it!) follow.
> > > > >
> > > > >    Container: "/filters"
> > > > >
> > > > >    o  "stream-subtree-filter": updating a filter could increase the
> > > > >       computational complexity of all referencing subscriptions.
> > > > >
> > > > >    o  "stream-xpath-filter": updating a filter could increase the
> > > > >       computational complexity of all referencing subscriptions.
> > > > >
> > > > > Do we want to say anything about modifying either of these
> > > > > causing the set of notifications delivered to recipients to
> > > > > shrink (or become
> > > unmanageably large)?
> > > > > I guess it may not be necessary, since the recipient gets a
> > > > > notification about the modification that includes the details of the filter.
> > > >
> > > > Yes, that was the thinking.
> > > >
> > > > >    Container: "/subscriptions"
> > > > >
> > > > >    o  "excluded-event-records": leaf can provide information about
> > > > >       filtered event records.  A network operator should have
> > > > >       permissions to know about such filtering.
> > > > >
> > > > > To be clear, this is event records filtered either via explicit
> > > > > filter or via access control restrictions.
> > > >
> > > > Yes.
> > >
> > > I think that the semantic difference is worth noting.
> > >
> > > > > Specifically, it can allow a receiver to learn that there exists
> > > > > access controls that deny it access to some data, in the case
> > > > > when they did not apply any filtering rules explicitly.
> > > >
> > > > Yes.
> > > >
> > > > >This potential for information leakage (of the  existence of
> > > > > ACLs) should be mentioned explicitly.
> > > >
> > > > Added the sentence: "Improper configuration could provide a
> > > > receiver with
> > > information leakage consisting of the dropping of event records."
> > >
> > > Can I counter-propose: "Improper configuration could allow a
> > > receiver to learn that event records were dropped due to an ACL when
> > > the existence of that ACL would otherwise be transparent."
> > >
> > > >
> > > > > Appendix A
> > > > >
> > > > > This example transport module does not specify the life cycle of
> > > > > dynamic subscriptions per Section 1.3, and a couple other things
> > > > > required from a transport module specification.  Perhaps we are
> > > > > okay claiming that since this is just an example YANG model and
> > > > > not a full transport example, the omission is okay, but it may
> > > > > be worth mentioning
> > > the omission for clarity.
> > > >
> > > > I added as the second sentence
> > > > " This example is not intended to be a complete transport model."
> > > >
> > > > Thanks again for the review, it was excellently done.
> > >
> > > And thanks for the clear explanations of the parts that I didn't
> > > understand, it was very helpful to me.
> >
> > No problem.  This thread has been good for me too.  I will post v25 as soon as
> you give the ok.
> 
> Please go ahead and post v25.

Posted

-Eric

> Thanks,
> 
> Ben