ros2 / design

Design documentation for ROS 2.0 effort
http://design.ros2.org/
Apache License 2.0
224 stars 192 forks source link

Add article about how ROS 2 integrates with DDS-Security #243

Closed kyrofa closed 5 years ago

kyrofa commented 5 years ago

This is not a new design proposal. Rather, it is a description of the way ROS 2 currently integrates with DDS-Security (i.e. SROS 2). No new ideas are contained here; this is meant to fill a hole in existing design documentation and provide a good basis for future design of SROS 2, providing necessary context both for the designer as well as the reviewer.

kyrofa commented 5 years ago

Thanks for the review, @mikaelarguedas, I think it's ready for another pass and some more discussion.

Not sure how you prefer to track the TODOs not addressed in this first PR (policy file design doc, not implemented features to be designed etc)?

We should be proposing the policy file design doc in the next few days; we can wait for it, remove that link from here and add it once it's available, or add a blurb in this doc about how it's (design-wise) TBD... I don't have strong feelings, do you have a preference?

Regarding iterating on this to include design for not-yet-implemented features, I say we land this PR and then propose new ones as necessary. That way folks have a foundation of what they know exists, and can review new designs with the proper context.

mikaelarguedas commented 5 years ago

We should be proposing the policy file design doc in the next few days; we can wait for it, remove that link from here and add it once it's available, or add a blurb in this doc about how it's (design-wise) TBD... I don't have strong feelings, do you have a preference?

I'd have a slight preference for the first option as it's only a matter of days, adding "todo: link to upcoming access control policy design doc" instead of the link (similar to https://github.com/ros2/design/blob/gh-pages/articles/114_generated_interfaces_python.md#magic-methods) and replace the todo with the link in the PR adding the policy design doc sounds good to me.

Regarding iterating on this to include design for not-yet-implemented features, I say we land this PR and then propose new ones as necessary. That way folks have a foundation of what they know exists, and can review new designs with the proper context.

:+1:

I think it's ready for another pass and some more discussion.

Thanks for the quick update, this looks great :+1:

kyrofa commented 5 years ago

I'd have a slight preference for the first option as it's only a matter of days [...]

I don't think I split out the three options very well, which makes it hard for you to specify which one you actually prefer, sorry about that :stuck_out_tongue: . However, given the following it sounds like you prefer the second option:

adding "todo: link to upcoming access control policy design doc" instead of the link (similar to https://github.com/ros2/design/blob/gh-pages/articles/114_generated_interfaces_python.md#magic-methods) and replace the todo with the link in the PR adding the policy design doc sounds good to me.

So I've gone ahead and done that. If you do actually prefer the first option (i.e. waiting for the policy proposal) then we can easily add it back.

kyrofa commented 5 years ago

I believe all comments have been addressed here, please let me know if I'm mistaken.