I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-savi-framework-05 Reviewer: Peter McCann Review Date: 2011-11-02 IETF LC End Date: IESG Telechat date: 2011-11-03 Summary: One minor issue Major issues: none Minor issues: The document presents the design of the SAVI model, and advocates putting SAVI validators as close to the end host as possible, forming a protection perimeter where there is some assurance that source IP addresses are valid inside the perimeter. However, the document does not discuss the possibility that some nodes inside the perimeter may be compromised or otherwise untrusted (for example, in case there are multiple distinct administrative domains connected in some topology). This seems to be a case of crusty on the outside, soft in the middle security. Perhaps some discussion of these issues is warranted. For example, it might make sense in some cases to deploy SAVI instances that do replicate state, which is argued against in the draft on the basis of memory savings. Nits/editorial comments: Section 1: and help with localizing hosts and identify misbehaving hosts. SHOULD BE: and help with localizing hosts and identifying misbehaving hosts. Section 2: Besides, in the case of legacy switches, the security level is lower, as there is no full protection for the hosts connected to the legacy server. SHOULD BE: Besides, in the case of legacy switches, the security level is lower, as there is no full protection for the hosts connected to the legacy switch. Section 3.1: constrained to a single IP address assignment methods SHOULD BE: constrained to a single IP address assignment method Section 4: figure Figure 1, SHOULD BE: Figure 1, Section 6: mix scenario can handle the same as scenario SHOULD BE: the mixed scenario can be handled the same as a scenario Reword this paragraph: Prioritization relationship between different address assignment methods is used as the basis to solve possible collisions. Current standard documents of address assignment methods have implied the prioritization relationship in general cases. However, considering in some scenarios, default prioritization level may not be quite suitable. Configurable prioritization level should be supported in a document of SAVI solution for the mix scenario. Section 7: This document suggests set 3 prefix configuration mechanisms at SAVI device: SHOULD BE: This document suggests a set of 3 prefix configuration mechanisms at SAVI device: used as premier check SHOULD BE: used as a first check _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
