Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF6412E8EE; Wed, 23 May 2018 13:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZX9GCC0Q9nY; Wed, 23 May 2018 13:23:38 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6529C12EA56; Wed, 23 May 2018 13:23:38 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 118883C001C00; Wed, 23 May 2018 13:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=OCnzBxKFuGT6OTaH1itQm7x3o5c=; b= tPA2Wuveqq3DneHuyp/X01CM4yo5XYaEHCsQHFuv0VJuVRpOC8/ighJrMg0Tp7YL gyAjE9/+vBfvpP+QRBwPIlHyimThfg8NLJMKAZavWpaY7cBK+5O9LsqLpv6hpRRf 2xAetCe8O3hKmvJUfsaItedI3tescBfeapbOma+TuyA= Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id D7B7C3C00074A; Wed, 23 May 2018 13:23:36 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id d10-v6so5521025itj.1; Wed, 23 May 2018 13:23:36 -0700 (PDT) X-Gm-Message-State: ALKqPwepC1aE0wQJ5J0zuGuhYiW9Sinqt+lR2Yuo5fwcq+cCWyvbheQt vYLkTWqJxCH8PlhneWvMrnw2e8d3lXsjT78D2UI= X-Google-Smtp-Source: AB8JxZq+40gMtLtY2oBCvYOxWjUCTSS5A9bh2NE7NyEkt6DZflqMTRFdl5G4sx0qmld0DSz9fa+cXYYXgj95VOImEmk= X-Received: by 2002:a24:9d44:: with SMTP id f65-v6mr6523856itd.119.1527107016241; Wed, 23 May 2018 13:23:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:985a:0:0:0:0:0 with HTTP; Wed, 23 May 2018 13:23:35 -0700 (PDT) In-Reply-To: References: <152709543734.26876.14669273511731581188.idtracker@ietfa.amsl.com> <64EA6F18-9275-40FC-8FDE-3E12C4458EFB@gmail.com> From: Ryan Sleevi Date: Wed, 23 May 2018 16:23:35 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Alvaro Retana Cc: Yoav Nir , Warren Kumari , SPASM , lamps-chairs@ietf.org, The IESG Content-Type: multipart/alternative; boundary="0000000000003cb949056ce54f90" Archived-At: Subject: Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 20:23:49 -0000 --0000000000003cb949056ce54f90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 23, 2018 at 3:53 PM, Alvaro Retana wrote: > On May 23, 2018 at 3:32:21 PM, Warren Kumari (warren@kumari.net) wrote: > > Hi! > > =E2=80=8BSo, here you say: "Add it up and it can take days on the web." a= nd above > that you say: "For typical systems I think the likely lifetime will be > between 1 day and 1 week. [...] , but I don=E2=80=99t think anything bey= ond 2 > weeks would ever count as short." > > "1 week" minus "days" is still greater than zero, and so it still *seems* > to me that removing revocation is a bad idea -- but, my role is (or shoul= d > be!) to make sure that this charter doesn't conflict with other work (esp= . > ops work), that the charter "describes the specific problem or deliverabl= es > (a guideline, standards specification, etc.) it has been formed to addres= s. > WG charters state the scope of work for group, and lay out goals and > milestones that show how this work will be completed." It is (IMO) the > sponsoring ADs, the WGs and IETFs decision as to if the ideas themselves > are acceptable. > I'm not (yet!) so arrogant that I'm sure I know the right answer to > everything, so I'd like to discuss this with EKR on the call tomorrow > , and will clear my > block once I've been assured process is being followed > / this has been considered. > > I agree with Warren=E2=80=99s assessment. > > However, I also think that a charter may give undue validation to items > that would benefit from at least a little more description or > consideration. IOW, adding (to the charter) a longer description, and > listing which things should be satisfied, or at least considered, seems > like a good idea to me. > This was my request in https://mailarchive.ietf.org/arch/msg/spasm/paYqxqRL1LEEPgwOuGmUVB8V6lE/?qi= d=3D356aa0482508fa29bf866d05ea1981e6 and Stephen Farrell's agreement in https://mailarchive.ietf.org/arch/msg/spasm/Evk_hbJsHBuBGEnNaMCqaQEVceI --0000000000003cb949056ce54f90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 23, 2018 at 3:53 PM, Alvaro Retana <aretana.ietf@gmai= l.com> wrote:
On May 23, 2018 at 3:32:21 PM, Warren Kumari (warren@kumari.net) wrote:<= /div>

Hi!

=E2=80=8BSo, here you say= : "Add it up and it can take days on the web." and above that you= say: "For typical systems I think the likely lifetime will be between= 1 day and 1 week. =C2=A0[...] , but I don=E2=80=99t think anything beyond = 2 weeks would ever count as short."

"1 week" minus &q= uot;days" is still greater than zero, and so it still *seems* to me th= at removing revocation is a bad idea -- but, my role is (or should be!) to = make sure that this charter doesn't conflict with other work (esp. ops = work), that the charter "describes the specific problem or deliverable= s (a guideline, standards specification, etc.) it has been formed to addres= s. WG charters state the scope of work for group, and lay out goals and mil= estones that show how this work will be completed." It is (IMO) the sp= onsoring ADs, the WGs and IETFs decision as to if the ideas themselves are = acceptable.
I'm not (yet!) so arrogant that I'm sure I know th= e right answer to everything, so I'd like to discuss this with EKR on t= he call= =C2=A0tomorrow, and will clear my block once I've bee= n assured process is being followed
/ this has been considered.

I ag= ree with Warren=E2=80=99s assessment.

However, I also think that a charter may give undue validation to items th= at would benefit from at least a little more description or consideration.= =C2=A0 IOW, adding (to the charter) a longer description, and listing which= things should be satisfied, or at least considered, seems like a good idea= to me.

=

--0000000000003cb949056ce54f90--