Status of:

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

The doc is still in IETF Last Call (up till Feb 08).

However, the IESG did discuss it on the IESG telechat today.

Here are the comments:

  Harald Alvestrand:
  Comment:
  [2005-02-03] Reviewed by Lucy Lynch, Gen-ART

  No show-stopper comments. Review in document comments.
  See http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-rap-cops-tls-10-lynch.txt

Basically that says everything is fine, module the RFC-Editor notes
that I already have recorded (quite a list).

  Sam Hartman:
  Comment:
  [2005-02-03] Section 9 of rfc 2246 says:

  In the absence of an application profile standard specifying
  otherwise, a TLS compliant application MUST implement the cipher
  suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
  Are you sure that's the cipher you want to require people to
  implement?  RSA seems more common today.  If that's what you want the
  current text is fine.

So pls let me know if you were indeed aware of that and if that
is what you want.

I propose that the authors prepare a new revision with any changes
they may want to make because of the above, plus the 
changes below (as discussed earlier). Then be ready to submit
to internet-drafts@ietf.org BEFORE noon US Eastern on Monday, so
it will get posted on Monday and so that we can get it
approved on Tuesday. Note that I will be offline for an
extended period of time after Tuesday (my tuesday in Europe).

Bert
on first Page (Status of this Memo):
OLD TEXT:
---------
...section 3 of RFC 3667 [RFC3667].  By submitting this...

NEW TEXT:
---------
...section 3 of RFC 3667.  By submitting this...

====================================

Section 5.1
OLD TEXT:
----------
<Client-Accept> ::= <Common Header>
                    <KA Timer>
                    [<ACCT Timer>]
                    [<Integrity (C-Num=16, C-Type=2)>]

NEW TEXT:
---------
<Client-Accept> ::= <Common Header>
                    <KA Timer>
                    [<ACCT Timer>]
                    [<Integrity (C-Num=16, C-Type=2)>]

Note also that this new format of the Client-Accept message does not
replace or obsolete the existing Client-Accept message format, which can
continue to be used for non-secure COPS session negotiations. 

======================================

Section 9
OLD TEXT:
----------
For the Integrity-TLS object for Client-Type 0, the IANA shall add the
following Flags value:
0x01 = StartTLS

NEW TEXT:
----------

The IANA shall add the following C-Num, C-Type combination for the
Integrity-TLS object to the registry at
http://www.iana.org/assignments/cops-parameters:
0x10  0x02    Message Integrity, Integrity-TLS      [RFCxxxx]

For Client-Type 0, the IANA shall add the following Flags value for the
Integrity-TLS object:
0x01 = StartTLS

Further, for Client-Type 0, the IANA shall add the following text for
Error Sub-Codes:
Error Code: 15
Error Sub-Code:
Octet 2: C-Num of the Integrity object
Octet 3: C-Type of the supported/preferred Integrity object or
                Zero.

Error-Code    Error-SubCode      Description
            Octet 2  Octet 3  
---------------------------------------------------
  15          16        0        No security 
  15          16        2        Integrity-TLS supported/preferred

=====================================

Section 11.1
OLD TEXT:
---------
[RFC2026] Bradner, S., "The Internet Standards Process - Revision 3",
RFC 2026, October 1996

NEW TEXT:
---------
(delete OLD TEXT)

OLD TEXT: 
----------
[RFC3280]...

NEW TEXT (add citation before RFC3280 citation):
-------------------------------------------------
[RFC2753] Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework for
Policy-based Admission Control", RFC 2753, January 2000.

[RFC3280]...

==============================

Section 11.2
OLD TEXT:
---------
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP 
  over Transport Layer Security", RFC 3207, February 2002.

NEW TEXT:
---------
(delete OLD TEXT)