Original text:
6.3.1.5.3. <del> The known_configuration extension allows the client to indicate that it wishes to reuse the server's known configuration and semi-static (EC)DHE key (see server-configuration for how to establish these configurations.  This extension allows the omission of the server certificate and signature, with three potential benefits: </del>  Shortening the handshake because the certificate may be large. the server's (EC)DHE key from the identified configuration and the client's key found in the ClientKeyShare.  If no key from an acceptable group is in the ClientKeyShare, the server MUST ignore the <del> known_configuration extension.  When this mechanism is used, the </del>  server MUST NOT send a Certificate/CertificateVerify message unless the ServerConfiguration message is also sent. <del> When the known_configuration data extension is in use, the handshake hash is extended to include the server's configuration data and certificate (see the-handshake-hash) so as to tightly bind them </del>  together. 6.3.1.5.4. <del> The pre_shared_key extension is used to indicate the identity of the pre-shared key to be used with a given handshake in association with a PSK or (EC)DHE-PSK cipher suite (see RFC4279 for background). </del>  %%% Hello Messages the application traffic key.  This message creates a pre-shared key (PSK) binding between the resumption master secret and the ticket label.  The client MAY use this PSK for future handshakes by <del> including it in the pre_shared_key extension in its ClientHello (pre- shared-key-extension) and supplying a suitable PSK cipher suite. </del>  %%% Ticket Establishment struct { uint32 ticket_lifetime_hint; opaque ticket<0..2^16-1>; } NewSessionTicket;

Reviewer comments:
Some fixes for things I didn't catch when I checked for typos in the big patch last time. Of note, you're missing a closing brace for the select in "PreSharedKeyExtension" and a semicolon after "KnownConfigurationExtension". I also corrected things to match the existing (admittedly unusual) indentation style of the document and put quotes around the extension IDs you missed. (some had them; some didn't)
Ok, spaces between cases reverted. I also added a similar bit of whitespace in another new extension.

Revised text:
6.3.1.5.3.  <ins> The "known_configuration" extension allows the client to indicate that it wishes to reuse the server's known configuration and semi- static (EC)DHE key (see server-configuration for how to establish these configurations.  This extension allows the omission of the server certificate and signature, with three potential benefits: </ins> Shortening the handshake because the certificate may be large. the server's (EC)DHE key from the identified configuration and the client's key found in the ClientKeyShare.  If no key from an acceptable group is in the ClientKeyShare, the server MUST ignore the  <ins> "known_configuration" extension.  When this mechanism is used, the </ins> server MUST NOT send a Certificate/CertificateVerify message unless the ServerConfiguration message is also sent.  <ins> When the "known_configuration" data extension is in use, the handshake hash is extended to include the server's configuration data and certificate (see the-handshake-hash) so as to tightly bind them </ins> together. 6.3.1.5.4.  <ins> The "pre_shared_key" extension is used to indicate the identity of the pre-shared key to be used with a given handshake in association with a PSK or (EC)DHE-PSK cipher suite (see RFC4279 for background). </ins> %%% Hello Messages the application traffic key.  This message creates a pre-shared key (PSK) binding between the resumption master secret and the ticket label.  The client MAY use this PSK for future handshakes by  <ins> including it in the "pre_shared_key" extension in its ClientHello (pre-shared-key-extension) and supplying a suitable PSK cipher suite. </ins> %%% Ticket Establishment struct { uint32 ticket_lifetime_hint; opaque ticket<0..2^16-1>; } NewSessionTicket;