Common Open Policy Service (COPS) Over Transport Layer Security (TLS)
draft-ietf-rap-cops-tls-11

State was "waiting for AD-goahead, coming from IETF Last Call".
But doc was on IESG agenda (in Feb 2005) while IETF Last Call was
completing.

All discusses cleared now; so doc is approved.

[Ballot comment]
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.

Review by Lucy Lynch, Gen-ART:

This draft falls between "basically ready" and "open issues":

This draft is basically ready for publication,  but has open issues:
the document is well written but the AD review has raised a couple
of points which the authors have already acknowledged:

Bert has already done an excellent in depth review of the IANA related
issues: http://ops.ietf.org/lists/rap/rap.2005/msg00000.html

and one of the authors has responded with some planned updates:
http://ops.ietf.org/lists/rap/rap.2005/msg00001.html

so a version 11 document should be forth coming...

Note also that the major change from version 9 to 10 was the use of  a
TLS Integrity object instaed of the previously defined Security ClientSI
Object - this leads to a  change  is proposed staus for another working
group document:

http://ops.ietf.org/lists/rap/rap.2004/msg00046.html

"Just a clarification. Since the draft defines a TLS Integrity object for
COPS, the WG is planning on sending the COPS-over-TLS document to the
IESG as a Proposed Standard and not Informational as originally planned.

-Scott Hahn
RAP WG co-chair"

You may want to link these two docs in the next cycle.

That said, in reviewing "primarily for readability and consistency"
this is a well written document. The structure is logical, the level
of the definitions is helpful, and the requirements (MUST/SHOULD/etc)
are very clear. A pleasure to read.

IANA Last Call Comments:
The IANA Considerations section says the following:
  For the Integrity-TLS object for Client-Type 0, the IANA shall add
  the following Flags value:
  0x01 = StartTLS
   
  Further values for the Flags field and the reserved field can only
  be assigned by IETF Consensus rule as defined in [RFC2434].

We are trying to understand how this will be entered into the cops-parameters registry. 

Is the Integrity-TLS object a new object defined in this document?
After looking in the COPS registry, we could not see an existing object with this name.  We do see "Message Integrity".  Can you please clarify as to where this assignment will go?

See:

[Note]: 'IESG: This document is in IETF Last Call, but the I (Bert) wants to get
      IESG review comments at Feb 3 telechat, so I can try and finsih this
      before I go absent for a while.
IESG: Pls also note that I already have a set of RFC-Editor notes that need
      to be applied to the document.' added by Bert Wijnen

[Note]: 'IESG: This document is in IETF Last Call, but the I (Bert) wants to get
      IESG review comments at Feb 3 telechat, so I can try and finsih this
      before I go absent for a while.
IESG: Pls also note that I already have a set of RFC-Editor notes that need
      to be applied to the document.' added by Bert Wijnen

AD review

----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Tuesday, January 25, 2005 00:22
To: Hahn, Scott; Rap-wg (E-mail)
Cc: Kulkarni, Amol; Walker, Jesse
Subject: AD review of: draft-ietf-rap-cops-tls-10.txt


Here is my AD review.

1. References and citation issues

      !! Missing Reference for citation: [RFC2753]
      P003 L012:              Server. See [RFC2753].
      P003 L014:              Client. See [RFC2753].

      !! Missing citation for Informative reference:
      P010 L055:        [RFC3207] Hoffman, P., "SMTP Service
                        Extension for Secure SMTP

      !! Missing citation for Normative reference:
      P010 L031:        [RFC2026] Bradner, S., "The Internet
                        Standards Process - Revision

      !! Missing Reference for citation: [RFC3667]
      P001 L015:    of section 3 of RFC 3667 [RFC3667].
                      By submitting this Internet-

  For the last one, you should not have a citation on the front page.
  so citation can just be removed.

2. I wonder about sect 4.1 and the IANA COnsiderations.
  Does sect 4.1 not describe another C-NUM C-Type combinations
  (namely C-NUM-16 and C-Type =2) that should be added to the registry
  at http://www.iana.org/assignments/cops-parameters where it now shows
 
    c-num  c-type  Description     Reference
    ------ ------  -------------------------     ---------
    0x01  0x01    Handle     [RFC2748]
    .... snip ...
    0x10  0x01    Message Integrity     [RFC2748]

  It seems to we need to ask to add
    0x10  0x02    Message Integrity, Integrity-TLS      [RFCxxxx]

3. Sect 4.2
  For error code 13 I see that RFC2748 explains the content of the
  sub-code. Unfortunately such is not recorded in the
  http://www.iana.org/assignments/cops-parameters

  For error code 15, you seem to be newly defining what goes in the
  sub-code. Is that something that needs to be registered? I am not
  sure myself. Can't say that rfc2748 is very clear on that. The last
  para of IANA COnsiderations in RFC2748 seems to say we must do so?

4. Sect 5.1
  It is not clear to me if the Client-Accept in RFC2748 sect 3.7
  is obsoleted, or if this doc just adds another form of the
  Client-Accept message. I think it is the latter, but would like
  to see it explicitly spelled out.
  If it is indeed an additional form, then the abstract is not
  explicit at that either.

I am requesting an IETF Last Call now.
So pls do not submit a new revision yet.
Let me know your reaction to the above asap.

Thanks,
Bert

Comments received from Security ADs.
Checking with WG chair and (main) author.

I also need to know what the intended target is (stds track or informational)

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Tuesday, August 31, 2004 18:44
To: Kulkarni, Amol; Hahn, Scott
Cc: Rap-wg (E-mail)
Subject: AD review: draft-ietf-rap-cops-tls-08.txt submission


Here is what I found

1. Sect 4.1, it is unclear what kind of field the FLAGS field is
  is it a bitmask? an Unsigned16, or what? If a bit field, which
  bit indicates the TLS flag? I also wonder if the flag would not
  be better called StartTLS, but that is a nit.

2. Same sect 4,1
  Also, I guess the ///// field is a reserved field?
  If so, I would make that clear, and I would state that it
  must be set to zero in transmit and be ignored on receipt.

3. I had this comment/question back inmarch of this year as well
  and have not yet seen a response:
    Section 7 states that the non-well-know port needs to be communicated
    by the server to the client. But it does not explain how. Am I missing
    something here?

4. You may want to add to the IANA considerations section that the registry
  is located at: http://www.iana.org/assignments/cops-parameters
  That is where they are supposed to add the error code.

5. Assigning value 16 as an error code is something that the WG should not
  do. The proper procedure is to mark it as a error-code-TBD-by-IANA
  and then ask IANA to assign and then RFC-Editor will fill in the numbers.
  I am not aware that other on-going work is taking place in this area,
  so the risk for conflicts is probably low.

6. I also still wonder:
  that StartTLS ClientSI object... who controls assignment of additional flags
  in the future?

x. You are now (changing) defining protocol messages for COPS.
  In sect 5 you change the ClientAccept. So I wonder:
  - does this doc UPDATE RFC2748 as a result?
    it seems to me it does and so it should state so and
    mention so in the abstract if we indeed agree
  - if we define protocol extensions to RFC2748, should this
    not be a stds track document instead of informational
    Certainly if it updates 2748, it should be stds track
    I think.
  - The fact that this document fills in the "how to" for the
    last para in the security considerations section of RFC2748
    may be another reason to make this stds track.

admin nits.
- There should be no reference to RFC2026, nor should their be
  a citation in the front matter. See www.ietf.org/ID-Checklist.html
  sect 2.1 item 7.
- If you do do a respin, better use the text from RFC3667/3668 anyway.


Thanks, Bert

Besides the AD review (as per below) I am also checking with Security ADs.

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: donderdag 25 maart 2004 22:14
To: jesse.walker@intel.com
Cc: Rap-wg (E-mail)
Subject: AD review of: draft-ietf-rap-cops-tls-07.txt


Took a while.. but I did find some time to do AD evaluation
of this document.

1. In sect 3.2.1 you talk about Protocol and Flags.
  How does this fit into the ClientSI object defined in RFC2748.
  Is this something needs to be addressed/described in IANA
  Considerations?
  Where should IANA register this? How are future assignments to
  be made? For protocols? for flags?

2. In sect 3.2.2 you define new sub-error codes. How does that fit
  into the definition of RFC2748? Are the sub-error codes zero by
  default? ANyway, this needs more explanation in IANA considerations
  as to how/where IANA needs to put these new assignments and how
  future values can be allocated, no?

3. Section 7 states that the non-well-know port needs to be communicated
  by the server to the client. But it does not explain how. Am I missing
  something here?

4. You may want to add IPR and copyright notices as per RFCs3667/8/9

Thanks,
Bert