Subject: [i2rs] Minutes of January 8th interim

From: "Susan Hares" <[email-masked]>
Date: Thu, 8 Jan 2015 15:12:18 -0500

This is a resend of Jeff’s minutes for today’s interim. 

Sue 

2RS interim 2014-01-08

Attendees:

Jeff Haas

Susan Hares

Chodorek ?

Dean Bogdanovic

Ignas Bagdonas

Dhruv Doty

Amit Dass

Don Fedyk

Joe Clark

Gonzalo Salgueiro

Sriganesh Kini

Jürgen Schönwälder

Jie Dong

Alexander Clemm

Alia Atlas

———

Document status and design teams

Need to review security directorate feedback on architecture.

Need to get the documents to the 

Joe will be giving us an update on the traceability document.

Sue will provide rib-info model update.  No update ready for today.

Problem statement: received directorate feedbacks - that has been integrated
and will be sent out shortly.

Architecture draft: small comments from various people, integrated, but need
to address security directorate comments.  

Charter needs to be revised after problem statements and architecture
drafts.

Security issues:

Questions [slides]

Ignas: On Q1 next steps - are you talking about general protocol
requirements or just security review comments?

Sue: These are working group decisions.  Need to look at netconf or restconf
with features added to either.  

Ignas: The way I read the security directorate comments is that they are
concerned about slightly different things. Not netconf, etc. Separate
signaling protocol, they are concerned about the transport issues.

Sue: You think they may be asking about the content of the protocol?

Ignas: Not that missed something. Two orthogonal aspects. Restconf can run
over TCP and others. Security directorate is asking about transport
security.

Jeff: we are providing requirements for what we need; see restconf/netconf
transport requirements.

Ignas: They are asking about authentication requirements.

Jeff: Think this is covered still in the protocols in question.

Sue: Can ask the security reviewer what they meant.

Q2 Validation credential of second ID.

Sue: Is everyone comfortable with secondary ID as opaque string?

Joe Clark: Updated traceability draft to cover this as “actor ID”.  Agent
may validate that a client can use a given opaque string, but not part of
the authentication protocol.

Alia: Secondary identifier just for troubleshooting.  If agent is acting as
broker, there was concern we wouldn’t have enough information for that
troubleshooting.

Sriganesh: Alia, to simplify troubleshooting or enable? Still could do this
based on agent IDs.

Alia: Simplify it.

Sriganesh: Need more explanation of what we mean by opaque? Operating on it
at the agent? Treating each client separately.

Alia: Opaque in terms of no understanding of what’s inside.  No decisions.

Sriganesh: As long as we clarify that it’s no decision making.

Q3.1: Security and asynchronous nature of i2rs protocol

Alia: Last write wins - based on priorities not tied. Labels for
transactions are not the default.

Jeff: Feedback from NYC interim was that there is not a clear mechanism for
priorities at this time.  Could be done with metadata.  However, protocols
would not use these for adjudicating whether one bit of config wins or not.
Work required in protocols.

Alia: This has been in architecture for a long time.

Jeff: Just highlighting things that may hinder implementation.

Checkpoint or transaction labels.

Sue: It is unclear that the security directorate may not have read the
priority stuff.  Write responses - unclear about what the group thinks about
labels?

Jeff: NYC netmod interim indicated that transctions and validation may slow
us down. We may need to avoid these to be fast?

Dean: Restconf transactions are atomic. You can have multiple transactions
within same session. 

Sue: Does that gives us the labeling that Alia wants?

Dean: I think it does, but need to check.

Alia: It is like a message-id. Need to get into the particular details about
how a protocol can do it?

Jeff: I don’t think that async transactions existing yet.

Alia: Alex, does pub-sub cover this?

Alex: Do not think it is directly applicable. Configuration vs.
subscription.

Alia: When you send your write - subscribe to that response? Other clients
may want to get those responses.

Alex: Be able to refer to a particular subscription?

Alia: Client does a write, subscribe to a notification for a particular
response. Second client may want to get those responses as well.

Alex: Need to discuss this requirement. If we want to apply this to
configuration changes, that is another mechanism. We were going after
operational data.

Jeff: Could you make sure to point out in the mailing list where the
requirement is for async writes for config state? I think the subscription
requirements are clear.

Alia: Ok.

Sue: I have not heard of any restconf/netconf protocol checkpoints

Jeff: Do not think it is spelled out. Would slow us down.

Alia: No, checkpoints are not in arch. Not even transactions. Just
message-ids.

Dean: In restconf, uses HTTP methods - states actions we’re doing. POST is
atomic. Multi-message transaction?

Alia: No, only single message in transaction.

Dean: In restconf, can only be read or write, not both.

Ephemeral 

Jeff: There is no indication that a discontinuity has happened. We may need
this to help with restart of agent.

Alia: Just need to get this into the protocol.

Collisions