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