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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

OK, that is good to hear.
But was I supposed to just assume that based on the silence?

Thanks,
Bert 

> -----Original Message-----
> From: Kulkarni, Amol [mailto:amol.kulkarni@intel.com]
> Sent: donderdag 6 november 2003 22:50
> To: Wijnen, Bert (Bert); Hahn, Scott; Mark Stevens (E-mail)
> Cc: Rap-wg (E-mail); Uri Blumenthal (E-mail)
> Subject: RE: Feedback on draft-ietf-rap-cops-tls-06.txt
> 
> 
> Bert,
> 
> I AM working on modifying the draft to Uri's satisfaction.
> 
> Amol
> 
> -----Original Message-----
> From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org] On Behalf
> Of Wijnen, Bert (Bert)
> Sent: Thursday, November 06, 2003 12:56 PM
> To: Hahn, Scott; Mark Stevens (E-mail)
> Cc: Rap-wg (E-mail); Uri Blumenthal (E-mail)
> Subject: RE: Feedback on draft-ietf-rap-cops-tls-06.txt
> 
> I guess that it just alternates between the security advisor 
> and the WG (and/or eduitors/authors)... but now we've been waiting
> for close to two weeks without any response from WG.
> 
> <ad hat on>
> This is not gonna work 
> I hope you understand the implied message here!
> </ad hat on>
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > Sent: maandag 27 oktober 2003 12:06
> > To: Rap-wg (E-mail)
> > Cc: Uri Blumenthal (E-mail)
> > Subject: Feedback on draft-ietf-rap-cops-tls-06.txt
> > 
> > 
> > Sorry for the long delay, but finally our Security Advisor has 
> > found time to review revision 6.
> > 
> > I hope that the authors/editors and the WG can quickly 
> > respond and act, so that we can now get some pressure to
> > complete this last RAP-WG document soon.
> > 
> > Thanks,
> > Bert 
> > 
> > -----Original Message-----
> > From: Uri Blumenthal [mailto:uri@lucent.com]
> > 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).
> > 
> > ==================================================
> > 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?
> > 	- policy - how it gets there, how it's processed,
> > 	  what it looks like, etc. Something comparable to
> > 	  VACM of SNMPv3...
> > 
> > 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).
> > 
> > Excessive use of abbreviations (PEP, PDP) without defining them
> > in this document doesn't help.
> > 
> > Otherwise the document is OK, notwithstanding the following.
> > 
> > SPECIFIC COMMENTS.
> > 
> > 3.2.1.  So is at least one protocol mandatory? And why is it valid
> > to make them all optional?
> > 
> > 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?
> > 
> > PDP implementations MUST NOT require use of access control?!  I'm
> > violently against this prohibition.
> > 
> > 8. Forcing to choose between insecure and X.509 PKI infrastructure
> > is unfair and improper. Recommendation: support Web of trust,
> > possibly other...
> > 
> > PDP hostname availavle via Access Control mechanism? I don't
> > understand - please clarify.
> > 
> > 9.1. And the point of backward compatibility with old insecure
> > implementations is...?
> > 
> > References. RFC2748 is not of January 200 (unless it's a part
> > of Gospel?).
> > 
> 
>