Draft: draft-ietf-quic-transport

Commentary: This just writes down what was proposed in . 
 Looks fine , but what about some guidance on stream vs connection errors ? And also the principle of nearly always choosing a hard protocol violation error , or a more granular error with same effect ? 
 Stream vs. connection is something that application protocols ( like HTTP ) need to worry about . The transport only concerns itself with connection errors . The idea that you pick the most helpful error is not something that we need to codify ( in my view ) . 
 Is n't that worth mentioning ? Or do we already have such text ? 
 This is already discussed in Section 11 , which makes me wonder if it would make more sense for text on this PR to be placed there too . 
 This I do not disagree with . I was merely suggesting that we explain why , as a general rule , a hard error is preferred as a design principle , not the nature of the error message which I do think should have a large degree of freedom . 
 Maybe there is a followup needed for the HTTP draft . If the principles are generally the same , we can copy the text and then add some more to cover the idea that we make most errors fatal to the connection rather than the stream . 
 I like Lucas suggestion of adding this text to the existing and already fairly complete text in section 11 . 
 I moved the second paragraph up to the error handling section , but the text about how codes are selected really belongs with the codes themselves . 
 We do n't really have any real principles that we agree on for deciding what error codes we are describing . Proposal : the error carries distinct semantics ( like stream rejection in HTTP ) , then it gets a new error code the error is frequent or particularly significant , then it gets a new error code , target a more generic error code that identifies the broad area of the protocol , if there is no more specific applicable error code , use PROTOCOL_VIOLATION 
 is example of an issue discussed where it would have been useful to have principles .
Paragraph (version A):
The most appropriate error code (error-codes) SHOULD be included in
the frame that signals the error.  Where this specification
identifies error conditions, it also identifies the error code that
is used.
Paragraph (version B):
The most appropriate error code (error-codes) SHOULD be included in
the frame that signals the error.  Where this specification
identifies error conditions, it also identifies the error code that
is used; though these are worded as requirements, different
implementation strategies might lead to different errors being
reported.  In particular, an endpoint MAY use any applicable error
code when it detects an error condition; a generic error code (such
as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place
of specific error codes.
Paragraph (version B):
In defining these error codes, several principles are applied.  Error
conditions that might require specific action on the part of a
recipient are given unique codes.  Errors that represent common
conditions are given specific codes.  Absent either of these
conditions, error codes are used to identify a general function of
the stack, like flow control or transport parameter handling.
Finally, generic errors are provided for conditions where
implementations are unable or unwilling to use more specific codes.