Channel Bindings for TLS
RFC 5929

Juergen Quittek has made a number of non-blocking editorial comments in his OPS-DIR review. I suggest that these are taken into consideration by the RFC Editor: 

1. Section 2, Introduction, line 1: [RFC5246] -> [RFC5056]
   
2. Sections 3.1, Description
Is it really necessary to keep the almost unreadable original text of the original IANA entry?  It is hard to parse and can easily be misunderstood.
It is an incomplete sentence with two notes embedded into it in brackets.
The following text that was added is readable, the original text has rather limited readability.
If there are strong reasons for keeping the original text, then I would suggest at least to add a line break or an empty line after the original text for marking the beginning of the new (readable) area.
But I would rather suggest to rephrase the first incomplete sentence.
Standards are written to achieve interoperability and this can only be achieved if all implementers read the same semantics from the standards text. My strong recommendation would be to turn this single incomplete sentence with two embedded notes into a few complete sentences of plain text covering also the notes without embedding them with brackets.
Currently, the note in "The first TLS Finished message sent (note:
the Finished struct)" is not very clear to me.
   
3. Section 4.1, Description:
For better readability I would suggest turning the note in brackets into a separate sentence. Different to Section 3.1, the text is clear as it is and no rewording is required, just replacing brackets by full stops.

4. Section 5.1 Description:
It starts with "There is a proposal for adding a "StartTLS" extension to TELNET ...".
It is not clear to the reader who made any proposal, where to find it and why it is relevant for this standard. Reporting about proposals does not seem to be very useful in a description that serves interoperability.

5. Section 6, second paragraph on page 13 starting with "Therefore
'tls-unique'":
The draft states "Therefore 'tls-unique' is generally better than 'tls-server-end-point'". What is generally better? This phrasing does not seem to be precise enough for a standards document.

6. Section 6, fourth paragraph on page 13 starting with "In other words":
The phrase "In other words" does not relate to the previous sentence but to some sentence earlier than that. It is not clear which sentence it refers to.

7. Section 6, fourth paragraph on page 13 starting with "In other words", lines 2-3:
"Channel binding is all or nothing" - this phrase deserves clarification.

8. Section 6, fourth paragraph on page 13 starting with "The specifics", lines
4:
the statement "it is RECOMMENDED that ..., except, perhaps, where ..."
appears to be not precise enough because you use "perhaps". Would it be possible to just remove "perhaps"? Using "Recommended, except, perhaps"
makes it hard for an implementer to understand what to do.

9. Section 7, 1st paragraph, lines 9 and 11: I would remove "(" and ")".

1) The abstract refers to RFC 5056 as "On Channel Binding".  Section 2 refers to "On Channel Bindings" as RFC 5246 (it's TLS 1.2) and it says the registration procedures for these channel bindings are in RFC 5246 (I think they're in 5056).  Should Section 2 read:

OLD:

 Subsequent to the publication of "On Channel Bindings" [RFC5246],
 three channel binding types for Transport Layer Security (TLS) were
 proposed, reviewed and added to the IANA channel binding type
 registry, all in accordance with [RFC5246]


NEW:

 Subsequent to the publication of "Transport Layer Security (TLS)
 Protocol Version 1.2" [RFC5246], three channel binding types for
 Transport Layer Security (TLS) were proposed, reviewed and added
 to the IANA channel binding type registry, all in accordance
 with [RFC5056].

2) Transfer of ownership: Is it transfer of ownership or transfer change control?  And, is it to the IESG or IETF?

3) Should the "should" be "SHOULD" in the last paragraph of 3.1?  6 provides uses requirements language wrt application protocols.  Actually, Section 7 uses "SHOULD" and it's talking about APIs.

4) Is "Subject:" needed in 3.2, 4.2, and 5.2?  It's in 5056.

5) Should the descriptions in 3.2, 4.2, and 5.2 point to <this document> ?

6) Owner/Change control: Should the IESG's email address be included?

7) I think you've got page breaks for the heading in Section 7.  There's four words on Page 6 ;)

8) Is there some reason you're not pointing to FIPS-180-3?  I think -3 obsoletes -2 (not entirely sure of this).

The second paragraph of the interoperability note in 3.1 only applies to connections that
have this channel binding type, but the text is written very generally. Perhaps a few words
for further context would be helpful so the MUST NOT and SHOULD NOT are clearer would
be in order.