Re: [PANRG] Review of draft-irtf-panrg-path-properties-02

[Theresa Enghardt <[e-mail]>]

Hi Med,

Thanks for your comments.

Please see inline:

On 3/26/21 1:09 AM, [e-mail] wrote:
>> -----Message d'origine-----
>> De : Panrg [mailto:[e-mail]] De la part de Theresa
>> Enghardt
>> Envoyé : vendredi 26 mars 2021 03:02
>> À : Holland, Jake <[e-mail]>; [e-mail]; draft-irtf-
>> [e-mail]
>> Objet : Re: [PANRG] Review of draft-irtf-panrg-path-properties-02
>>
>> […]
>>
>> I agree it would be good to substitute "entity" with a more specific
>> term in many instances later in the document.
>>
>> However, I am not sure what a good term for these is, as I'm not sure
>> I
>> want to overload "Node". But maybe it actually is a Node, which may
>> be
>> on-path or off-path, and maybe in some cases it has to be on-path?
> [Med] Not sure about this. I'd prefer to add an entry for "entity" in Section 2 to cover the intended usage (data plane, control plane, on-path, off-path, can be a node/host).

[TE] Agreed, perhaps this makes sense, and I agree that the distinction 
between data plane and control plane can be useful here.


> [… on Transparency ...]
> [Med] FWIW, another common usage of "transparent" is when a network function is invoked without requiring any signaling from the endpoints (unlike explicit mode) and while its presence is not easily detected by the endpoints (e.g., transparent proxies).
>
> It would be useful if the overlap with the common usage is clarified/avoided. Thank you.

[TE] RFC 2616 defines a transparent proxy as "a proxy that does not 
modify the request or response beyond what is required for proxy 
authentication and identification." Is this the definition you'd use as 
well, or are you referring to a different definition?

For the RFC 2616 definition, I think our Transparency definition 
actually covers that - if the proxy neither blocks nor modifies the HTTP 
payload, it is transparent to these parts of the packet, but it does 
potentially modify other parts of the packet. Also, it most likely 
terminates the TCP connection, so it isn't transparent to any protocol 
that is lower in the stack than HTTP. Do you agree? Maybe this could be 
one clarifying example.

Beyond the transparent proxy, I'm wondering if "This node explicitly 
communicates with the endpoint" is another type of (Non-)Transparency, 
next to "block", "modify", and "read". Explicit communication between 
node and endpoint perhaps already means that the node modifies packets, 
but it's a bit more high-level, talking about the semantics of the 
modification, and implies intention. Maybe it's a separate property. 
This might be useful to have, but maybe it's too difficult to accurately 
model. But maybe talking about implicit VS. explicit signalling can be 
helpful, possibly referring to RFC 8558?

Thoughts, anyone?


Best,
Theresa