Draft: draft-ietf-taps-interface

Commentary: wrote : " Why is the text talking about " many properties " that can no longer be changed , instead of relying on the earlier , nice and clear distinction between Selection and Connection Properties ? " . = In line with the suggestion from this is now changed , it says Selection Properties . wrote : " Where earlier , Selection Properties were said to remain readable , now they are only queryable ? " . = In line with answer , this PR replaces " query " with " read " in this text . wrote : " Are " applied " Selection Properties still Selection Properties ? Should n't they better be referred to using a different term ? " and here , suggested : " In the , we define Protocol Stack as a Transport Services implementation concept , and we talk about a certain protocol stacks providing certain features ( see . Perhaps we could rephrase this part of the API draft to use that terminology , e.g. , the application can query the actually used protocol stack and then know which Transport Features it supports . " = I do n't know how to apply this change , and it generally sounds a bit complicated to me . I think that Selection Properties should keep their name . Regarding the confusing text with the example , I removed this and I think it makes things clearer . Regarding the return type , I think I now finally understood the bigger problem . Returning a Boolean instead of a Preference should make sense and should be easy to implement ( as also described in this PR ) . The problem is that not all Selection Properties are of type Preference . E.g. , is an enumeration , representing , or . What sense does it make if this becomes only or ? Similarly , and are of type " Collection of ( Preference , Enumeration ) " , and indeed it would make sense to expect a Collection of booleans , not a singular boolean . This PR now explicitly says that , upon reading , the Preference type of a Selection Property ( not the whole Selection Property ! ) changes into Boolean . 
 MANY thanks for the proposed fix ( which I committed ) ! I had n't really understood the problem just from reading the issue discussion . 
 As , here follows a bit of feedback on the different Property types in the Interface draft , from the perspective of an academic developer who is currently attempting to follow the draft spec as closely as possible while trying to implement a path - aware transport system in a In , it says : At this point , the reader of the document could be expected to conclude the following : Selection Properties are a set of preferences for protocol / path selection that ( obviously ) can no longer be meaningfully changed once a connection has been established . Connection Properties are a set of " run - time preferences " for connections which could still be adjusted when a connection is already established , but should ideally already be known during protocol / path selection The text goes on to state : With this wording , the reader can now reasonably conclude that the original Selection Properties that have resulted in a given Connection should remain available during the lifetime of that Connection , perhaps in form of a copy of the original data structure . So far so straight forward . In however , this conclusion is called into question . After the text has gone on to introduce the 5 different   , it states At this point , the reader becomes confused . Why is the text talking about " many properties " that can no longer be changed , instead of relying on the earlier , nice and clear distinction between Selection and Connection Properties ? Where earlier , Selection Properties were said to remain readable , now they are only queryable ? The type of a Selection Property that has been " applied " mutates from a Preference Level to become a Boolean ? Are " applied " Selection Properties still Selection Properties ? Should n't they better be referred to using a different term ? So the original Selection Preferences that resulted in the current Connection are not available after all ? Only the ( Boolean ) Properties of the chosen Protocol can be " queried " ? But wait , the text goes on : This is a complicated way of saying that the values only reflect the actual Properties of the chosen Connection and ( in direct contradiction to the previous paragraph ) do not actually indicate whether a Selection Property has also been " applied " or not . ( A Boolean only carries exactly one bit of information after all . ) In other words , the Protocol Properties can be queried . The usefulness of this is probably limited however . If we already know that our Connection is using , e.g. , TCP , we do n't have to issue any " queries " to know that the Connection offers reliable transport , is subject to congestion control and preserves packet ordering . ( This is indeed how I have chosen to implement this . The chosen Protocol can be queried for the Properties it inherently has . In the Preconnection phase , the Selection Preferences are matched against these and any / conflict results in that Protocol being dropped from consideration . ) Hoping not to be unreasonable ( or somehow block - headed ) , I have the following suggestions Either introduce a new term for Properties that have been " applied " , or Use the term " Preferences " ( e.g. , " Selection Preferences " , " Connection Preferences " ) to refer to a collection of adjustable " Settings " and the term " Properties " to refer to measured or queried values that are actual Properties of underlying Connections and Protocols Go into a bit more detail about what the draft really means when talking about " querying " Properties ( versus setting them ) , maybe even in terms of exemplary interactions with Property data structures . ( After all , the draft elsewhere goes into considerable detail with it 's exemplary Event - based system ) Think about whether it in general would clear things up when the explicit notion of Protocol Properties as a ( static ) counterpoint to ( adjustable ) Selection Properties is introduced 
 ( Replying as an individual and co - author ) Thanks for raising this issue ! Yes , this matches my understanding is well . If the later text confuses this issue for the reader , then perhaps we 'll need to tweak it . I 'd say that Selection Properties can no longer be changed , Connection Properties still can be changed ( though maybe changing a Connection Property later would not have any effect , e.g. , if Capacity Profile changes but was only taken into account when selecting a path ) . Perhaps the text should reflect that . For me , these are synonyms , whereby a " query " is what the application has to do in order to read the properties . Perhaps the " queried " should become " read " to avoid confusion . That is indeed how I think of it on a conceptual level , but I understand how this might confuse implementers , especially if they ca n't just change a data type of a property . In the , we define Protocol Stack as a Transport Services implementation concept , and we talk about a certain protocol stacks providing certain features ( see . Perhaps we could rephrase this part of the API draft to use that terminology , e.g. , the application can query the actually used protocol stack and then know which Transport Features it supports . I would strongly prefer using our existing terminology to introducing yet another term . Good question . I vaguely remember discussing this , and I think folks felt like querying the Selection Properties that the application had set was not very useful at that stage . The other text you quoted indeed sounds a bit complicated and maybe it can be reworded to be clearer . Curious to hear what my co - authors and/or other TAPS participants think ! 
 I completely second what wrote . With regards to querying the Transport Features selected vs. getting the preferences provided earlier , I remember we had lengthy discussions and somewhat converged to the current state . Primary arguments ware Multiple read / query variants are confusing Original Preferences are not really useful - if you really want to read them later , keep the Preferences Object Constrained implementations do n't want to be forced to store them . based on these arguments , what option would you prefer a ) different get / query operations of selection properties after the connection has been set up b ) the current way of " mutating " preferences with clearer description in the text 
 Just to add : having finally gotten around to carefully reading this , I also completely agree with everything wrote . This is exactly how I would have answered , and her suggestions are exactly what I think should be done to address these comments . I also agree with that these were the arguments regarding querying the querying issue , and I agree with the arguments as well . The quoted text containing the example is a great catch ! Such a terribly convoluted paragraph . I have a nagging feeling that this was my fault ! :-( 
 PR tries to solve this ; the PR itself contains a full explanation of my rationale for the changes . Please take a look ! 
 Great , this looks good to me now . I think now it is simple enough that we do n't need an example anymore . Looks good , one clarification suggestedWorks for me ( with changes ) . I would propose a slight rewording -and add a hint that this exposing can also be implemented differently .
Paragraph (version B):
connection-props provides a list of Connection Properties, while
Selection Properties are listed in the subsections below.  Selection
Properties are only considered during establishment, and can not be
changed after a Connection is established.  After a Connection is
established, Selection Properties can only be read to check the
properties used by the Connection.  Upon reading, the Preference type
of a Selection Property changes into Boolean, where "true" means that
the selected Protocol Stack supports the feature or uses the path
associated with the Selection Property, and "false" means that the
Protocol Stack does not support the feature or use the path.
Implementations of Transport Services systems may alternatively use
the two Preference values "Require" and "Prohibit" to represent
"true" and "false", respectively.