renghardt
commented
5 years ago Based on the replies from Med, apparently he agrees with most of the proposed changes, so we can use them as a starting point for the next version -- if that's okay with you, Cyrill, obviously :)
I'm pushing back on one comment: [Med2] - "IMO, an endhost does not care about a path per se, but about the service it will get when path(s) is/are used to forwarded its packets. Picking a path or any other decision about how to make use of available ones is an outcome of the intended connectivity service. […] This [suggestion to add] is better. I suggest: s/about a path and the services it provides/about services provided via a path" --> While I agree that services are important, I do think that some nodes care about the physical path itself and not just the services. Therefore, I'd like to go with "[information … that an entity … might have or want to have] about a path and the services provided via a path".
Comments on the abstract:
[Med1]: "[Internet paths] assumes a global connectivity. I don’t think this restriction is justified (consider enterprise networks, mesh networks, etc.)." I agree - perhaps change "Internet paths" to "paths across a network"?
[Med2]: "Instead of reasoning about paths, what actually matters is the connectivity service(s) provided via an upstream network." Well, this is the Path-Aware Networking Research Group, so it makes sense to reason about paths, right? Yes, as an endpoint you actually care about what services your path provides, but I'm not sure I want to change any text based on this comment. Maybe add "[information … that an entity … might have or want to have] about a path and the services it provides"?
[Med3]: "A host will have a partial visibility of the available path(s) (and their associated services). The full visibility cannot be established beforehand. Furthermore, such information is volatile (e.g., handover or multi-attachment with session continuity)." I agree, but I'm not sure I want to add text to the abstract based on this. I don't think we imply full visibility here if we talk about "information" that a host can get about paths. But we have to make sure this point is clear in the body of the text.
[Med4]: "GENERAL: the properties are dependent of the direction. Some properties will apply for inbound, outbound, or both." I agree, and I think our (planned) definition accounts for this: Links are unidirectional, the reverse direction is another unidirectional link between the same nodes, and a property applies on a sequence of path elements.
[Med5]: "[Between two hosts] excludes point-to-multipoint communications. Consider the case of an STB which want to retrieve TV channels using multicast." Right now, we define path as between two hosts (will perhaps change to "between two nodes" to include, e.g., overlays, but of course the two nodes can be hosts), and then point-to-multipoint can be expressed as a set of multiple paths, one for each pair of sender and receiver. Then, the same property can apply to multiple paths and, thus, be essentially the point-to-multipoint communication. About the text of the abstract, perhaps changing this to "[properties of paths] between two or more nodes" helps?