This is a resend of Jeffs minutes for todays 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 wouldnt 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 whats inside. No decisions. Sriganesh: As long as we clarify that its 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 dont 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 were 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
I2RS 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
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
