> > I would suggest the strong, unambiguous statement with explanation > for > > why the statement is being made. > > Yes. > > > There is no need to describe (possible) exceptions. > > My opinion is exactly the opposite. Do describe the exceptions, as precisely > and unambiguously as you can. > > I don't buy the assumption that "one can never figure all the possible reasons > when/why <XXX> should not apply". Most of the reasons people will use when deciding to continue using these technologies are financially or resource driven (i.e., there are costs to changing) or to ensure a MITM ability to monitor. Getting consensus in IETF that such reasons are "valid" is, in my experience, futile. I really couldn't see IETF getting consensus on any case where the recommendation would be "SHOULD NOT". The only real effect of insisting on such a change to this draft would be to delay its publication indefinitely. I believe it's already past time for these technologies to be deprecated by IETF. The proposed indefinite delay in publication in order to accommodate futile argument is unnecessary and, IMO, harmful. Barbara -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
