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

From: Theresa Enghardt <[email-masked]>
Date: Thu, 1 Apr 2021 19:12:07 -0700

Hi Med,

Thanks for your comments.

Please see inline:

On 3/26/21 1:09 AM, [email-masked] wrote:
>> -----Message d'origine-----
>> De : Panrg [mailto:[email-masked]] De la part de Theresa
>> Enghardt
>> Envoyé : vendredi 26 mars 2021 03:02
>> À : Holland, Jake <[email-masked]>; [email-masked]; draft-irtf-
>> [email-masked]
>> 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

---

From: <[email-masked]>
Date: Wed, 7 Apr 2021 13:05:35 +0000

Hi Theresa, all,

Please see inline. 

Cheers,
Med

> De : Theresa Enghardt [mailto:[email-masked]]
> Envoyé : vendredi 2 avril 2021 04:12
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>;
> Holland, Jake <[email-masked]>; [email-masked]; draft-irtf-
> >> Enghardt Envoyé : vendredi 26 mars 2021 03:02 À : Holland, Jake
> >> <[email-masked]>; [email-masked]; draft-irtf-
> >> [email-masked] Objet : Re: [PANRG] Review of
> >> draft-irtf-panrg-path-properties-02
> >>
> >> […]
> >>
> >> 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).
> >

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

> terminates the TCP connection, so it isn't transparent to any

[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

[Med] This would be useful, indeed. 

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

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

> model.

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

 But maybe talking about implicit VS. explicit signalling can
> helpful, possibly referring to RFC 8558?

_________________________________________________________________________________________________________________________

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.

---

From: Theresa Enghardt <[email-masked]>
Date: Tue, 20 Apr 2021 15:24:40 -0700

Hi Med, all,

Please see inline.

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

[TE] I see, thanks for the clarification. Our draft's definition would 
surely not classify these as transparent with respect to HTTP or TCP, 
and I agree that it'll be good to clarify this overlap in terminology.

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

[TE] How would you define transparency to endpoints? There could be a 
distinction between whether an endpoint explicitly communicates with the 
on-path node (e.g., explicit signals as discussed in RFC 8558). Is this 
the same as the "accepting a service that will be provided" that you 
mention below?

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

[TE] Yes, I we probably can't capture all nuances in the Path Properties 
draft.

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

[TE] Oh, this is basically the same point made above: Transparency can 
be difficult to define and I think a definition based on nodes that can 
send, receive, forward, or modify packets won't capture all nuances.

Best,
Theresa

---

From: <[email-masked]>
Date: Wed, 21 Apr 2021 05:26:47 +0000

Hi Theresa, 

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 21 avril 2021 00:25
> >>> endpoints (unlike explicit mode) and while its presence is not
> >>> easily detected by the endpoints (e.g., transparent proxies).
> >>>
> >> 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.
> 
> [TE] I see, thanks for the clarification. Our draft's definition
> would surely not classify these as transparent with respect to HTTP
> or TCP, and I agree that it'll be good to clarify this overlap in
> terminology.
> 

[Med] Thanks. 

> >> 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.
> 
> [TE] How would you define transparency to endpoints?

[Med] This can be defined as adding an intermediate function to a communication without an explicit signal/consent from one of the endpoints.  

 There could be a
> distinction between whether an endpoint explicitly communicates with
> the on-path node (e.g., explicit signals as discussed in RFC 8558).
> Is this the same as the "accepting a service that will be provided"
> that you mention below?

[Med] Yes. 

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