AD review: draft-ietf-rap-cops-tls-08.txt submission

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

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