+1 David Harrington [email protected] +1-603-828-1401
> -----Original Message----- > From: tsv-area [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Sunday, March 16, 2014 1:06 AM > To: [email protected]; [email protected]; [email protected]; tsv- > [email protected]; [email protected] > Subject: RE: AD sponsoring draft-masotta-tftpexts-windowsize-opt-09 > > I am uncomfortable with independent stream > submissions modifying standards track documents, > and getting published as standards track. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: tsv-area [[email protected]] On Behalf Of joel jaeggli > [[email protected]] > Sent: 15 March 2014 16:20 > To: Joe Touch; [email protected]; [email protected]; Martin Stiemerling > Subject: Re: AD sponsoring draft-masotta-tftpexts-windowsize-opt-09 > > On 3/14/14, 1:34 PM, Joe Touch wrote: > > Hi, Joel, > > > > On 3/13/2014 3:22 PM, joel jaeggli wrote: > >> Greetings, > >> > >> I have taken on the AD sponsorship of > >> draft-masotta-tftpexts-windowsize-opt and am looking for some > additional > >> review before revisiting the subject of and IETF last call. > > > > FWIW, this ought to be vetted in a broader venue, e.g., TSVWG. I'm not > > very comfortable with AD sponsored standards-track updates. > > This is very useful feedback. > > The process that got this thing from an independent stream submission > in iesg conflict review to where we are today is somewhat torturous, > that's why I'm asking. > > >> https://datatracker.ietf.org/doc/draft-masotta-tftpexts-windowsize-opt/ > > > > A quick check indicates a few disconnects, summarized below. > > > > Joe > > > >> Congestion and Error Control > >> > >> From a congestion control standpoint while the number of blocks in > >> a window does not represent a threat, > > > > The entirety of TCP's congestion control is about managing the window > > size; the same is true here. Increasing the window absolutely increases > > the potential for congestion and represents a threat. > > > > The doc includes a number of SHOULDs that are underspecified, e.g., > > SHOULD implement a timeout on retransmissions (what value?), and > SHOULD > > abort (under what conditions?) > > I sympathize with the authors lack of desire to specify specific values > which may be appropriate now but not into the future. That said. I would > be happier with examples. (I am aware of some of them) > > > > How are retransmissions handled? Go-back-N is known problematic; SACK > > requires a much more complex mechanism. > > > > The document should also request that IANA register "windowsize" as the > > TFTP option string (and IANA should have a registry of these - they > > currently don't appear to). > > Yes that seems necessary. > > > > > ---- > >
