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

[[e-mail]]

Hi Theresa, all,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Theresa Enghardt [mailto:[e-mail]]
> Envoyé : vendredi 2 avril 2021 04:12
> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>;
> Holland, Jake <[e-mail]>; [e-mail]; draft-irtf-
> [e-mail]
> Objet : Re: [PANRG] Review of draft-irtf-panrg-path-properties-02
> 
> 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.
> 

[Med] Great. Thanks.

> 
> > [… 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?

[Med] I'm afraid that some functions that are "traged" as transparent in operational networks are doing more than that. For example, in mobile network there are functions that inject/strip headers (HTTP headers), TCP options, etc. 

> 
> 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

[Med] I think we could reason in term of "transparency to endpoints" in general, not only to a protocol.  

> that is lower in the stack than HTTP. Do you agree? Maybe this could
> be
> one clarifying example.

[Med] This would be useful, indeed. 

> 
> 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

[Med] This means that an endpoint accepts whatever "service" that will provided by the node that is explicitly added to the communicated path. This is mainly from the sender standpoint. An interesting feature that we may consider is to associate a remote peer on the "consent" process to involve an intermediate function. 

 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.

[Med] I agree this is a separate property that it is worth to capture in the I-D. 

> This might be useful to have, but maybe it's too difficult to
> accurately
> model.

[Med] Not sure what you meant by "model".


 But maybe talking about implicit VS. explicit signalling can
> be
> helpful, possibly referring to RFC 8558?
> 
> Thoughts, anyone?
> 
> 
> Best,
> Theresa


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.