Subject: framework v09 uploaded, ready for IESG review

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 24 Sep 2003 13:16:27 -0700

Hi, 

I just uploaded v09 of the framework draft. There are limited changes comparing to v08, and all are driven by discussion in the mailing list. Here is a summary of the changes. 
1) Section 3.2 End of first paragraph: clarify virtualization's potential impact on ForCES.
2) 2) end of Section 3.2: clarify on the FE topology info gathering:
3) Section 4.2.1: clarify proximity focus on "very close".
4)"Section 4.3.2: point out the impact on FE topology due to the FE up/down event
5) Section 8.2.3: clarify around multicast security issue

The detailed [old] versus [new] text are provided below for your evaluation.

Lily
 <<draft-ietf-forces-framework-09.txt>> 
-------------------------------------------Detailed change log ----------

1) Section 3.2 End of first paragraph: clarify virtualization's potential impact on ForCES.
[old] "FE virtualization should occur only in the pre-association phase and hence has no impact on ForCES." 
[new] "If FE virtualization occur only in the pre-association phase, it has no impact on ForCES. However, if FE virtualization results in dynamic resource change on FE during post-associaiton phase, the FE model needs to be able to report such capability and the ForCES protocol needs to be able to inform the CE of such change via asynchrounous messages." 
2) end of Section 3.2: clarify on the FE topology info gathering:
[old]
        When it is necessary to forward packets between FEs, the CE needs to understand the FE topology.  The FE topology can be queried from the FEs by CEs. 

[new]
        When it is necessary to forward packets between FEs, the CE needs to understand the FE topology.  The FE topology may be queried from the FEs by the CEs via ForCES protocol, but all the FEs are not required to provide that information to the CEs. So the FE topology information may also be gathered by other means outside of the ForCES protocol (like inter-FE topology discovery protocol). 

3) Section 4.2.1: clarify proximity focus on "very close".
[old] "The ForCES Working Group has made a conscious decision that the first version of ForCES will not be designed to support configurations where the CE and FE are located arbitrarily in the network. In particular, ForCES is intended for "very close" CE/FE localities in IP networks, as defined by ForCES Applicability Statement ([7]). " 
[new] "The ForCES Working Group has made a conscious decision that the first version of ForCES will be focused on very close" CE/FE localities in IP networks, as defined by ForCES Applicability Statement ([7]). " 

4)"Section 4.3.2: point out the impact on FE topology due to the FE up/down event
4.3.2 Add a sentence at the end of the first paragraph: 
[new] "When an FE leaves or join an existing NE that is already in post-association phase, the CE needs to be aware of the impact on FE topology and deals with the change accordingly. " 
5) Section 8.2.3: on multicast security
        [old]"IPsec can support both unicast and multicast transport. When multicast is used, IPsec can be used with manual keying with no replay protection and no automatic rekeying.  This meets  the confidentiality and integrity requirements.  Multicast-based solutions relying on IPsec should specify how rekeying and replay protection are provided. "

        [new] "IPsec can support both unicast and multicast transport. At the time this document was published, MSEC working group is actively working on standardizing protocols to provide multicast security [17]. Multicast-based solutions relying on IPsec should specify how to meet the security requirements in [3]."