GenART LC review of draft-ietf-nea-pt-tls-05

"Roni Even" <> Mon, 04 June 2012 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3C4411E80DF; Mon, 4 Jun 2012 14:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fhDgSf814vHC; Mon, 4 Jun 2012 14:22:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 23D2D11E80EC; Mon, 4 Jun 2012 14:22:58 -0700 (PDT)
Received: by werb13 with SMTP id b13so3605459wer.31 for <multiple recipients>; Mon, 04 Jun 2012 14:22:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=5FGk1VhOrYtA3rMsj8vOwLC415uw9sXew8WnrWZhFik=; b=01L3UtUaaqsaa85rMRGi7Guw9qAGO6QRMo08QzcJ6DaurUFcFyxqDH6roIeiP1l9Px sX4j5JrEScMFfOA8Y0nTAfdca9+Oy2J1t5Htj6dZvEWUyJ+bHhPAkIy+iYS4Hv6Q3pHr +qbKOW5XfAy2PRR/JoXTBZa6UOuiS7QkFXrvd0/+pwgBpnIIO4cg2H3DZa0fuZ6UOf2i Z639Pv4Hul4C89Q6fWyNSG1LoUGSA4YfKHrl4TDHyLnrt9NQLO6EhKnnmvOmLuFjzfV7 2KSjsAQ4JtMH7DC/v7ujI3zfVFHXqzjx1LxNPAA/9KdPvlNhxQeE3yw+8Wj8Cy95lfos Pl1g==
Received: by with SMTP id y58mr6011977web.106.1338844975531; Mon, 04 Jun 2012 14:22:55 -0700 (PDT)
Received: from windows8d787f9 ( []) by with ESMTPS id gb9sm22526945wib.8.2012. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 14:22:54 -0700 (PDT)
From: Roni Even <>
Subject: GenART LC review of draft-ietf-nea-pt-tls-05
Date: Tue, 05 Jun 2012 00:20:26 +0300
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01CD42B1.032B5AF0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac1Cl9xExNAkih6WSYeHA9SkXDOg7g==
Content-Language: en-us
Cc:, 'IETF' <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Jun 2012 21:23:02 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


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 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  section 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




Nits/editorial comments: