Thanks for the review!
>This is a fairly high-level review, but I do have two substantive
>comments:
>
>I see a glaring omission in section 5... Security.
>I see that the security considerations hint at this, but I think we need
>at least a placeholder here to underscore its relative importance. Here's
>a crack at some text...
The omission was not intentional in the sense that we didn't feel it was
necessary; just that we did not have time to get inputs on this. Its
definitely planned for the future.
>Secure: The communication both between applications and I2RS client and
>between I2RS client and I2RS agent (and others?) should use secure
>(authenticated and encrypted) transport. Further, a fine-grained trust
>model should be defined to ensure that the payload communications (both
>read-only and read-write access) are properly authenticated (you are who
>you say you are and I trust you to communicate with me), and to give
>tight control over what a given communicator is and is not permitted to
>know or manipulate. These controls should include the ability to limit
>the manipulation to a range of acceptable values or even limit the rate
>of change. IOW - if the knob goes from 0 to 11, but I only want to allow
>application X to be able to turn it between 2 and 5, the framework needs
>to support that.
>
>Given the amount of control possible with I2RS or other SDN-style control
>surfaces, security and trust model for any of these software manipulation
>tools MUST be designed in from day one. Bolt-on security (that is,
>security that is not integral to the protocol specification) has the
>potential to sharply limit the application of these tools because it
>would require a level of trust and coordination between those maintaining
>applications and those maintaining the routing network that simply does
>not exist today in most companies.
That sounds reasonable.
>Section 6 - there are XML interfaces to some router OSes now. You may
>have intended this to be covered under CLI, since it shares similarities,
>but when we're talking about existing interfaces and protocols, that
>might be an important distinction.
>http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r4.1/xml/programming/guide
>/xl41apidoc.html
Good point.
--Tom
>
>
>Thanks,
>
>Wes George
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of
>> Alia Atlas
>> Sent: Tuesday, February 26, 2013 5:51 PM
>> To: [email protected]
>> Subject: [i2rs] updated draft-atlas-i2rs-problem-statement-01
>>
>> I updated the problem-statement draft, but requested manual posting to
>> get the name-change and meta-data right.
>> While waiting for that to happen, I've attached the draft so there's
>> more time to review it before IETF.
>>
>> Regards,
>> Alia
>
>This E-mail and any of its attachments may contain Time Warner Cable
>proprietary information, which is privileged, confidential, or subject to
>copyright belonging to Time Warner Cable. This E-mail is intended solely
>for the use of the individual or entity to which it is addressed. If you
>are not the intended recipient of this E-mail, you are hereby notified
>that any dissemination, distribution, copying, or action taken in
>relation to the contents of and attachments to this E-mail is strictly
>prohibited and may be unlawful. If you have received this E-mail in
>error, please notify the sender immediately and permanently delete the
>original and any copy of this E-mail and any printout.
>_______________________________________________
>i2rs mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
