Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

I consider the document “ready with issues”, see below for detailed comments:

* 4.1 Inter-Area Path Computation

you write: "This could be represented in the IRO as:” and then a number of diagrams. It is unclear to me whether those different option are functionally equivalent. The text suggests so to me, but that doesn’t seem to make sense….. (or I completely misunderstand the text)

To me it seems that the three sequences you give are all possible sequences for the given topology not equivalent, I think the text needs some clarification in that case.

The same goes for 4.2, 4.3 etc.


* 4.5 P2MP

I am guessing that the tree you show is the result of the three paths you give before, but some explanation would be good.

7 security considerations

I think these are a bit weak. Especially compared to what RFC5440 provides. I consider an attacker gaining fine grained control over the network path a very serious risk. The flippant comment about “routing around trouble” doesn’t really do it for me. I would encourage you to take a good look at the security considerations in 5440 and assess how those considerations change given the finer grained control you provide. Some or even most may remain the same, and it is fine to say so, but I can imagine that some risks are higher because of the fine-grained control, and you seem to suggest so too given the “the security techniques in rfc5440 are considered more important”. So I really think this draft would benefit from a better security considerations section.

Hope this helps,

Klaas

--
Klaas Wierenga
Identity Architect
Cisco Cloud Services