Re: [tcpm] WGLC for UTO

[Joe Touch <[e-mail]>]

I had a few minor points; I don't think any are showstoppers, but the WG
might consider whether it'd be useful to fix these before this goes out
the door. I think it should, since some are holes in behavior that ought
to be defined.

---

- MUST/MAY/SHOULD on the whole option
	I didn't see this; I'm not sure I care what the decision is,
	but it should be stated in the abstract and intro

- sec 3 at "Before opening..." for two paragraphs
This section uses 2119 language in ways I don't understand. An app that
wishes to do something SHOULD? If it wishes to do something, it "DOES"
it. I don't see a reason for 2119 there, or MAY at the end of that
paragraph, or MAY in the next. In these cases, there are choices
involved that determine what happens. You cannot dictated userland /
application behavior when defining these events in this document, IMO.

- sec 3 "In addition to"
There is no reason in requiring (via SHOULD) a refresh of
SYN-coordinated state. Either that state is coordinated, or it is not.
If not, then the connection is in error.

- sec 3 "A host that supports"
What happens if there is no option space in the next outgoing segment?
What happens if there is no option space at all? Do you tell the app? Do
you do anything special? IMO, this deserves a separate section rather
than just a note at the end of 3.0

- sec 3.1 "When a host"
"In this case, they SHOULD" - they who?

- sec 3.1 "In general"
This is contrary to the default values. CHANGEABLE defaults to true, but
ENABLED defaults to false. That means, IMO, that received UTO options
would be dropped, not acted upon, in the default case.

- sec 6
I thought this section should say a few specific things:

1) There are no new IANA namespaces. (which you say)

2) This doc requires IANA to assign a value from the TCP Option
namespace, to be referred in section 3.3 accordingly. (which you don't
quite ask for!)

-----------------------------------------------------------------------

Very minor points, if an edit occurs:

- intro near "applications can set"
apps typically set/change this param via the OPEN/SEND socket calls, not
the TCP OPEN/SEND API. The two use the same names; it'd be useful to be
clear here.

- intro/throughout
'other end' seems informal; other end of the TCP connection, etc.?

- intro last two paragraphs
these would be useful to move earlier

- sec 3
'per-application basis' -> 'per-connection basis'

- sec 3 at LOCAL_UTO
it should be more clear what the relationship between the system-wide
USER TIMEOUT and local USER_TIMEOUT is; alternately, a list of the
global vars would be useful.

- sec 3.1 "This means that"
This paragraph is part of a discussion on checks and limits; this should
not be the first place you introduce the "max" concept.

- hysteresis?
The doc doesn't describe how quickly the UTO can be changed by the
remote end or application. Does it matter, e.g., for security reasons?

- sec 3.2 "The host requirements rfc"
"seconds is RECOMMENDED" -> append "in that RFC" (you're not doing the
recommending; you're quoting 1122)

- sec 3.2
If you retransmit the option and attach it to a particular byte, and the
byte is ACKd, then why don't you KNOW the option has been received
(i.e., second part of the handshake)? if the other end receives data
over 1 window away from that byte, why doesn't it KNOW the source end
knows it has been recieved (i.e., third part of the handshake)?

About retransmission, IMO, it SHOULD be done - or else what's the point
of this?

- sec 3.4
"TCP implementations" -> "Current TCP implementations"

- sec 4.1
Firewalls may parse this option in unencrypted TCP segments only.

- sec 5
in addition to IPsec, cite RFC2385 for peer authentication

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