On 3/15/14, 10:05 PM, [email protected] wrote: > I am uncomfortable with independent stream > submissions modifying standards track documents, > and getting published as standards track.
Agree to the former that's a basis for IESG conflict review, the later isn't possible under our rules. In it's present form it is AD-sponsored, so it has been removed from the independent stream. This was done after conflict review in the IESG concluded that it conflicted with existing (not ongoing) IETF work. I doubt there's enough work here to form tftpext-redux, hence my solicitation of feedback to help the author and provide me with guidance as to how to proceed. Thanks joel > 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. > >> >> ---- >> > > >
signature.asc
Description: OpenPGP digital signature
