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? Cheers, Michael - - - PS: I believe that the ones below are resolved, but I'm repeating them here in case someone disagrees with an answer: 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. 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. 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. _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
