Appeal re draft-masotta-tftpexts-windowsize-opt (Patrick Masotta; 2013-11-14) - 2013-11-14
Appeal - 2013-11-14
From: "Patrick Masotta"
Subject: Appeal - draft-masotta-tftpexts-windowsize-opt
Date: November 14, 2013 3:35:19 PM GMT+02:00
To: "'Jari Arkko'"
Cc: IESG
Jari,
Sorry for the delay, I had a very busy time in my job lately.
Tell me if you need more details or anything changed.
I have all the supporting e-mails with the corresponding headers etc.
etc.
Please let me know
Thanks
Best,
Patrick
APPEAL
My draft draft-masotta-tftpexts-windowsize-opt was up for consideration
in 2012-2013 to be published as an RFC. It eventually failed to be
published as an independent submission through the RFC Editor and later
through the IETF I was left with no other choice than to stop what I
considered an abnormal reviewing process. The draft has been of
particular interest to the Transport Area Directors. It is my belief
today that the Transport Area Directors private jobs might have
represented a conflict of interests and lapses in ethics leading to an
inadequate draft review. They have insistently casted technical
opinions on topics when they either had not previously read the draft,
and/or had not enough expertise on, and/or non-technical spurious
interests had biased their judgment. These factors determined a
systematic lack of progress and eventually led to a full stop in the
draft's normal evolution and final publication process. Further below
(under "BACKGROUND AND DETAILS").
I appeal the decision to not adopt the draft for publication and to
continue my draft evaluation with the previously involved IETF Transport
Area members.
SUGGESTED REMEDIES
Considering:
1) The draft reviewing process should be sponsored by IETF members
committed to improve the quality of the draft and final RFC.
2) IETF Area Directors making go/no go decisions on drafts should not
work for companies that sell their position as IETF AD.
I'm ready to work on my draft and finish its reviewing process sponsored
by some other IETF member not related to the previously involved
Transport Area members.
BACKGROUND AND DETAILS
Sent: Wed 3/7/2012 11:57 PM
To: internet-drafts@ietf.org
Initial submission of draft-masotta-tftpexts-windowsize-opt-00.txtOn 13/09/12 1:08 PM, Wesley Eddy wrote:
I've looked at this now.
I agree with Noel that it could be a useful extension. It certainly
would improve TFTP performance.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!
The former paragraph among other things clearly shows Wesley Eddy has
not read the draft. He asks for things clearly stated within the draft's
text.
At the time Wesley Eddy wrote the former comment he was the IETF
"Transport Area Director" and privately working for "MTI Systems"
See:
http://www.ietf.org/iesg/bio/wesley-eddy.html
http://mti-systems.com/
"MTI Systems" is a company that even today offers for sale the following
services:
See:
http://mti-systems.com/services.html
* Network and Communications Engineering:
Development, specification, and standardization of protocols through
international standards bodies such as the Internet Engineering Task
Force (IETF), including leadership of working groups,study groups, and
design teams.
At the time the draft was voted as an independent submission Pete
Resnick wrote:
Fri 11/30/2012 4:07 PM
Pete Resnick has entered the following ballot position for
conflict-review-masotta-tftpexts-windowsize-opt-00: Yes
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.
But Wesley Eddy and his team mate at the Transport Area Martin
Stiemerling were the only 2 members opposed with technical issues.
See:
https://datatracker.ietf.org/doc/conflict-review-masotta-tftpexts-windowsize-opt/ballot/311132/#wesley-eddy
Please notice from the former link Martin Stiemerling reasoning to stop
the draft.
Martin Stiemerling Discuss (2012-12-11)
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."
He just only "fully" supports his coworker Wesley Eddy. No further
analysis.
Later is Martin Stiemerling who "accepts" to sponsor the draft on the
IETF track saying things like:
Wed 2/13/2013 3:08 AM
A note ahead:
I will sponsor this draft if the draft has solved the outstanding
issues and got also review from the Transport community in the IETF.
However, there is no automatic mechanism that the sponsoring will
happen.
Please share the updated draft with the tsvwg
(https://datatracker.ietf.org/wg/tsvwg).
That note was 100% representative of Martin Stiemerling attitude
towards my Draft. He wants me to publish the draft at https://
datatracker.ietf.org/wg/tsvwg where some other people presumably will
read my draft, presumably will do his job. Next he immediately began
rising concerns like:
02/13/2013 Martin Stiemerling wrote:
Imagine a network where multiple hosts are using TFTP to pull OS
images from a server. How they set the windowsize nominally may be
one value, but after a power outage when they all start up, what
will they set the value to? It's not possible to use a fixed number
and be robust to the range of conditions anticipated on Internet
scale.
He did not read the draft, he does not know TFTP, he is not familiar
with the TFTP extension framework. Why is this guy reviewing my draft?
He doesn't know what he's talking about. Finally he requests a new
paragraph added specifically on Transport/Congestion Control; I have
added the paragraph in draft-07:
01/18/2013 11:19 AM, Patrick Masotta wrote: (New paragraph added)
"Congestion control
From a congestion control standpoint while the number of blocks in a
window does not represent a threat, the rate at which TFTP UDP
datagrams are sent SHOULD follow the congestion control guidelines in
Section 3.1 of RFC 5405 [4]."
but Martin Stiemerling refuses it.
2/13/2013 3:08 AM Martin Stiemerling wrote:
It is not enough to link to RFC 5405 only. RFC 5405 is a cook book on
what issues are to be considered to make UDP traffic safe for the
public Internet.
He again ignores TFTP is a protocol not used in Internet but in private
networks 99% on PXE (Boot/Install)
related scenarios.
Next I've have asked for some RFC containing a similar paragraph to the
one requested by him:
2/14/2013 3:53 AM Patrick Masotta wrote:
My draft quotes Section 3.1 of RFC 5405 and that RFC also quotes
other RFC explaining the measures that have to be taken.
If you consider something else has to be added provide a similar
already published RFC with the required quote for reference.
But he never provided such a reference (does that reference even
exists?) Instead he does recommend me to attend the Orlando conference.
2/13/2013 3:08 AM Martin Stiemerling wrote:
... I recommend looking for expert feedback in tsvwg and also asking
for a presentation slot at the upcoming IETF meeting on Orlando --
assuming that you will be a the IETF meeting. However, the
presentation would be good, but it is not mandatory.
Regards,
Martin
After this Martin also recommends:
3/13/2013 12:01 PM Martin Stiemerling wrote:
Please share this draft with the tsvwg
(https://datatracker.ietf.org/wg/tsvwg).
This will ensure adequate feedback from the tsvwg.
At this point and knowing that:
1) Martin Stiemerling and Wesley Eddy are close coworkers at the ITEF
Transport Area.
2) Martin Stiemerling did not read my work after purposely inserting
errors in the draft 07 submitted to him, the ones that were never
spotted by him.
3) Martin Stiemerling does not seem to know much about TFTP.
4) Martin Stiemerling repeatedly displayed his obvious intentions of
getting things tangled on my draft instead of cooperating for getting
a better document.
I decided to stop working with Martin Stiemerling and Wesley Eddy or any
other close member of the IETF Transport Area.
They (Wesley Eddy & Martin Stiemerling ) do not want to make a good
RFC out of my draft. They just want to make me waste my time, get me
exhausted and quit the task; probably to end up writing the same RFC
with their names on it or why not with the name of some of their
company's customers.
Please let me know if you need more information or clarification at any
point of this appeal.
Thank you.
Sincerely,
Patrick Masotta