Draft: draft-ietf-taps-interface

Commentary: There are many ways to do this , but this one mimics the " private browsing " paradigm " as I understand it . 
 Can you say more ? I read as specifically about flushing state , not Connection Group vs. Connection issues generally . This is not literally " flushing " the state but I 've update taps - interface to reflect this design while , I think , preserving the spirit of the original text . 
   used to be about state and context sharing as well as entanglement . Now it 's about entanglement . We need to rename Connection Groups ( " connection contexts " ? ) in the architecture to replace the existing " group " concept , and to retain " connection group " in the API for entanglement . 
 Seems like this could be 360 degrees of rotation in our thinking ? ( which could be OK , NEAT was written to specify both contexts and flow groups ) . Let 's try some definitions here and see if we converge ... 
 I think brings this back in synch again so no need to rename , possibly the last part of this section in architecture should be removed though as we do not have fine - grained control 
 Section 9.1 of taps - impl loosely refers to the need for an interface to " flush protocol state " to preserve anonymity , but such a capability is not in taps - interface . 
 I do n't like this text : " Applications must have a way to flush protocol cache state if desired . This may be necessary , for example , if application - layer identifiers rotate and clients wish to avoid linkability via trackable TLS tickets or TFO cookies . " Those of you who know me , would immediately see a " MUST" ... "if desired . " and a " may be necessary " . My suggestion is that this digs too deep , and we should remove the text . I could also live with something more neutral though : Note : There are case where applications need to flush protocol cache state , for example , if application - layer identifiers rotate and a client wishes to avoid linkability of trackable TLS tickets or TFO cookies . 
 I 'm fine to have the more neutral sentence proposed by  . I do n't think we should specify an interface for it but I think it 's good to mention . 
 I agree that the best approach is to make it more neutral . The other option would be to say that this interface is implementation specific . For sure , we do not want it in the API I think . 
 I have no opinion on  's comment , but I 'm a bit mystified by the " should n't be in the API doc " argument . Perhaps I 'm not understanding the purpose of taps - interface ? I thought it was a qualitative description of the controls offered to the application , which this clearly would be ! 
 I would define taps as an interface to control network connections . So flushing state is a good thing in some scenarios for privacy but not really needed to handle network connections . 
 See also -- this surfaced that we have drifted on connection group versus context , which we need to fix in arch . 
  to write a PR against API to propose a context API that would provide the intent of this functionality . Alternative is to NOP this in the API doc ( " connection contexts are too implementation specific to expose in a general way " or similar ) 
 A second alternative is a one - bit fix : a selection property that requires a given connection to be in a separate connection context ( which implies a separate connection group ) from other connections created in the preconnection . 
 A very nice approach IMO , thanks for doing thisI like this approach for the simplicity , but it still solves only half of the problem we have with connection groups vs. connection contexts . I am fine with merging this , but IMHO it does not fully Thanks looks good to me now .
Paragraph (version B):
Note that this does not guarantee no leakage of information, as
implementations may not be able to fully isolate all caches (e.g.
RTT estimates).  Note that this property may degrade connection
performance.