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

From: "Roni Even" <[email-masked]>
Date: Tue, 5 Jun 2012 00:20:26 +0300

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  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
words?

Nits/editorial comments:

---

From: Paul Sangster <[email-masked]>
Date: Wed, 13 Jun 2012 09:55:55 -0700

Thanks for the detailed review, comments are in-lined...

From: Roni Even [mailto:[email-masked]]
Sent: Monday, June 04, 2012 2:20 PM
To: [email-masked]
Cc: 'IETF'; [email-masked]
Subject: GenART LC review of draft-ietf-nea-pt-tls-05

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.

Reviewer: Roni Even

Review Date:2012-6-4

IESG Telechat date:

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.

[PS:] Ok, we can reword this in hopes of getting a particular value (race condition with other upcoming RFCs).

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.

[PS:] The goal of this section is to introduce and summarize the different phases of PT-TLS.  We felt a brief discussion of the general message flow was helpful to the reader to understand what occurs during this phase (similar to what we did in the other sub-sections).  Your correct that this information is covered later in more detail.

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

[PS:] I presume this is about the PEN 0 being for the IETF.  Correct, it's the IETF's name space that administered by the IANA.  What text would you like to see to make this more clear?  Can we do it in one place, for example stating that the IETF name space is administered by the IANA?

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

[PS:] The purpose of this section was just to summarize and enumerate the message types for vendor id 0.   I don't think it's a general rule that any message type defined in the IETF (IANA :)) name space must (or should be) supported by all implementations.  It will vary depending on the purpose of the message so that normative language is included in the descriptions of the message.

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.

[PS:] I agree, it says "Specification Required also implies use of a Designated Expert".  The policy is just "Specification Required" so we could remove the "Expert Review with" and make it clear it's the Specification Required IANA 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.

[PS:] Thanks will reword this section to make it more clear.

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.

[PS:] I think this is a MUST.  The next sentence just points out that this normative text might change in a future revision (which is not currently planned).

8.       In section 3.7.2 "the recipient SHOULD send". Why not make it a MUST here.

[PS:] I ok with making this change, let's see what others think ...

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.

[PS:] Perf is just an informational (hint) preference.

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.

[PS:] Thanks, this was supposed to be an example.  Will fix these.

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.

[PS:] Not "the entire original message" as its at most the first 1024 bytes of the offending message.  This allows the recipient to either caches recently sent messages and/or message identifiers when determining what caused the error.  We thought this flexibility was useful and had very little cost.

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?

[PS:] We were hoping to emphasize the aspects of 5226 that are most important to this specification.  We weren't trying to change how the IANA policy was interpreted.  Did you think we did so?  Is there a portion of this text that is most troubling or was this just a question?

Nits/editorial comments:

---

From: "Roni Even" <[email-masked]>
Date: Tue, 19 Jun 2012 12:16:19 +0300

Hi,

I am OK with your responses. The only thing I am not sure is about using PEN
0 defined in the registry.

Decimal

| Organization

| | Contact

| | | Email

| | | |

0

  Reserved

    Internet Assigned Numbers Authority

      iana&iana.org

I was wondering how this enterprise number should be specified since it
appears as "Reserved" in the registry. I have no specific suggestion

Roni

From: Paul Sangster [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2012 7:56 PM
To: Roni Even; [email-masked]
Cc: 'IETF'; [email-masked]; [email-masked]
Subject: RE: GenART LC review of draft-ietf-nea-pt-tls-05

Thanks for the detailed review, comments are in-lined.

Reviewer: Roni Even

Review Date:2012-6-4

IESG Telechat date:

Major issues:

Minor issues:

[PS:] Ok, we can reword this in hopes of getting a particular value (race
condition with other upcoming RFCs).

[PS:] The goal of this section is to introduce and summarize the different
phases of PT-TLS.  We felt a brief discussion of the general message flow
was helpful to the reader to understand what occurs during this phase
(similar to what we did in the other sub-sections).  Your correct that this
information is covered later in more detail.

[PS:] I presume this is about the PEN 0 being for the IETF.  Correct, it's
the IETF's name space that administered by the IANA.  What text would you
like to see to make this more clear?  Can we do it in one place, for example
stating that the IETF name space is administered by the IANA?

[PS:] The purpose of this section was just to summarize and enumerate the
message types for vendor id 0.   I don't think it's a general rule that any
message type defined in the IETF (IANA J) name space must (or should be)
supported by all implementations.  It will vary depending on the purpose of
the message so that normative language is included in the descriptions of
the message.

[PS:] I agree, it says "Specification Required also implies use of a
Designated Expert".  The policy is just "Specification Required" so we could
remove the "Expert Review with" and make it clear it's the Specification
Required IANA policy. 

[PS:] I think this is a MUST.  The next sentence just points out that this
normative text might change in a future revision (which is not currently
planned).

[PS:] I ok with making this change, let's see what others think .

[PS:] Not "the entire original message" as its at most the first 1024 bytes
of the offending message.  This allows the recipient to either caches
recently sent messages and/or message identifiers when determining what
caused the error.  We thought this flexibility was useful and had very
little cost.

[PS:] We were hoping to emphasize the aspects of 5226 that are most
important to this specification.  We weren't trying to change how the IANA
policy was interpreted.  Did you think we did so?  Is there a portion of
this text that is most troubling or was this just a question?

 

Nits/editorial comments:

---

From: Paul Sangster <[email-masked]>
Date: Tue, 19 Jun 2012 08:25:43 -0700

NEA has 2 existing RFCs (PA and PB protocols) that use the PEN of 0 in exactly the same way as PT-TLS.  One option might be to change "Reserved" to "Reserved for IETF Use".
From: Roni Even [mailto:[email-masked]]
Sent: Tuesday, June 19, 2012 2:16 AM
To: Paul Sangster; [email-masked]
Cc: 'IETF'; [email-masked]; [email-masked]
Subject: RE: GenART LC review of draft-ietf-nea-pt-tls-05

Hi,
I am OK with your responses. The only thing I am not sure is about using PEN 0 defined in the registry.

Decimal
| Organization
| | Contact
| | | Email
| | | |
0
  Reserved

I was wondering how this enterprise number should be specified since it appears as "Reserved" in the registry. I have no specific suggestion
Roni

From: Roni Even [mailto:[email-masked]]
Sent: Monday, June 04, 2012 2:20 PM
To: [email-masked]<mailto:[email-masked]>
Cc: 'IETF'; [email-masked]<mailto:[email-masked]>
Subject: GenART LC review of draft-ietf-nea-pt-tls-05

Reviewer: Roni Even

Review Date:2012-6-4

IESG Telechat date:

Major issues:

Minor issues:

Nits/editorial comments: