Re: [TOOLS-DEVELOPMENT] [Trustees] Fwd: PKCS#9 and #10

Robert Sparks <rjsparks@nostrum.com> Fri, 15 January 2021 22:05 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77843A1235; Fri, 15 Jan 2021 14:05:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.932
X-Spam-Level:
X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.009, NICE_REPLY_A=-0.262, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 9Rk3HFKyi0Bk; Fri, 15 Jan 2021 14:05:12 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C873A1245; Fri, 15 Jan 2021 14:05:11 -0800 (PST)
Received: from unformal.localdomain ([47.186.1.92]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 10FM59mL089592 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 Jan 2021 16:05:10 -0600 (CST) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1610748311; bh=xdb09eMXep46q7d0x5DFewTvksFNnAswvI4Drgk7nGE=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=J52NiY/gRSQP3smWnvN/gNuDExEkbwDVLhsXrh+/m3h7rqOWNBnn8SwLWCnLVB+yF 1fXrpXcEz53r/7waMLaYsksHD2XZbU0cu1bRfTmzJFLEnOC2UgFdM1Shik5YRBiZRd 2dfDl17AVFNAVZ+902nwYJF7ycabvIzqBPnr5Ae0=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.1.92] claimed to be unformal.localdomain
To: Stephan Wenger <stewe@stewe.org>, Benjamin Kaduk <kaduk@mit.edu>
Cc: Trustees Trustees <trustees@ietf.org>, Henrik Levkowetz <henrik@levkowetz.com>, IETF Tools Development <tools-development@ietf.org>
References: <E8CEA61867EF1E4A9BD05D64D74F76B250F9EE68@MX307CL02.corp.emc.com> <CAHbuEH4YWd_J9+XFUdWUq4kUkiURLEgvoXTT+G9ucdEkVuzP7Q@mail.gmail.com> <f0f7dbbd-9295-3065-5644-e89b3182696f@levkowetz.com> <CAHbuEH7XmEVGwcUcXgETB35gdve9N8xBvd3W7+c3OFbs6BDFww@mail.gmail.com> <a436e583-83e9-cede-f2b8-c903d114b976@nostrum.com> <20210115213132.GQ21@kduck.mit.edu> <baeb0d75-234f-a469-a37f-16752ccb9311@nostrum.com> <174520CB-0B80-470B-9888-4311E0639AB1@stewe.org>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <0161458e-b23f-76e5-83f7-bc0c3c379fa9@nostrum.com>
Date: Fri, 15 Jan 2021 16:05:04 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <174520CB-0B80-470B-9888-4311E0639AB1@stewe.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-development/XUs8fsu5Ta9zpKxqM-X20fKLWXk>
Subject: Re: [TOOLS-DEVELOPMENT] [Trustees] Fwd: PKCS#9 and #10
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Development mail list <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2021 22:05:14 -0000

Well, we've got two trustees on the thread so far :)

Can one of you take the token to find out if the trust is willing to 
publicly home this document (and maybe others), and if so, let us know 
how to point to it?

Then the "Additional Resources" approach  approach would work with no 
further datatracker changes.

RjS

On 1/15/21 3:57 PM, Stephan Wenger wrote:
> It is my understanding that the IETF's IPR disclosure mechanism is primarily (exclusively?) targeted towards patent IP.  I'm not sure that adding a copyright-related disclosure into a patent database increases transparency.  OTOH, the Trust's web page is primarily concerned about copyright (and trademark) rights.  Insofar, it may be better if we find an appropriate home on the Trust webpage for this.
> Stephan
>
>
> On 1/15/21, 13:46, "Trustees on behalf of Robert Sparks" <trustees-bounces@ietf.org on behalf of rjsparks@nostrum.com> wrote:
>
>      If the audience is only the IESG (or future IESGs), adding comments to
>      each of the documents with a pointer to a place where the pdf lives
>      might be enough. There's not a mechanic for capturing a pdf (or any
>      file) as a comment on a doc.
>
>      But if the audience is people looking at the main page of the documents,
>      then the IPR disclosure path is the best I can thing of so far.
>
>      If the trust had a place they wanted to put documents like this where
>      the public could see them via URL, you could add an additonalURL to the
>      documents pointing to it. I've wondered where the trust keeps grants on
>      pre-5378 documents for example - might be nice if those were public if
>      possible.
>
>      RjS
>
>      On 1/15/21 3:31 PM, Benjamin Kaduk wrote:
>      > To reintroduce a smidgeon more context, I kicked things into motion by
>      > noting that https://datatracker.ietf.org/iesg/discusses/ lists a document
>      > as having a 1031-day-old Discuss, and looking at the ballot positions
>      > indicates that there was a need to follow up on the licensing.
>      >
>      > I am not 100% confident that I would think to look at the IPR declarations
>      > against that document to attempt to resolve such a situation, but I also
>      > don't have any better ideas for where to put something in a mechanical way
>      > (i.e., that doesn't rely on the possibly-former AD updating a ballot
>      > position).
>      >
>      > -Ben
>      >
>      > On Fri, Jan 15, 2021 at 03:24:08PM -0600, Robert Sparks wrote:
>      >> There's been context-away.
>      >>
>      >> As Henrik suggested, you _could_ enter them as IPR disclosures (with the
>      >> pdf as an attachment), and those would come up in searches on any
>      >> documents that obsoleted/modified these.
>      >>
>      >> Why does that not seem the right thing to do?
>      >>
>      >> RjS
>      >>
>      >> On 1/15/21 10:37 AM, Kathleen Moriarty wrote:
>      >>> Hello,
>      >>>
>      >>> Is there any way we can address this?  Ben, current AD is assuming the
>      >>> transfer didn't happen even though it was complete.  There's no marker
>      >>> attached to the datatracker record to indicate the transfer for these
>      >>> 2 documents happened.
>      >>>
>      >>> Thank you,
>      >>> Kathleen
>      >>>
>      >>> On Wed, Jul 31, 2019 at 12:00 PM Henrik Levkowetz
>      >>> <henrik@levkowetz.com <mailto:henrik@levkowetz.com>> wrote:
>      >>>
>      >>>      Hi Kathleen,
>      >>>
>      >>>      On 2019-07-30 21:29, Kathleen Moriarty wrote:
>      >>>      > Hello!
>      >>>      >
>      >>>      > I am not sure how I can attach this change in the copyright and
>      >>>      change
>      >>>      > control status to RFC2985 and RFC2986.  The IPR disclosure page
>      >>>      doesn't
>      >>>      > quite fit as the license is specific to the standard and opening
>      >>>      it up
>      >>>      > further for use.  For the other PKCS documents, we did a
>      >>>      revision of the
>      >>>      > RFC.  I'd like this to not be lost with me and for others doing
>      >>>      work with
>      >>>      > these standards to know that it is fine for them to do so.  Any
>      >>>      ideas?
>      >>>
>      >>>      IPR declarations carry forward through "obsoletes" and "replaces"
>      >>>      document
>      >>>      relationships, so if a new RFC marks the previous one as
>      >>>      obsoleted, the
>      >>>      IPR declaration should show up for any new RFCs for the same standard.
>      >>>
>      >>>      Registering the change for the current RFCs seems to be the right
>      >>>      thing
>      >>>      to do.
>      >>>
>      >>>
>      >>>      Best regards,
>      >>>
>      >>>              Henrik
>      >>>
>      >>>
>      >>>
>      >>> --
>      >>>
>      >>> Best regards,
>      >>> Kathleen
>      >>>
>      >>> _______________________________________________
>      >>> TOOLS-DEVELOPMENT mailing list
>      >>> TOOLS-DEVELOPMENT@ietf.org
>      >>> https://www.ietf.org/mailman/listinfo/tools-development
>
>      _______________________________________________
>      Trustees mailing list
>      Trustees@ietf.org
>      https://www.ietf.org/mailman/listinfo/trustees
>