Subject: Re: [yam] [Fwd: [secdir] secdir review of draft-ietf-yam-rfc1652bis-03]

From: John C Klensin <[email-masked]>
Date: Thu, 04 Mar 2010 16:54:11 -0500

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.

     john

--On Thursday, March 04, 2010 16:43 -0500 Barry Leiba
<[email-masked]> wrote:

>> One argument is that he is suggesting non-normative
>> clarifications.  From that standpoint, that seems reasonable
>> to include for yam-related work.
>> 
>> A different argument is that there is, nonetheless, some
>> actual substance to the changes and that that is /not/ within
>> scope for yam.
>> 
>> How does the wg feel about this?
> 
> This WG participant feels great about having you discuss it
> with him, use your judgment, and make a recommendation to the
> WG about what we should do.
> 
> Barry
> _______________________________________________
> yam mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yam

---

From: Ned Freed <[email-masked]>
Date: Sun, 07 Mar 2010 16:22:55 -0800 (PST)

> 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