Joe Touch wrote:
That is not an innocent action.
It is a fair action by innocent providers.
It is a violation of standards. They may do it innocently, but it's
still a violation.
You misunderstand standardization processes.
That innocent operators must violate some standard means
the standard must be changed.
Moreover, there already is a change, RFC4821-stype PMTUD.
This document doesn't make it more of a violation; it
just explains the existing violation.
There is no point just to explain standards when the real
world recognizes that the standards can not be followed
and must be changed.
So, the proper thing for IETF to do is to obsolete RFC1191.
There is no reason for IETF to ignore operational feedback
from the real world that RFC1191 is a bad idea.
That is not the focus of this document. Again, we don't create a new
requirement.
Your draft reduces existing requirements to make RFC1191-style
PMTUD more harmful.
If you feel there is consensus to raise this change, that
would be a separate issue.
Do you think there is explicit consensus on your draft that
we should make RFC1191-stype PMTUD more harmful?
It also violates RFC 791 and 1121.
To stop the fair violation, obsolete RFC1191.
The steps needed to allow DF clearing need to be determined; I don't
know what they are, but that's outside the scope of this doc.
Your draft has too much to do with RFC1191-stype PMTUD and
is narrowly scoped to make RFC1191-stype PMTUD more harmful,
which means it is in scope.
- regarding clearing the DF bit, this document only restates existing
requirements
Yes, there are other, new requirements that this document introduces.
But the rules about not clearing the DF bit are not new.
The problem is that the real world requires standards must change.
We can obsolete RFC1191. Or, we must permit DF clearing.
So, there is no point to say DF clearing forbidden without
obsoleting RFC1191.
That many operators are actively violating the standard track
RFCs means the standard track RFCs are defective.
Or that they have defective equipment,
Yes, they often have equipments with RFC1191-style PMTUD.
or that their logic in deciding
to run their equipment this way is defective.
Don't ignore the logic in the real world to filter ICMP,
which requires standard changes.
Just because "everyone
does it" doesn't make it correct or warrant changing the specs (see RFC
2525 for treatment of TCP implementation errors, e.g.).
That is a completely different example from your draft.
it is not surprising if end users think you are guilty.
Again, this document doesn't change the current situation.
That's not a excuse not to change the current situation.
Worse, your draft will, by loosening a requirement, changes
the current operational situation worse.
Operators who
clear the DF bit are not innocent - they need to override a default
setting. They are active participants. They ARE guilty of violating
existing standards.
Comments are Requested For by IETF to them, the active participants.
Their comments are that they can't follow the standard, because
*SOMEONE ELSE* filters ICMP. They are not guilty.
Now, it's time for IETF to modify RFCs.
You seem to think that this is OK because they have good reasons. That
may make their actions acceptable, but it will not make them compliant
*until* someone updates the standards that require the DF not be
cleared. This is not that document.
Once RFC1191 is obsoleted, your draft becomes almost useless
because no one will follow the rate limitation requirement of
your draft.
Masataka Ohta