RE: Feedback on draft-ietf-rap-cops-tls-06.txt

Hi Uri,

Thanks for reviewing the draft. I've made most of the changes you've
asked for. However, I have some comments below...

Thanks,
Amol

-----Original Message-----
From: Uri Blumenthal [mailto:[email protected]]
Sent: donderdag 23 oktober 2003 23:58
To: Wijnen, Bert
Cc: Blumenthal, Uri
Subject: COPS etc.3.2.1. So is at least one protocol mandatory? And why
is it valid to make them all optional?


Bert,

Sorry for prolonged silence - was sick and then took me
time to get through the e-mail piles.

Here's my review of COPS-06, please forward it to the
appropriate AD and WG chair(s).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

cops-06.txt

GENERIC COMMENTS.

I'd prefer the following important issues described
somewhere:
	- key provisioning (how the initial/first keys
	  get in);
	- key management/update;
	- key requirments. What kind of keys are accepted?
	  Public Key in X.509 format only? Anything else?
	  Any reason why neither symmetric keys nor
	  password-based methods (such as SRP, or what's in
	  SSL) are there?
-------------
Amol> I assume the above points refer to the authentication keys used by
the client and the 'insecure' COPS server. There is some description of
the keys and how to use them in the original COPS RFC. However, the key
provisioning and management has been left out as an implementation
issue.=20
I'm not sure if I should use this draft to modify or clarify something
that's essentially a COPS/TCP RFC issue.


	- policy - how it gets there, how it's processed,
	  what it looks like, etc. Something comparable to
	  VACM of SNMPv3...
----------
Amol> Again, I believe that policy specification is not within the scope
of this draft. Maybe I should explicitly mention that?

I found the text on Access Control exceedingly muddy/unclear. I'm
coming from reasonably good understanding of Access Control, but
shallow knowledge of COPS. Request rephrasing (and maiing it
CLEARER).
------------
Amol> Are you referring to Section 5 or section 8? I've updated text in
both sections, but I'd still like to know.

4.4.  I'm not sure server (in the last case) should be allowed to
just proceed establishing insecure connection. Perhaps better if
the client decides how to proceed?
----------
Amol> I don't think so. The client, by indicating that a secure
connection is optional, should be OK with the insecure connection being
established.=20