> I concur with Barry. I fear that the path Steve apparently
> wants to go down --as I understand it, to incorporate warnings
> in security considerations simply because a mechanism can be
> used to transfer bad stuff -- leads to madness. But I'm happy
> to have you discuss it with him to see if you, together, can
> find an acceptable basis for moving forward.
There are really two issues here. First is whether or not to attempt to address
this in 1652bis. Even if I were to agree that we should address this, it most
certainly doesn't belong in 1652bis, if for no other reason than nobody dealing
with this issue is going to look there for advice.
As for whether ot belongs in 5321bis/5322bis, I'm afraid I have to agree with
John: This is a path to madness, or more accurately, to a world where security
considerations contain so many obvious, irrelevant, or both issues that the
real issues specific to a given protcol or format simply get lost in all the
other noise. And this is not a path which, if followed, will improve overall
Internet security. To the extent it has an effect, if will be the opposite.
I also have to say I find the notion that a short security considerations
section is necessarily a bad one to be worth pushing back against. There are
plenty of protocols and extensions that do not introduce additional security
considerations. We even have a term for this: Good design.
Ned
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
