Subject: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt

From: "Durham, David" <[email-masked]>
Date: Wed, 19 Sep 2001 11:09:47 -0700

Hi,

Some comments/questions on the subject draft:

5.1  Key Midcom Requirements MET by COPS 
    
     2. Actions on failed commands must be clearly specified (proceed 
     or reject) and the protocol should include failure reason codes. 
     (R61, R63) 
   
          COPS uses an error object that is used to identify a 
          particular COPS protocol error. The error sub-code field 
          contains additional detailed client (i.e. the MIDCOM COPS 
          client) specific error codes.  

[Dave] Likewise, the synchronous COPS Report message & Report-type object
seems to meet this requirement rather directly. 

5.2  Key Midcom Requirements NOT met by COPS 

     1. The protocol must allow specification of a flow identifier or 
     pinhole by at least five tuple (R40, R45, R44). A ruleset 
     comprises of a flow identifier and action. 
      
This requirement is easily met by the current Classifier specification of
existing COPS PIBs.If necessary, existing COPS Classifiers can be extended
(object inheritance) to add the new MIDCOM specific filtering parameters, or
new Classifier objects can easily be defined. 
       
[Dave] This could met by the classifier, but if the purpose of the flow
identifier is to identify a request to the agent from the middle box, then
the COPS request-handle is an variable sized identifier that can directly
represent the flow identifier and 5-tuple, or whatever else is required to
uniquely identify that request state. In either case, why is this
requirement NOT met?

     2. The protocol should allow multiple Agents to interact 
     simultaneously with a Middle Box and vice-versa. (R3a1, R3a2) 
			as the MIDCOM protocol 
          The COPS protocol does not allow several COPS servers to 
          control the same COPS client; this is a COPS architectural 
          issue. 
          One possible way to meet this requirement is to have several 
          Midcom clients on a Middle 

[Dave] Multiple COPS servers can control the same client, so long as each
server is using a different Client-Type identified in the COPS message
headers. Thus, different agents can interact simultaneously with a middle
box using COPS. I believe this requirement is met already.

     4. The MIDCOM protocol is a client/server protocol where the 
     Middle Box is the server. This implicitly requires that the Midcom 
     agent establish contact with the Middle Box. 
           
          In COPS, the COPS client initiates contact, which goes 
          against the current MIDCOM principles. 
      
[Dave] Is this just saying that the midcom terminology for client vs. server
is reversed from what is defined in the RAP framework? That is, the PDP must
find and contact the PEPs?

     5. The Agent must be authenticated by the Middlebox as part of the 
     registration process. (R33) 
           
          COPS uses transport security mechanisms (TLS or IPSEC), 
          therefore the requirement is met but not within the protocol. 
           
[Dave] COPS already provides a built-in security mechanism that uniquely
authenticates the client and server with one another, TLS & IPSEC are just
gravy (I believe the COPS over TLS document is already in queue to be RFCed)
. 

Cheers,
-Dave              

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, September 18, 2001 6:33 AM
> Subject: I-D ACTION:draft-aoun-midcom-cops-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: COPS applicability as the MIDCOM protocol
> 	Author(s)	: C. Aoun et al.
> 	Filename	: draft-aoun-midcom-cops-00.txt
> 	Pages		: 8
> 	Date		: 17-Sep-01
> 	
> This draft discusses the applicability of the COPS protocol as the 
> MIDCOM protocol. 
> It discusses the architectural similarities between COPS and Midcom 
> and how COPS meets most of the key requirements for the Midcom 
> protocol. 
> The COPS client for the MIDCOM protocol will be specified in 
> separate internet drafts.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-aoun-midcom-cops-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-aoun-midcom-cops-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-aoun-midcom-cops-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: Melinda Shore <[email-masked]>
Date: Wed, 19 Sep 2001 14:30:08 -0400

>Some comments/questions on the subject draft:

Because the midcom requirements document really isn't even
close to done it's impossible to know whether or not a given
protocol meets the requirements.  Also, protocol selection
is outside the charter of the current iteration of the working
group.

Melinda