Skip to content

Minutes 2017 12 20

Jump to bottom
ericvoit edited this page Dec 21, 2017 · 2 revisions
Meeting Materials Attending
(These notes) Tianran Zhou, Xufeng Liu, Eric Voit, Zhengguangying (Walker), Henk Birkholz, Igor

Summary of changes in drafts based on mailing list interactions

  • Eric reviewed changes. No objections. Note, see updated file here as I have separated the configured subscription state machine into two parts for simplified reading.

Attestation and signatures and bundles in draft-ietf-netconf-notification-messages

  • After Eric & Henk discussions, we are working one common header. We will decide later if a degenerate case to carry a single notification record provides efficiency.

        +--ro message-header
    |  +--ro message-time            yang:date-and-time
    |  +--ro message-id?             uint32
    |  +--ro message-generator-id?   string
    |  +--ro notification-count?     uint16
    +--ro notifications*
    |  +--ro notification-header
    |  |  +--ro notification-time         yang:date-and-time
    |  |  +--ro yang-module?              yang:yang-identifier
    |  |  +--ro yang-notification-name?   notification-type
    |  |  +--ro subscription-id*          uint32
    |  |  +--ro notification-id?          uint32
    |  |  +--ro observation-domain-id?    string
    |  +--ro notification-contents?   
    |  +--ro notification-footer!
    |     +--ro signature-algorithm    string
    |     +--ro signature-value        string
    |     +--ro integrity-evidence?    string
    +--ro message-footer!
       +--ro signature-algorithm    string
       +--ro signature-value        string
       +--ro integrity-evidence?    string

Open questions:

Based on what Andy was asking for in order to get some processing efficiency, should we have a separate container for each subscription in the list? Right now, we discover a new notification message every time we see a new notification-header. But is that too complicated, is it better to encapsulate? Should get an opinion from the NETCONF alias.

Alignment of I2NSF & YANG Push comparison (Henk)

I2NSF model should be updates to become a series of Notifications. Each of these notifications can fall under the bundled header listed above.

Future meetings

In 2 weeks

  • Framework concepts for ECA (Igor/Xufeng)

    • Produce discussion material on a Generalized Network Control Automation framework. Discussion material is preferable to a detailed specification at this time as there is a lot which is still moving.

  • Security & UDP Transport (Tianran)

    • What else is needed for defining the UDP. Can we start with defining the delta from the NETCONF bindings or HTTP2 bindings.
    • Call home considerations are needed for security as call home needs some selection for this scenario.

In 4 weeks

  • Multi linecard (Tiaran)
    • Next step: a technical specification for the various transactions previously identified as needed for the interaction model described in the draft.

6 Weeks+

  • Smartfilters (Alex)
    • Open Question: Do we include aggregation as part of the filtering? Said no before, but Henk thinks perhaps useful.
Clone this wiki locally