RE: AD review of: draft-ietf-rap-cops-tls-10.txt

["Kulkarni, Amol" <amol.kulkarni@intel.com>]

Bert,

Thanks for your review. Please see my comments below, preceded with
'Amol>'.

Thanks,
Amol

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 
Sent: Monday, January 24, 2005 3:22 PM
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]
=======================
Amol> Yes, I think we should do that.


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?
======================
Amol> I think that would be a good idea since we're specifying actual
content of the message for a specific client type (client type 0). The
description of error code 13 in RFC2748 is very generic and doesn't
define any new values. That's probably why it isn't in the registry.


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.
=====================
Amol> It is the latter. We're adding another form of the Client-Accept
message, not replacing the earlier one.

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
> -----Original Message-----
> From: Hahn, Scott [mailto:scott.hahn@intel.com]
> Sent: Thursday, December 09, 2004 19:09
> To: iesg-secretary@ietf.org
> Cc: Wijnen, Bert (Bert); Kulkarni, Amol; Walker, Jesse
> Subject: Publication of draft-ietf-rap-cops-tls-10.txt
> 
> 
> I would like to request the publication as Proposed Standard of the
> following draft 
> 
> http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-10.txt
> 
> Respectfully,
> 	Scott Hahn
> 	RAP WG co-chair
>