On Thu, Apr 2, 2020 at 10:54 AM Michael Welzl <mich...@ifi.uio.no> 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.
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.)
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. :-)
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
