Draft: draft-ietf-tls-tls13

Commentary: PTAL 
 LGTM 
 lgtm 
 Do n't forget no_certificate . 
 Not relevant : nocertificateRESERVED(41 ) , /\ fatal / ,   wrote : 
 Right . I just noticed that we send an empty certificate instead .
Paragraph (version A):
One of the content types supported by the TLS record layer is the
alert type.  Alert messages convey the severity of the message
(warning or fatal) and a description of the alert.  Alert messages
with a level of fatal result in the immediate termination of the
connection.  Like other messages, alert messages are encrypted as
specified by the current connection state.
Paragraph (version B):
One of the content types supported by the TLS record layer is the
alert type.  Like other messages, alert messages are encrypted as
specified by the current connection state.
Paragraph (version B):
Alert messages convey the severity of the message (warning or fatal)
and a description of the alert.  Warning-level messages are used to
indicate orderly closure of the connection (see closure-alerts).
Upon receiving a warning-level alert, the TLS implementation SHOULD
indicate end-of-data to the application and, if appropriate for the
alert type, send a closure alert in response.
Paragraph (version B):
Fatal-level messages are used to indicate abortive closure of the
connection (See error-alerts).  Upon receiving a fatal-level alert,
the TLS implementation SHOULD indicate an error to the application
and MUST NOT allow any further data to be sent or received on the
connection.  Servers and clients MUST forget keys and secrets
associated with a failed connection.  Stateful implementations of
session tickets (as in many clients) SHOULD discard tickets
associated with failed connections.
Paragraph (version B):
All the alerts listed in error-alerts MUST be sent as fatal and MUST
be treated as fatal regardless of the AlertLevel in the message.
Unknown alert types MUST be treated as fatal.
Paragraph (version A):
Error handling in TLS is very simple.  When an error is detected, the
detecting party sends a message to its peer.  Upon transmission or
receipt of a fatal alert message, both parties immediately close the
connection.  Servers and clients MUST forget keys, and secrets
associated with a failed connection.  Stateful implementations of
session tickets (as in many clients) SHOULD discard tickets
associated with failed connections.
Paragraph (version A):
Whenever an implementation encounters a condition which is defined as
a fatal alert, it MUST send the appropriate alert prior to closing
the connection.  For all errors where an alert level is not
explicitly specified, the sending party MAY determine at its
discretion whether to treat this as a fatal error or not.  If the
implementation chooses to send an alert but intends to close the
connection immediately afterwards, it MUST send that alert at the
fatal alert level.
Paragraph (version A):
If an alert with a level of warning is sent and received, generally
the connection can continue normally.  If the receiving party decides
not to proceed with the connection (e.g., after having received a
"user_canceled" alert that it is not willing to accept), it SHOULD
send a fatal alert to terminate the connection.  Given this, the
sending peer cannot, in general, know how the receiving party will
behave.  Therefore, warning alerts are not very useful when the
sending party wants to continue the connection, and thus are
sometimes omitted.  For example, if a party decides to accept an
expired certificate (perhaps after confirming this with the user) and
wants to continue the connection, it would not generally send a
"certificate_expired" alert.
Paragraph (version B):
Error handling in the TLS Handshake Protocol is very simple.  When an
error is detected, the detecting party sends a message to its peer.
Upon transmission or receipt of a fatal alert message, both parties
immediately close the connection.  Whenever an implementation
encounters a condition which is defined as a fatal alert, it MUST
send the appropriate alert prior to closing the connection.