Subject: IESG review comments on ForCES framework and authors' responses

From: "Yang, Lily L" <[email-masked]>
Date: Fri, 24 Oct 2003 13:36:21 -0700

Hi, We got some feedback from IESG on the framework draft. Here is a summary of the comments and our response:

1. The standard 2119 boilerplate should be moved inside
    section 1
[response] ok.
2.   Security considerations section should be changed to
    allow for L2 solutions. (see below for detail discussion)
[response] L2 may be allowed as a deployment option coupled with "no security (at higher layer" for a particular L2 technology. But on the other hand, ForCES protocol should not rely on any praticular L2 security to satisfy security requirements as L2 solution can vary and ForCES should stay L2-agnostic. So We porpose to add a sentence at the 2nd paragraph of 8.2 to calrify this, so the new paragraph reads:
        Both TLS and IPsec can be used potentially to satisfy all of the security requirements for ForCES protocol.  Other approaches may be used as well but are not documented here, including using L2 security mechanisms for a given L2 interconnect technology, as long as the requirements can be satisfied. 
3.  Section 5.7
  It was suggested to change
  "SNMP management agent" into "SNMP agent".
[response] ok.

4. Sect 9
  Reference [4] is pointing to SNMPv1 (RFC1157) which is now
  Historic. RFC3410 or RFC3411 should be used
  instead.
[response] replace it with RFC3410.

5. A few minor editorial fixes.

Attached is the new v10 draft that incorporated all the above changes. 

Lily

 <<draft-ietf-forces-framework-10.txt>> 

> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]] 
> Sent: Friday, October 24, 2003 12:12 AM
> To: Russ Housley
> Cc: Putzolu, David; Patrick Droz
> Subject: Re: IESG comments on draft-ietf-forces-framework-08
> 
> 
> David, Patrick-
> 
>  OK, Russ and I clarified the comments below unicast.
>  What needs to be done is:
> 
>   1. The standard 2119 boilerplate should be moved inside
>      section 1
> 
>   2. Security considerations section should be changed to
>      allow for L2 solutions.
> 
>  Did you follow up on the rest of the comments?
>      
> -- 
> Alex
> http://www.psg.com/~zinin/
> 
> Friday, October 10, 2003, 3:47:06 PM, Russ Housley wrote:
> > Alex:
> 
> >> >> > What is the problem that you see with the current text?
> >> >> > Do you have examples of the definitions that would benefit
> >> >> > from the 2119 language?
> >>
> >> > RFC 3602 is one recent example.
> >>
> >>I meant would be able to suggest specific places in the text
> >>of the draft that would benefit the 2119 lingo.
> 
> > That was not the point of my comment.
> 
> >> >> > You mean for the particular case of ForCES over a 
> LAN, correct?
> >> >> > I would certainly not want them to throw away 
> IP-level mechanisms.
> >>
> >> > Several things in the document led me to the conclusion that the 
> >> components
> >> > would be on the same LAN.  After all, they are 
> cooperating to provide a
> >> > router.  An architecture that employs layer 3 routing 
> for communications
> >> > between the components leads to chicken-and-egg that are 
> not discussed in
> >> > the document.
> >>
> >>I would rather look at the questions of CE-FE proximity and 
> specifics
> >>of the media as orthogonal. IP security has the benefit of not
> >>depending on specifics of the media used in a particular 
> instantiation
> >>of Forces. That is, I'd rather us to avoid having to define security
> >>mechanisms for each potential FE-CE connecting technology...
> 
> > The overhead of security at L2 and L3 are different.  I am 
> assuming wired 
> > PHY, not a wireless PHY, otherwise they are even more 
> different.  If you 
> > know the two ends are on the same piece of wire, why not 
> take advantage of it.
> 
> > Russ
> 
>