Hi Brian,
Sorry about the delay, I had chatted with the co-authors and have been
wanting to reply to this email, but just found time.
I am enclosing the original and the responses. Responses are prefixed with ANA>
for easier readability.
=============================================== Last call comments
========================================
[Responses are prefixed with ANA>]
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-tcpm-persist-04.txt
Reviewer: Brian Carpenter
Review Date: 2011-06-05
IETF LC End Date: 2011-06-03
IESG Telechat date: 2011-06-09
Summary: Almost ready, but...
--------
Comment:
--------
(These are my Last Call comments, to which I've seen no response so far.)
ANA> apologies for the delay.
I have no problem with the message of this draft, but there are problems in
the way the message is delivered.
Major issues:
-------------
Why is this Informational? If it matters, it should be a Standards Track
document updating RFC 1122.
ANA> I agree, it should have been a standards track document since it clarifies
the RFC 1122 wording. I believe the TCPM chairs and WG group had
ANA> approved us to come up with a informational RFC that clarifies the
intention of RFC 1122 regarding persist state. We have no problems making ANA>
this a standards track, I'll leave it to the chairs to comment on this.
If it's not a Standards Track document, why is it using RFC 2119 language?
ANA> I think we need to remove the RFC 2119 language if the target is
informational.
" The problem is applicable to TCP and TCP derived flow-controlled
transport protocols like SCTP."
This statement is not much use on its own. Does this draft apply to SCTP?
If it does, which text in the SCTP spec is affected?
ANA> SCTP persist state handling is the same as recommended for TCP. RFC 4960
isn't very clear about this aspect, but it supports the receiver
ANA> keeping its window open indefinitely.. section 6.1 from RFC 4960 :
If the sender continues to receive new packets from the receiver
while doing zero window probing, the unacknowledged window probes
should not increment the error counter for the association or any
destination transport address. This is because the receiver MAY
keep its window closed for an indefinite time. Refer to Section
6.2 on the receiver behavior when it advertises a zero window.
The sender SHOULD send the first zero window probe after 1 RTO
when it detects that the receiver has closed its window and SHOULD
increase the probe interval exponentially afterwards. Also note
that the cwnd SHOULD be adjusted according to Section 7.2.1. Zero
window probing does not affect the calculation of cwnd.
ANA> I remember checking with Randall Stewart on the applicability of this
draft to SCTP before we made this claim.. but we are open to any
ANA> suggestion here.
Important editorial issues:
---------------------------
The draft says:
(begin quote from draft-ietf-tcpm-persist-04)
1. Introduction
Section 4.2.2.17 of Requirements for Internet Hosts [RFC1122] says:
"A TCP MAY keep its offered receive window closed indefinitely.
As long as the receiving TCP continues to send acknowledgments in
response to the probe segments, the sending TCP MUST allow the
connection to stay open."
DISCUSSION:
It is extremely important to remember that ACK (acknowledgment)
segments that contain no data are not reliably transmitted by
TCP.
(end quote from draft-ietf-tcpm-persist-04)
The closing quotation mark is incorrectly placed - it belongs after
'TCP.' not after 'open.'. The reader will be misled by this. You might
consider even clearer flags for the extract, as I have used above.
ANA> Sure we can fix this. Good catch.
(begin quote from draft-ietf-tcpm-persist-04)
5. Clarification Regarding RFC 1122 Requirements
As stated in Requirements for Internet Hosts [RFC1122], a TCP
implementation MUST NOT close a connection merely because it seems to
be stuck in the ZWP or persist condition. Unstated in RFC 1122, but
implicit for system robustness, a TCP implementation MUST allow
connections in the ZWP or persist condition to be closed or aborted
by their applications or other resource management routines in the
operating system.
(end quote from draft-ietf-tcpm-persist-04)
Both these sentences seem to assert things about RFC 1122, and about the state
of mind of its editor, that I have no reason to believe. RFC 1122 doesn't
say anything about the MUST NOT being "merely because" anything - the statement
in section 4.2.2.17 is completely unambiguous. And I don't see any grounds for
asserting that the second sentence is any way implicit in RFC 1122. Quite the
opposite - you are documenting an oversight. I think you should say so. For
example:
5. Update to RFC 1122 Requirements
Requirements for Internet Hosts [RFC1122] states that a TCP
implementation MUST NOT close a connection if it seems to
be stuck in the ZWP or persist condition, as long as ackowledgements
are being received. The present document updates this requirement by
adding that a TCP implementation MUST allow connections in the ZWP
or persist condition to be closed or aborted by their applications or
other resource management routines in the operating system.
ANA> Excellent catch!. I am comfortable using the above text which you
suggested.
Minor editorial
---------------
These are examples - I think the English needs a general tidy-up:
" Per Requirements for Internet Hosts [RFC1122] as long as the ACK's
are being received for window probes, a connection can continue to
stay in the persist condition."
The use of "Per" like this is, well, sloppy. "According to..." would be better.
There is a missing comma after "[RFC1122]".
"ACK's" should be "ACKs".
ANA> Point taken, will correct it.
" Systems that adhere too strictly to the above verbiage of
Requirements for Internet Hosts [RFC1122]..."
It isn't "verbiage", which means "The use of many words without necessity, or
with
little sense; a superabundance of words; verbosity; wordiness" according to my
favourite on-line dictionary. It is just "wording".
ANA> I think even other IESG reviewer also pointed this out (Stewart ?)
Corrected already I guess, if not will correct it.
ANA> Thanks for your valuable comments, Brain. Will incorporate them.
ANA> As far as the comment on standards track versus informational, my
preference was to go with standards since it can be construed as a update
ANA> to RFC 1122. I'll leave it to the chairs to comment further on this. I am
also copying David Harrington in the loop since his question
ANA> also centered around the RFC 2119 language...
============================================ End Last call comments
==============================
Thanks,
-Anantha
> -----Original Message-----
> From: Brian E Carpenter [mailto:[email protected]]
> Sent: Saturday, June 04, 2011 1:16 PM
> To: [email protected]; General Area Review
> Team
> Subject: Gen-ART telechat review of draft-ietf-tcpm-persist-04.txt
>
> Please see attached review.
>
>
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
