Last Call Review of draft-ietf-netconf-subscribed-notifications-23
review-ietf-netconf-subscribed-notifications-23-secdir-lc-lonvick-2019-03-28-00

Hello,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security 
area directors. Document editors and WG chairs should treat these 
comments just like any other last call comments.

The summary of the review is Ready With Nits.

This is not an area that I'm very familiar with so I skimmed the draft 
and reviewed the Security Considerations section. Overall, the document 
appears to be well constructed and well written.

RFC 3552 (BCP 72) is very thorough, but kind'a long. So my succinct 
thought about a Security Considerations section is that it should 
describe threats to the protocol and/or the implementation, and either 
ways to thwart them, or state that some threats are beyond the scope of 
the threat model. While the authors of the ID have been thorough in the 
rest of the specification, they may have gone a bit outside what is 
needed for a Security Considerations section. Below are some comments 
that the authors may wish to consider. And it's OK with me if they 
disregard my comments as I think the document is Ready anyway.

5.4. Security Considerations

CML>>> I'm not sure that the following paragraph is describing a threat 
or mitigation. While it is good information, perhaps it belongs 
elsewhere? Or, if there's a threat there, could it be specifically 
described?

    One subscription "id" can be used for two or more receivers of the
    same configured subscription.  But due to the possibility of
    different access control permissions per receiver, it cannot be
    assumed that each receiver is getting identical updates.

CML>>> In the following paragraph, I think you're describing a threat 
and a remedy tactic. Perhaps you could delineate them by adding, "To 
counter this," as the start to the second sentence.

    With configured subscriptions, one or more publishers could be used
    to overwhelm a receiver.  Notification messages SHOULD NOT be sent to
    any receiver which does not support this specification.  Receivers
    that do not want notification messages need only terminate or refuse
    any transport sessions from the publisher.

CML>>> Again, I'm not sure that the following paragraph is describing a 
threat or a remedy.

    When a receiver of a configured subscription gets a new
    "subscription-started" message for a known subscription where it is
    already consuming events, the receiver SHOULD retrieve any event
    records generated since the last event record was received.  This can
    be accomplish by establishing a separate dynamic replay subscription
    with the same filtering criteria with the publisher, assuming the
    publisher supports the "replay" feature.

The rest of the security considerations section is appropriately 
describing protections for data nodes that may be susceptible to misuse. 
Best regards, Chris