Hi Chris

OK, that all looks fine.

- Stewart

On 21/12/2015 14:46, Chris Bowers wrote:

Stewart,

Thanks for the feedback.  See inline below [CB].

The diff of the new version can be found at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-mrt-frr-algorithm-07

Chris

*From:*rtgwg [mailto:[email protected]] *On Behalf Of *Stewart Bryant
*Sent:* Wednesday, December 09, 2015 5:34 AM
*To:* [email protected]; [email protected]; [email protected]
*Subject:* draft-ietf-rtgwg-mrt-frr-algorithm - some comments

Hi,

I am sorry for the late comments

I have looked at the algorithm draft and have a some top level
concerns.

Firstly you have the sections that describe the operation in detail
and the python code both as normative. That is always a dangerous
thing to do since it is not clear which has priority in the
event of a difference.

[CB] I have added text to designate the pseudo-code as normative and the python code as not normative.

<t>While this Python code is believed to correctly implement the

pseudo-code description of the algorithm, in the event of a difference,

the pseudo-code description should be considered normative. </t>


I am concerned that the algorithm, which can stand on it's own
right and a comparison with other methods is included in this
text. I think that the comparison text from this draft and from
the architecture draft should be put into a single comprehensive
evaluation draft.

Again I am concerned about the assertion of completeness, since it
is complete only against a number of unstated constraints.

[CB] Removed unqualified instances of “complete”.


Finally the authors have clearly copied the security section from
the architecture draft. Whilst I am sure that the algorithm has
no security concerns per se, that is only because it is placed
in an operational context by code that does input parameter
filtering and an operating system that ensures it executes
correctly. What I would expect from a security analysis was
guidance to the implementers of any particular fragility in
the algorithm that they needed to consider (there may of
course be none).

[CB] I changed the security section to read.

<t>The algorithm described in this document does not introduce new

security concerns beyond those already discussed in the document

describing the MRT FRR architecture <xref

target="I-D.ietf-rtgwg-mrt-frr-architecture"/>.</t>



- Stewart


_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to