Draft: draft-ietf-quic-recovery

Commentary: by removing a paragraph mentioning pipeACK and moving RFC3168 to a normative reference . 
 In Recovery-31 there are several references that I judge as normative and not informative ones . Section 7.8 : " A sender MAY use the pipeACK method described in Section 4.3 of [ RFC7661 ] to determine if the congestion window is sufficiently utilized . " A normative reference necessary to follow if one selects to use the optional method . Sectiom 7.3.2 : " Implementations MAY reduce the congestion window immediately upon entering a recovery period or use other mechanisms , such as Proportional Rate Reduction ( [ PRR ] ) , to reduce the congestion window more gradually . " Another case of a suggested mechanism , which if one is to follow it requires one to read that PPR reference . Secondly , why the alternative reference style . Section 8.3 : "  can be treated as equivalent to loss ( [ RFC3168 ] ) , but other responses can be specified , such as ( [  ] ) or ( [ RFC8311 ] ) . " So RFC3168 is the normative specification for the treat it equal to loss .  is the TCP alternative back - off an experimental specification for the alternative . And RFC8311 is the process for performing other experiments with alternative responses . I judge all necessary depending on what one intendeds to do . So to my understanding this results in two downrefs to experimental specifications . I think that is acceptable in the context they are used in this document . But to be tried in IETF last call . However , I think I do n't want to generally recommend them to be acceptable as downrefs so I have no intentions to promote them for the  registry . 
 Moving discussion from the PR to the issue . : I 'm not the expert on what should be normative , but these were intentionally marked as informative references since they 're all TCP specific RFCs . The pipeACK reference in particular seems like an odd one . If this is what the chairs want , then I 'm ok with it as an editor , but these choices were intentional . : I see what is saying , but I also see some wiggle room in RFC 3967 , Section 1.1 : When a reference to an example is made , such a reference need not be normative . For example , text such as " an algorithm such as the one specified in [ RFCxxxx ] would be acceptable " indicates an informative reference , since that cited algorithm is just one of several possible algorithms that could be used . I am also somewhat concerned that trying to get the downrefs into the registry is more likely to run into trouble ( Sec 3 ) This procedure should not be used if the proper step is to move the document to which the reference is being made into the appropriate category . It is not intended as an easy way out of normal process . Rather , the procedure is intended for dealing with specific cases where putting particular documents into the required category is problematic and unlikely ever to happen . 
 Thanks for digging up the relevant text , Based on that text from RFC 3967 , it does n't seem like we need to make these references normative . I agree that the pipeACK reference is odd , but I think that 's probably because of the use of MAY there . I 'm happy to replace the MAY with a can -- it is meant to present an option , not a permission -- and make that reference informative as well . : thoughts ? 
 I think at last RFC3168 should be referenced normatively somewhere ( probably section 7.1 though ) because you need to know what the ECN bits are in order to do anything with it . I guess because of section 7.1 . RFC8311 should also be a normative reference . 
 RFC3168 is already a normative reference in the transport doc , which in my view is appropriate . 
 Was wondering about this as well given the transport doc is of course a normative reference of this doc . However , as this doc uses terms like CE also directly itself I think the right practice is to also have it as a normative reference here , and as you have to read it no matter what , it definitely should n't hurt . 
 talks about ECN - CE markings , but really all of Section 7 talks about a response to an increase in ECN - CE count by the peer , which is defined in the transport doc . This does point to a small editorial issue . The text in Section 4.1 says : This really should be : 
 Good point on the editorial issue . 
 With that change , the only thing we 're left with is . This does require an understanding of ECN , and it has RFC 2119 keywords , but it 's really an optional mechanism that is suggested . We could remove the RFC 2119 words there , since they 're really unnecessary . 
 My point is that RFC3168 should be normative because not matter what you need to understand what an ECN - CE mark is and that is defined / specified in RFC3168 . 
  has a point , see 
 -transport is a normative reference . So 3168 is already ( transitively ) a normative reference . The question is whether this specific text requires anything from 3168 to understand . I do n't see that it does , especially given the suggested change , which talks about a concept defined in -transport , not 3168 . 
 has made these editorial changes ; can you see if anything else needs to be done here ? 
 I will note that it was never my intention to let any of theses Experimental or informational TCP specs to be into the downref registry by this last call . So , the pipeack reference needs to be reformulated to not be a normative one . As currently stated it is a clear normative reference per IESG Statement ( [ ] ) , and especially " Note 1 : Even references that are relevant only for optional features must be classified as normative if they meet the above conditions for normative references . " You need to find a formulation that normative describes what the implementation MAY do , and then you can exemplify with the TCP version . Then one in Section 7.3.2 I can accept as still being informative as the MAY statement is related to the primary aspect of the sentence and the reference to PPR is exemplifying . Still this is very much on the border and may still generate a comment in IESG . For RFC 3168 I do n't understand why not making it to a normative one . There are no issues with its status as it is proposed standard . And simply the security consideration section still implies that you need to know what a ECN - CE mark is to interpret this . So please make this one normative . 
 I 'm ok with RFC 3168 being normative , particularly since it 's already normative in transport , but would like to avoid making the others normative . 
 if pipeack is not normative then a reformulation is necessary of that sentence in Section 7.8 to not state is as a mechanism that MAY be implemented . 
 The sentence currently has a can , not a MAY : " A sender can use the pipeACK method described in Section 4.3 of { { ? RFC7661 } } to determine if the congestion window is sufficiently utilized . " But I sent out PR to make it clearer that pipeACK is an example , PTAL and see if that helps . 
 what PR proposes removing that first sentence do resolve the pipeack to me . So merging , and moving RFC3168 to normative will resolve this issue to my understanding . 
 Thanks ! I 'll update PR to include moving RFC3168 to normative . 
 : I believe this is purely editorial , but I 'd like to confirm . 
 We 've meandered to a route that AFAICT makes reference types accurate to their existing intent , or avoids them becoming normative . I 'm happy for this to be editorials .
Paragraph (version A):
A sender can use the pipeACK method described in Section 4.3 of
RFC7661 to determine if the congestion window is sufficiently
utilized.