Hi,
> On Apr 2, 2020, at 10:42 PM, Kyle Rose <[email protected]> wrote: > > On Thu, Apr 2, 2020 at 10:54 AM Michael Welzl <[email protected] > <mailto:[email protected]>> wrote: > Hi, > > I sifted through the review now, trying to address some easy things, removing > some more things that were already addressed, creating issues for things that > require some discussion… as a result, we now have new PR #515, issues #520 - > #526, and here is one item thatI’d like to check with Kyle via this email: > > 5.2. Specifying Transport Properties > > * Using the same enum (Require(d[sic])/Avoid/Ignore) for the queried output > of selected properties seems like a shortcut that will lead to some confusion. > > MW: I agree; partially addressed: s/Required/Require wherever it's a > Preference level. > > Kyle: FWIW, my objection to the other issue (using a normative term as an > indication of what was chosen) isn't that it's underspecified, only that it's > confusing. I put it roughly in the same category as specifying -1 as an error > indicator in an abstract API. Is the idea that the output parameters could be > fed into the protocol selection logic for a subsequent connection to select > the same protocol? Is that useful? > > Philipp Tiesel: We had text saying that these should turn into Boolean when > queried and should reflect whether the protocol stack chosen provides the > feature. I will have to double-check whether this text is still in the > description of the preference type. > > MW: I found this text: "Querying a Selection Property after establishment > yields the value Require for properties of the selected protocol and path, > Avoid for properties avoided during selection, and Ignore for all other > properties." - this seems ok to me. Kyle? > > I don't have a strong opinion about it. I just find it potentially confusing. > Just in case, the alternative I had in mind was having an output enum > something like { Selected, Avoided, Ignored } independent of the input type. > As long as you understand this and are still okay with the interface you've > chosen, that is fine by me. I got it now, and I think your proposal is much better. I’ll do this in a PR. > If you go with the existing approach, I wonder if "Avoid" should be > "Prohibit", analogous to "Require" for selected properties. (Similarly, maybe > the opposite of "Selected" is "Prohibited" in my alternative approach.) > > 11.1.10. Capacity Profile > > * Very little of this section is about capacity. Traffic Profile? > > Gorry Fairhurst: > > I don't much like Traffic Profile - to a traffic profile specifies the > > characteristics of the traffic the sender is transmitting, not the > > treatment that traffic expects from the network service. > > I'm trying to think of "capacity" as "path and protocol selection and network > treatment", but it's just not clicking. Maybe there's a term of art > definition of "capacity" I'm just not familiar with. I buy "capacity" as > "network treatment", but path selection and protocol selection are both > properties of the traffic as defined by the endpoints, is it not? Maybe > "Capacity and Traffic Profile"? (Again, not something I feel especially > strongly about.) I also don’t have a strong opinion about this, but I’ll leave it for Gorry to answer. > 5.2.11. Provisioning Domain Instance or Type > > * What about ordering of similar interfaces? I have a 2-SIM cellphone with > wifi. > > Philipp Tiesel: > > Each cellular provider will have a unique PVD. > > SGTM. > > 8.2. Receive Events > > * "A call to Receive will be paired with a single Receive Event" or possibly > multiple ReceivedPartial Events? > > * Also, can the draft be consistent about Receive vs. Received, et al.? > > MW: I can't find a consistency problem; I think that some such things were > already fixed with recent PR's, perhaps this problem has self-resolved. > > Also LGTM. > > Thanks for the thoroughness, BTW. This is also the kick in the ass I needed > to get back to looking at this. :-) Thanks to you for your careful review! Cheers, Michael
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
