Re: [tcpm] Re: draft-ietf-tcpm-tcp-uto-05

[Fernando Gont <[e-mail]>]

At 04:31 a.m. 30/05/2007, Lars Eggert wrote:

>This has been suggested before, but I think it was in an off-list email.
>
>Implementors are free to choose whatever variable names they like for
>their implementation - there is no expectation that these names will
>be used as-is. For example, RFC2581 and RFC2988 define similar state
>variables, for which implementations also choose different names.
>
>For this reason I'm unconvinced that renaming the state variables is
>necessary. (At the very least, I wouldn't want to add the "TCP_"
>prefix. If the WG thinks some of the other name changes clarify
>things, I could be convinced to go with it.)

I agree with Lars here.


>>W.r.t. the granularity of the UTO configuration (cf. second-to-
>>last paragraph of Section 3.1), I had suggested to mention the
>>possibility of configuration *per-interface* because knowledge
>>of the first-hop link technology and its characteristics might
>>perhaps be an incentive for implementations to adapt the UTO
>>defaults and limits in a very user-friendly way, without specific
>>manual configuration or knowledge (to be) built into applications.
>>I cannot imagine support of "per-host" (better: "per-peer" ?)
>>or "per-user" granularity without very specific (usually manual)
>>configuration.
>>
>>Has this proposal been overlooked, or are there arguments against it?
>
>Hm - we may have overlooked this suggestion. I'm fine with adding
>"per-outgoing-interface" to the list in that paragraph:
>
>   Note that these limits MAY be specified as system-wide constants or
>   at other granularities, such as on per-host, per-user, per-outgoing-
>   interface or even per-connection basis.

Will commit this into the draft.


>>(2)
>>
>>The modified text uses the wording "UTO options" at several
>>places (in particular, repaetedly in Section 3, twice in
>>Section 3.2, and three times in Section 4.1).
>>IMHO, this is a bit confusing, as you define only a single
>>UTO option (i.e. option code and option format).
>>
>>I therefore propose to change "UTO options" in most places
>>to "the UTO option", e.g. (near the end of Section 3):
>>
>>    A TCP implementation that does not support UTO options MUST
>>silently
>>    ignore them [RFC1122], thus ensuring interoperability.
>>---
>>    A TCP implementation that does not support the UTO option MUST
>>    silently ignore it [RFC1122], thus ensuring interoperability.

I agree that in a few instances the use of "UTO options" may be a 
little bit confusing. Will try to change the text as suggested.


>>(4)
>>
>>The new wording at the end of 4.1 almost 'invites' middleboxes
>>to modify the UTO.  This should be avoided!
>>Such changes are obstructions to end-to-end transparency and security.
>>If you leave this suggestion in the draft, you will have to deal
>>with various IAB concerns !
>
>Good point. The "or the option contents" part is problematic. Suggest
>to rephrase that paragraph to:
>
>   Stateful firewalls usually time out connection state after a
>period of
>   inactivity.  If such a firewall exists along the path, it may close
>   or abort connections regardless of the use of the TCP User Timeout
>   Option.  In the future, such firewalls may learn to parse the TCP
>   User Timeout Option and adapt connection state management
>accordingly.

Will commit this change.


>PS: Fernando, since you have the editing token, will you incorporate
>these changes?

Yes.

Alfred: Let us know if the text suggested by Lars addresses your 
comments. Once again, thanks so much for your thorough review!

Thanks!

-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm