See below.
On 03/04/2020 11:20, Michael Welzl wrote:
Hi,
On Apr 2, 2020, at 10:42 PM, Kyle Rose <kr...@krose.org
<mailto:kr...@krose.org>> wrote:
On Thu, Apr 2, 2020 at 10:54 AM Michael Welzl <mich...@ifi.uio.no
<mailto: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.
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.
To me:
Traffic profile makes me think of TSpec, MF-Classifier, etc. Something
that I can define within a network device that will decide what
forwarding behaviour I see, and how I may police to this. in DS, this
could be defined as "A traffic profile specifies the temporal properties
of a traffic stream selected by a classifier. It provides rules for
determining whether a particular packet is in-profile or
out-of-profile." [RFC2475]. To me this isn't that?
Capacity is about how fast a sender can currently send along a path. My
expectations for accessing capacity might be related to the treatement I
tell the network that I wish to receive, such as the DSCP that is set.
However, this isn't a capacity specification, and a capacity profile is
just about OK to me - but not perfect, because the description doesn't
"profile" capacity.
I'd be OK with a range of words here - and not OK with some others.
Other possibilities could be:
"Network Service"
"Network Service Marking"
Or even more-specific:
"DS Marking"
I would be very happy to think upon others - but the keyword space is
limited and we should avoid overlap with terms that mean something else :-).
Gorry
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
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
--
G. Fairhurst, School of Engineering
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
