Subject: Re: [tcpm] 793bis: what to say about source routing

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 3 Dec 2021 10:51:00 +0000

Hi all,

The existing 793bis test already implies that use of source routing is optional, since it starts with an if-clause.

For what it is worth, I think that we could add a comment along the lines of „source routing may be disabled or unsupported on some systems“ to make this more explicit. I don’t see much harm in such an informative statement. If we go down this route, IMHO the 793bis spec does not have to discuss why stacks implement or don’t implement features below TCP.

Having said this, I don’t see a strong need for any additional wording. I just don’t object to a brief note.

In any case, as long as there is no other PS or BCP guidance, the normative statements in 793bis should not change 1122.

Michael (with no hat whatsoever) 

From: tcpm <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, December 1, 2021 5:44 AM
To: Gorry Fairhurst <[email-masked]>
Cc: tcpm IETF list <[email-masked]>
Subject: Re: [tcpm] 793bis: what to say about source routing

Hi, Gorry, 

To me, your final point is the most significant. 

Notably, putting the proposed note in TCP would suggest either that IP source routing is deprecated (it isn’t) or that TCP support for it should be considered optional (it should not) - regardless of whether is deprecated in the future or not.

Joe

—

Joe Touch, temporal epistemologist

www.strayalpha.com <http://www.strayalpha.com> 

On Nov 30, 2021, at 1:17 AM, Gorry Fairhurst <[email-masked]> wrote:

To me the security concerns are not relevant here - this is a transport spec., and the mechanisms below need to be designed correctly, and while an exmaple or two are good, it seems rather silly to state or enumerate the different sub-transport protocols or their individual concerns.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 3 Dec 2021 07:38:05 -0800

Hi, Michael,

Although *use* of source routing with TCP is optional, *support for* source routing is not.

Source routing is not deprecated for IPv4 and we should not imply support for it in TCP is optional in any way.

TCP isn’t deciding whether to use source routing, so this doc has no rationale for warning about whether source routing is enabled or not.

Joe

—
www.strayalpha.com

> On Dec 3, 2021, at 2:51 AM, Scharf, Michael <[email-masked]> wrote:
> 
> Hi all,
>  
> From: tcpm <[email-masked] <mailto:[email-masked]>> On Behalf Of [email-masked] <mailto:[email-masked]>
> To: Gorry Fairhurst <[email-masked] <mailto:[email-masked]>>
> Cc: tcpm IETF list <[email-masked] <mailto:[email-masked]>>
> www.strayalpha.com <http://www.strayalpha.com/>
> 
> 
> On Nov 30, 2021, at 1:17 AM, Gorry Fairhurst <[email-masked] <mailto:[email-masked]>> wrote:
>  
> _______________________________________________
> tcpm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>

---

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 3 Dec 2021 16:17:25 +0000

Hi Joe,

Maybe the statement

“use of source routing may be disabled on some systems”

would just avoid the terms “support” and “implementation”?

Anyway, I am not a native speaker, and I don’t have a strong personal preference.

Michael

From: [email-masked] <[email-masked]>
Sent: Friday, December 3, 2021 4:38 PM
To: Scharf, Michael <[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>; tcpm IETF list <[email-masked]>
Subject: Re: [tcpm] 793bis: what to say about source routing

Hi, Michael,

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com>

On Dec 3, 2021, at 2:51 AM, Scharf, Michael <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

From: tcpm <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, December 1, 2021 5:44 AM
To: Gorry Fairhurst <[email-masked]<mailto:[email-masked]>>
Cc: tcpm IETF list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tcpm] 793bis: what to say about source routing

Hi, Gorry,

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com/>

On Nov 30, 2021, at 1:17 AM, Gorry Fairhurst <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 3 Dec 2021 09:44:13 -0800

Hi, Michael,

I’m left wondering a question - so? I.e., SR may be disabled. So what? 

If we say anything, it should be:

“TCP MUST support use of non-deprecated IP capabilities that affect its implementation.”

But do we even really need to say that? I don’t think so. And we definitely don’t need to call out SR or anything else in that regard in this doc.

Joe

—

> On Dec 3, 2021, at 8:17 AM, Scharf, Michael <[email-masked]> wrote:
> 
> Hi Joe,
>  
> Maybe the statement
>  
> On Dec 3, 2021, at 2:51 AM, Scharf, Michael <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi all,
>  
> [email-masked]

---

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 3 Dec 2021 19:32:28 +0000

Joe,

793bis inherits text on Source Routing from 1122 (well, “SR” also has another meaning in RTG).

If we keep the wording from 1122 in 793bis, this IMHO is a reason to call out Source Routing. So, I’d be fine in adding a small informational warning sign to put these 1122 requirements in the right context. But I also agree to your argument that terms such as “support” or “implementation” should best be avoided. In a nutshell, I don’t think we are in strong disagreement.

Maybe let’s just give others the opportunity to speak up as well.

Michael

Sent: Friday, December 3, 2021 6:44 PM

Hi, Michael,

Joe

—

On Dec 3, 2021, at 8:17 AM, Scharf, Michael <[email-masked]<mailto:[email-masked]>> wrote:

Hi Joe,

Maybe the statement

Michael

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Friday, December 3, 2021 4:38 PM
To: Scharf, Michael <[email-masked]<mailto:[email-masked]>>
Cc: Gorry Fairhurst <[email-masked]<mailto:[email-masked]>>; tcpm IETF list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tcpm] 793bis: what to say about source routing

Hi, Michael,

Joe

—

Hi all,

Hi, Gorry,

Joe

—

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 3 Dec 2021 11:37:03 -0800

Agreed - let’s hear from others…

—

> On Dec 3, 2021, at 11:32 AM, Scharf, Michael <[email-masked]> wrote:
> 
> Joe,
>  
> From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> 
> To: Scharf, Michael <[email-masked] <mailto:[email-masked]>>
> On Dec 3, 2021, at 8:17 AM, Scharf, Michael <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Joe,
>  
> Maybe the statement
>  
> From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> 
> To: Scharf, Michael <[email-masked] <mailto:[email-masked]>>
> Cc: Gorry Fairhurst <[email-masked] <mailto:[email-masked]>>; tcpm IETF list <[email-masked] <mailto:[email-masked]>>

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Mon, 6 Dec 2021 09:21:49 -0800 (PST)

> Agreed - let?s hear from others?

Given this "request", I am in agreement with Joe Touch on that 793bis should
not being including language on IP source routing.  In software terms this would be
a layering violation, and those usually are avoided if at all possible.

The handling of IP layer functionality belongs in RFC791, and follow on
documents that cover hosts (RFC1122/23) and routers (RFC1812). 

Regards,
Rod Grimes

> ?
> > 793bis inherits text on Source Routing from 1122 (well, ?SR? also has another meaning in RTG).
> >  
> > If we keep the wording from 1122 in 793bis, this IMHO is a reason to call out Source Routing. So, I?d be fine in adding a small informational warning sign to put these 1122 requirements in the right context. But I also agree to your argument that terms such as ?support? or ?implementation? should best be avoided. In a nutshell, I don?t think we are in strong disagreement.
> >  
> > Maybe let?s just give others the opportunity to speak up as well.
> >  
> > Michael
> >  
> >  
> >  
> > I?m left wondering a question - so? I.e., SR may be disabled. So what? 
> >  
> > ?TCP MUST support use of non-deprecated IP capabilities that affect its implementation.?
> >  
> > But do we even really need to say that? I don?t think so. And we definitely don?t need to call out SR or anything else in that regard in this doc.
> >  
> > Joe
> >  
> > ?
> > ?use of source routing may be disabled on some systems?
> >  
> > would just avoid the terms ?support? and ?implementation??
> >  
> > Anyway, I am not a native speaker, and I don?t have a strong personal preference.
> >  
> > Michael
> >  
> >  
> >  
> > TCP isn?t deciding whether to use source routing, so this doc has no rationale for warning about whether source routing is enabled or not.
> >  
> > Joe
> >  
> > ?
> > For what it is worth, I think that we could add a comment along the lines of ?source routing may be disabled or unsupported on some systems? to make this more explicit. I don?t see much harm in such an informative statement. If we go down this route, IMHO the 793bis spec does not have to discuss why stacks implement or don?t implement features below TCP.
> >  
> > Having said this, I don?t see a strong need for any additional wording. I just don?t object to a brief note.
> >  
> > Notably, putting the proposed note in TCP would suggest either that IP source routing is deprecated (it isn?t) or that TCP support for it should be considered optional (it should not) - regardless of whether is deprecated in the future or not.
> >  
> > Joe
> >  
> > ?

-- 
Rod Grimes                                                 [email-masked]