Skip to main content

Last Call Review of draft-ietf-nea-pt-tls-
review-ietf-nea-pt-tls-genart-lc-even-2012-06-07-00

Request Review of draft-ietf-nea-pt-tls
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-06-13
Requested 2012-05-31
Authors Paul Sangster , Nancy Cam-Winget , Joseph A. Salowey
I-D last updated 2012-06-07
Completed reviews Genart Last Call review of -?? by Roni Even
Genart Telechat review of -?? by Roni Even
Genart Telechat review of -?? by Roni Even
Assignment Reviewer Roni Even
State Completed
Request Last Call review on draft-ietf-nea-pt-tls by General Area Review Team (Gen-ART) Assigned
Completed 2012-06-07
review-ietf-nea-pt-tls-genart-lc-even-2012-06-07-00
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.



Please resolve these comments along with any other Last Call comments you may
receive.



Document:

draft-ietf-nea-pt-tls-05

Reviewer: Roni Even

Review Date:2012–6–4

IETF LC End Date: 2012–6–13

IESG Telechat date:



Summary: This draft is almost ready for publication as a standard track

RFC

.



Major issues:



Minor issues:

1.



In section 3.2

“Therefore, this specification requests the IANA reserve a TCP port number for
use with the PT-TLS protocol upon publication of this specification as an
Internet standard RFC.” I think it will  be better to have here the assigned
port number and instruct the RFC editor to put the correct value.

2.



In section 3.4.2.2 last paragraph you summarize the text from section 3.8 while
in the paragraph above you provide the reference. Why do you need the last
paragraph if 3.8 is referenced.

3.



In various places you refer to SMI 0 as IETF SMI number while according to the
table it is IANA SMI number.

4.



I assume that all implementations MUST support message type vendor ID 0. Is
this mentioned?

5.



In section 3.5 and 6.1 you propose a policy of “Expert Review with
Specification Required “. I think that according to RFC5226 expert review is
implied if you select a specification required policy.

6.



In section 3.6 on 9+ “Recipients of messages   of type 9 or higher that do not
support the PT-TLS Message Type Vendor ID and PT-TLS Message Type of a received
PT-TLS message MUST respond with a Type Not Supported PT-TLS error code in a
PT-TLS Error message.” I think this is true only for Message Type Vendor ID 0.

7.



In 3.7.1 for Max vers and prefs ver you say that they MUST be set to 1. I think
it will be more correct here to say SHOULD since you explain afterwards that
they may have other values.

8.



In section 3.7.2 “the recipient SHOULD send”. Why not make it a MUST here.

9.



In section 3.7.2 “The version selected MUST be within the Min Vers to Max Vers
inclusive range sent in the Version Request   Message” I was expecting to see
pref ver here.

10.



In section 3.8.3 “ The SASL client authentication starts when the NEA Server 
enters the PT-TLS Negotiation phase and its policy indicates  that an
authentication of the NEA Client is necessary but was not performed during the
TLS handshake protocol “ my read of  s

ection 3.8 second paragraph is that it can be done even if was done in the TLS
handshake so the last part of the sentence is not correct, if there is a policy
you do it anyhow. This comment is also for the third paragraph.

11.



In section 3.9 I noticed that you propose to send the entire original message.
Isn’t it enough to send only the message identifier. This is based on the last
sentence of this section.

12.



Most of the text in section 6.1 repeats RFC5226 but in your words. Are you
trying to change some of RFC5226 text if not why write it in different words?







Nits/editorial comments: