Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks draft-ietf-teas-interconnected-te-info-exchange-05.txt Do not be alarmed. 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. The document includes the problem statement: A mechanism is required that allows TE-path computation in one domain to make informed choices about the TE-capabilities and exit points from the domain when signaling an end-to-end TE path that will extend across multiple domains. [TE is "traffic engineering".] The document describes, in general terms, the need for exchanging information about reachability between domains without revealing the totality of routing information. To this end, the document anticipates the use of abstracted reachability information. The information suggests that a path might exist, but it is not a guarantee of reachability. The numerous examples definitely motivate the need for exchange of "meta routing information" (my term), but my concern is about the privacy of the information. In fact, one reason for using abstracted information may be to obscure the details because they are sensitive: In section 3.2 "Confidentiality", ... an operator of a domain may desire to keep confidential the details about its internal network topology and loading. This information could be construed as commercially sensitive. also 4.1.1 While abstraction uses available TE information, it is subject to policy and management choices. Thus, not all potential connectivity will be advertised to each client. The filters may depend on commercial relationships, the risk of disclosing confidential information, and concerns about what use is made of the connectivity that is offered. >From a security viewpoint, I wonder if the architecture should have sensitivity labels for abstracted reachability information. Although one domain may be willing to share some partly redacted reachability information with another domain with which it has a limited trust relationship, the first domain might want the second domain to refrain from disclosing that information to other domains. Perhaps the first domain might offer two records with different abstraction levels, and the most abstracted one would be "shareable" while the lesser abstraction would be "private." I found the notion of situational address interpretation disconcerting. In "4.5. Addressing Considerations", we learn that "one address may mean one thing in the client network, yet the same address may have a different meaning in the abstraction layer network or the server network" and "human operators may well become confused." Should addresses have labels that define the domain of interpretation? The notion of some kind of anticipatory information being generated and dispersed to neighboring networks was confusing. Section 4.3 "Considerations for Dynamic Abstraction" discusses "fluidity". The second sentence is an impenetrable run-on word sequence. However, it is followed by something that is asserted to be more significant --- it is apparently "stability". Some wordsmithing for clarification would be helpful. Nits ---- 1.1.9. Abstraction Layer Network ... networks and one or more client network (should be networks) 3.2, last sentence "understanding that less information that is made available the more" should be "that the less ..." 3.5, last sentence "Thus, while the data shared in reduced," should be "is reduced" Hilarie