Ran
I appreciate you taking the time to present your draft at the i2RS interim. Your draft suggests: When the I2RS session is opened, An I2RS Client should advertise to an I2RS Agent that the I2RS Client's identifier and priority. The I2RS Client's identifier and priority should be managed by the I2RS Agent, and associated with its I2RS session. It was an important contrast to the existing assumption which Joel pointed out - that I2RS authentication is done outside of the I2RS protocol. This is the agreed upon position in the I2RS architecture document. The I2RS architecture has proposed that the other authentication protocols (For Example AAA's Radius or Diameter) would establish the identity outside the I2RS protocol. Most routing people have AAA protocols to establish identity for other purposes. The priority would be associated with the client identity and stored by the I2RS agent per client. Your draft provides another alternative the WG should hear during its deliberation process. It could be done outside the I2RS protocol as a simple authentication scheme. As a WG chair, I appreciate your willingness to bring an alternate proposal to our current thoughts to help us keep nimble in our thinking. During the next 2 weeks, I hope you will continue to actively participate in the authentication and identity discussion. Joel's comments were: . We already have an identity establishing mechanism between the client-agent. It is the AAA authentication. If we introduce into the I2RS protocol any in-protocol portion fo identity, we make our lives harder . [Ran]: Could you expand upon the question and concepts? . [joel]: If you look at the I2RS mutual authentication in AAA, it is a identity that other people understand. The client -agent authentication in the out-protocol use is what people understand. . [Ran]: netconf/restconf have authentication, but it only includes identity. It does not include the priority. We can also modify priority. . [Joel]: Let me step back into your draft for a moment. You have a constraint on the format of Identity and the mappings between identity to implementation format. We had that debate, and decided these implementation mappings are an implementation format. . [Joel]: Let me return to priority, the NACM (as defined in Jeff's draft) will give us priority associated with a client. We do not need new mechanism. . [Ran]: Is this a requirement in the architecture or a restatement from the WG discussion? . [Sue]: Restatement of the WG discussion on NACM. The implementation mapping should be implied in the architecture document. However we are grateful for your question that makes this clearer. . [Alia]: We choose this direction to maximize re-use of existing protocols and mechanism for the first release of the I2RS protocol. . [Sue]: Is Client priority store in the agent per node? How does it occur? . [Jeff]: It is stored in the NACM for client, and the client identity is tagged to a node (E.g. per route). This further implies that priority is an attribute that is stored in the NETCONF Access Control Model [RFC6536 <https://tools.ietf.org/html/rfc6536> ] as part of a rule-list. E.g.: +--rw rule-list [name] +--rw name string +--rw group* union +--rw rule [name] +--rw name string +--rw module-name? union +--rw (rule-type)? | +--:(protocol-operation) | | +--rw rpc-name? union | +--:(notification) | | +--rw notification-name? union | +--:(data-node) | +--rw path node-instance-identifier +--rw access-operations? union +--rw action action-type +--rw comment? string +--rw i2rs:i2rs-priority i2rs-priority-type People may respond to this post with other discussion points on the identity and secondary identity. Sue
_______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
