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

S Moonesamy <> Mon, 08 March 2010 19:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41CC13A6A83 for <>; Mon, 8 Mar 2010 11:09:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.197
X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8+rEGol4--VU for <>; Mon, 8 Mar 2010 11:09:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 13B493A69B1 for <>; Mon, 8 Mar 2010 11:09:36 -0800 (PST)
Received: from ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id o28J9XpA014275 for <>; Mon, 8 Mar 2010 11:09:39 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple;; s=mail; t=1268075381; x=1268161781; bh=JUWQco9J49HSTUak5lMYlzTDBkA=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type; b=cFXOouAdlXCCXyTNkSthvczGhyqe56WxC1UfkMR/nYN1VpgVJKvp0+sUe25fOslJz 5q8GxbvR4w3RG8BL7GtVNAnxwLpBgr47/c0esIIrtZSxAmLhMy77i9sLOcfAKokynX yUvatgvldDBwhbipTAPE/nLS7UQMdsQ8Jrf3tliw=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 08 Mar 2010 11:09:03 -0800
From: S Moonesamy <>
In-Reply-To: <>
References: <> <> <p06240804c7b4bcb4b668@[]> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [yam] [secdir] secdir review of draft-ietf-yam-rfc1652bis-03
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Mar 2010 19:09:38 -0000

At 08:43 08-03-10, Dave CROCKER wrote:
>This is a clear and supportable stance.  And as Ned notes, a short 
>Security section that is valid should be defended.
>I'm entirely comfortable with my name on this document, with that position.

Personally, I also consider it is a clear and supportable stance.

>I'll note that confusion about the exposure this option does /not/ 
>create seems to be pretty easy to suffer.  Defending against /that/ 
>problem is probably worth a small amount of extra text.


>Got some support.

I agree.  BTW, I used the text you provided.

>And I have developed and even greater concern for the thinking that 
>this type of binary mechanism causes a malware window.  I think we 
>now have affirmative proof that the confusion is common.

That's fine as long as we do not have to address any confusion that 
does not contribute to the clarity of specification in a substantive way.

>So, I'll suggest that we use Ned's text:

I also used that text.

I'll post the WG response shortly.

S. Moonesamy
YAM WG Secretary