IETF conflict review for draft-masotta-tftpexts-windowsize-opt
conflict-review-masotta-tftpexts-windowsize-opt-01

The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-masotta-tftpexts-windowsize-opt@tools.ietf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-masotta-tftpexts-windowsize-opt-06

The IESG has completed a review of
draft-masotta-tftpexts-windowsize-opt-06 consistent with RFC5742.


The IESG recommends that 'TFTP Windowsize Option'
NOT be published as an
Informational RFC.


The IESG has concluded that this document extends an IETF protocol in a
way that requires IETF review and should therefore not be published
without IETF review and IESG approval.

The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
http://datatracker.ietf.org/doc/conflict-review-masotta-tftpexts-windowsize-opt/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-masotta-tftpexts-windowsize-opt/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
I agrre strongly with the proposed 5742 response and urge the ISE to not publish.
Does the IESG want to supply an "IESG note" at this stage to handle the eventuality that the ISE decides to publish anyway?

[Ballot comment]

I'm no-objection here but do think that the transport ADs
discuss points ought to be but have not yet been fully
discussed as they seem to me to be reasonable points.

[Ballot discuss]
Given the widespread use of TFTP in bootstrapping devices, and hence its importance to the Internet, I think that this needs to go for IETF review.

[Ballot discuss]
In the past, many RFCs have updated RFC 1350 by adding new TFTP Options. All of those drafts have a) explicitly updated 1350, b) been published on the standards track.

Why is this document different from its predecessors?

[Ballot discuss]
In full support of Wes' DISCUSS and the response should be "The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval."

[Ballot discuss]
I do not think this document conflicts with IETF work.  However, it may be harmful for those using it, and it clearly should not be used across the Internet.

In September, I sent these comments to the ISE, which do not seem to be addressed in the document:
"""
It is definitely missing text about what you do in the case of loss,
and probably completely pathologically broken, as currently written.

I say this because the window size is specified as any chosen value,
without any probing of what the network can actually support.

Further, on losses, the entire window is retransmitted.  So, a single
packet loss (which could be signalling congestion) causes retransmission
of an entire window, and this is going to occur either at line rate or
probably the same rate that the last window was paced out at, which
caused loss.

It sounds like a great way to shoot yourself in the foot while trying
to improve performance!
"""

This is just clearly an unsafe algorithm since it fails to backoff in response
to loss.  An overly aggressive setting will harm other traffic.

At minimum, it should:
1) halve the window size in-use on losses

2) encourage implementation of a "memory" such that if a window size
causes loss, you use a smaller size for subsequent transfers to the
same host

3) make it clear that host buffers can be a constraint on tiny devices
and that part of the TFTP 1-segment benefit is that it greatly simplifies
the resources and memory needed for reordering, etc., as this may be
taking place within a 1st or 2nd stage bootloader.

[Ballot comment]
There is no current work in TFTP that I can see, and given that TFTP is almost exclusively used in local network environments nowadays, I have a hard time seeing how this could do any damage. Therefore, I am recommending a simple "No conflict" message. The only other choice is to decide that they are extending RFC 1350 in a sufficiently horrible way that it needs IETF Review. Transport folks should probably give the document a read.

The draft draft-masotta-tftpexts-windowsize-opt-06.txt
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

This document describes a TFTP option which allows the client and
server to negotiate a windowsize of consecutive blocks to send
as an alternative for replacing the single block lock-step schema.

It was reviewed by Noel Chiappa and Wes Eddy; I believe that
the extension to TFTP it describes would be useful.

Thanks, Nevil (ISE)

--
Nevil Brownlee (ISE), rfc-ise@rfc-editor.org