From nobody Tue Feb 1 04:34:16 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38C13A07E2; Tue, 1 Feb 2022 04:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net 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 fb1VhLyl4Q0n; Tue, 1 Feb 2022 04:34:02 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D2483A07DF; Tue, 1 Feb 2022 04:33:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=From:Cc:To:Subject:MIME-Version:Date:Message-ID:Content-Type ; bh=1z+InzNFQ8aglKKrkLmzrSuyUl64ZsvhBmykrBiH5Ds=; b=rzZeRzfBCsUWBeEX6qQeMflo 6jleBKIn/npd7hDlsSxN7FEc055BwOeOMl5qgvJydb5Pw6acjl9r8JuSSDa6F/P3qzjanWxFBrDKa nEetnOXVy79PI3i6EIbaSOmjwqSRVJXAqaTmCL2pgXk9tcAGMueRxEVQSq5FXZom5bZHtIKMW9r1A W73XF3sqxjijSj+E+MfI7uTXM5Ouxq8m6uEwT8bvJDcYNUyv9TlxlY3Fq/2ClYjpSQJ53PKDdgTYh Bcavg9vAKk9FAaO6exnlayWVHpTnUbIQvphr2DTQ7K5MurKQu4PMrVI0QF8KalilcV/1Xbk5ZVOVt tMmlbFBHvA==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:42430) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nEsM4-0005vh-Tq; Tue, 01 Feb 2022 13:33:52 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPV6:2001:67c:2e8:1200::fd3]) by allealle.ripe.net with esmtp (Exim 4.94.2) (envelope-from ) id 1nEsM4-0004tF-Qb; Tue, 01 Feb 2022 13:33:52 +0100 Content-Type: multipart/alternative; boundary="------------1cl0ipX0ADupU5EmrwGxSnyC" Message-ID: Date: Tue, 1 Feb 2022 13:33:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 To: Christopher Morrow , Russ Housley Cc: SIDROps Chairs , SIDR Operations WG , Chris Morrow , Job Snijders , IESG , Eric Vyncke , draft-ietf-sidrops-6486bis@ietf.org References: <164362677155.28792.13241248233184382872@ietfa.amsl.com> <6778460A-C69A-40B3-9295-A5AB8913C6FA@vigilsec.com> From: Adianto Wibisono In-Reply-To: X-RIPE-Signature: 5a3bc02617213164a8f39ba32e60793892408c4594390687f5f77250dea02864 Archived-At: Subject: Re: [Sidrops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidrops-6486bis-09=3A_=28with_COMMENT=29?= X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 12:34:09 -0000 This is a multi-part message in MIME format. --------------1cl0ipX0ADupU5EmrwGxSnyC Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, It is indeed a better text. Minor nit however, we will have 'in-flight modification' that only appears in the abstract, but not elaborated further on the draft. The old abstract is elaborated nicely on the first paragraph of the draft, explaining that we have the manifest to protect against replay attacks and unauthorized deletions.             However, digital signatures provide no protection against attacks that             substitute "stale" versions of signed objects (i.e., objects that were             valid and have not expired, but have since been superseded) or attacks             that remove an object that should be present in the repository.             To assist in the detection of such attacks, the RPKI repository system can             make use of a signed object called a "manifest". Perhaps if we want to keep in-flight modification in the abstract, we need to elaborate further in the draft, since usually I expect abstract to be a compressed version of what will be elaborated later. Cheers, Adianto On 31/01/2022 18:56, Christopher Morrow wrote: > oh yea, that's nice :) I was struggling with the sentence myself (upon > re-reading eric's question) .. since it seems to be talking about: >   "you have a remote copy (the RP) and your copy, the manifest helps > you tell what's going to change in the local copy" >   (missing the context of local/remote copy correlation did me in) > > anyway, yay! better text. > > On Mon, Jan 31, 2022 at 11:38 AM Russ Housley > wrote: > > I think this is an improvement. > > Russ > > > On Jan 31, 2022, at 11:16 AM, Job Snijders > wrote: > > > > Dear Éric, > > > > I think you raise a "valid" concern (no pun intended ;-)) > > > > I think something along the following lines might help clarify the > > purpose of RPKI Manifests. > > > > OLD: > >    Specifically, if an RP checks a manifest's contents against the > >    signed objects retrieved from a repository publication point, > then > >    the RP can detect "stale" (valid) data and deletion of signed > objects. > > > > NEW: > >    Specifically, if an RP checks a manifest's contents against the > >    signed objects retrieved from a repository publication point, > then > >    the RP can detect replay attacks, in-flight modification, or > >    unauthorized deletion of signed objects. > > > > What do others think? > > > > Kind regards, > > > > Job > > > > On Mon, Jan 31, 2022 at 02:59:31AM -0800, Éric Vyncke via > Datatracker wrote: > >> Éric Vyncke has entered the following ballot position for > >> draft-ietf-sidrops-6486bis-09: No Objection > >> > >> When responding, please keep the subject line intact and reply > to all > >> email addresses included in the To and CC lines. (Feel free to > cut this > >> introductory paragraph, however.) > >> > >> > >> Please refer to > https://www.ietf.org/blog/handling-iesg-ballot-positions/ > >> for more information about how to handle DISCUSS and COMMENT > positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ > >> > >> > >> > >> > ---------------------------------------------------------------------- > >> COMMENT: > >> > ---------------------------------------------------------------------- > >> > >> Thank you for the work put into this document. > >> > >> Please find below one non-blocking COMMENT points. > >> > >> Special thanks to Chris Morrow for the shepherd's write-up > including the > >> section about the WG consensus (even if I would have appreciated a > >> justification for the PS status). > >> > >> I hope that this helps to improve the document, > >> > >> Regards, > >> > >> -éric > >> > >> -- Abstract -- > >> In "then the RP can detect "stale" (valid) data", is "valid" > really the right > >> word to use ? I would naively expect "invalid". Or is it just > an indication > >> that the data *was* valid and is stale? The use of "(.*)" in > the abstract was > >> more to explain the previous word and this use is different and > could confuse > >> the reader. > >> > >> > >> > >> _______________________________________________ > >> Sidrops mailing list > >> Sidrops@ietf.org > >> https://www.ietf.org/mailman/listinfo/sidrops > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --------------1cl0ipX0ADupU5EmrwGxSnyC Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi all,

It is indeed a better text.

Minor nit however, we will have 'in-flight modification' that only appears in the abstract, but not elaborated further on the draft.
The old abstract is elaborated nicely on the first paragraph of the draft, explaining that we have the manifest to protect against replay attacks and unauthorized deletions.

            However, digital signatures provide no protection against attacks that
            substitute "stale" versions of signed objects (i.e., objects that were
            valid and have not expired, but have since been superseded) or attacks
            that remove an object that should be present in the repository.  

            To assist in the detection of such attacks, the RPKI repository system can
            make use of a signed object called a "manifest".

Perhaps if we want to keep in-flight modification in the abstract, we need to elaborate further in the draft,
since usually I expect abstract to be a compressed version of what will be elaborated later.

Cheers,

Adianto

On 31/01/2022 18:56, Christopher Morrow wrote:
oh yea, that's nice :) I was struggling with the sentence myself (upon re-reading eric's question) .. since it seems to be talking about:
  "you have a remote copy (the RP) and your copy, the manifest helps you tell what's going to change in the local copy"
  (missing the context of local/remote copy correlation did me in)

anyway, yay! better text.

On Mon, Jan 31, 2022 at 11:38 AM Russ Housley <housley@vigilsec.com> wrote:
I think this is an improvement.

Russ

> On Jan 31, 2022, at 11:16 AM, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
>
> Dear Éric,
>
> I think you raise a "valid" concern (no pun intended ;-))
>
> I think something along the following lines might help clarify the
> purpose of RPKI Manifests.
>
> OLD:
>    Specifically, if an RP checks a manifest's contents against the
>    signed objects retrieved from a repository publication point, then
>    the RP can detect "stale" (valid) data and deletion of signed objects.
>
> NEW:
>    Specifically, if an RP checks a manifest's contents against the
>    signed objects retrieved from a repository publication point, then
>    the RP can detect replay attacks, in-flight modification, or
>    unauthorized deletion of signed objects.
>
> What do others think?
>
> Kind regards,
>
> Job
>
> On Mon, Jan 31, 2022 at 02:59:31AM -0800, Éric Vyncke via Datatracker wrote:
>> Éric Vyncke has entered the following ballot position for
>> draft-ietf-sidrops-6486bis-09: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thank you for the work put into this document.
>>
>> Please find below one non-blocking COMMENT points.
>>
>> Special thanks to Chris Morrow for the shepherd's write-up including the
>> section about the WG consensus (even if I would have appreciated a
>> justification for the PS status).
>>
>> I hope that this helps to improve the document,
>>
>> Regards,
>>
>> -éric
>>
>> -- Abstract --
>> In "then the RP can detect "stale" (valid) data", is "valid" really the right
>> word to use ? I would naively expect "invalid". Or is it just an indication
>> that the data *was* valid and is stale? The use of "(.*)" in the abstract was
>> more to explain the previous word and this use is different and could confuse
>> the reader.
>>
>>
>>
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops
--------------1cl0ipX0ADupU5EmrwGxSnyC-- From nobody Tue Feb 1 22:43:16 2022 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E023A25A4; Tue, 1 Feb 2022 22:42:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-6486bis@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, morrowc@ops-netman.net X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <164378415609.9683.10141540796531135717@ietfa.amsl.com> Date: Tue, 01 Feb 2022 22:42:36 -0800 Archived-At: Subject: [Sidrops] Murray Kucherawy's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 06:42:38 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-sidrops-6486bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The response to question 7 of the shepherd writeup doesn't really answer the question being asked. Also, please tidy up the stuff identified in the answer to question 11. Section 4.2.1: * "... this field is more recent any previously-generated ..." -- s/recent/recent than/ Appendix B: * Since this is obsoleting, not updating, RFC 6486, I think this is more like "Changes Since RFC 6486". From nobody Wed Feb 2 02:04:28 2022 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 482763A2C53; Wed, 2 Feb 2022 02:04:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Zaheduzzaman Sarker via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-6486bis@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, morrowc@ops-netman.net, morrowc@ops-netman.net X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Zaheduzzaman Sarker Message-ID: <164379626127.24070.9456287680446733998@ietfa.amsl.com> Date: Wed, 02 Feb 2022 02:04:21 -0800 Archived-At: Subject: [Sidrops] Zaheduzzaman Sarker's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 10:04:22 -0000 Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-sidrops-6486bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the efforts on this specification. It was a good read. After reading the shepherd's writeup I was expecting an update to 6486 but the document actually obsoletes 6486. Something happened between when the shepherd writeup was written and when this doc went for publication, not captured. Not a big deal I guess, would have been better to get this captured. Nits: Section 4.2.1 : "The issuer MUST ensure that the value of this field is more recent any previously-generated Manifest", missing "than" ? From nobody Wed Feb 2 05:07:01 2022 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A36213A09F9; Wed, 2 Feb 2022 05:06:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francesca Palombini via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-6486bis@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, morrowc@ops-netman.net, morrowc@ops-netman.net X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Francesca Palombini Message-ID: <164380721377.28554.13713193582509780845@ietfa.amsl.com> Date: Wed, 02 Feb 2022 05:06:54 -0800 Archived-At: Subject: [Sidrops] Francesca Palombini's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 13:06:55 -0000 Francesca Palombini has entered the following ballot position for draft-ietf-sidrops-6486bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work on this document I have an easy to fix point that should be address before publication (although it probably does not rise to the level of DISCUSS). I also have a number of minor comments (answers will be appreciated) and nits. Francesca # Major 1. ----- objects from a successful fetch. This implies that the RP MUST not FP: This should be "MUST NOT" (rather than "MUST not") # Minor 2. ----- FP: as noted by the shepherd, there are some references to fix: * RFC 6485 needs to be replaced with RFC 7935 The following references need to be removed as they are not used. == Unused Reference: 'RFC6482' == Unused Reference: 'RFC6493' == Unused Reference: 'RFC8209' == Unused Reference: 'RFC8488' (this was even last called as downref) 3. ----- monotonically for each newly-generated Manifest. Each RP MUST verify that a purported "new" Manifest contains a higher manifestNumber than previously-validated Manifests. FP: This should contain a sentence about what the RP has to do if verification fails (I expect ignore the "new" Manifest). Same comment for the thisUpdate field: Manifest. Each RP MUST verify that this field value is greater (more recent) than the most recent Manifest it has validated. And for the text in Section 5.1: Note: An RP MUST verify all mandated syntactic constraints, i.e., constraints imposed on a CA via a "MUST". publication point that is described by the manifest. (RPs are required to verify the CMS signature.) 4. ------ nextUpdate time. Each manifest encompasses a CRL, and the nextUpdate field of the manifest SHOULD match that of the CRL's nextUpdate field, as the manifest will be re-issued when a new CRL FP: What are the exception cases where it is expected not to match (i.e. what is the reason for the SHOULD here)? 5. ----- The RP MUST check that the current time (translated to UTC) is between thisUpdate and nextUpdate. If the current time lies within FP: I am not sure the parenthesis needs to be there - this seems like an unnecessary implementation detail. # Nits 6. ----- * all published signed objects that are verifiable using EE FP: Please expand all acronyms (EE, OID) on first use 7. ----- termed a "one-time-use" EE certificate [RFC6487] FP: missing period From nobody Wed Feb 2 08:21:27 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8874B3A14EA for ; Wed, 2 Feb 2022 08:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.351, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 yMFx6nst8RMr for ; Wed, 2 Feb 2022 08:21:20 -0800 (PST) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl0gcc02on2070e.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d05::70e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7BA3A14EE for ; Wed, 2 Feb 2022 08:21:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ME+vbkm67fYPFIDZ5S75/eLStq/2uVvz8Gxj7ghWyNlPKHtSVVF5o8AT+i1RdaQTiUch+uVoeIT54yus6y8se1tgcpFqZiWVXARXicaGPkm8+iOT6Pl4dSIPq2rA/vOJ4VEt1sx/yV6gpd6bgJ+yhJ559EzatCsUIMEusudWekM268h43jvNFvnG589v3Tv5UAhD3YunOOAtkMsHiZo1aT6SxIGFr+NRJHWnofjn3IKFAkeXjDO3xoYhqKFp3auetJ7TsUd15PvceeP7mlsuHmZgqoZ6MaQImLtxOtsrsYO+89g5Po5t3MMuB7CbiOFA85/pvZv6ngESl6rdbfNQYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UF+cDjOjwcrttvvNnQ42QDyDnMbL4+eity9fq4oLnZ4=; b=GLqw3WxYaBDZH0v4qjr1B0hW8SDGX4t5SNVdQP4AdWa7tccdW++QtI+Tq8MJ1A5oLiatnkao2YcUKbGjcSKcxceIJUsDBUL2+YFUQ/L9e9nwtuy6Ehos0RoVwUZ+04bpzoykfQY4VozJhL4uCXAdqWiVzMdfcmAF+1AomiiCoOeh65BfhSZk0bUttwH6FBeWDIvmTpyyD8AtdOrleHQ4lJoJ6GZfdzYFVOzWjYf8DItr8Jqp+xVnxqxFmgpXyW6krBVA/IUU8eZd7u55qqVyUsZzKagwBT6uzsfEyvHrmKYLhXuzUPZl6DL4MwyEIrYkAQ8D2IPi6SjznK+EXuIF9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UF+cDjOjwcrttvvNnQ42QDyDnMbL4+eity9fq4oLnZ4=; b=n+keWEcv+0SwZLj++IIhJCAbr8/q7LxDN6zWBUPOgBSHe8+Z864tIfENIco/ss3Q22TuQ/J9IhuE67tbzZiXUnNF0A1MLYbLTLnbjqqZ94kle9wTpTfNYOeg7L/2pbVi4sFXVTS4qHQmXPdWYXmMTvkHums+PyeRT3N1Bolr0NI= Received: from BLAPR09MB6322.namprd09.prod.outlook.com (2603:10b6:208:2af::22) by BLAPR09MB7298.namprd09.prod.outlook.com (2603:10b6:208:2a6::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Wed, 2 Feb 2022 16:21:16 +0000 Received: from BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::99ab:eef5:2030:3f97]) by BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::99ab:eef5:2030:3f97%7]) with mapi id 15.20.4951.012; Wed, 2 Feb 2022 16:21:16 +0000 From: "Borchert, Oliver (Fed)" To: Job Snijders , Keyur Patel CC: "sidrops@ietf.org" , "Borchert, Oliver (Fed)" Thread-Topic: [Sidrops] Closed -- [WGLC] draft-ietf-sidrops-8210bis-05 - Ends 31/January/2022 Thread-Index: AQHYFtX+bUsNBqfVM0SrgLrMNKXTLqx9hwCAgAKZUAA= Date: Wed, 2 Feb 2022 16:21:16 +0000 Message-ID: <33F461A3-6D77-4C5E-9F53-D59443D697CA@nist.gov> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.57.22011101 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ef7d6d2c-fbe6-41cc-c425-08d9e6680a02 x-ms-traffictypediagnostic: BLAPR09MB7298:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wGXHQNTMbOCu4SXxVEY9PwT1yo34z0qAwKhD8CbofobnOZ0oU6yUuMHqF+x/Z74nUfbygyyLnammZhhGFdCBHUA1vau+2B1SnGbl2l/+ieh/qJ1kNzbv9OuAYpCfy8Clha8OfCAPP6TUiq7nfQ/oCbb/Y1vwogknUv9XqkQWgbdpFZfUZMApGvy2Ly/Fbd+aKuA0Wwtfr2oo+xc7e/BOwRGaiNWqAoaHOgpYIDeCI2J5fr3xRrhBqSp3oW7CS5NleN/nadpIHRhHmJaac4QFwpdY76hyHU84f7TAeDWoVYa659S5SZiA/E+zZtl0R0G7Lzv1RJ6BNVfER3Kc6AdGrI/os1aiaQ17c1zTEld5JE+pU8KEck6kSK1oZBuDq/HdjvDEqIZj0RqAdE275Brgpmgx1L4jHvJMuxddmb78tqtDpWK4Zv0snYmhfRrfFYXVwsqWnR+FeFJiW9iBrsgaBSZ263DwT0d5g4gAAy51baDaeQTXtawivDnHMbycKxEgWA4bS4r3MMubHnfZNw1lWJVyOlBPHmOAi9oj9zZhGY8KOEMTP8uqZCVwmj9CX4BrIamU3HfhfM95ikN2erPrQQEqCRXZOs76tJL5g5T1TuRkpl8GYhZ/MzrV4dex2/GsbOKbsmHv1531HoyOtdWGICi+vOUI+Wwk+IzGiqNRBCD8EYsYSDNjo/qtiHQ++g8yT54Tn0UUeoA519v16mg4O744du8czDHkwj9fkhBUTg/RX0VCvLZRv+BomZGWBOOSYabJu1k4Y4doXy/b9ItQ1mQlaEHEoTXHmPhaXCkppfYUDN/EwVYEgq4hVqcPHQLG x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR09MB6322.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(76116006)(83380400001)(38070700005)(2906002)(66574015)(6506007)(8936002)(4326008)(316002)(53546011)(2616005)(5660300002)(110136005)(33656002)(54906003)(66476007)(107886003)(6512007)(66556008)(64756008)(66946007)(66446008)(166002)(40140700001)(8676002)(122000001)(38100700002)(966005)(82960400001)(71200400001)(508600001)(6486002)(36756003)(186003)(86362001)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TTlSWEVCNzlRcUhKbmxRVlM2czFEdDdrcXpSWnJNQ3dReG5TWUJ2elpHM3Rt?= =?utf-8?B?ck5wOWgxTXBQbUY2M0ZoZnNPRzgwOUNyR1RtSGRleEpzUXorQWNUZzRyTWZn?= =?utf-8?B?Ly9aRGVBNlU0L0FWMVB0WnlaTTRLdFRvZ0kySDcvdGtVdjlLcDltTGo5Q1NQ?= =?utf-8?B?b3FENHhTQ2oweE5qN2dPMUtXdXVYYkt3RWN4Ty83WThEQVdOSXR1S3pacDZu?= =?utf-8?B?cE96OWROV2NMdlpoR3ZjRE95bWlnOXFWZjFuaTdtRUNXR1FlZXFsdGtIK3lB?= =?utf-8?B?M214UUQwQklQblh3d3dOcEttaXpNQ2VQMk9wL1R3cy9tMDhXeGxPUjUvaFFS?= =?utf-8?B?eDhURG9wT1c2bWdqQzBRTXFaZ1FoaHhwWVlNQ2tGckY1ekdDYTZvY1VOcHFH?= =?utf-8?B?SEgzWTM2emorQ3pNK0RpZ2NFZm5iK1pxbWkxOHJNNUFQTEZOYUY2YVlLTUpN?= =?utf-8?B?NnJOd1IwTEhSdC9aMi9lUXQ3WkNBZ3JCZWs5aFFQQU1NNnh0Ym91Z21hMU00?= =?utf-8?B?Q2hCWmljZklKbCt3elhlZzUvcTMyeDFzM2RHbGNRcjNmUnhWYjZJQ0c4QlNV?= =?utf-8?B?M3ArVTE2Y3Z5Z053ZmNyNGJUU2ZoTE14NEFURHQvRnNEa1lCbjN6a1BaOEF5?= =?utf-8?B?UGMrejlvRDRlNkVHeW1HaC9WWVNLU2J5TTAyOWRPb3RqTFc1eEN2TllNcytw?= =?utf-8?B?VnR5TUhqSUdOREJEK1J1WG1kOWdsZGZkYTRlWVhXSUpNbmVrN3BmSXFraTdR?= =?utf-8?B?eXlhNXVEZytsVG1ZVysvZkNyaTczSGZ0ZU1JbUNkZDdPd3hFOVQvRmdadFJv?= =?utf-8?B?MDNySTlGbnRpMnd5R0hMNzFwVTRIUnNPMDh3VU1sODNORXpsOFBiRnhLbGF5?= =?utf-8?B?NGFtb0ZVNGVsalVKNVRZYnZaL05LTUl2bFk3anp5di92VXFGTFZSTXRpM1R4?= =?utf-8?B?TzRQSll6MlBLTHBlM2FBZ1FLRDdXQldvdXJEYy93Y2dVZEp0YkxUa1lWYTQ3?= =?utf-8?B?WDNPT0dVbWlZOWhuaDZoZjFDWVY3QitaRjZBZGNqc3FDS2h1ZnJheUpWT1NG?= =?utf-8?B?THJIWXlhM04wM05LYW1hTlBMU0xrVkh5VzBFVTVobVRUM2dFOFlmSk9RYXZu?= =?utf-8?B?amQ1UUdZS0NDOUdOK0RmbW84L2JER25DTmVOaEg5MXZ2ZndNUWRnQ25RbXZX?= =?utf-8?B?bzU0eHNZL2dkY090ZVFLMG4xQjBuQitwZjdmRVp4RGhlSlUwZThjSHlFaFFp?= =?utf-8?B?eXhOUk5COWY4NmtsN0dyL3ZtSDNRbkhEaHdCc2xSeWxsTzBjRmZqRW44elow?= =?utf-8?B?Mk5NZzlzc1VialhVTDZDL1V4aCtCWThMbEJKWlViSG1URUhnZUJBRkR6MFN4?= =?utf-8?B?TFlxSjd3UTEvZjE0cWpZTVJLTXYyTFZwOVBhaDZHWmVxTVpCQnowWGVHdmt6?= =?utf-8?B?SkM4SmQwSTZCejNkV1BpeGRodzFXVTdacGZ0YkZXRlRQdG15Qi9pMjNiVkd0?= =?utf-8?B?OC9pVlMwV1pJRHNjSFV0Nnh1NXRFenBHY1laem1sWEg1N1NyaERydjR2cE9z?= =?utf-8?B?SHU4SmR0VHZUdmladnZxUkVjT0tFaCtucDM1eU1oYVVCRXRXZ0dSTTZocGFR?= =?utf-8?B?SElzcUxObnFOMnBXV3c0WlRTM3BKa2IxcUM0OW1rVUxQb1A1d0tZZzBmWUVP?= =?utf-8?B?MTJqb3V3amE2R0h0UDlBcnBsUTJUNWIvVUwvc3VJdjU2UDVwUm1VdmRyazRm?= =?utf-8?B?dDduTnBPWjlGR2E4Nlh4b0hrQlV2dGlMN0NjODF2K1RsazZOUGFSYlBLRkY2?= =?utf-8?B?U3VTTTJPSlNmZUhkODdvdz09?= Content-Type: multipart/alternative; boundary="_000_33F461A36D774C5E9F53D59443D697CAnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6322.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ef7d6d2c-fbe6-41cc-c425-08d9e6680a02 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2022 16:21:16.7482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB7298 Archived-At: Subject: Re: [Sidrops] Closed -- [WGLC] draft-ietf-sidrops-8210bis-05 - Ends 31/January/2022 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 16:21:26 -0000 --_000_33F461A36D774C5E9F53D59443D697CAnistgov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gZmFyIHdlIGRpZCBub3QgaGF2ZSB0aGUgdGltZSB0byB1cGRhdGUgdGhlIGltcGxlbWVudGF0 aW9uIHRvIHRoZSBsYXRlc3QgY2hhbmdlcy4NCg0KU2FpZCB0aGF0IEkgYW0gc29ycnkgdG8gbWlz cyB0aGlzIGxhc3QgY2FsbCBiZWNhdXNlIEkgd291bGQgaGF2ZSByZS1yZXF1ZXN0ZWQgb25lIG1v cmUgZWRpdG9yaWFsIGNoYW5nZSB0aGF0IEkgcG9pbnRlZCBvdXQgZHVyaW5nIHRoZSBwcmV2aW91 cyBXTEMuIFRoZSBpc3N1ZSBpcyB0aGUgRmxhZ3MgZmllbGQsIHdoaWNoIGlzIGRlZmluZWQgdHdp Y2UsIE9uY2Ug4oCcZ2xvYmFsbHnigJ0gaW4gY2hhcHRlciA1LjEgRmllbGRzIG9mIFBEVSB3aGlj aCBjb250YWlucyB0aGUgZXhwbGFuYXRpb24gb24gd2hhdCB0byBkbyBmb3IgdGhlIFJPQSBhbmQg S2V5IGhhbmRsaW5nLiBUaGVuIG9uZSBtb3JlIHRpbWUgaW4gY2hhcHRlciA1LjEyIEFTUEEgUERV Lg0KDQpJIG1lbnRpb25lZCB0aGF0IGFscmVhZHkgaW4gTm92ZW1iZXIgb3IgRGVjZW1iZXIgdGhh dCBmb3IgY29tcGxldGVuZXNzIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gYWRkIHRoZSB0ZXh0IGZy b20gNS4xMiBpbnRvIDUuMSBhcyBpdCBpcyBkb25lIHdpdGggdGhlIG90aGVyIFBEVeKAmXMuDQoN Ck9saXZlcg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KT2xpdmVyIEJvcmNoZXJ0LCBDb21wdXRlciBTY2llbnRpc3QNCk5hdGlvbmFsIEluc3RpdHV0 ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3kNCihPZmZpY2UpICsxLjMwMS45NzUuNDg1Ng0K KEdWb2ljZSkgKzEuMjQwLjY2OC40MTE3DQoNCg0KRnJvbTogU2lkcm9wcyA8c2lkcm9wcy1ib3Vu Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSm9iIFNuaWpkZXJzIDxqb2I9NDBmYXN0bHkuY29t QGRtYXJjLmlldGYub3JnPg0KRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDMxLCAyMDIyIGF0IDI6NDEg UE0NClRvOiBLZXl1ciBQYXRlbCA8a2V5dXJAYXJyY3VzLmNvbT4NCkNjOiAic2lkcm9wc0BpZXRm Lm9yZyIgPHNpZHJvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1NpZHJvcHNdIENsb3NlZCAt LSBbV0dMQ10gZHJhZnQtaWV0Zi1zaWRyb3BzLTgyMTBiaXMtMDUgLSBFbmRzIDMxL0phbnVhcnkv MjAyMg0KDQpIaSBhbGwsDQoNCkFyZSBhbnkgaW1wbGVtZW50YXRpb24gcmVwb3J0cyBhdmFpbGFi bGU/IEkgdGhpbmsgT2xpdmVyL05JU1QgbWlnaHQgaGF2ZSBvbmUsIGlzIHRoZXJlIGFub3RoZXI/ DQoNCkl0IG1pZ2h0IGJlIGdvb2QgdG8gY29uZmlybSB0aGlzIGJlZm9yZSBmb3J3YXJkaW5nIHRv IElFU0cuDQoNCktpbmQgcmVnYXJkcywNCg0KSm9iDQoNCk9uIE1vbiwgMzEgSmFuIDIwMjIgYXQg MjA6MDksIEtleXVyIFBhdGVsIDxrZXl1ckBhcnJjdXMuY29tPG1haWx0bzprZXl1ckBhcnJjdXMu Y29tPj4gd3JvdGU6DQpIaSBGb2xrcywNCg0KVGhpcyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBp cyBjbG9zZWQuIEF0IHRoaXMgcG9pbnQsIHRoZSBkcmFmdCBpcyByZWFkeSB0byBwcm9ncmVzcyBm dXJ0aGVyLiBBY2NvcmRpbmdseSB3ZSB3aWxsIHByZXBhcmUgYSByZXBvcnQgYW5kIGZvcndhcmQg aXQgdG8gSUVTRy4NCg0KUmVnYXJkcywNCk5hdGhhbGllLCBDaHJpcyAmIEtleXVyDQoNCg0KRnJv bTogS2V5dXIgUGF0ZWwgPGtleXVyQGFycmN1cy5jb208bWFpbHRvOmtleXVyQGFycmN1cy5jb20+ Pg0KRGF0ZTogTW9uZGF5LCBKYW51YXJ5IDE3LCAyMDIyIGF0IDI6MjkgUE0NClRvOiAic2lkcm9w c0BpZXRmLm9yZzxtYWlsdG86c2lkcm9wc0BpZXRmLm9yZz4iIDxzaWRyb3BzQGlldGYub3JnPG1h aWx0bzpzaWRyb3BzQGlldGYub3JnPj4NClN1YmplY3Q6IFtXR0xDXSBkcmFmdC1pZXRmLXNpZHJv cHMtODIxMGJpcy0wNSAtIEVuZHMgMzEvSmFudWFyeS8yMDIyDQoNCg0KSGkgRm9sa3M6DQoNCg0K DQpBIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGhhcyBiZWVuIHJlLWlzc3VlZCBmb3IgZHJhZnQt aWV0Zi1zaWRyb3BzLTgyMTBiaXMtMDUsIOKAnFRoZSBSZXNvdXJjZSBQdWJsaWMgS2V5IEluZnJh c3RydWN0dXJlIChSUEtJKSB0byBSb3V0ZXIgUHJvdG9jb2wsIFZlcnNpb24gMuKAnS4gIEFsbCB0 aGUgcGVuZGluZyBlZGl0cyBhbmQgZGlzY3Vzc2VzIGZyb20gdGhlIHByZXZpb3VzIGxhc3QgY2Fs bCBoYXMgYmVlbiByZXNvbHZlZC4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBj b21tZW50cy4gVGhlIFdHTEMgd2lsbCBlbmQgb24gSmFudWFyeSAzMXN0LCAyMDIyLg0KDQoNCg0K VGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LWlldGYtc2lkcm9wcy04MjEwYmlzPGh0dHBzOi8vZ2NjMDIuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmll dGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWlldGYtc2lkcm9wcy04MjEwYmlzJmRhdGE9MDQl N0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdDYmJkOTJlMTlkZDU4NDdhNGExMmMw OGQ5ZTRmMThiYzAlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdD NjM3NzkyNTQ4Nzk2MTA0NDMxJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xq QXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzIw MDAmc2RhdGE9UVlYblJMZWNsa0tzeXNIaE52N2dUQmdlSXJha3o2T2tpa2hPWWNDUnlNayUzRCZy ZXNlcnZlZD0wPi4gQXV0aG9ycywgcGxlYXNlIHJlcGx5IGluZGljYXRpbmcgd2hldGhlciB5b3Un cmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiB0aGF0IGhhc24ndCBiZWVuIGRpc2Nsb3NlZC4N Cg0KDQoNClJlZ2FyZHMsDQoNCk5hdGhhbGllLCBDaHJpcyAmIEtleXVyDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNpZHJvcHMgbWFpbGluZyBs aXN0DQpTaWRyb3BzQGlldGYub3JnPG1haWx0bzpTaWRyb3BzQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyb3BzPGh0dHBzOi8vZ2NjMDIuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9y ZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNpZHJvcHMmZGF0YT0wNCU3QzAxJTdDb2xpdmVyLmJv cmNoZXJ0JTQwbmlzdC5nb3YlN0NiYmQ5MmUxOWRkNTg0N2E0YTEyYzA4ZDllNGYxOGJjMCU3QzJh YjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2Mzc3OTI1NDg3OTYyNjA2 NTMlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYy bHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMjAwMCZzZGF0YT1IVUF3NjRR SGxFa3FEamUzWGV2NlNIT255aG9xTSUyQiUyQjJyYnRnZ0UzVVh3cyUzRCZyZXNlcnZlZD0wPg0K --_000_33F461A36D774C5E9F53D59443D697CAnistgov_ Content-Type: text/html; charset="utf-8" Content-ID: <0320BC80590D424DAFA0A020B0B10B15@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIg MiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3Nl LTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p bHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q291cmllcjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZv bnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvdXJpZXIiPlNvIGZhciB3ZSBkaWQgbm90IGhhdmUgdGhlIHRpbWUgdG8gdXBkYXRlIHRoZSBp bXBsZW1lbnRhdGlvbiB0byB0aGUgbGF0ZXN0IGNoYW5nZXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj5TYWlkIHRoYXQgSSBhbSBzb3JyeSB0byBtaXNz IHRoaXMgbGFzdCBjYWxsIGJlY2F1c2UgSSB3b3VsZCBoYXZlIHJlLXJlcXVlc3RlZCBvbmUgbW9y ZSBlZGl0b3JpYWwgY2hhbmdlIHRoYXQgSSBwb2ludGVkIG91dCBkdXJpbmcgdGhlIHByZXZpb3Vz IFdMQy4gVGhlIGlzc3VlIGlzIHRoZSBGbGFncyBmaWVsZCwgd2hpY2ggaXMgZGVmaW5lZCB0d2lj ZSwNCiBPbmNlIOKAnGdsb2JhbGx54oCdIGluIGNoYXB0ZXIgNS4xIEZpZWxkcyBvZiBQRFUgd2hp Y2ggY29udGFpbnMgdGhlIGV4cGxhbmF0aW9uIG9uIHdoYXQgdG8gZG8gZm9yIHRoZSBST0EgYW5k IEtleSBoYW5kbGluZy4gVGhlbiBvbmUgbW9yZSB0aW1lIGluIGNoYXB0ZXIgNS4xMiBBU1BBIFBE VS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+SSBt ZW50aW9uZWQgdGhhdCBhbHJlYWR5IGluIE5vdmVtYmVyIG9yIERlY2VtYmVyIHRoYXQgZm9yIGNv bXBsZXRlbmVzcyBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIGFkZCB0aGUgdGV4dCBmcm9tIDUuMTIg aW50byA1LjEgYXMgaXQgaXMgZG9uZSB3aXRoIHRoZSBvdGhlciBQRFXigJlzLiAmbmJzcDsmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q291cmllciI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPk9saXZl cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDb3VyaWVyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD b3VyaWVyO2NvbG9yOmJsYWNrIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5PbGl2ZXIgQm9yY2hl cnQsIENvbXB1dGVyIFNjaWVudGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj5O YXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9sb2d5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvdXJpZXI7Y29sb3I6YmxhY2siPihPZmZpY2UpICsxLjMwMS45NzUuNDg1NjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4oR1ZvaWNlKSArMS4yNDAuNjY4LjQxMTc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5TaWRyb3BzICZsdDtzaWRyb3Bz LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBKb2IgU25pamRlcnMgJmx0O2pvYj00 MGZhc3RseS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwg SmFudWFyeSAzMSwgMjAyMiBhdCAyOjQxIFBNPGJyPg0KPGI+VG86IDwvYj5LZXl1ciBQYXRlbCAm bHQ7a2V5dXJAYXJyY3VzLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3NpZHJvcHNAaWV0 Zi5vcmcmcXVvdDsgJmx0O3NpZHJvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PlJlOiBbU2lkcm9wc10gQ2xvc2VkIC0tIFtXR0xDXSBkcmFmdC1pZXRmLXNpZHJvcHMtODIxMGJp cy0wNSAtIEVuZHMgMzEvSmFudWFyeS8yMDIyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QXJlIGFueSBpbXBsZW1lbnRhdGlvbiByZXBv cnRzIGF2YWlsYWJsZT8gSSB0aGluayBPbGl2ZXIvTklTVCBtaWdodCBoYXZlIG9uZSwgaXMgdGhl cmUgYW5vdGhlcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5JdCBtaWdodCBiZSBnb29kIHRvIGNvbmZpcm0gdGhpcyBiZWZvcmUgZm9yd2FyZGluZyB0byBJ RVNHLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPktpbmQg cmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5K b2I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPk9uIE1vbiwgMzEgSmFuIDIwMjIgYXQgMjA6MDksIEtleXVyIFBhdGVsICZsdDs8YSBo cmVmPSJtYWlsdG86a2V5dXJAYXJyY3VzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtleXVyQGFycmN1 cy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K SGkgRm9sa3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluIj4NClRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaXMgY2xvc2Vk LiBBdCB0aGlzIHBvaW50LCB0aGUgZHJhZnQgaXMgcmVhZHkgdG8gcHJvZ3Jlc3MgZnVydGhlci4g QWNjb3JkaW5nbHkgd2Ugd2lsbCBwcmVwYXJlIGEgcmVwb3J0IGFuZCBmb3J3YXJkIGl0IHRvIElF U0cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVp biI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluIj4NClJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpOYXRoYWxpZSwgQ2hyaXMgJmFtcDsgS2V5dXI8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4i Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8Yj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5LZXl1 ciBQYXRlbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtleXVyQGFycmN1cy5jb20iIHRhcmdldD0iX2Js YW5rIj5rZXl1ckBhcnJjdXMuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBK YW51YXJ5IDE3LCAyMDIyIGF0IDI6MjkgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9 Im1haWx0bzpzaWRyb3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2lkcm9wc0BpZXRmLm9y ZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzaWRyb3BzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+c2lkcm9wc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltX R0xDXSBkcmFmdC1pZXRmLXNpZHJvcHMtODIxMGJpcy0wNSAtIEVuZHMgMzEvSmFudWFyeS8yMDIy PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMyMTI1 MjkiPkhpIEZvbGtzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZjtjb2xvcjojMjEyNTI5Ij5BIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGhhcyBi ZWVuIHJlLWlzc3VlZCBmb3IgZHJhZnQtaWV0Zi1zaWRyb3BzLTgyMTBiaXMtMDUsIOKAnFRoZSBS ZXNvdXJjZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChSUEtJKSB0byBSb3V0ZXIgUHJvdG9j b2wsIFZlcnNpb24gMuKAnS4mbmJzcDsgQWxsIHRoZSBwZW5kaW5nIGVkaXRzIGFuZCBkaXNjdXNz ZXMgZnJvbSB0aGUgcHJldmlvdXMgbGFzdCBjYWxsIGhhcyBiZWVuIHJlc29sdmVkLiBQbGVhc2Ug cmVwbHkgdG8gdGhlIGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLiBUaGUgV0dMQyB3aWxsIGVuZCBv biBKYW51YXJ5IDMxPHN1cD5zdDwvc3VwPiwgMjAyMi48L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMy MTI1MjkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzIxMjUyOSI+VGhlIGRyYWZ0IGNh biBiZSBmb3VuZCBhdCA8YSBocmVmPSJodHRwczovL2djYzAyLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRv YyUyRmh0bWwlMkZkcmFmdC1pZXRmLXNpZHJvcHMtODIxMGJpcyZhbXA7ZGF0YT0wNCU3QzAxJTdD b2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0NiYmQ5MmUxOWRkNTg0N2E0YTEyYzA4ZDllNGYx OGJjMCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2Mzc3OTI1 NDg3OTYxMDQ0MzElN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlM Q0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMjAwMCZhbXA7 c2RhdGE9UVlYblJMZWNsa0tzeXNIaE52N2dUQmdlSXJha3o2T2tpa2hPWWNDUnlNayUzRCZhbXA7 cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzM3QUI3Ij5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc2lkcm9wcy04 MjEwYmlzPC9zcGFuPjwvYT4uIEF1dGhvcnMsIHBsZWFzZSByZXBseSBpbmRpY2F0aW5nIHdoZXRo ZXIgeW91J3JlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIgdGhhdCBoYXNuJ3QgYmVlbiBkaXNj bG9zZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMjEyNTI5Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmO2NvbG9yOiMyMTI1MjkiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjtjb2xvcjojMjEyNTI5 Ij5OYXRoYWxpZSwgQ2hyaXMgJmFtcDsgS2V5dXI8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KU2lkcm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 U2lkcm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlNpZHJvcHNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJG c2lkcm9wcyZhbXA7ZGF0YT0wNCU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5nb3YlN0Ni YmQ5MmUxOWRkNTg0N2E0YTEyYzA4ZDllNGYxOGJjMCU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0 NjU1YzYxZGVjJTdDMSU3QzAlN0M2Mzc3OTI1NDg3OTYyNjA2NTMlN0NVbmtub3duJTdDVFdGcGJH WnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3 aUxDSlhWQ0k2TW4wJTNEJTdDMjAwMCZhbXA7c2RhdGE9SFVBdzY0UUhsRWtxRGplM1hldjZTSE9u eWhvcU0lMkIlMkIycmJ0Z2dFM1VYd3MlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHJvcHM8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_33F461A36D774C5E9F53D59443D697CAnistgov_-- From nobody Wed Feb 2 08:24:21 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E281F3A155A for ; Wed, 2 Feb 2022 08:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.351, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 P_cSTgLILb-G for ; Wed, 2 Feb 2022 08:24:06 -0800 (PST) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2096.outbound.protection.outlook.com [40.107.91.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1184B3A1542 for ; Wed, 2 Feb 2022 08:24:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hX3MkF2Et4FG/sOwS+JZt01HIb70hgtH3Icuj8Pdm+JoNmlM9/eWdls0+0iBam6oRUR8jGtxO/VSgx5rPu9mZWC1W7ald0zKnWTO+KpqSAat2kApRVHfMQ5udN1A/Dr6ydZo0wK+W4TKN/eFNVcj7q95vY+2MqjBtj8DvnirO+DWoGeEzRBsuFf5ExdiPt2s8vhqaHxlRZXbFgI3M7up41MQZxDg16P2L4uimi44QvGidQnNd80cwUPpfp6HXCMBtvrHnjAwz26zx+0XjGGWivrSEqgb8H12xyReKF7XZf2sAYsg62ur5kK5U7e9PO5jAUwV3q7LlY6Ur38bjZQRow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YzkPVNH0n06QDKWsHLR9QgDpgX/oYJ7Kz/+lMoXtCWI=; b=O62FeK8MHahbOo2AX31wTvMCXjdNr2LScK8+1uRF/7U+LgB2ytML+ptgRDtt7C9DSp/r+/IbE/jxwG1eugqlBE3PVkIKRg5u68/7azWZPUGyU28T5Pfwq1g1kCmJfsd/kSnCF2NZIIe1PCLM2qJOV/iEuXDH/JOZh0XmDxWdhxxiOGtwl4XWQkZNphn3FfqyCtPaBecFvFFIFojQiEnFOwEXaL1g83xHw32cpC/4KchP0ElFcjYjMNEuPt9kLFVq+uhQBtPckPoUMvnDq1lacPeN/5D60SkobgKWUNM9qdi54Kx2xQjsE4ROZRZbJBI6vjTNIbMrAJnaEAL7XDYq1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YzkPVNH0n06QDKWsHLR9QgDpgX/oYJ7Kz/+lMoXtCWI=; b=lu1NViHZjL0k77BP+uiB41vXMsZmne9v+/nQ/qIGbNhXy+zYJ94ZHOaRJr06lT7pEfplY2PhVkWQePSny/Pmkf8Gbgn36r/GceNyfo2UzZmQ1NKsrjl+uhXQm6CZA7yP33U8LFs0/q7aRTeyCYYiUWaStIDIkFZOsjcBkI1ck3M= Received: from BLAPR09MB6322.namprd09.prod.outlook.com (2603:10b6:208:2af::22) by BLAPR09MB6385.namprd09.prod.outlook.com (2603:10b6:208:28a::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.11; Wed, 2 Feb 2022 16:24:03 +0000 Received: from BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::99ab:eef5:2030:3f97]) by BLAPR09MB6322.namprd09.prod.outlook.com ([fe80::99ab:eef5:2030:3f97%7]) with mapi id 15.20.4951.012; Wed, 2 Feb 2022 16:24:03 +0000 From: "Borchert, Oliver (Fed)" To: Job Snijders , Keyur Patel CC: "sidrops@ietf.org" , "Borchert, Oliver (Fed)" Thread-Topic: [Sidrops] Closed -- [WGLC] draft-ietf-sidrops-8210bis-05 - Ends 31/January/2022 Thread-Index: AQHYFtX+bUsNBqfVM0SrgLrMNKXTLqx9hwCAgAKZUACAAADHgA== Date: Wed, 2 Feb 2022 16:24:03 +0000 Message-ID: References: <33F461A3-6D77-4C5E-9F53-D59443D697CA@nist.gov> In-Reply-To: <33F461A3-6D77-4C5E-9F53-D59443D697CA@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.57.22011101 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 44aa05fe-0d31-4168-1722-08d9e6686d7f x-ms-traffictypediagnostic: BLAPR09MB6385:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BVJ1bm++LP8WIZZAwfJOZKs45qtUZ9SbiHjMANCh7Y8sHz0JHOIxbhW2Wp5kIYTMwWjUnxnL4YI7iglrsDrBikKnZdoMFHsF2+/Cwfuu66bzSJzJqSJWTDJCOwYV0vt5/CA5UVB4FU5bEgraF+uwg5vWJdb6/TPuUVbud0tyv28kcghxCUDYBS/SFUv59OIrE5CbNKvqVHn7HJDK5bQ32TwvIOV/BhJTza2BdK5pLTSMAhdILHel9jkZ0KjX6tqD7IoY3qqBW1mU33FMHrNsTD5a78MtUPZ0I9DvWa/GoYnSAl14CJC4w9UZPmeGMXfmDXksx1usdRKMLUCIEU79DFTEoDqjfi4Ux7ichunZYmlD9wjkriySs1ew6aoGpC2sQWfo/aIRc+UV6l5ocno9vK9oIXwsmHLEaX77z96Apn93U8rWDMg3bERShCl/cBYkvDfy49+mksb6+7+rsRr3sI7wMCVedWt/1wtv4MpH9Yim+kaDzHxlCPWBUOSgZcPsJB2E4AjmMUwSrvcZWJtQJkBntFChyQETfw56n0i+xI1Tc+N80vGnpbQNG9/K6xmIkaSBmZpNd9dr4LC0/pBokrEQUmbFFtotHaIlapIs6d2M6CkQqYWZw1/wtGYlZfw6xC3IZe7f5fk6kOS9MTheYnRNv0Qh+jA8ppcpbgWX9m8KYzzgenfD7PnhHrQ4zzRifP0NiQ6BW1U1oIVbIGlfFWjwJcpyQ8gtbngfxyIY/TBKDPzTr1aH7RaToBpc4d2kcdqIJJ9qQy+82Mi2N/g3tHlABSVaP8bkARBDWIT0qmf2npdihYLl5umql+ZpBSXb x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR09MB6322.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(38070700005)(4326008)(66446008)(66476007)(166002)(82960400001)(76116006)(66946007)(8936002)(8676002)(64756008)(66556008)(316002)(122000001)(86362001)(110136005)(5660300002)(38100700002)(54906003)(2616005)(107886003)(36756003)(6486002)(71200400001)(508600001)(53546011)(186003)(6512007)(33656002)(6506007)(2906002)(83380400001)(66574015)(966005)(40140700001)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?c2FLeTNkTzhGNXMvNnhyRTcvbklpTENCMTBpVFdtT0l2QnJuc09kNVFuTFZh?= =?utf-8?B?YTlBbjJVazNKWENFd3JtaHBUNS96NXd3akpnbm82QmJuU2RuQXZmSnFMb09D?= =?utf-8?B?eWxrbWtodmlZMFZ2SXBaaXNIRitjOTlkWTVWQjdqT0Z5Y3lsNUJzSWR6emlE?= =?utf-8?B?eWhQVW14eVpJTktycit3dFhhTkU0NkZHcnhtK2tWUHBwSVFhZFpVTFlRVnhL?= =?utf-8?B?ZkV0NktXYkllbUlGLzdrZUM2Y04rdXVpZjl1YWE3OTNUaFlKOERtYWZXTXBD?= =?utf-8?B?MGwycWVPQnlGY0ZMdVg1UGZpSGc1UXc4MXduSk5rcXVnWDBDZFZxUDFxalAv?= =?utf-8?B?TjFRamhZeE9mSUxEbzB0bVQraHp2M0lzak1lSTk4UnpMYVZaMlYvRjZxbzRp?= =?utf-8?B?TElTSUJIWHcyTWRUZ3lqTHRoeHFvVFdDTXNFY0g3bHhvMHNOemtFeVJaNG81?= =?utf-8?B?K2hjcWpSR0pJTTYwZkNwejhMYlZMSTN0cWYvcm54U3Q2K1FvQW56OTRsUmg3?= =?utf-8?B?bjhJbVQwM0kyMEx3MUNZOEs4c3FLeDhCRlRDVytKL2FoM3lJdmY0MGVUV0RR?= =?utf-8?B?RXlhWVl0TnROcXQ4U1ZOWjVZN0VhYmJDek5QNXVUWGc5M0h6MVg1ckFyU0xu?= =?utf-8?B?MlJSc2lISkt6MHBvM0hSd0ZVUWhXaE0zeUo2RUl4WWpaeHhPaWRLMk1pMTZj?= =?utf-8?B?emJWVXZhWG56cWc0YWVtNlhmeFZLMzdHcWhRdUxMWktXUzdYTnkvdndBMVIr?= =?utf-8?B?WVU3aXNVV0dNdUtJSll4c3VXZ1piYnVXN2RaOGZGbkpvaXkwSVo1QkQrQW9o?= =?utf-8?B?Rm5VNHBubkQrTVBWVC93NllPTTlVZWNDQ2svT3p2VWFzck9sdkhnZWYrZlIr?= =?utf-8?B?amVaQ2VKbkFITFVyV0Zvcm5IUGdkMFN0eExHSnV3TGc4QVJ1Rm9wTkY1YURv?= =?utf-8?B?UUtGUTl2WENCeXhobWFZNDB1MzlWUGZ2THVYSGFMMiszbDFyc241NDJCSHVk?= =?utf-8?B?cjBoZkRMWDBDck9rMnF5WDU3V2ZWL2I0SURpbkxXNGMxNGY2NlFPK3h3eFZT?= =?utf-8?B?T01Ga0cxMklwNlZyWXdkL1ZyRGQ4RkNUL0RZQXBXM3VLQWpCMEdTeEE0NTAz?= =?utf-8?B?UHc4SXZtb3JmaE43cjJ2M2QvQnV1NDU0Ni8yL1VsN2dNZUpIbCszNmp1ekFJ?= =?utf-8?B?R1h1dUVaSmFheEhTQlY2Vi9LcWpBSmxaamRBOFpFQ0J4L0MwcE43K3VuTTJ3?= =?utf-8?B?alZ6L09HK2ZoQ0hLOW44TW1QbXJJUW9NQURZa1VXRFg4TzBDMlJPaUFJQ1NI?= =?utf-8?B?THFaQStYN2RUU3FMU0M5bHdjbWI5bm4xR0xzNUNhQjdRQVVCMXhUTkhOZHRN?= =?utf-8?B?QVBybHFaaStTNVFSRGhhUVFLVUNDRDNhK3JDZUw3SUJUcjBEaitCUE1ydndv?= =?utf-8?B?R0tISE9XSjBmL2ZhMnRzNjhsR2F6anVGRWxadFF4b1RQU2xNUUl0ejRSL2pu?= =?utf-8?B?aU1kWnZPZXdXaG91dGsyZU83LzBJU3psRmQxMTVRYmJ1RUlFUFYrUkdkRmlp?= =?utf-8?B?T2o5U01ST2dxMXlNR1FRajk5TG90VVN4c3JNajVNQlRSeE9Sa3hObkROOUZS?= =?utf-8?B?a2NKaVZHejVySnMxQkt1TUxnVUlQYzJjcEV2WEZaOFVrTnU4dnJ2NHhZdVZ1?= =?utf-8?B?RjJ6VEszZ1pkaSs3MXJBdE91MnJteUNCeHhHTFZTai9JWngzMjFITnEwSVNZ?= =?utf-8?B?U0RJcFptRlpMSDRoQ1E0NzlEcVB0Yk9jZnBTV0w5S2FVMW9PUkd1TVRZd1lh?= =?utf-8?B?YjJxelBKbGViSEcrNFVlZz09?= Content-Type: multipart/alternative; boundary="_000_A54E368003C3483BA84C5A91547FD57Bnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6322.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 44aa05fe-0d31-4168-1722-08d9e6686d7f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2022 16:24:03.6731 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6385 Archived-At: Subject: Re: [Sidrops] Closed -- [WGLC] draft-ietf-sidrops-8210bis-05 - Ends 31/January/2022 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 16:24:20 -0000 --_000_A54E368003C3483BA84C5A91547FD57Bnistgov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kIEkgZm9yZ290LCBhcyBUaW0gc28gbmljZWx5IHNhaWQsIEkgdG9vIGRvIG5vdCBvYmplY3Qg YWdhaW5zdCB0aGUgb3ZlcmFsbCBjb250ZW50IG9mIHRoaXMgZG9jdW1lbnQuDQpTb21lIHNvcnRp bmcgb2YgdGhlIHRleHQgdG8gdGhlIHByb3BlciBjaGFwdGVycyBhcyBtZW50aW9uZWQgYmVsb3cg d291bGQgaGF2ZSBiZWVuIG5pY2UgdGhvdWdoLg0KDQpPbGl2ZXINCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk9saXZlciBCb3JjaGVydCwgQ29tcHV0 ZXIgU2NpZW50aXN0DQpOYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNobm9s b2d5DQooT2ZmaWNlKSArMS4zMDEuOTc1LjQ4NTYNCihHVm9pY2UpICsxLjI0MC42NjguNDExNw0K DQoNCkZyb206IE9saXZlciBCb3JjaGVydCA8b2xpdmVyLmJvcmNoZXJ0QG5pc3QuZ292Pg0KRGF0 ZTogV2VkbmVzZGF5LCBGZWJydWFyeSAyLCAyMDIyIGF0IDExOjIxIEFNDQpUbzogSm9iIFNuaWpk ZXJzIDxqb2I9NDBmYXN0bHkuY29tQGRtYXJjLmlldGYub3JnPiwgS2V5dXIgUGF0ZWwgPGtleXVy QGFycmN1cy5jb20+DQpDYzogInNpZHJvcHNAaWV0Zi5vcmciIDxzaWRyb3BzQGlldGYub3JnPiwg T2xpdmVyIEJvcmNoZXJ0IDxvbGl2ZXIuYm9yY2hlcnRAbmlzdC5nb3Y+DQpTdWJqZWN0OiBSZTog W1NpZHJvcHNdIENsb3NlZCAtLSBbV0dMQ10gZHJhZnQtaWV0Zi1zaWRyb3BzLTgyMTBiaXMtMDUg LSBFbmRzIDMxL0phbnVhcnkvMjAyMg0KDQpTbyBmYXIgd2UgZGlkIG5vdCBoYXZlIHRoZSB0aW1l IHRvIHVwZGF0ZSB0aGUgaW1wbGVtZW50YXRpb24gdG8gdGhlIGxhdGVzdCBjaGFuZ2VzLg0KDQpT YWlkIHRoYXQgSSBhbSBzb3JyeSB0byBtaXNzIHRoaXMgbGFzdCBjYWxsIGJlY2F1c2UgSSB3b3Vs ZCBoYXZlIHJlLXJlcXVlc3RlZCBvbmUgbW9yZSBlZGl0b3JpYWwgY2hhbmdlIHRoYXQgSSBwb2lu dGVkIG91dCBkdXJpbmcgdGhlIHByZXZpb3VzIFdMQy4gVGhlIGlzc3VlIGlzIHRoZSBGbGFncyBm aWVsZCwgd2hpY2ggaXMgZGVmaW5lZCB0d2ljZSwgT25jZSDigJxnbG9iYWxseeKAnSBpbiBjaGFw dGVyIDUuMSBGaWVsZHMgb2YgUERVIHdoaWNoIGNvbnRhaW5zIHRoZSBleHBsYW5hdGlvbiBvbiB3 aGF0IHRvIGRvIGZvciB0aGUgUk9BIGFuZCBLZXkgaGFuZGxpbmcuIFRoZW4gb25lIG1vcmUgdGlt ZSBpbiBjaGFwdGVyIDUuMTIgQVNQQSBQRFUuDQoNCkkgbWVudGlvbmVkIHRoYXQgYWxyZWFkeSBp biBOb3ZlbWJlciBvciBEZWNlbWJlciB0aGF0IGZvciBjb21wbGV0ZW5lc3MgaXQgd291bGQgbWFr ZSBzZW5zZSB0byBhZGQgdGhlIHRleHQgZnJvbSA1LjEyIGludG8gNS4xIGFzIGl0IGlzIGRvbmUg d2l0aCB0aGUgb3RoZXIgUERV4oCZcy4NCg0KT2xpdmVyDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpPbGl2ZXIgQm9yY2hlcnQsIENvbXB1dGVyIFNj aWVudGlzdA0KTmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neQ0K KE9mZmljZSkgKzEuMzAxLjk3NS40ODU2DQooR1ZvaWNlKSArMS4yNDAuNjY4LjQxMTcNCg0KDQpG cm9tOiBTaWRyb3BzIDxzaWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBKb2Ig U25pamRlcnMgPGpvYj00MGZhc3RseS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBNb25kYXks IEphbnVhcnkgMzEsIDIwMjIgYXQgMjo0MSBQTQ0KVG86IEtleXVyIFBhdGVsIDxrZXl1ckBhcnJj dXMuY29tPg0KQ2M6ICJzaWRyb3BzQGlldGYub3JnIiA8c2lkcm9wc0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbU2lkcm9wc10gQ2xvc2VkIC0tIFtXR0xDXSBkcmFmdC1pZXRmLXNpZHJvcHMtODIx MGJpcy0wNSAtIEVuZHMgMzEvSmFudWFyeS8yMDIyDQoNCkhpIGFsbCwNCg0KQXJlIGFueSBpbXBs ZW1lbnRhdGlvbiByZXBvcnRzIGF2YWlsYWJsZT8gSSB0aGluayBPbGl2ZXIvTklTVCBtaWdodCBo YXZlIG9uZSwgaXMgdGhlcmUgYW5vdGhlcj8NCg0KSXQgbWlnaHQgYmUgZ29vZCB0byBjb25maXJt IHRoaXMgYmVmb3JlIGZvcndhcmRpbmcgdG8gSUVTRy4NCg0KS2luZCByZWdhcmRzLA0KDQpKb2IN Cg0KT24gTW9uLCAzMSBKYW4gMjAyMiBhdCAyMDowOSwgS2V5dXIgUGF0ZWwgPGtleXVyQGFycmN1 cy5jb208bWFpbHRvOmtleXVyQGFycmN1cy5jb20+PiB3cm90ZToNCkhpIEZvbGtzLA0KDQpUaGlz IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGlzIGNsb3NlZC4gQXQgdGhpcyBwb2ludCwgdGhlIGRy YWZ0IGlzIHJlYWR5IHRvIHByb2dyZXNzIGZ1cnRoZXIuIEFjY29yZGluZ2x5IHdlIHdpbGwgcHJl cGFyZSBhIHJlcG9ydCBhbmQgZm9yd2FyZCBpdCB0byBJRVNHLg0KDQpSZWdhcmRzLA0KTmF0aGFs aWUsIENocmlzICYgS2V5dXINCg0KDQpGcm9tOiBLZXl1ciBQYXRlbCA8a2V5dXJAYXJyY3VzLmNv bTxtYWlsdG86a2V5dXJAYXJyY3VzLmNvbT4+DQpEYXRlOiBNb25kYXksIEphbnVhcnkgMTcsIDIw MjIgYXQgMjoyOSBQTQ0KVG86ICJzaWRyb3BzQGlldGYub3JnPG1haWx0bzpzaWRyb3BzQGlldGYu b3JnPiIgPHNpZHJvcHNAaWV0Zi5vcmc8bWFpbHRvOnNpZHJvcHNAaWV0Zi5vcmc+Pg0KU3ViamVj dDogW1dHTENdIGRyYWZ0LWlldGYtc2lkcm9wcy04MjEwYmlzLTA1IC0gRW5kcyAzMS9KYW51YXJ5 LzIwMjINCg0KDQpIaSBGb2xrczoNCg0KDQoNCkEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFz IGJlZW4gcmUtaXNzdWVkIGZvciBkcmFmdC1pZXRmLXNpZHJvcHMtODIxMGJpcy0wNSwg4oCcVGhl IFJlc291cmNlIFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgKFJQS0kpIHRvIFJvdXRlciBQcm90 b2NvbCwgVmVyc2lvbiAy4oCdLiAgQWxsIHRoZSBwZW5kaW5nIGVkaXRzIGFuZCBkaXNjdXNzZXMg ZnJvbSB0aGUgcHJldmlvdXMgbGFzdCBjYWxsIGhhcyBiZWVuIHJlc29sdmVkLiBQbGVhc2UgcmVw bHkgdG8gdGhlIGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLiBUaGUgV0dMQyB3aWxsIGVuZCBvbiBK YW51YXJ5IDMxc3QsIDIwMjIuDQoNCg0KDQpUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zaWRyb3BzLTgyMTBi aXM8aHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0 Zi1zaWRyb3BzLTgyMTBiaXMmZGF0YT0wNCU3QzAxJTdDb2xpdmVyLmJvcmNoZXJ0JTQwbmlzdC5n b3YlN0NiYmQ5MmUxOWRkNTg0N2E0YTEyYzA4ZDllNGYxOGJjMCU3QzJhYjVkODJmZDhmYTQ3OTdh OTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2Mzc3OTI1NDg3OTYxMDQ0MzElN0NVbmtub3duJTdD VFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJ azFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMjAwMCZzZGF0YT1RWVhuUkxlY2xrS3N5c0hoTnY3Z1RC Z2VJcmFrejZPa2lraE9ZY0NSeU1rJTNEJnJlc2VydmVkPTA+LiBBdXRob3JzLCBwbGVhc2UgcmVw bHkgaW5kaWNhdGluZyB3aGV0aGVyIHlvdSdyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSIHRo YXQgaGFzbid0IGJlZW4gZGlzY2xvc2VkLg0KDQoNCg0KUmVnYXJkcywNCg0KTmF0aGFsaWUsIENo cmlzICYgS2V5dXINCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KU2lkcm9wcyBtYWlsaW5nIGxpc3QNClNpZHJvcHNAaWV0Zi5vcmc8bWFpbHRvOlNp ZHJvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np ZHJvcHM8aHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2lkcm9w cyZkYXRhPTA0JTdDMDElN0NvbGl2ZXIuYm9yY2hlcnQlNDBuaXN0LmdvdiU3Q2JiZDkyZTE5ZGQ1 ODQ3YTRhMTJjMDhkOWU0ZjE4YmMwJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMl N0MxJTdDMCU3QzYzNzc5MjU0ODc5NjI2MDY1MyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpX SWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZN bjAlM0QlN0MyMDAwJnNkYXRhPUhVQXc2NFFIbEVrcURqZTNYZXY2U0hPbnlob3FNJTJCJTJCMnJi dGdnRTNVWHdzJTNEJnJlc2VydmVkPTA+DQo= --_000_A54E368003C3483BA84C5A91547FD57Bnistgov_ Content-Type: text/html; charset="utf-8" Content-ID: <074A01EDDD03634FA526D5E0F37C1F3E@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDb3VyaWVyOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIg MiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3Nl LTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p bHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q291cmllcjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZv bnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvdXJpZXIiPkFuZCBJIGZvcmdvdCwgYXMgVGltIHNvIG5pY2VseSBzYWlkLCBJIHRvbyBkbyBu b3Qgb2JqZWN0IGFnYWluc3QgdGhlIG92ZXJhbGwgY29udGVudCBvZiB0aGlzIGRvY3VtZW50Lg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNvdXJpZXIiPlNvbWUgc29ydGluZyBvZiB0aGUgdGV4dCB0byB0aGUgcHJv cGVyIGNoYXB0ZXJzIGFzIG1lbnRpb25lZCBiZWxvdyB3b3VsZCBoYXZlIGJlZW4gbmljZSB0aG91 Z2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj5PbGl2 ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q291cmllciI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q291cmllcjtjb2xvcjpibGFjayI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+T2xpdmVyIEJvcmNo ZXJ0LCBDb21wdXRlciBTY2llbnRpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+ TmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4oT2ZmaWNlKSArMS4zMDEuOTc1LjQ4NTY8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q291cmllcjtjb2xvcjpibGFjayI+KEdWb2ljZSkgKzEuMjQwLjY2OC40MTE3PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T2xpdmVyIEJvcmNoZXJ0ICZs dDtvbGl2ZXIuYm9yY2hlcnRAbmlzdC5nb3YmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2Rh eSwgRmVicnVhcnkgMiwgMjAyMiBhdCAxMToyMSBBTTxicj4NCjxiPlRvOiA8L2I+Sm9iIFNuaWpk ZXJzICZsdDtqb2I9NDBmYXN0bHkuY29tQGRtYXJjLmlldGYub3JnJmd0OywgS2V5dXIgUGF0ZWwg Jmx0O2tleXVyQGFycmN1cy5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtzaWRyb3BzQGll dGYub3JnJnF1b3Q7ICZsdDtzaWRyb3BzQGlldGYub3JnJmd0OywgT2xpdmVyIEJvcmNoZXJ0ICZs dDtvbGl2ZXIuYm9yY2hlcnRAbmlzdC5nb3YmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBb U2lkcm9wc10gQ2xvc2VkIC0tIFtXR0xDXSBkcmFmdC1pZXRmLXNpZHJvcHMtODIxMGJpcy0wNSAt IEVuZHMgMzEvSmFudWFyeS8yMDIyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPlNvIGZhciB3ZSBk aWQgbm90IGhhdmUgdGhlIHRpbWUgdG8gdXBkYXRlIHRoZSBpbXBsZW1lbnRhdGlvbiB0byB0aGUg bGF0ZXN0IGNoYW5nZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3Vy aWVyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIi PlNhaWQgdGhhdCBJIGFtIHNvcnJ5IHRvIG1pc3MgdGhpcyBsYXN0IGNhbGwgYmVjYXVzZSBJIHdv dWxkIGhhdmUgcmUtcmVxdWVzdGVkIG9uZSBtb3JlIGVkaXRvcmlhbCBjaGFuZ2UgdGhhdCBJIHBv aW50ZWQgb3V0IGR1cmluZyB0aGUgcHJldmlvdXMgV0xDLiBUaGUgaXNzdWUgaXMgdGhlIEZsYWdz IGZpZWxkLA0KIHdoaWNoIGlzIGRlZmluZWQgdHdpY2UsIE9uY2Ug4oCcZ2xvYmFsbHnigJ0gaW4g Y2hhcHRlciA1LjEgRmllbGRzIG9mIFBEVSB3aGljaCBjb250YWlucyB0aGUgZXhwbGFuYXRpb24g b24gd2hhdCB0byBkbyBmb3IgdGhlIFJPQSBhbmQgS2V5IGhhbmRsaW5nLiBUaGVuIG9uZSBtb3Jl IHRpbWUgaW4gY2hhcHRlciA1LjEyIEFTUEEgUERVLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDb3VyaWVyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNvdXJpZXIiPkkgbWVudGlvbmVkIHRoYXQgYWxyZWFkeSBpbiBOb3ZlbWJlciBv ciBEZWNlbWJlciB0aGF0IGZvciBjb21wbGV0ZW5lc3MgaXQgd291bGQgbWFrZSBzZW5zZSB0byBh ZGQgdGhlIHRleHQgZnJvbSA1LjEyIGludG8gNS4xIGFzIGl0IGlzIGRvbmUgd2l0aCB0aGUgb3Ro ZXIgUERV4oCZcy4gJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDb3VyaWVyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvdXJpZXIiPk9saXZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291 cmllciI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD b3VyaWVyO2NvbG9yOmJsYWNrIj5PbGl2ZXIgQm9yY2hlcnQsIENvbXB1dGVyIFNjaWVudGlzdDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+ TmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgVGVjaG5vbG9neTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+KE9mZmljZSkg KzEuMzAxLjk3NS40ODU2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3Vy aWVyO2NvbG9yOmJsYWNrIj4oR1ZvaWNlKSArMS4yNDAuNjY4LjQxMTc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5TaWRyb3BzICZsdDtzaWRyb3BzLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBKb2IgU25pamRlcnMgJmx0O2pvYj00MGZhc3RseS5jb21A ZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgSmFudWFyeSAzMSwg MjAyMiBhdCAyOjQxIFBNPGJyPg0KPGI+VG86IDwvYj5LZXl1ciBQYXRlbCAmbHQ7a2V5dXJAYXJy Y3VzLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3NpZHJvcHNAaWV0Zi5vcmcmcXVvdDsg Jmx0O3NpZHJvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbU2lkcm9w c10gQ2xvc2VkIC0tIFtXR0xDXSBkcmFmdC1pZXRmLXNpZHJvcHMtODIxMGJpcy0wNSAtIEVuZHMg MzEvSmFudWFyeS8yMDIyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MS4waW4iPkFyZSBhbnkgaW1wbGVtZW50YXRpb24gcmVwb3J0cyBhdmFp bGFibGU/IEkgdGhpbmsgT2xpdmVyL05JU1QgbWlnaHQgaGF2ZSBvbmUsIGlzIHRoZXJlIGFub3Ro ZXI/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5JdCBt aWdodCBiZSBnb29kIHRvIGNvbmZpcm0gdGhpcyBiZWZvcmUgZm9yd2FyZGluZyB0byBJRVNHLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjEuMGluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+S2luZCByZWdh cmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Sm9i PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MS4waW4iPk9uIE1vbiwgMzEgSmFuIDIwMjIgYXQgMjA6MDksIEtleXVyIFBhdGVsICZsdDs8YSBo cmVmPSJtYWlsdG86a2V5dXJAYXJyY3VzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtleXVyQGFycmN1 cy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQpIaSBGb2xrcyw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQombmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+ DQpUaGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGlzIGNsb3NlZC4gQXQgdGhpcyBwb2ludCwg dGhlIGRyYWZ0IGlzIHJlYWR5IHRvIHByb2dyZXNzIGZ1cnRoZXIuIEFjY29yZGluZ2x5IHdlIHdp bGwgcHJlcGFyZSBhIHJlcG9ydCBhbmQgZm9yd2FyZCBpdCB0byBJRVNHLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NCiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluIj4NClJl Z2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MS4waW4iPg0KTmF0aGFsaWUsIENocmlzICZhbXA7IEtleXVyPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KPGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5G cm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+S2V5dXIgUGF0ZWwgJmx0 OzxhIGhyZWY9Im1haWx0bzprZXl1ckBhcnJjdXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2V5dXJA YXJyY3VzLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgSmFudWFyeSAxNywg MjAyMiBhdCAyOjI5IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86c2lk cm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNpZHJvcHNAaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86c2lkcm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNp ZHJvcHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bV0dMQ10gZHJhZnQt aWV0Zi1zaWRyb3BzLTgyMTBiaXMtMDUgLSBFbmRzIDMxL0phbnVhcnkvMjAyMjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDoxLjBpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMyMTI1MjkiPkhpIEZv bGtzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4w aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmO2NvbG9yOiMyMTI1MjkiPkEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gcmUt aXNzdWVkIGZvciBkcmFmdC1pZXRmLXNpZHJvcHMtODIxMGJpcy0wNSwg4oCcVGhlIFJlc291cmNl IFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgKFJQS0kpIHRvIFJvdXRlciBQcm90b2NvbCwgVmVy c2lvbiAy4oCdLiZuYnNwOyBBbGwgdGhlIHBlbmRpbmcgZWRpdHMgYW5kIGRpc2N1c3NlcyBmcm9t IHRoZSBwcmV2aW91cyBsYXN0IGNhbGwgaGFzIGJlZW4gcmVzb2x2ZWQuIFBsZWFzZSByZXBseSB0 byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMuIFRoZSBXR0xDIHdpbGwgZW5kIG9uIEphbnVh cnkgMzE8c3VwPnN0PC9zdXA+LCAyMDIyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMyMTI1Mjki PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MS4waW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMyMTI1MjkiPlRoZSBkcmFmdCBjYW4gYmUg Zm91bmQgYXQgPGEgaHJlZj0iaHR0cHM6Ly9nY2MwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZo dG1sJTJGZHJhZnQtaWV0Zi1zaWRyb3BzLTgyMTBiaXMmYW1wO2RhdGE9MDQlN0MwMSU3Q29saXZl ci5ib3JjaGVydCU0MG5pc3QuZ292JTdDYmJkOTJlMTlkZDU4NDdhNGExMmMwOGQ5ZTRmMThiYzAl N0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM3NzkyNTQ4Nzk2 MTA0NDMxJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlq b2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzIwMDAmYW1wO3NkYXRh PVFZWG5STGVjbGtLc3lzSGhOdjdnVEJnZUlyYWt6Nk9raWtoT1ljQ1J5TWslM0QmYW1wO3Jlc2Vy dmVkPTAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzMzN0FCNyI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNpZHJvcHMtODIxMGJp czwvc3Bhbj48L2E+LiBBdXRob3JzLCBwbGVhc2UgcmVwbHkgaW5kaWNhdGluZyB3aGV0aGVyIHlv dSdyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSIHRoYXQgaGFzbid0IGJlZW4gZGlzY2xvc2Vk Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmO2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm O2NvbG9yOiMyMTI1MjkiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6IzIxMjUyOSI+ TmF0aGFsaWUsIENocmlzICZhbXA7IEtleXVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjEuMGluIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NClNpZHJvcHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OlNpZHJvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5TaWRyb3BzQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vZ2NjMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUy RnNpZHJvcHMmYW1wO2RhdGE9MDQlN0MwMSU3Q29saXZlci5ib3JjaGVydCU0MG5pc3QuZ292JTdD YmJkOTJlMTlkZDU4NDdhNGExMmMwOGQ5ZTRmMThiYzAlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1 NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM3NzkyNTQ4Nzk2MjYwNjUzJTdDVW5rbm93biU3Q1RXRnBi R1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFX d2lMQ0pYVkNJNk1uMCUzRCU3QzIwMDAmYW1wO3NkYXRhPUhVQXc2NFFIbEVrcURqZTNYZXY2U0hP bnlob3FNJTJCJTJCMnJidGdnRTNVWHdzJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyb3BzPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A54E368003C3483BA84C5A91547FD57Bnistgov_-- From nobody Wed Feb 2 09:09:42 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96FE3A1607; Wed, 2 Feb 2022 09:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 iZr-kXEbNPdq; Wed, 2 Feb 2022 09:09:38 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9E93A1603; Wed, 2 Feb 2022 09:09:38 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.93) (envelope-from ) id 1nFJ8P-00052N-Q6; Wed, 02 Feb 2022 17:09:34 +0000 Date: Wed, 02 Feb 2022 09:09:33 -0800 Message-ID: From: Randy Bush To: "Borchert, Oliver (Fed)" Cc: SIDR Operations WG In-Reply-To: <33F461A3-6D77-4C5E-9F53-D59443D697CA@nist.gov> References: <33F461A3-6D77-4C5E-9F53-D59443D697CA@nist.gov> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [Sidrops] Closed -- [WGLC] draft-ietf-sidrops-8210bis-05 - Ends 31/January/2022 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 17:09:41 -0000 > I would have re-requested one more editorial change that I pointed out > during the previous WLC. The issue is the Flags field, which is > defined twice, Once $B!H(Bglobally$B!I(B in chapter 5.1 Fields of PDU which > contains the explanation on what to do for the ROA and Key > handling. Then one more time in chapter 5.12 ASPA PDU. > > I mentioned that already in November or December that for completeness > it would make sense to add the text from 5.12 into 5.1 as it is done > with the other PDU$B!G(Bs. easy hack with no semantic impact. anybody object if i do it? might wait to see if there are other bugs. randy From nobody Wed Feb 2 11:54:23 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF203A1DD9 for ; Wed, 2 Feb 2022 11:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 sJvk70TnN_xC for ; Wed, 2 Feb 2022 11:54:16 -0800 (PST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2079.outbound.protection.outlook.com [40.107.236.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A523A1DD5 for ; Wed, 2 Feb 2022 11:54:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gduf/ulCdeVxPCmCusuQTB+RVQxOrzbJbmqucoL6jTVYfbq5sxojNCBnN9qNxwqSbhX9q5ITVNBXRqBqfJ7v05D2om5wosIPB62hOzBj6eSnIRbN3mtEEK8K61ZXlbyFRocU9uVyEVnLsTsRb1BB3sDvGJuEsKH7LIpw9IGV2C6NTAkrG5H2ZGyESdf6Sq/NUovo4+TOorGFME89ly3DtQ+BFnu+L18M4rhWkU3faCQX8xH/uc6UIeDkpOwazTDt/2C8Wlo2+EkV0bbJ/jFQhbbGT5WODjuKtNccw44cVufAChACfdux3qAcoaKvjMmLcFqnT5KYjBgKXIBvHCIfUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IXvMiFZTXy5b84uiD6R2/TuBGLpnYePyx+hKJyo5/dk=; b=iDZr2GpQBDfsk/aki/5oiTaxaB0uJW+O6URcs10gUoa9qrQSeaxE5RaXcV9MKj5moqUWvuYHko7w+SD/TkVY1B+lL4CtgP8VFtGiesN1HwIuIyPdiH1u3+uY5+s80z0SoS7lFNmu2lQ1LVPaCpyRrtGZ3PLAsnCRV56qHQmpYvKIPQwEJoketJzy2yendgKGIBs6m6mAAAOU9zaxOeQLgoj5hyOqrA5Armae7IwrcIDX/T4c7uGGzfCyHuZ5ITTFc2JltLs1tiHes3TIjGRjxOEjRN75LHijh4K0Ps3r78grghn63YAQKRMXPBf2MXRYX8sekAg/vAuSXbmHvdEing== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IXvMiFZTXy5b84uiD6R2/TuBGLpnYePyx+hKJyo5/dk=; b=NKhihe+wLIG1h4OH4LBS5myF19C2rIpw7GiMXV9p6GvPLpcFk9XD77ORi9mfb7R3tOeFgem2SQSA3ma6U2O4AaOWo6Ozs3prr7yME5rrgO04yAzL94ww9UuNjeKJxLaOx+Ty+Dt/wdCqzz4g79sy/LOf2zlNBf5/Bbgk3pwuOD8= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by DM5PR18MB2246.namprd18.prod.outlook.com (2603:10b6:4:b7::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Wed, 2 Feb 2022 19:54:13 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::5dfe:39d8:a0e2:fff2]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::5dfe:39d8:a0e2:fff2%3]) with mapi id 15.20.4951.012; Wed, 2 Feb 2022 19:54:13 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: Closed -- [WGLC] draft-ietf-sidrops-rpkimaxlen-09 - Ends 2/February/2022 Thread-Index: AQHYGG6ngb5DXQBYGE6+mFojng+0Mg== Date: Wed, 2 Feb 2022 19:54:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.54.21101001 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arrcus.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: beeb06c4-6dbd-492e-378d-08d9e685c9ba x-ms-traffictypediagnostic: DM5PR18MB2246:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qqUjVmenIyNLNV619G5Y1kTPvVVWQfoTLUa0xr3OEcLALa+GqWNvSZ8omMmPnpUfTD16fhAMmGDPUkAIhhDidopo8PGlvr0Ob+3VUvJeOnCL+TVilu67D0e3CQVUQHV4EGb/oSheOZO9DFiqpneizvJaxdjQY41pOYRUuKY460Nc0cpsjm66+tlLqMFdsmIuBjYaSNG8wkTbwHbTmc5jF43+8vdMFh+8n4fYNii/k3SKU2y0w3IQZoa6PX0VQgKbbEP5Bn0uA1bRJPJz6W1VP/1mTxeeMY5jKu/1oh7Xh6E62fcBEvKKJacqnrWkGaAblVP/16er6Z/ixxy8tqok5cjpEo2+ldM9J+US77Uk4cgut1J/Nh/DK5IB1zYmKMh74BtHlVUhfx79mfwWT8iGl29lnbvHOw/HsfUYYg3DiwkqCwAyRU7WWbyisRWji7kV6ULhi0RDuq9bGo6AoH9qZV+2uCx2zTtsvQ7y5yYQAE0a8iED/Y8OAHi2UCiLTegM4sOjKmbC+thQrbZQ6j8BBrRRFTx+l1Lk5fu4DIGlEexPLsR8WP9g/CcHNgVhLQdQkd6QSvAM1sykRW8i6vH/RmASTCG0n2RvYKJ9GRJNkOybZXENrIZHRk2napcjDmupbPEhM03dlfJE6cOJI+KnxHmkIHGb3xAJeKCUfP71CqB6DS6WPIbM93uWo09QQFCkYBMZeYCX5K+zRGGUboQscK35PaToatNU7nNY3beP2pe7rHHEIhEi03gjb54MFFuVprDXo03mAwxDnFvVADzR23yu6G7RrwMN71tzv0qQ/f6kLtYMm9Zn53NlEjSVRJkD x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(346002)(39840400004)(136003)(366004)(376002)(396003)(83380400001)(6506007)(186003)(64756008)(8936002)(8676002)(66476007)(66556008)(66446008)(26005)(76116006)(66946007)(122000001)(9326002)(71200400001)(5660300002)(2906002)(33656002)(2616005)(53546011)(6512007)(38100700002)(6916009)(166002)(508600001)(966005)(6486002)(38070700005)(316002)(86362001)(36756003)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?V2lNaEo0cmQvblJTNDNyRzNNL3EyYlVXbE1NajA4YUF4UVhPOElzUEFLSXJo?= =?utf-8?B?MGNWdmZTZCtZSnk2MzIrcmFVR2pKekx1WndrOTZmNDYrUUpNVU1pRk9zdjVW?= =?utf-8?B?cnliNmoxVEkvTHgyVVdpdVZBMkxzSHNlbWVkaFJTWjBuTlVZNWJqTE1wWHRO?= =?utf-8?B?elJyVUw2bHBnengrdzg3ZzgrVkRnMi9WQXQyZlBHOHltU1Q0a0FlZzVkVXl0?= =?utf-8?B?OEsxVkNTcjZSUjlDa2ZYUm0rT1lZK0wzeUY2ZGpuZ3pzYkVYc2Q5RnJEY3dp?= =?utf-8?B?QTdoWFF1RlhTa1F4cXVOTm9VRjFva3BzeEtqUmt4MkMwd2lHSWkzTWhyd25p?= =?utf-8?B?UFcvTzljME1lU1VYK01UMzV1LzlVQW41UjBxNVZvc3NBZDB1Y29IMlFGNEtF?= =?utf-8?B?SUUvQ2plYUc4Z3E3dTAzZHRQcUZDZUFhVWt4U0pBelFrWitJQlZDeXg5VDVh?= =?utf-8?B?eHlOaGlSYjVYN0YvelpwL0hETmNSWmZCOHVxUi9vM0hoeHp1SUV2bWd2TTJB?= =?utf-8?B?cHhIVDR3bGJjay9ZUjZ4NW4rVFdYNEhYbFhaSUxHRkpIU0R2RHFPc0tkVFp4?= =?utf-8?B?S3pBc2NmRHY3YmxQVThVbjlESTR0NkRQalJycVBrVENIM1p1ZTNVamlONDNF?= =?utf-8?B?THJINCtkSExBRFZjMjNzRmlwanlvL29ISG9jeC9WbnVISllSU2ZFZCtsYVpD?= =?utf-8?B?NUZoZ0VBcmtndTBWbmU2TlBSTnV6Ry9UYnZ3emRCa29lQ3pNV0ZVdVRVMi8z?= =?utf-8?B?ZGpWMWQwaGVnRFRUUlRYUXNqcEFKY2p5dnIyWkozaEtkanplbUhzSXJRcVIv?= =?utf-8?B?bkdiNFZJbWFrU0hMSVZseDNib0w5aFdHdWIxMytmdTRhc2IwYnpxWVU3bnJr?= =?utf-8?B?dkVZaHBibS8wbkIyS2lSalR1WDZxRitUQ1NLU0hXV2EzWDNmbGU2NXpCMThh?= =?utf-8?B?eS9XcjZOWnBJaVN3eXY2RlNoOVJzbjYxUlVCK0RWOGNIc2V5NThpUGZLMERE?= =?utf-8?B?dGQ5cUU3c1lZYTdHa2RHR2lTZVZ0K1k1Q0w5MDc3VGQwcU4weTlyRHM5S0Ra?= =?utf-8?B?MjVQSjBWRXllOXpIZnR5a1VpYURYcE9hTENibkRQSkorYXVmUVJLT2J2TXR2?= =?utf-8?B?WExxc2xkVkpJUnN3dHlVN1lFVVFMaWxld0RPNDF6MnhET01EdjRNN2dKL2JL?= =?utf-8?B?NzBGeXRZUCt6NDBkdm1Fd0RoZ21POWpIaGRsWmxwQ09Ick1jbm9vQWhWSzV5?= =?utf-8?B?TGREcHNtdGZwTG9KQVNCZ0JWV1RhUjlXa3kxaHBNK2VWOUdXYTl3T00vZzQ4?= =?utf-8?B?K2YyUXFDc0dUSm55VlNEWlQ3VTljbXVTZlZ2WEtwS1pnb3RiMmFtVTJYdEZO?= =?utf-8?B?Y0x2M1NKZ3BDWjdremdzckpVNGxCSzBNUDA5aDMrcmxtdllIZzJkOHNjM0Vu?= =?utf-8?B?TGttcUF3YU9samU1c2tXSkc4SFRzdUtzQ2ZtYjhDbm9hY3dyelhUcVlzNmNH?= =?utf-8?B?TlQvRG05cmh6ZVZHNWNNRGxwRmMwZ3AyaWhnQktVc1RUaTFUMkxvcXJiYm03?= =?utf-8?B?cTRvSWFqbzh5UDFjQndORmZaeG5Ja1FsNmVNQ2F2a1NuemlzU3VMOGQvZml4?= =?utf-8?B?aTF0YklYZXhmc3p2RTh2R0JXdm9DYldHRWpvbTdsUXBqZHhtaFhNZTNWcEZj?= =?utf-8?B?YjUyRktBQi9lOUpad0k3MmlKMjVKWU9RRytHb3NaNDV2TmkxcTE1eStRR1FG?= =?utf-8?B?Yzk4bGo1QVYwREJlNUQ0L1k1eXJ0Q0NZaHdaTHRQNzdHOG42UllaMlM0TWFV?= =?utf-8?B?Zm1iQ29mV1NjcjVqb21qRHN6ZVVnd1kxYkRveXhmY1JmT211NHNsY2M5cHBo?= =?utf-8?B?R0lzTGJzcnZlWHBSWkFBUThDdVJ4d1czbGFFcDB5YllyNWZDaDNqWnBDTFZq?= =?utf-8?B?T2pENmZRcVRQVUsrc2EzVGpTcWtrZ1pTTTFVUEw5TVQxTHFuTUtXNjA0S1A5?= =?utf-8?B?SjZrbWRDTzJFQ3d2UTBDNi93RWNtV0J3dG9NVHJKTTFKdThRRUlLbjVrUTVw?= =?utf-8?B?ZDZqdWdLYU9jTTZ4Z2xNU0NZWnlQcUxvM01oYW9ua0pxdlFLOE0xbXp1WVdi?= =?utf-8?B?d3E2KzhydFJEMjRlelFSd0NQdXBsNnMvYzlDVm9MWVErR2RPQVUxOHBnRW16?= =?utf-8?Q?Qg6sGx7N27rLD0LXHGv7Ep09i5mpAdQsEAS+ocWaE3U2?= Content-Type: multipart/alternative; boundary="_000_FF8FF442EFC54C51A46EDAFCA90D37ECarrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: beeb06c4-6dbd-492e-378d-08d9e685c9ba X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2022 19:54:13.7380 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MB02fQ1xytZy7zGh0m/vKA1vX26phnjI/GGKTzawzzggyx86ywlmxzTseWPd4ZTGWVapSvjapBf0CFj6iZsNzA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR18MB2246 Archived-At: Subject: Re: [Sidrops] Closed -- [WGLC] draft-ietf-sidrops-rpkimaxlen-09 - Ends 2/February/2022 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 19:54:22 -0000 --_000_FF8FF442EFC54C51A46EDAFCA90D37ECarrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRm9sa3MsDQoNCkkgaGF2ZW7igJl0IHNlZW4gYW55IGNvbW1lbnRzIG9uIHRoZSBXR0xDIGZv ciB0aGlzIGRyYWZ0IChhc3N1bWluZyBpdCBpcyBnb29kIGZvciBub3cpLiBUaGlzIHdvcmtpbmcg Z3JvdXAgbGFzdCBjYWxsIGlzIGNsb3NlZC4gQXQgdGhpcyBwb2ludCwgdGhlIGRyYWZ0IGlzIHJl YWR5IHRvIHByb2dyZXNzIGZ1cnRoZXIuIEFjY29yZGluZ2x5IHdlIHdpbGwgcHJlcGFyZSBhIHJl cG9ydCBhbmQgZm9yd2FyZCBpdCB0byBJRVNHLg0KDQpSZWdhcmRzLA0KTmF0aGFsaWUsIENocmlz ICYgS2V5dXINCg0KDQpGcm9tOiBTaWRyb3BzIDxzaWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9u IGJlaGFsZiBvZiBLZXl1ciBQYXRlbCA8a2V5dXJAYXJyY3VzLmNvbT4NCkRhdGU6IFdlZG5lc2Rh eSwgSmFudWFyeSAxOSwgMjAyMiBhdCAxMDowNCBBTQ0KVG86ICJzaWRyb3BzQGlldGYub3JnIiA8 c2lkcm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtTaWRyb3BzXSBbV0dMQ10gZHJhZnQtaWV0Zi1z aWRyb3BzLXJwa2ltYXhsZW4tMDkgLSBFbmRzIDIvRmVicnVhcnkvMjAyMg0KDQoqKioqU2VuZGVy IGlzIG5vdCBmcm9tIEFycmN1cyoqKg0KSGkgRm9sa3M6DQoNCkEgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgaGFzIGJlZW4gcmUtaXNzdWVkIGZvciBkcmFmdC1pZXRmLXNpZHJvcHMtcnBraW1heGxl bi0wOSwg4oCcVGhlIFVzZSBvZiBNYXhsZW5ndGggaW4gdGhlIFJQS0nigJ0uIEFsbCB0aGUgcGVu ZGluZyBlZGl0cyBhbmQgZGlzY3Vzc2VzIGZyb20gdGhlIHByZXZpb3VzIGxhc3QgY2FsbCBoYXMg YmVlbiByZXNvbHZlZC4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50 cy4gVGhlIFdHTEMgd2lsbCBlbmQgb24gRmVicnVhcnkgMnRoLCAyMDIyLg0KDQpUaGUgZHJhZnQg Y2FuIGJlIGZvdW5kIGF0OiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWlldGYtc2lkcm9wcy1ycGtpbWF4bGVuLTA5Lg0KDQpSZWdhcmRzLA0KTmF0aGFsaWUsIENo cmlzICYgS2V5dXINCg0KDQo= --_000_FF8FF442EFC54C51A46EDAFCA90D37ECarrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OmluaGVyaXQ7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxl LWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSBGb2xrcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgaGF2ZW7igJl0IHNlZW4gYW55IGNvbW1lbnRzIG9uIHRo ZSBXR0xDIGZvciB0aGlzIGRyYWZ0IChhc3N1bWluZyBpdCBpcyBnb29kIGZvciBub3cpLiBUaGlz IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGlzIGNsb3NlZC4gQXQgdGhpcyBwb2ludCwgdGhlIGRy YWZ0IGlzIHJlYWR5IHRvIHByb2dyZXNzIGZ1cnRoZXIuIEFjY29yZGluZ2x5IHdlIHdpbGwgcHJl cGFyZQ0KIGEgcmVwb3J0IGFuZCBmb3J3YXJkIGl0IHRvIElFU0cuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5OYXRo YWxpZSwgQ2hyaXMgJmFtcDsgS2V5dXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNpZHJvcHMgJmx0 O3NpZHJvcHMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEtleXVyIFBhdGVsICZs dDtrZXl1ckBhcnJjdXMuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEphbnVh cnkgMTksIDIwMjIgYXQgMTA6MDQgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O3NpZHJvcHNAaWV0 Zi5vcmcmcXVvdDsgJmx0O3NpZHJvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PltTaWRyb3BzXSBbV0dMQ10gZHJhZnQtaWV0Zi1zaWRyb3BzLXJwa2ltYXhsZW4tMDkgLSBFbmRz IDIvRmVicnVhcnkvMjAyMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4qKioqU2VuZGVyIGlzIG5vdCBmcm9tIEFycmN1cyoq Kg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGkgRm9sa3M6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3Jw aGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6 ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O2NhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpz dGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O2luaGVyaXQmcXVvdDss c2VyaWY7Y29sb3I6YmxhY2siPkEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gcmUt aXNzdWVkIGZvciBkcmFmdC1pZXRmLXNpZHJvcHMtPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtpbmhlcml0JnF1b3Q7LHNlcmlmO2NvbG9yOiMwNzA3MDY7YmFja2dyb3VuZDoj RkZFRTk0Ij5ycGtpbWF4bGVuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtp bmhlcml0JnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj4tMDksDQog4oCcVGhlIFVzZSBvZiBNYXhs ZW5ndGggaW4gdGhlIFJQS0nigJ0uIEFsbCB0aGUgcGVuZGluZyBlZGl0cyBhbmQgZGlzY3Vzc2Vz IGZyb20gdGhlIHByZXZpb3VzIGxhc3QgY2FsbCBoYXMgYmVlbiByZXNvbHZlZC4gUGxlYXNlIHJl cGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50cy4gVGhlPC9zcGFuPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPldHTEM8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+d2lsbA0KIGVuZCBvbiBGZWJydWFy eSAyPHN1cD50aDwvc3VwPiwgMjAyMi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87 LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93 czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6IDxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1z aWRyb3BzLXJwa2ltYXhsZW4tMDkiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1pZXRmLXNpZHJvcHMtcnBraW1heGxlbi0wOTwvYT4uIDxvOnA+DQo8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxp Z246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87 dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh dXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDtjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApO3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRv d3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO3dvcmQtc3BhY2luZzowcHgi Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5OYXRoYWxpZSwgQ2hyaXMgJmFtcDsgS2V5dXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dz OiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTt3b3JkLXNwYWNpbmc6MHB4Ij4N CjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_FF8FF442EFC54C51A46EDAFCA90D37ECarrcuscom_-- From nobody Wed Feb 2 17:44:41 2022 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5E23A1275; Wed, 2 Feb 2022 17:44:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-6486bis@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, morrowc@ops-netman.net, morrowc@ops-netman.net X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <164385267401.26801.16932009193407138969@ietfa.amsl.com> Date: Wed, 02 Feb 2022 17:44:34 -0800 Archived-At: Subject: [Sidrops] Roman Danyliw's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 01:44:34 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-sidrops-6486bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Ben Kaduk's DISCUSS position. ** Section 8. The Section 4.2.1 guidance that “Each RP MUST verify that a purported "new" Manifest contains a higher manifestNumber than previously-validated Manifests” is crucial to prevent a replay-like attack. What is the recovery procedure if an RP loses that state (i.e., “forgets” what the last manifestNumber was for a given publication point)? Should it be TOFU (trust whatever is the first value it downloads next)? ** Editorial -- Section 1. In the spirit of inclusive language consider replacing “man-in-the-middle”. For example, s/man-in-the-middle attack on the retrieval/an on-path attack during the retrieval/ -- Section 4.2.1. Editorial. In the thisUpdate field, s/is recent any/is more recent than any/ From nobody Thu Feb 3 02:43:26 2022 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 545633A0FC1; Thu, 3 Feb 2022 02:43:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-6486bis@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, morrowc@ops-netman.net, morrowc@ops-netman.net X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <164388499653.23462.16919739523606949941@ietfa.amsl.com> Date: Thu, 03 Feb 2022 02:43:17 -0800 Archived-At: Subject: [Sidrops] Lars Eggert's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 10:43:19 -0000 Lars Eggert has entered the following ballot position for draft-ietf-sidrops-6486bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Using lowercase "not" together with an uppercase RFC2119 keyword is not acceptable usage. Found: "MUST not" Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "man"; alternatives might be "individual", "people", "person". ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 5.2. , paragraph 5, nit: > ion point to effect this operation. Thus the term "fetch" refers to an operat > ^^^^ A comma may be missing after the conjunctive/linking adverb "Thus". Section 11.1. , paragraph 11, nit: > Appendix B. Changes to RFC 6486 In 2019 it came to light that multiple Relyin > ^^^^ A comma is probably missing here. Uncited references: [RFC6493], [RFC6482], [RFC8209], and [RFC8488]. Reference [RFC6485] to RFC6485, which was obsoleted by RFC7935 (this may be on purpose). From nobody Thu Feb 3 04:02:53 2022 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 014093A13EE; Thu, 3 Feb 2022 04:02:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-sidrops-6486bis@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, morrowc@ops-netman.net, morrowc@ops-netman.net X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <164388976597.15129.830524103308089518@ietfa.amsl.com> Date: Thu, 03 Feb 2022 04:02:45 -0800 Archived-At: Subject: [Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 12:02:46 -0000 Robert Wilton has entered the following ballot position for draft-ietf-sidrops-6486bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document, just a couple of minor comments: 1) Section 4.2.1. Manifest nextUpdate: This field contains the time at which the next scheduled manifest will be issued. The value of nextUpdate MUST be later than the value of thisUpdate. The specification of the GeneralizedTime value is the same as required for the thisUpdate field. If the authority alters any of the items that it has published in the repository publication point, then the authority MUST issue a new manifest. Even if no changes are made to objects at a publication point, a new manifest MUST be issued before the nextUpdate time. Each manifest encompasses a CRL, and the nextUpdate field of the manifest SHOULD match that of the CRL's nextUpdate field, as the manifest will be re-issued when a new CRL is published. When a new manifest is issued before the time specified in nextUpdate of the current manifest, the CA MUST also issue a new CRL that revokes the EE certificate corresponding to the old manifest. Although this last sentence is not wrong, am I right in thinking that this sentence isn't specific to when the manifest is issued, i.e., isn't it the case that that CA MUST issue a new CRL whenever a new manifest is issues for any reason (e.g., as per 5.1, step 2)? If so, perhaps this sentence could be tweaked to make that clearer. 2) 5.2. Considerations for Manifest Generation A new manifest MUST be issued and published before the nextUpdate time. Should any guidance be given about how far before the nextUpdate time a new manifest should be issued. E.g., is publishing right at the nextUpdate time (e.g., 1 millisecond before) sufficient , or does it make sense to publish it a bit earlier than the nextUpdate time? Nits: 4.1. eContentType The eContentType for a manifest is defined as id-ct-rpkiManifest and has the numerical value of 1.2.840.113549.1.9.16.1.26. Would numerical object identifier, or numerical OID, be better than numerical value here? 4.2. eContent I would have preferred for "file" to be "filename" in the structure, but I presume that this can't be changed at this stage anyway ... Regards, Rob From nobody Thu Feb 3 06:43:24 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164793A1C0C for ; Thu, 3 Feb 2022 06:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 2_UBXC7jsEui for ; Thu, 3 Feb 2022 06:43:18 -0800 (PST) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 050ED3A1C0E for ; Thu, 3 Feb 2022 06:43:17 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id a8so9498359ejc.8 for ; Thu, 03 Feb 2022 06:43:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=FJVKo0D/gkNKp25HxnVWh51gCv/jp+pHiMMmTKvd/pI=; b=Atb6vc8GZxgPfdudZwvo20RAfDUEjjE1KYJOfrKEDvVcpSgZrbPMLbsd0L51DSmCkc VCV/5lMoqwChgPjyRF5GW9vQ67LaovN4/yZe+Ey9c4N83REt5ETerF4kXnWiF9YXro8u 1xQQA+7sbt14uU0HP4WyqeeB83REuDo1Sy7K0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FJVKo0D/gkNKp25HxnVWh51gCv/jp+pHiMMmTKvd/pI=; b=SxEGM7ddumAhwy6wFT0V5jx3cRMhBNpH2hnR5p8iN7dRYzdqceKibLL4EsobeiuqEP 4vt1PrUwj9RHLAm1o0vHWq8WdcnkvvubYF65hLmCekBiJ1RryB1OclhC8MUUHQUBlORP cUbNJBrLclpIfIHd48gGjBpybU4XHp3ml3p14KgRyDhET8hkemZw13SWKC/oz8iLBRhe DgFSF4Iiw+5hkKBlmTXigIrjFcTa/eeSIY/QrzQ5rtTTKYnx7pfA1Xm2TOHz3LDoMOm6 upnNd3UtZ/SszCl/yKGbDqo7VZDCAfb19SkrVAMYlnCJxe4z4hITNcYeUcQLBQRX9/fJ aQwA== X-Gm-Message-State: AOAM532wkkp1WaIoKpnCRucerVRV4R3f2YCdOkdookcnNVzmp2QJUgaf 8Q+GTd3qRP08Ks1FBKgkmktCpR92dvRf4g== X-Google-Smtp-Source: ABdhPJy/qE6y7+U2NkFG+oP9tsdehb0F/AY9O+kby6IBA+Ov3BftBx6kB9GfdTudP7atJilAc/Rtqg== X-Received: by 2002:a05:6402:1705:: with SMTP id y5mr35359632edu.200.1643899384870; Thu, 03 Feb 2022 06:43:04 -0800 (PST) Received: from snel ([2a10:3781:276:2:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id og23sm8810969ejc.186.2022.02.03.06.43.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Feb 2022 06:43:04 -0800 (PST) Date: Thu, 3 Feb 2022 15:43:02 +0100 From: Job Snijders To: Adianto Wibisono Cc: Christopher Morrow , Russ Housley , SIDROps Chairs , SIDR Operations WG , Chris Morrow , IESG , Eric Vyncke , draft-ietf-sidrops-6486bis@ietf.org Message-ID: References: <164362677155.28792.13241248233184382872@ietfa.amsl.com> <6778460A-C69A-40B3-9295-A5AB8913C6FA@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] =?iso-8859-1?q?=C9ric_Vyncke=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-sidrops-6486bis-09=3A_=28with_COMMENT=29?= X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 14:43:22 -0000 Dear IESG, SIDROPS, other interested parties, Logistics: In consultation with the authors & wg chairs I now hold the editoral token for this draft. I've uploaded the draft XML to github and adhere to a 'one sentence per line' style to make diff reading easier. Adianto - thank you for pointing out that the abstract and introduction didn't connect well. I've adjusted both slightly in hopes readability is improved. https://github.com/job/draft-ietf-sidrops-6486bis/commit/ce3c5bae1b8e6fdd6c1f55718fb86c7db44c313e A copy of the changeset for archival purposes is avaliable below: Kind regards, Job commit ce3c5bae1b8e6fdd6c1f55718fb86c7db44c313e Author: Job Snijders Date: Thu Feb 3 14:36:47 2022 +0000 Incorporate feedback from Adianto https://mailarchive.ietf.org/arch/msg/sidrops/38TER8ns8vGqTgfBObwYRg7gSos/ diff --git draft-ietf-sidrops-6486bis.xml draft-ietf-sidrops-6486bis.xml index f059e20..d262f29 100644 --- draft-ietf-sidrops-6486bis.xml +++ draft-ietf-sidrops-6486bis.xml @@ -69,7 +69,7 @@ A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. - Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. + Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects. This document obsoletes RFC 6486. @@ -80,8 +80,8 @@
The Resource Public Key Infrastructure (RPKI) makes use of a distributed repository system to make available a variety of objects needed by relying parties (RPs). Because all of the objects stored in the repository system are digitally signed by the entities that created them, attacks that modify these published objects are detectable by RPs. - However, digital signatures provide no protection against attacks that substitute "stale" versions of signed objects (i.e., objects that were valid and have not expired, but have since been superseded) or attacks that remove an object that should be present in the repository. - To assist in the detection of such attacks, the RPKI repository system can make use of a signed object called a "manifest". + However, digital signatures alone provide no protection against attacks that substitute "stale" versions of signed objects (i.e., objects that were valid and have not yet expired, but have since been superseded), or in-flight attacks that remove an object that should be present in the repository. + To assist in the detection of such attacks, RPKI repository systems make use of a signed object called a "manifest". @@ -635,7 +635,7 @@
The authors would like to acknowledge the contributions from George Michelson and Randy Bush in the preparation of the manifest specification. Additionally, the authors would like to thank Mark Reynolds and Christopher Small for assistance in clarifying manifest validation and RP behavior. - The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, and Sean Turner for their helpful review of this document. + The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, and Adianto Wibisono for their helpful review of this document.
From nobody Thu Feb 3 07:06:13 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D963A05F8 for ; Thu, 3 Feb 2022 07:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 jUuxRDGdYO8X for ; Thu, 3 Feb 2022 07:06:02 -0800 (PST) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 291643A060D for ; Thu, 3 Feb 2022 07:06:02 -0800 (PST) Received: by mail-ej1-x632.google.com with SMTP id a8so9705790ejc.8 for ; Thu, 03 Feb 2022 07:06:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=u+N43X9zYE8dTHjCQ/LAZwFLrOMdrSSdJyUU6r0u1mQ=; b=iB6JXJJ/03TFBkeG68CXV/yy5mtoGNjWJAYjh4LD7+hGfQvnL+1ir/hGfZ3hOyez9q 7Emqtr2wuxP1KgbctehJeUsrYUHD4toPJ5oSKL0FGjVG0sEiZq5VYAi6VIA0oqIMYPav e+MnAgwV6xqsQWA/mURizu4sfkVBKOACqqAec= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=u+N43X9zYE8dTHjCQ/LAZwFLrOMdrSSdJyUU6r0u1mQ=; b=B4MnNrAw1jqQj86DFwWo4H2wxFiBD+syzofWNm4MWmOY5QnScVdYdRf5VQthoJuZ4O 3flBwTxJ7grTCBjF04TawnnjgL/oAxDgppnGgsRORemslhsBop/OR06WVaFOo5+8xffj 3tbtUzwJZUv7CFZCGYi48bB+B5GI3s+RXS3qiwXbS58MjDLiXqVszQ7YnkN6ISQ670R9 8/F2A2vQaI3q0jkBkah1gE2Ny1oLf0gsWGW1oSd+Cspff6lUM4U42AQjz8kSngAIStls 28MIm3v/heQBV+/bMYmJB4horqH62f7dzRdaPaVaYWNhwnrWqBbRBr+Q2xA6AYsZp6y3 bFCA== X-Gm-Message-State: AOAM531M+oDoSDPHlOWh/29lphhlPB2R9W5U5IG6Q0meR9xZNU60zIpf q8mtyhFXFVIlBrOtJOn3IxED/Q== X-Google-Smtp-Source: ABdhPJxD2ebD1PFm6XLKQhXDbMKvRUhpSWtTMwYaDDotOgKHnhprbtHR98CorCV7iNNQ2HnLb7w4fQ== X-Received: by 2002:a17:906:478c:: with SMTP id cw12mr29183621ejc.214.1643900759416; Thu, 03 Feb 2022 07:05:59 -0800 (PST) Received: from snel ([2a10:3781:276:2:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id ha3sm16751376ejb.157.2022.02.03.07.05.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Feb 2022 07:05:58 -0800 (PST) Date: Thu, 3 Feb 2022 16:05:57 +0100 From: Job Snijders To: Murray Kucherawy Cc: The IESG , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-6486bis@ietf.org Message-ID: References: <164378415609.9683.10141540796531135717@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <164378415609.9683.10141540796531135717@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Murray Kucherawy's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 15:06:08 -0000 Dear Murray, Thank you for the review! On Tue, Feb 01, 2022 at 10:42:36PM -0800, Murray Kucherawy via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The response to question 7 of the shepherd writeup doesn't really answer the > question being asked. I searched through the archives and found this 2011 message: https://mailarchive.ietf.org/arch/msg/sidr/qIH6oAeWpeHzYmE783oK-rKi6ck/ "No IPR declarations have been submitted directly on this I-D." In the interest of progressing this document it seems prudent to obtain stronger assurances that the -bis document does not introduce new IPR concerns. Through the sidrops@ietf.org mailing list I'll publicly request whether the authors know of any IPR related to this document, once all four responded I'll circle back to this thread to tidy up that aspect. Stay tuned. > Also, please tidy up the stuff identified in the answer to question 11. Thanks for pointing this out. I've resolved all nits. > Section 4.2.1: > > * "... this field is more recent any previously-generated ..." -- > s/recent/recent than/ > > Appendix B: > > * Since this is obsoleting, not updating, RFC 6486, I think this is more like > "Changes Since RFC 6486". Thanks, these two have been changed. A diff is viewable here, or below as patch(1) formatted changeset: https://github.com/job/draft-ietf-sidrops-6486bis/commit/f9663bd4f24046fab9e0bb361259af7c42c39cc6 Kind regards, Job -- commit f9663bd4f24046fab9e0bb361259af7c42c39cc6 Author: Job Snijders Date: Thu Feb 3 14:47:42 2022 +0000 Incorporate feedback from Murray Kucherawy https://mailarchive.ietf.org/arch/msg/sidrops/xWHUPInYdZhNKaQe7RF6RAInNI0/ diff --git draft-ietf-sidrops-6486bis.xml draft-ietf-sidrops-6486bis.xml index f59546d..dac779f 100644 --- draft-ietf-sidrops-6486bis.xml +++ draft-ietf-sidrops-6486bis.xml @@ -7,17 +7,14 @@ - - - ]> - + @@ -108,7 +105,7 @@ are similar to those for CRLs. The syntax of the manifest payload differs from CRLs, since RPKI repositories contain objects not covered by CRLs, e.g., digitally signed objects, such as Route - Origination Authorizations (ROAs). + Origination Authorizations (ROAs) . This document obsoletes . @@ -252,7 +249,7 @@ This field contains the time when the manifest was created. This field has the same format constraints as specified in for the CRL field of the same name. - The issuer MUST ensure that the value of this field is more recent any previously-generated Manifest. + The issuer MUST ensure that the value of this field is more recent than any previously-generated Manifest. Each RP MUST verify that this field value is greater (more recent) than the most recent Manifest it has validated. @@ -633,7 +630,7 @@
The authors would like to acknowledge the contributions from George Michelson and Randy Bush in the preparation of the manifest specification. Additionally, the authors would like to thank Mark Reynolds and Christopher Small for assistance in clarifying manifest validation and RP behavior. - The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, and Adianto Wibisono for their helpful review of this document. + The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, and Murray Kucherawy for their helpful review of this document.
@@ -657,10 +654,7 @@ &RFC6486; &RFC6487; &RFC6488; - &RFC6493; &RFC8174; - &RFC8209; - &RFC8488; @@ -684,51 +678,51 @@ ]]>
-
+
In 2019 it came to light that multiple Relying Party implementations were in a vulnerable position, possibly due to perceived ambiguity in From nobody Thu Feb 3 07:12:45 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0523A07E4 for ; Thu, 3 Feb 2022 07:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 rxQC6eqFgyOd for ; Thu, 3 Feb 2022 07:12:40 -0800 (PST) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 EEFAE3A053F for ; Thu, 3 Feb 2022 07:12:39 -0800 (PST) Received: by mail-ej1-x62b.google.com with SMTP id s13so9858935ejy.3 for ; Thu, 03 Feb 2022 07:12:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition; bh=o65ATsMu8Tt8G6g1Jn0rKknGTYt50GawKwZVeM7P424=; b=sYEEJxRhCjUq6VCxSmubdCQI5B45I9Ytz9dM8vnfBiCjSgFJ9ppwBLeP3fABZTUCM8 YagO8k6TN5cmrPrLfrMNs5ftNj/a/0O6OP+TGtQFQHfMiC5NBlvgVTiE6IdJgBJZBXPD TgD1xHMHu4heKNnD+1DW/DASGDLx2jHigl61E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition; bh=o65ATsMu8Tt8G6g1Jn0rKknGTYt50GawKwZVeM7P424=; b=FFLkYv3sJ0FZE4HKIfinEpeCv44Wt9S3+VeJxW/JgO4d3XQmKU2IBypp3zqjsQZaay J+0wejqS4UNPY00MYMWAzBb72tRdk5UrY2afZ2P9gnu3L5FD01Whid3bY6uwCRVXsnMn WLTC540u8RXnaX39l7eAmbjZGkOiPSsmFGS4mk+xCqyUrU0fhCGxSmV8Ysa8VIcRCHJl 81YDZFXn6A1nhE7CrqbFPZP8RDZwE2LN2c++K2x/wQf0nfJLswN9yNPlS45HqL+8o3Q+ I3WroWlQPrX5AZO23sDf8e9oLUvgmx+a+ZB1oDADAjISPa+wYwCQ9+qK77UJCQM1wywl NAEQ== X-Gm-Message-State: AOAM531NIJ66vFMFa9MybxQLjs9Au++NjNI9qFppQZIi8/P6ITwT4H3J UJRuql8VLi5B60z3oTl8GRK2D/KUVwn6sWziQaSQCYYje4/aEWGkxqWWp7cvQq/mpgY8phdbBlG 4Nf2kIaveD94BT85EKK6FBQHhLpIyABrXC6b9i8N9Cv4bhAtWVnj86OE= X-Google-Smtp-Source: ABdhPJw7aOLy0G0uKF+a2VvTllSdEDqtAMzJnb6ftUm2H5XKa4O4kMkkot8F6VQie3M5CNxmT87Pwg== X-Received: by 2002:a17:907:d13:: with SMTP id gn19mr29206826ejc.252.1643901158104; Thu, 03 Feb 2022 07:12:38 -0800 (PST) Received: from snel ([2a10:3781:276:2:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id cr8sm22195221edb.47.2022.02.03.07.12.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Feb 2022 07:12:37 -0800 (PST) Date: Thu, 3 Feb 2022 16:12:36 +0100 From: Job Snijders To: sidrops@ietf.org, sra@hactrn.net, stkent@verizon.net, gih@apnic.net, mlepinski@ncf.edu Cc: superuser@gmail.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [Sidrops] IPR call for draft-ietf-sidrops-6486bis-09 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 15:12:44 -0000 Dear authors of draft-ietf-sidrops-6486bis, IPR statements related to https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis Murray Kucherawy pointed out that the shepherd write-up on IPR statements felt a bit off. See: https://mailarchive.ietf.org/arch/msg/sidrops/xWHUPInYdZhNKaQe7RF6RAInNI0/ I searched the archives but couldn't find recent unambigious statements. The simplest remedy is to issue a call, which is this very email. I ask that the authors respond ('reply-all') to this email with a message indicating whether they know about IPR related to this draft. Thanks! Kind regards, Job From nobody Thu Feb 3 07:16:38 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5570D3A0828 for ; Thu, 3 Feb 2022 07:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 4jmUmqKf7sK8 for ; Thu, 3 Feb 2022 07:16:27 -0800 (PST) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 38AA43A082C for ; Thu, 3 Feb 2022 07:16:27 -0800 (PST) Received: by mail-ej1-x632.google.com with SMTP id d10so9830185eje.10 for ; Thu, 03 Feb 2022 07:16:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=tgyOw/gM+jtbdRsoZArB1eQQSFfwZdduMuyTeOtijw0=; b=q9FWWiN4NtheRPp+a4DOTq7pFxFFKtB36mP6wAFVJqXSF3Vox6yUAhIVIkzrfi2oJg 2Qbz9satWmLHaPPkjMJRS7gZDzGayTMVKbG0REdeRymwBV7Tw42dzvbPUY46WEx1DzUV qccvVRD09kuelCSuGtp6kIqT50Gj9rZMgwEnA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=tgyOw/gM+jtbdRsoZArB1eQQSFfwZdduMuyTeOtijw0=; b=HRAu/kLaM1McEm9OZhIQNtA5ehxhyTeyj+ey8CfmyHcMM2OVO+HY3wZIq2w7faKw1b LLml5J3ZfZJFNrs1iXL+cStxGifcVmakYAhiqfFT72+0SB0lZF1/+GB9TCGHIjn2/PQA gSDQ4NjS6aDYW1UOL0UTqZ5T5znlGRu1NHHKxUlUHCBGkQ22QJfhfDpcnazrMZnHWF7q zDGaxwGOKvDZ30mKuiVCxxdR5Njpb+0mTwMFRW1+Lt2+mZwMB0BLnkDgpRTWepw/Hfn7 VrnaxeFtBMmu7IRhy191z7/IeYcSKxbxBd3WrVFISO+5x8unW3r6JuXjowWYtMfINMbu Ue7Q== X-Gm-Message-State: AOAM531nu7JDGadUyorLNK0fpEA1/nBHjRp+tGhr8d8f7V0ApO8citIh BH4Jc90T1W/lx7tXWpFiVTqzog== X-Google-Smtp-Source: ABdhPJx7qWlJ6v7wmRDb+AyICNqDSUMdj2qp105Gxy5wxPnH1yjQOCCLGxVZ2sD0aSxuF3N9J93V7Q== X-Received: by 2002:a17:907:3e9b:: with SMTP id hs27mr29992115ejc.72.1643901384044; Thu, 03 Feb 2022 07:16:24 -0800 (PST) Received: from snel ([2a10:3781:276:2:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id gz19sm16917541ejc.10.2022.02.03.07.16.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Feb 2022 07:16:23 -0800 (PST) Date: Thu, 3 Feb 2022 16:16:21 +0100 From: Job Snijders To: Zaheduzzaman Sarker Cc: The IESG , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-6486bis@ietf.org Message-ID: References: <164379626127.24070.9456287680446733998@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <164379626127.24070.9456287680446733998@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Zaheduzzaman Sarker's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 15:16:33 -0000 Dear Zaheduzzaman Sarker, Thank you for the review. On Wed, Feb 02, 2022 at 02:04:21AM -0800, Zaheduzzaman Sarker via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the efforts on this specification. It was a good read. > > After reading the shepherd's writeup I was expecting an update to 6486 but the > document actually obsoletes 6486. Something happened between when the shepherd > writeup was written and when this doc went for publication, not captured. Not a > big deal I guess, would have been better to get this captured. You are right that something happened: after shepherd write-up during IETF Last-Call the observation was made that the document should obsolete 6486 as it is a complete replacement. See the emails before/after this message https://mailarchive.ietf.org/arch/msg/sidrops/_Ys3mNuBs4AIDEi7aT4CkRj94ic/ for more context about the change. > Nits: > > Section 4.2.1 : "The issuer MUST ensure that the value of this field is more > recent any previously-generated Manifest", missing "than" ? This nit was addressed through https://mailarchive.ietf.org/arch/msg/sidrops/EYxcUtZLF7go2UBnOoOXqwn6bRY/ Kind regards, Job From nobody Thu Feb 3 08:07:51 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD173A0C1B for ; Thu, 3 Feb 2022 08:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net 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 0ENm3wio3hCD for ; Thu, 3 Feb 2022 08:07:46 -0800 (PST) Received: from sonic301-32.consmr.mail.ne1.yahoo.com (sonic301-32.consmr.mail.ne1.yahoo.com [66.163.184.201]) (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 A476E3A0C15 for ; Thu, 3 Feb 2022 08:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1643904465; bh=41mO1hwENkDInPd85MA8ffxFUDuHe1oO9W7ANIkuOpM=; h=Date:Reply-To:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=gjxJEI5wtXBmvFLsfcR4Z90D9duIBne/T1AmxSwHx3eUIVQuzv6Y67lycQD2oI15ZBhxGkdb5uVmsY0iMC3GDTk3JD54T2MS3yqcaK1Dy8HCPtVG+X35Wdnn3g4PQ3y+0f5yhZBpcGliiENCUJeW7o6THdd+zLFsLQj/s24KCB68nJo8pb6asgAQjrVfbWv1BqBz1KL+dIiRpYOjJYA/PkzO22LMrZ6qfgOPxVWMt1mSf5f4h6rqBdA+RKpXtd0VLWjMRHNC97yJOG0poZBYmJIeZeZ0iJ7p3OIa74yKEUknB2qm7Q1+0Ze4P42Id/vuG28+zfa1JaBxvrNll0rnVw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643904465; bh=kcBVjO6L0jeyhmTy3AqNUp2ZvtuocLkEbhITW5MHcO2=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=MF5UNkfHsg/kAClo2+kt9iVHstX1gUjeNFlf6xOPYG0HJC/k6dLDbERHdE/8t8fzY1BMMxxjZJOcRa5A7wooe7RvigtCObRPdgas9g0ppWVIfvYsQAXECAoEzJWcntEurKoXQ1zQe1CTWm4XSKxu8EOOVkegBgArUy2XUMeuqA7wWgHj4XykiZCNcqBAb8HPrpNgjbpbUetpTHtRPth8koaIL6Mdk5FntX4lICE+Ny2qoB6yJ8zxSd+k7Y2v7U8V4/aw4Qwh/Ud+qXSkcNEnKDSvF07sRRbHuVILpwhoBa0fjgGNY3/PPsLm4lWI0UewVPhx37ZWg9zmgm5egl+dzw== X-YMail-OSG: aD_qU6gVM1l0nYMMoL1AknI0_7l4AxTntPCG6Bludbsk11JL9enMOcmb.XqoBim MZLnOowTBWGRzprtlApYpe0sJg7GQjb_dTjo_K0Kt4O34UkHvVZO5_NIqbU_._DbAO0ZZmT7chQY KvVb9eZ4xespLrUkbX770rG30.5M3em4ObfrymgXZpnAaEHk8EqCVRrhHJ56aNp0KT4BGF3oHSXA iWVttYmADZEnCf6EhFkmiz1dixKr_TIbJIaEr.maAusuJU3erRxg5U20SF3M0VCtzyZBFcmZHBHF NJUhwybdGOfh6aFLexAkgsWvYKuiU2elTaiSzWWW0lfMxLRL9hHaKUQBV9mZXjCbhACy0mLnrUYi cao9S78yCK_DQOLLCyfay1AOItkMSppaD5bXx5Mq4XL.UgcaRu.qSyvAvy0826jEupboG68NyWgf eTeGmWq_tdl2SKnstAGwwJalmJSXD2lqiFGUqE8SIGUL_MNIm9hFz5CC_cFKGXu_hTzzwxVrtvhm khKqveWTBydSpzVUDnjIgnK65lXhMzXYamgQCOQPip92eWZynrOojRteqWntjgd539Uv34xzv4Pm lkaJ30kFtBFMhLxcQOmAGkkovUJjMfgSi8xYJeC324fXnm1H4AasI9PYW8YpOP4hz55QLWbrYAQr 7GtcIqOItrkfVwfM..w0vv7bi_Wqu9ckmXtjatgpltxJBuKkl2MjQEorXPvPU.tNYzBTQB1huDDx L2ERFFlU53BzV4roRdIuWjj5x6W5tdegLfbJoSVfjBJ3K9QawDWxRPpfaJvcd7KPpwtFgAUgEk4H kT9zQXw6DmI2ZwdQdncllQw14Y3CrWs4thCTWZvS.Kl7.YD5qSnKMPMBz4QR.XsPNKxRkZLrsCV7 kI0SHX4hfhz1HWFhVeMV2vSqZgO_eZR6hOSH8XKmD6Qhi4vO9h85XPOd_dBubIIxTVY6CWBpctzs ppC1NmRosJhBqMBALd6l4ty2.KcOSLWaxgTIVDdhyf8XITmvVoH8XqVQBL5.adTCCxqW0HqcECgb ZVplZ.E1f4905PI.g93Iu.imNrrqdyK8z977d_ORdiTykLHyBx_vLVnuUfUhVv_CL_CvKP39DsEL WTZJIlI4gXPjUIXvZfaJyo8wmQgcYigr2GTkHqjN9Im3ZwYZ.SbKOA0o5daPOs.f4J7Ftpm8EB7G iao3An9A7lcffvtCRDbWb_fUoxidt3EoCvrHzgmP8JlGiRE1qvcTC9Y.G1gqk3iVGN0q.9nF8Zvz clHlc0B7dAaoG.zjysqoq7hfS0JqKQY5Fgp8OTW82d.Mi5GH5.puBur8P.uCKxYNVMAvn2tPKGGo qT05VVBqO.uIUwHPGyMh1rzIlwoIEcQeSfEfb0NdrNoSr_UMa4fRRAmm.zu8AXgZEzy_86cr2hCv DyxKbWVRUcxDh9tkBQsXul8vuWI.ZWvE5BzbmHA45uW98f66MeVVhkyS616blAAqG7KlPP9k0hY8 y_mlWrYb0K.a65yc87T7oUx0w3au_35s3OdaIzm1L7R8VK_7wRiWBgk1m0thnu24EKF1vQoiWr8j QXcog7UQQ334HsYVb1DdfAhMYZupuZuwe1dGlzgdBIDwsR28ZvsbgegAsLcmYdX.4wH_hMXynswb Ucj_yfg2eDkAOySa1H7Jwpnp8SRWYTdc3ju5GaVInGOT8svAYi..zJSvnvksb2Xm2pzMmw0TB6KW cQ3ZOjDB1ZNAtzUP9FFsLplEyz_mG1rFLjeRMq58rs14AYhCoEzWNo5uZ_FU_vnXFaeeyaN1h.o3 3ritaulEtcNBIPsbruTw23J0vFU7acJG69GWRbTsS6nNETj_RGhqXf3OcAzSKUek6QzERoxJfYNJ sKyJ1VX3jBhPoOzjkvH8HJujAQX55QbBQQeSxKFQPA_wHRqlCenJ_S1Tk7VcZZSdOWerF3Jfj07Z R4aZXguvsq18OM5kchBLy7fUVTqZZ86Czyv7t4SLrsrOy.5zR6ncsXftiA..n84KWEZbkXKxtTas 6hsb_UBxaypDwCKdEFiLY9mGwuO7aRZBTZetIpgPYKYdbNWZwp6w3diYzTPIELIiPGazqaFz2ceM CxjWMizjLXlfcrT6TAXlZ6x.uafQxnbhiV3oC5_utg2nrwuKuwG3NaduEruZ8f78OGL3wH4TIYyC wmnZnrBxgqn8do2sCmjs1lSfoLH1GtUxM9IjGD8cZ0sVEfB8jv24qi.krhR.FJeDZIbSoD6nxCq8 6_pCpDtV0HC7DY5thmBnysow04mjX_1vO4aP9_bt.IqsJhIhP20cX3TeraNxSW9J48TYYIERQSjH DwdH20VKofsSQQR0_WXEQPQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Thu, 3 Feb 2022 16:07:45 +0000 Received: by kubenode522.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 979d60b86c5ec4528e47b74eb439320d; Thu, 03 Feb 2022 16:07:41 +0000 (UTC) Message-ID: <30809112-5c40-3f3d-533b-e4158066b8fe@verizon.net> Date: Thu, 3 Feb 2022 11:07:40 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Reply-To: stephen.kent@verizon.net Content-Language: en-US To: Job Snijders , sidrops@ietf.org, sra@hactrn.net, gih@apnic.net, mlepinski@ncf.edu Cc: superuser@gmail.com References: From: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.19615 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] IPR call for draft-ietf-sidrops-6486bis-09 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 16:07:50 -0000 I am aware on no IPR related to this document. Steve > Dear authors of draft-ietf-sidrops-6486bis, > > IPR statements related to https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis > > Murray Kucherawy pointed out that the shepherd write-up on IPR > statements felt a bit off. See: https://mailarchive.ietf.org/arch/msg/sidrops/xWHUPInYdZhNKaQe7RF6RAInNI0/ > > I searched the archives but couldn't find recent unambigious statements. > The simplest remedy is to issue a call, which is this very email. > > I ask that the authors respond ('reply-all') to this email with a > message indicating whether they know about IPR related to this draft. > > Thanks! > > Kind regards, > > Job From nobody Thu Feb 3 08:19:21 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12233A0CF0 for ; Thu, 3 Feb 2022 08:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 Vy_fko8u6WTG for ; Thu, 3 Feb 2022 08:19:09 -0800 (PST) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 38EA73A0CF2 for ; Thu, 3 Feb 2022 08:19:09 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id w14so7049634edd.10 for ; Thu, 03 Feb 2022 08:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=4eKoAdSQAcPTHZ0yEH5PSkTQhEITZXtj8Aa2MrCUa6Y=; b=aiG5LcQloI6fYYLSiD9m1QKnTRwcwxcIKmRVj41Pdkkc70eyFsDdiVPWvcSNg9dZrP /yHhIh5l02kF9G6fRND9arulzpZHAqMjCIDRaic+Uc8kXtzWdoKNJfI1BIwHCz02D8lN IvDNHusTod9LZc2yxXGtydfuPxJ6F5PAqwK1Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=4eKoAdSQAcPTHZ0yEH5PSkTQhEITZXtj8Aa2MrCUa6Y=; b=RIBZ6CyHJ7qNB1N6txW8gxirpLh0EVDTa1wK/jvOOoEOkGldd9v0Z+2T8/iKxGuesL E1mUqsp69ALuRI9T7DR8SaonyLh7OJR41pVQtERNYDEMDcZ53zCK1+z26xjII0QtIU2y sC+JeTuXlEIcme7PF0AtYWDvYuBWeqNCREILV/cv+G5l1ET9VjCoScWbkP89bCEin2Fq q3P0WYCDyfMQMs4XSylCHzda0NhjA+pUcl6KG6KxCtr4Z6xGQXcnROMb3CjELiPZp55G xV8PHlD5cpFal4toSBJaAprKbX0g/Zaa3NRwZKvT4oIW8wl40nJCWdx7V6re2b10rlVg P7kA== X-Gm-Message-State: AOAM531os0IfIndBUt80idqeUV9uo3siR3vif1o071hETMt5g04bYJ7/ U89enxnG5txb95ENL8jyJ1qd4A== X-Google-Smtp-Source: ABdhPJxN+xe/FYfEVs8JRHThTnaGr9HKS90MDFJ9yiw8D9SaXfJ/rXaa5nlnBWbLUVzEd7hdFpyknw== X-Received: by 2002:a05:6402:b8e:: with SMTP id cf14mr35633509edb.196.1643905146506; Thu, 03 Feb 2022 08:19:06 -0800 (PST) Received: from snel ([2a10:3781:276:2:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id by22sm16950783ejb.5.2022.02.03.08.19.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Feb 2022 08:19:06 -0800 (PST) Date: Thu, 3 Feb 2022 17:19:04 +0100 From: Job Snijders To: Francesca Palombini Cc: The IESG , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-6486bis@ietf.org Message-ID: References: <164380721377.28554.13713193582509780845@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <164380721377.28554.13713193582509780845@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Francesca Palombini's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 16:19:14 -0000 Dear Francesca Palombini, On Wed, Feb 02, 2022 at 05:06:54AM -0800, Francesca Palombini via Datatracker wrote: > # Major > > 1. ----- > > objects from a successful fetch. This implies that the RP MUST not > > FP: This should be "MUST NOT" (rather than "MUST not") You are right, a small oversight on proper capitalisation. I've updated this for -10: https://github.com/job/draft-ietf-sidrops-6486bis/commit/27928105481a16ef097ae69681950135ba23349f > # Minor > > 2. ----- > > FP: as noted by the shepherd, there are some references to fix: > > * RFC 6485 needs to be replaced with RFC 7935 > > The following references need to be removed as they are not used. > > == Unused Reference: 'RFC6482' > == Unused Reference: 'RFC6493' > == Unused Reference: 'RFC8209' > == Unused Reference: 'RFC8488' (this was even last called as downref) The above has been addressed through https://mailarchive.ietf.org/arch/msg/sidrops/EYxcUtZLF7go2UBnOoOXqwn6bRY/ > 3. ----- > > monotonically for each newly-generated Manifest. Each RP MUST > verify that a purported "new" Manifest contains a higher > manifestNumber than previously-validated Manifests. > > FP: This should contain a sentence about what the RP has to do if verification > fails (I expect ignore the "new" Manifest). To resolve this comment I propose to add the following sentence to that paragraph: ADD: If the purported "new" Manifest contains an equal or lower manifestNumber than previously-validated Manifests, the RP SHOULD use locally cached versions of objects, as described in . > Same comment for the thisUpdate field: > > Manifest. Each RP MUST verify that this field value is greater > (more recent) than the most recent Manifest it has validated. To resolve this comment I propose to add the following sentence to that paragraph: ADD: If this field in a purported "new" Manifest is smaller (less recent) than previously-validated Manifests, the RP SHOULD use locally cached versions of objects, as described in . > And for the text in Section 5.1: > > Note: An RP MUST verify all mandated syntactic constraints, i.e., > constraints imposed on a CA via a "MUST". > > publication point that is described by the manifest. (RPs are > required to verify the CMS signature.) I am not entirely sure what the question or comment is in the above paragraph about section 5.1 - can you elaborate? > 4. ------ > > nextUpdate time. Each manifest encompasses a CRL, and the > nextUpdate field of the manifest SHOULD match that of the CRL's > nextUpdate field, as the manifest will be re-issued when a new CRL > > FP: What are the exception cases where it is expected not to match (i.e. what > is the reason for the SHOULD here)? The RPKI is a globally deployed production system; this means the RPKI operator community to be careful about what it can mandate from RPs versus what it can mandate from CAs. Putting in a stronger mandate was discussed in the working group: For example, I observed some time window alignment issues in the wild. Detailed discussion in this thread https://mailarchive.ietf.org/arch/msg/sidrops/VNG77j05I2JXOwv4qkSy-DCgRNE/ Aligning the Manifests eContent nextUpdate with the Manifest's EE certificate's "Not After" with the associated CRL's "nextUpdate" optimizes operations (it thwarts needless CRL growth); but deviation from this recommendation for alignment does not negatively impact cryptographic robustness. Hence, I believe a softer 'SHOULD' is appropriate. Does my elaboration help? > 5. ----- > > The RP MUST check that the current time (translated to UTC) is > between thisUpdate and nextUpdate. If the current time lies within > > FP: I am not sure the parenthesis needs to be there - this seems like an > unnecessary implementation detail. I believe this implementation detail is useful: in this context the ASN.1 Type "GeneralizedTime" is used, which allows specification of an timezone offset. There are some seemingly thorny complications related to Validity Time windows as described in https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5 Therefor I believe it is useful to remind implementers to normalize towards Zulu. > # Nits > > 6. ----- > > * all published signed objects that are verifiable using EE > > FP: Please expand all acronyms (EE, OID) on first use Thanks! EE already was expanded, but I added capitaliation to improve readability; I added expansion for OID. Did I miss any others? > 7. ----- > > termed a "one-time-use" EE certificate [RFC6487] > > FP: missing period thanks, added. An overview of the changes related to this feedback can be found here: https://github.com/job/draft-ietf-sidrops-6486bis/commit/124c15569a991083cf8b8ca3ac249d98c49d41ef The changeset in patch(1) format is also available below. Kind regards, Job commit 27928105481a16ef097ae69681950135ba23349f Author: Job Snijders Date: Thu Feb 3 15:22:38 2022 +0000 MUST not -> MUST NOT Feedback from Francesca Palombini https://mailarchive.ietf.org/arch/msg/sidrops/chrDRb2twlBi4zwOw6qG__SBYnk/ diff --git draft-ietf-sidrops-6486bis.xml draft-ietf-sidrops-6486bis.xml index ed7de68..bd07ae4 100644 --- draft-ietf-sidrops-6486bis.xml +++ draft-ietf-sidrops-6486bis.xml @@ -565,7 +565,7 @@ Termination of processing means that the RP SHOULD continue to use cached versions of the objects associated with this CA instance, until such time as they become stale or they can be replaced by objects from a successful fetch. - This implies that the RP MUST not try to acquire and validate subordinate signed objects, e.g., subordinate CA certificates, until the next interval when the RP is scheduled to fetch and process data for this CA instance. + This implies that the RP MUST NOT try to acquire and validate subordinate signed objects, e.g., subordinate CA certificates, until the next interval when the RP is scheduled to fetch and process data for this CA instance.
commit 124c15569a991083cf8b8ca3ac249d98c49d41ef Author: Job Snijders Date: Thu Feb 3 15:38:59 2022 +0000 Add a sentence about what to do when the manifestNumber verification shows a lower or equal manifestNumber compared to previously-validated Manifests Add a sentence about what to do when the manifest validity window is older compared to previously-validated Manifests Expand acronyms Add missing period. Feedback from Francesca Palombini https://mailarchive.ietf.org/arch/msg/sidrops/chrDRb2twlBi4zwOw6qG__SBYnk/ diff --git draft-ietf-sidrops-6486bis.xml draft-ietf-sidrops-6486bis.xml index d8b545c..3a5df83 100644 --- draft-ietf-sidrops-6486bis.xml +++ draft-ietf-sidrops-6486bis.xml @@ -97,7 +97,7 @@ Authority (CA) publication points in repositories (directories containing files that are subordinate certificates and Certificate Revocation Lists (CRLs) issued by this CA and other signed objects - that are verified by end-entity (EE) certificates issued by this CA). + that are verified by End-Entity (EE) certificates issued by this CA). Manifests are modeled on CRLs, as the issues involved in detecting @@ -153,11 +153,11 @@
A CA's manifest is verified using an EE certificate. The SubjectInfoAccess (SIA) field of this EE certificate contains the - access method OID of id-ad-signedObject. + access method Object Identifier (OID) of id-ad-signedObject. The CA MUST sign only one manifest with each generated private key, and MUST generate a new key pair for each new version of the manifest. - This form of use of the associated EE certificate is termed a "one-time-use" EE certificate + This form of use of the associated EE certificate is termed a "one-time-use" EE certificate .
@@ -236,6 +236,7 @@ Conforming manifest issuers MUST NOT use number values longer than 20 octets. The issuer MUST increase the value of this field monotonically for each newly-generated Manifest. Each RP MUST verify that a purported "new" Manifest contains a higher manifestNumber than previously-validated Manifests. + If the purported "new" Manifest contains an equal or lower manifestNumber than previously-validated Manifests, the RP SHOULD use locally cached versions of objects, as described in . @@ -244,6 +245,7 @@ This field has the same format constraints as specified in for the CRL field of the same name. The issuer MUST ensure that the value of this field is more recent than any previously-generated Manifest. Each RP MUST verify that this field value is greater (more recent) than the most recent Manifest it has validated. + If this field in a purported "new" Manifest is smaller (less recent) than previously-validated Manifests, the RP SHOULD use locally cached versions of objects, as described in . @@ -617,7 +619,7 @@
The authors would like to acknowledge the contributions from George Michelson and Randy Bush in the preparation of the manifest specification. Additionally, the authors would like to thank Mark Reynolds and Christopher Small for assistance in clarifying manifest validation and RP behavior. - The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, and Murray Kucherawy for their helpful review of this document. + The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, Murray Kucherawy, and Francesca Palombini for their helpful review of this document.
From nobody Thu Feb 3 08:27:15 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0DA3A0D46 for ; Thu, 3 Feb 2022 08:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net 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 00PskMGz9nzm for ; Thu, 3 Feb 2022 08:27:08 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4EFE3A0D3F for ; Thu, 3 Feb 2022 08:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=Message-Id:To:Date:Subject:Mime-Version:Content-Type:From:CC ; bh=Zdjzz1c7dY6rQ907g9PXRnhYBimmADffYBb2gUVbGh8=; b=rXxFmMxgnX0i94VQMPuwfxBz rtKyciDAny2HtTn548qcQuR9Av9gXRC7OssA6F/0YB3Y1pOEa6bq1BB4/Ec2IPz45Yfzmwa8O8ErL /4wEdamo8n5tioiR2Jin0tidj4CikFAc7r72eOMuT1SPIzMshf8NqAbiyyX0um+1eTwSEBRkpUkaM UDNLhwqbR9Iafq6pfp3yC27t3AfceUQU0oNPkeZRVW37a44r8Et+btolo0NJ4ABYJReTGDO1ktqj7 3PiLeacempX4kqaZppb1LgtCfqd5+ujhtsmX8Ch80s/6D02ZKd8ffggSIxg4UQdUddO6M9A1RcA1d swh3Dp76/Q==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:48966) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nFewk-0003Ml-8L for sidrops@ietf.org; Thu, 03 Feb 2022 17:26:58 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nFewk-0001Kc-5K for sidrops@ietf.org; Thu, 03 Feb 2022 17:26:58 +0100 From: Ties de Kock Content-Type: multipart/alternative; boundary="Apple-Mail=_CBE80326-7FF7-40E9-8C9A-EC7B58C1D749" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Date: Thu, 3 Feb 2022 17:26:57 +0100 References: <004b01d7f037$42626090$c72721b0$@student.utwente.nl> <9F86E690-C065-4438-BAFF-97AE7DBF2D1F@ripe.net> To: SIDR Operations WG In-Reply-To: <9F86E690-C065-4438-BAFF-97AE7DBF2D1F@ripe.net> Message-Id: <526728C7-D7D1-4B8F-9AE6-F3D0756EA522@ripe.net> X-Mailer: Apple Mail (2.3693.60.0.1.1) X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1d05e782c6a8abbe29cbb0e5f50b71ac5 Archived-At: Subject: Re: [Sidrops] draft-kwvanhove-sidrops-rpki-tree-hints-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 16:27:14 -0000 --Apple-Mail=_CBE80326-7FF7-40E9-8C9A-EC7B58C1D749 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 13 Dec 2021, at 17:00, Ties de Kock wrote: >=20 >=20 > Hi Koen, >=20 >> On 13 Dec 2021, at 16:36, Koen van Hove = > = wrote: >>=20 >> Dear all, >> =20 >> Based on your feedback I hereby present the second version of the = tree hints draft [1].=20 >> =20 >> Russ Housley rightly pointed out to me that whilst additional fields = cannot be added to the PKIX certificate profile, non-critical extensions = can be added. I believe adding the hints to the certificate directly, = rather than using a separate object, reduces operational complexity, = might simplify some issues with =E2=80=9Cwhat if the limits change=E2=80=9D= (as that now only happens when the certificates change). I hope it also = makes the political problem less troubling. Additionally, I reduced the = limits to the two main ones, although others can be added in a similar = fashion. Apart from that, the main concept was left unchanged. >=20 > That is a significant realisation. I think this will need some testing = to see > what implementations are intolerant to additional extensions, but that = should be > quick --- but if this works, this is much easier to implement, both = for RPs and > CAs. >=20 > This also specifies the exceptions much more naturally :). Recent versions of Fort, OctoRPKI, routinator, rpki-client, rpki-prover, = and rpstir2 accepted non-critical certificate extensions on a CA certificate = during interoperability testing. The RIPE NCC RPKI Validator 3 was not tested but should also accept such certificates. Due to the lack of a testing environment, rpstir, and = rcynic were not tested. This means we have a limited but interoperable path to extend resource certificates. Kind regards, Ties --- >=20 > Kind regards, > Ties >=20 > --- >> =20 >> Koen van Hove >> =20 >> [1] = https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-tree-hints/ = _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops = > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops = --Apple-Mail=_CBE80326-7FF7-40E9-8C9A-EC7B58C1D749 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 13 Dec 2021, at 17:00, Ties de Kock <tdekock@ripe.net> = wrote:


Hi Koen,

On 13 = Dec 2021, at 16:36, Koen van Hove <k.w.vanhove@student.utwente.nl> wrote:

Dear all,
 
Based on your feedback I hereby present the = second version of the tree hints draft [1]. 
 
Russ Housley rightly = pointed out to me that whilst additional fields cannot be added to the = PKIX certificate profile, non-critical extensions can be added. I = believe adding the hints to the certificate directly, rather than using = a separate object, reduces operational complexity, might simplify some = issues with =E2=80=9Cwhat if the limits change=E2=80=9D (as that now = only happens when the certificates change). I hope it also makes the = political problem less troubling. Additionally, I reduced the limits to = the two main ones, although others can be added in a similar fashion. = Apart from that, the main concept was left = unchanged.

That is a significant = realisation. I think this will need some testing to see
what implementations are intolerant to additional extensions, = but that should be
quick --- but if this works, = this is much easier to implement, both for RPs and
CAs.

This also specifies the exceptions much more naturally = :).

Recent versions of Fort, OctoRPKI, routinator, = rpki-client, rpki-prover, and
rpstir2 accepted non-critical = certificate extensions on a CA certificate = during
interoperability testing.

The RIPE NCC RPKI Validator 3 was not tested but = should also accept such
certificates. Due to the lack of a = testing environment, rpstir, and rcynic were
not = tested.

This means we have a limited = but interoperable path to extend = resource
certificates.

Kind = regards,
Ties

---

Kind regards,
Ties

---
 
Koen van Hove
 
[1] https://datatracker.ietf.org/doc/draft-kwvanhove-sidrops-rpki-t= ree-hints/
_______________________________________________
Sidrops mailing = list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops
=

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

= --Apple-Mail=_CBE80326-7FF7-40E9-8C9A-EC7B58C1D749-- From nobody Thu Feb 3 08:37:42 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74763A0D61 for ; Thu, 3 Feb 2022 08:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 xqKOmcneGfnG for ; Thu, 3 Feb 2022 08:37:28 -0800 (PST) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 EAA773A0B80 for ; Thu, 3 Feb 2022 08:37:27 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id s13so10587825ejy.3 for ; Thu, 03 Feb 2022 08:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=5Yzu6yJbRUMmdunDnygqAMWnhUF88tHtBiKUFLp5blw=; b=I28ban2DEQtJ+hkRmAmTKKOP1nl/AP9QQEsI/6PU/jOZ5McpmzVvhuqiJUOm+QP9Yl HLDD2tyZWl4SMxT1ewMkAduUHckIVwMEPzKA7+ReI47U9Lww4g5YhMqxMcbdOB353WMs nJlvg1AybFnn6HizQceT8JGH0LhQ8AXBbF35Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=5Yzu6yJbRUMmdunDnygqAMWnhUF88tHtBiKUFLp5blw=; b=DyXvD0dIHKt+J9l01p76BIi09aeDBEhg5nN298we2sDVO/N/SKgOHxRlUcEMmWkha/ AknNDlwFRCRvZ2ya/DJ0wRiJVSbkrpdcmndjUsJINyzDJZ/U/zjRiPJSQRmlkMLJuZtV JJvy+CeBuFVr+gC1e3YOjra+Z2h2DDAYvdI9hBzjbFhkrLzuDktfe5qUB6wrFa/d7BtY /rfFOWABlGrMrKsfA7LfNhSA+L7I4T8aFTbnNBFXhlViDJ4VDlNv2B0xn9GWcDWyUtD+ CyJk54TbUndkgAclQNIvwvmIgEsWX4ayGehAuJ7WlLMM8B73UqY2myBf81kO3AYILcgC La2w== X-Gm-Message-State: AOAM5320Vl0G9RTYAfJtEFd/6s3xDOlcuJintYce9nbcOgFKQbYiIgyV CVhfV/DlO2xPVe/Y/KHLauNkEkoPDOKouw== X-Google-Smtp-Source: ABdhPJxb10MNXm8KvE+9/ySqVFAdCUp9umJMs3X+P0jUdyQ1dJOByGA3K0ShWhtz3eQif2Nwtr11jQ== X-Received: by 2002:a17:906:d551:: with SMTP id cr17mr28880046ejc.247.1643906244323; Thu, 03 Feb 2022 08:37:24 -0800 (PST) Received: from snel ([2a10:3781:276:2:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id s26sm22845215eds.39.2022.02.03.08.37.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Feb 2022 08:37:23 -0800 (PST) Date: Thu, 3 Feb 2022 17:37:22 +0100 From: Job Snijders To: Roman Danyliw Cc: The IESG , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-6486bis@ietf.org Message-ID: References: <164385267401.26801.16932009193407138969@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <164385267401.26801.16932009193407138969@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Roman Danyliw's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 16:37:41 -0000 Dear Roman, Thank you for this review! On Wed, Feb 02, 2022 at 05:44:34PM -0800, Roman Danyliw via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Ben Kaduk's DISCUSS position. > > ** Section 8. The Section 4.2.1 guidance that “Each RP MUST verify that a > purported "new" Manifest contains a higher manifestNumber than > previously-validated Manifests” is crucial to prevent a replay-like attack. > What is the recovery procedure if an RP loses that state (i.e., “forgets” what > the last manifestNumber was for a given publication point)? Should it be TOFU > (trust whatever is the first value it downloads next)? Through this update I made an attempt to clarify https://mailarchive.ietf.org/arch/msg/sidrops/NzCcNzcN46FD7RgV3D5ULMnEhxs/ If the RP has "forgotten" what the last manifestNumber was (for example, a brand new RP instance which only has a Trust Anchor Locator in its trust store, and an empty cache), there obviously is notthing for the RP to compare the purported "new" Manifest against. It is not entirely TOFU, in the sene that the cryptographic validity through signatures is checked, and the Manifest's eContent, EE certificate, and CRL all contain pointers to determine whether the object at hand is is valid within the set of constraints outlined in both the original RFC and this -bis document. > ** Editorial > -- Section 1. In the spirit of inclusive language consider replacing > “man-in-the-middle”. For example, s/man-in-the-middle attack on the > retrieval/an on-path attack during the retrieval/ Updated: https://github.com/job/draft-ietf-sidrops-6486bis/commit/83ade7f35d6e7b8379cb798e258c3cbb86278fee > -- Section 4.2.1. Editorial. In the thisUpdate field, s/is recent any/is more > recent than any/ Thanks, this was already addressed through https://mailarchive.ietf.org/arch/msg/sidrops/EYxcUtZLF7go2UBnOoOXqwn6bRY/ Kind regards, Job commit 83ade7f35d6e7b8379cb798e258c3cbb86278fee Author: Job Snijders Date: Thu Feb 3 16:36:14 2022 +0000 Add more inclusive language Feedback from Roman Danyliw https://mailarchive.ietf.org/arch/msg/sidrops/VFKYHp2WdsJ7yVt8fHY3hBSJnzY/ diff --git draft-ietf-sidrops-6486bis.xml draft-ietf-sidrops-6486bis.xml index d103cf4..97db9fd 100644 --- draft-ietf-sidrops-6486bis.xml +++ draft-ietf-sidrops-6486bis.xml @@ -85,7 +85,7 @@ A manifest is a signed object that enumerates all the signed objects (files) in the repository publication point (directory) that are associated with an authority responsible for publishing at that publication point. Each manifest contains both the name of the file containing the object and a hash of the file content, for every signed object issued by an authority that is published at the authority's repository publication point. A manifest is intended to allow an RP to detect unauthorized object removal or the substitution of stale versions of objects at a publication point. - A manifest also is intended to allow an RP to detect similar outcomes that may result from a man-in-the-middle attack on the retrieval of objects from the repository. + A manifest also is intended to allow an RP to detect similar outcomes that may result from an on-path attack during the retrieval of objects from the repository. Manifests are intended to be used in Certification Authority (CA) publication points in repositories (directories containing files that are subordinate certificates and Certificate Revocation Lists (CRLs) issued by this CA and other signed objects that are verified by End-Entity (EE) certificates issued by this CA). @@ -609,7 +609,7 @@
The authors would like to acknowledge the contributions from George Michelson and Randy Bush in the preparation of the manifest specification. Additionally, the authors would like to thank Mark Reynolds and Christopher Small for assistance in clarifying manifest validation and RP behavior. - The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, Murray Kucherawy, and Francesca Palombini for their helpful review of this document. + The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, Murray Kucherawy, Francesca Palombini, and Roman Danyliw for their helpful review of this document.
From nobody Thu Feb 3 08:45:54 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736AA3A0E36 for ; Thu, 3 Feb 2022 08:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 F3KpWhPIisuS for ; Thu, 3 Feb 2022 08:45:41 -0800 (PST) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 81A5F3A0E37 for ; Thu, 3 Feb 2022 08:45:40 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id k25so10532342ejp.5 for ; Thu, 03 Feb 2022 08:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=H532frzSAbKDKKoMvu1pf9VTVDe1xzcG1wK57lDGxDc=; b=XRVogy5yxeTidaFeAxnu5Ywob/GFLwrpwFFUH2m70gP/qYLzOfmHkn7kBYj49WOV0o L5zafLPCSeV4/ws/mtOxhnElvJe8tzzKjBPV5QFMFpwbvjZDA43CmD3QGLuUDAaNPaup 2zrJdcfIBkAPHYwtdNs2UDPh7KW/VMvFJkB70= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=H532frzSAbKDKKoMvu1pf9VTVDe1xzcG1wK57lDGxDc=; b=QmEfucouHmATlaeI0mFpcajtB64Yr8sMWA38jWlHWcSAA9hx6Hsq4zn3aUQi8VgiLG k4W+fJx6wBJvd/d8JJ9iUlV8os/31db3lOcXWGGHmtUmXwoTd2nu0P4wjCi7PqdO5qs5 8RV3CTMcBljQE5v6mL1mY8hToo6B5hMTvLl2NJv1BhbL5Gnmokuqg9J7FKj6hmKAfdDV UevWskySGnPjNUS2F5BmwJBAt9yM+G8NjRiz5DIovBxyCiia4UTYsf4eJI4AnQerxSve UKhaObCfxX/8tW66rE+s36GUWnLpIeb5lAf+ezWypLW19YOCNqF2USDfyA2NJc5LL0zZ xxiA== X-Gm-Message-State: AOAM533+TtpN/En84wvzO7iFRR4YSF1Y1QvBtgdFo1RtYsdwxOSJWVKr iwWLx2d1QA4GTntdSQiMnNixQw== X-Google-Smtp-Source: ABdhPJwxB2+RUkAr0pYXuOJtVxByouQMQyeXLYJiyhcJAK34Rg8RgKOTQu3JDgK7N5YSNM/oC1CHeg== X-Received: by 2002:a17:907:3e8d:: with SMTP id hs13mr30573692ejc.0.1643906737593; Thu, 03 Feb 2022 08:45:37 -0800 (PST) Received: from snel ([2a10:3781:276:2:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id ry6sm8689162ejc.45.2022.02.03.08.45.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Feb 2022 08:45:37 -0800 (PST) Date: Thu, 3 Feb 2022 17:45:35 +0100 From: Job Snijders To: Lars Eggert Cc: The IESG , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-6486bis@ietf.org Message-ID: References: <164388499653.23462.16919739523606949941@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <164388499653.23462.16919739523606949941@ietfa.amsl.com> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] Lars Eggert's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 16:45:47 -0000 Dear Lars, Many thanks for your review of this document! On Thu, Feb 03, 2022 at 02:43:17AM -0800, Lars Eggert via Datatracker wrote: > Using lowercase "not" together with an uppercase RFC2119 keyword is not > acceptable usage. Found: "MUST not" This was addressed after Francesca's feedback, see https://mailarchive.ietf.org/arch/msg/sidrops/NzCcNzcN46FD7RgV3D5ULMnEhxs/ for resolution > Found terminology that should be reviewed for inclusivity; see > https://www.rfc-editor.org/part2/#inclusive_language for background and more > guidance: > > * Term "man"; alternatives might be "individual", "people", "person". This was addressed after Roman's feedback, see https://mailarchive.ietf.org/arch/msg/sidrops/4rlNabm2w9r6vD3r-2oY5ezr6Fs/ for resolution > ------------------------------------------------------------------------------- > All comments below are about very minor potential issues that you may choose to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), so there > will likely be some false positives. There is no need to let me know what you > did with these suggestions. > > Section 5.2. , paragraph 5, nit: > > ion point to effect this operation. Thus the term "fetch" refers to an operat > > ^^^^ > A comma may be missing after the conjunctive/linking adverb "Thus". My mastering of the English language is insufficient. I propose to leave this up to the RFC Editor (I will request the RFC Editor to pay attention to this sentence) > Section 11.1. , paragraph 11, nit: > > Appendix B. Changes to RFC 6486 In 2019 it came to light that multiple Relyin > > ^^^^ > A comma is probably missing here. Added. > Uncited references: [RFC6493], [RFC6482], [RFC8209], and [RFC8488]. This was fixed through https://mailarchive.ietf.org/arch/msg/sidrops/EYxcUtZLF7go2UBnOoOXqwn6bRY/ > Reference [RFC6485] to RFC6485, which was obsoleted by RFC7935 (this may be on > purpose). I have no reason to believe this was done on purpose. Updated! Full overview of the diff based on your feedback: https://github.com/job/draft-ietf-sidrops-6486bis/commit/f862be520c37c956e839f1770371d799d8fd8295 Kind regards, Job commit f862be520c37c956e839f1770371d799d8fd8295 Author: Job Snijders Date: Thu Feb 3 16:43:40 2022 +0000 Update reference and add missing comma Feedback from Lars Eggert https://mailarchive.ietf.org/arch/msg/sidrops/HeKoTC1AKAOGLM7CtBKx-1allSw/ diff --git draft-ietf-sidrops-6486bis.xml draft-ietf-sidrops-6486bis.xml index 97db9fd..c1268a7 100644 --- draft-ietf-sidrops-6486bis.xml +++ draft-ietf-sidrops-6486bis.xml @@ -4,7 +4,7 @@ - + @@ -261,7 +261,7 @@ This field contains the OID of the hash algorithm used to hash the files that the authority has placed into the repository. The hash algorithm used MUST conform to the RPKI Algorithms and Key Size - Profile specification . + Profile specification . @@ -609,7 +609,7 @@
The authors would like to acknowledge the contributions from George Michelson and Randy Bush in the preparation of the manifest specification. Additionally, the authors would like to thank Mark Reynolds and Christopher Small for assistance in clarifying manifest validation and RP behavior. - The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, Murray Kucherawy, Francesca Palombini, and Roman Danyliw for their helpful review of this document. + The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, Murray Kucherawy, Francesca Palombini, Roman Danyliw, and Lars Eggert for their helpful review of this document.
@@ -629,7 +629,7 @@ &RFC5280; &RFC6481; &RFC6482; - &RFC6485; + &RFC7935; &RFC6486; &RFC6487; &RFC6488; @@ -703,7 +703,7 @@
- In 2019 it came to light that multiple Relying Party implementations + In 2019, it came to light that multiple Relying Party implementations were in a vulnerable position, possibly due to perceived ambiguity in the original specification. This document attempts to clarify the innovative concept and application From nobody Thu Feb 3 09:36:06 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193043A118F for ; Thu, 3 Feb 2022 09:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 pVeAHs72zZ1U for ; Thu, 3 Feb 2022 09:36:01 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA633A1189 for ; Thu, 3 Feb 2022 09:36:01 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-100-88-186.hsd1.ma.comcast.net [73.100.88.186]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id E33144E614; Thu, 3 Feb 2022 17:35:58 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 1B6132EA00FF; Thu, 3 Feb 2022 12:35:58 -0500 (EST) Date: Thu, 03 Feb 2022 12:35:58 -0500 From: Rob Austein To: Job Snijders Cc: sidrops@ietf.org, sra@hactrn.net, stkent@verizon.net, gih@apnic.net, mlepinski@ncf.edu, superuser@gmail.com In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Message-Id: <20220203173558.1B6132EA00FF@minas-ithil.hactrn.net> Archived-At: Subject: Re: [Sidrops] IPR call for draft-ietf-sidrops-6486bis-09 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 17:36:06 -0000 I am not aware of any IPR claims related to this draft. From nobody Thu Feb 3 10:15:27 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AC43A0860; Thu, 3 Feb 2022 07:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gEilyASV5Pv3; Thu, 3 Feb 2022 07:19:58 -0800 (PST) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 3DAFE3A085D; Thu, 3 Feb 2022 07:19:58 -0800 (PST) Received: by mail-ua1-x935.google.com with SMTP id n15so5781929uaq.5; Thu, 03 Feb 2022 07:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hcKX8IE1h4vsEWM8v7g2GSMksiXRor37sc6lu1irzVY=; b=ZexzKfqMJp0p6Amc6VaW/NmL2TYaf77LLnzL00XtMa/ER4VAm4vON1XxyoD8hltbXC SIuq7B5C7OXa//PguLw7//6gsgi47AXnmBWbrZ28S98vek+vLNpJ2hvg9fPS1gNO7Dfk Tij0jmDabmU45FNa5ku8Zn05kz3J8ckvs3zqX1WXzfjB1rkxuWfYoNhz7rnwCaCRtcdI +GaipJ6oAoC4F9ZSo4fnNLDMwGHg5nfVXKNRuDf8fRlk3g5QwiH8hksdax7zUr7JhhE+ bEk5M3nyX9HKn7Z81EQPTQGHeZ43VxZxkWCdRplRHc8k7X7Z8YfmgrG3W263Z+qNYFzG nbfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hcKX8IE1h4vsEWM8v7g2GSMksiXRor37sc6lu1irzVY=; b=cdnZPkUYOb+i2sbbnUffzk6tGUldtEjpcQvUiz9hkBEr8UlZItZf/cn795ZExJQc96 cKJD1g7srSWI6GACXXTO782Kz6vp6/KD72U+sboNgOeulv1UEBZkI90kM+3whpnYMCFl Jn2Hqa0ugsJioiivZy/2ls4vUg+A12Yfir+X5nCKylGPLVC+QmrJ0mmyuGjKN2e3OwPz A03sJVpWi4fiNugmZcPnOmbHPvuyT+EvllHgpNv7VJ16fg5RIUnZB8tT7N2CmOQOD3Ry j6KHzf3l2YEpfuN2sJQVt0cytXd/Z+R+Pisfr3svJuBCFBXNM3+XwN9oXLZLNIsDGC77 TfiA== X-Gm-Message-State: AOAM531Q84Bn6z/N6M+bXZhLKKi0AytzKLlRcJmUgKrxxzaRFIC1+d7z Jal6dgWPup+4BgDNYLSoNghMmM5bKGcNIM4RyJ8= X-Google-Smtp-Source: ABdhPJwDLJfPRy6CZayOyGjYZode9f2NR8wlpuEJo14KBaOUDMPROs/TeNtfmFSNtCN3IH7DFMyfcCZK8IqBzyhZUoU= X-Received: by 2002:a05:6102:919:: with SMTP id x25mr13484720vsh.18.1643901595736; Thu, 03 Feb 2022 07:19:55 -0800 (PST) MIME-Version: 1.0 References: <164378415609.9683.10141540796531135717@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 3 Feb 2022 07:19:44 -0800 Message-ID: To: Job Snijders Cc: The IESG , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-6486bis@ietf.org Content-Type: multipart/alternative; boundary="000000000000a8e46b05d71eaa0d" Archived-At: X-Mailman-Approved-At: Thu, 03 Feb 2022 10:15:25 -0800 Subject: Re: [Sidrops] Murray Kucherawy's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 15:20:03 -0000 --000000000000a8e46b05d71eaa0d Content-Type: text/plain; charset="UTF-8" On Thu, Feb 3, 2022 at 7:06 AM Job Snijders wrote: > > The response to question 7 of the shepherd writeup doesn't really answer > the > > question being asked. > > I searched through the archives and found this 2011 message: > https://mailarchive.ietf.org/arch/msg/sidr/qIH6oAeWpeHzYmE783oK-rKi6ck/ > > "No IPR declarations have been submitted directly on this I-D." > Right, but question 7 asks whether the authors have affirmed they know of no IPR claims that still need to be filed. The IESG last call includes a declaration that none have been filed, but that answers a slightly different question. > In the interest of progressing this document it seems prudent to obtain > stronger assurances that the -bis document does not introduce new IPR > concerns. > > Through the sidrops@ietf.org mailing list I'll publicly request whether > the > authors know of any IPR related to this document, once all four responded > I'll > circle back to this thread to tidy up that aspect. Stay tuned. > Good stuff, thank you! -MSK --000000000000a8e46b05d71eaa0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 3, 2022 at 7:06 AM Job Snijde= rs <job@fastly.com> wrote:
<= /div>
> The response to question 7 of the shepherd writeup doesn't = really answer the
> question being asked.

I searched through the archives and found this 2011 message:
https://mailarchive.ietf.org/= arch/msg/sidr/qIH6oAeWpeHzYmE783oK-rKi6ck/

=C2=A0 =C2=A0 "No IPR declarations have been submitted directly on thi= s I-D."

Right, but question 7 asks= whether the authors have affirmed they know of no IPR claims that still ne= ed to be filed.=C2=A0 The IESG last call includes a declaration that none h= ave been filed, but that answers a slightly different question.
=C2=A0
In the interest of progressing this document it seems prudent to obtain
stronger assurances that the -bis document does not introduce new IPR conce= rns.

Through the sidrops@i= etf.org mailing list I'll publicly request whether the
authors know of any IPR related to this document, once all four responded I= 'll
circle back to this thread to tidy up that aspect. Stay tuned.

Good stuff, thank you!

-MS= K

--000000000000a8e46b05d71eaa0d-- From nobody Thu Feb 3 10:15:32 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893723A0813; Thu, 3 Feb 2022 07:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.676 X-Spam-Level: X-Spam-Status: No, score=-7.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 fKjo7JmlTOCj; Thu, 3 Feb 2022 07:23:46 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on20626.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1b::626]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8658F3A0A6D; Thu, 3 Feb 2022 07:23:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I7jiRhr1WLifhmXfcxK2FLjKvqJ86u2mxA+yutKz6cLmNUmM+zsz2S20RxBhSTnltf+cIWY1f51v4g00tHPhma3BiFo2E6GZLSdTjb6nZ2VE+VSUFS+hL+hhxJ0t+fyva56gA6DEHtX+r3pLSMJ/gGJRgPEcxAgWKs1PNcS95KmzXLcmgUEJAlAq8m3WcNWAt9S+PSb4SVwUb2BjSCyY146cAEdOb+9sV3d8VDyEhTkKR4SI6pWTgriDoI+Sjq3f/5/yU8uONNyiDEKqfo4bsmuaYoZl4aduAdVS2pHiTn+Gwqvm810WR9KPtltbtjBSBuwihXvIw98Fh0LFpgLpCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6emSRo9dG1gTPSxYV/OVgf5n1bJxPuB9sbCCSPbF+9w=; b=KlJeT1NVLqtG0EZ7EGtVx+BW6/YxtpJT++pKbWlfqkHw3AikwfXQxzthN7t08krS3RYBSo/dPaTyFnN2Urp+rdPHufpYBjCwOwP7wgBAlcnlBKLjIoizCczx/wY9DDN8fRBzxwHv7E2OkXH2j5aHZfd+5IaoRoLOAFEoSc9LpGDqpNW9Ghph4F0gwpau+jf5MhKbHFq7lbZE9+7+ECYqZWhj4noU9oUkhTPwpbct9Ivn9uVtfT7yUhIK5/u4iRyDFGkEtYwoWrB91TAGVlZ1sw7/HVHL65heBYRvvwk+b7PwP2EuCsS30SkSr81LiStLcDaTtTuCr6xTl2sBkqJ6fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6emSRo9dG1gTPSxYV/OVgf5n1bJxPuB9sbCCSPbF+9w=; b=C6oVdKt7Y+Jx33XCu3CCHuFH0c9n9FrSO+7H9c//ADM6KTwvQAS+PadNvIM4N4/jVD0GbI8uH7xbUPkEEXFAnmB9dFcCGJjvorfJBeyrXPAlXmY1bKGzkUq3x5UE8LI6FwfVlIfMhdmVc/XULcbhlgPQpKm6uZALTmDbylajAig= Received: from HE1PR07MB4187.eurprd07.prod.outlook.com (2603:10a6:7:98::23) by VI1PR07MB5616.eurprd07.prod.outlook.com (2603:10a6:803:bd::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Thu, 3 Feb 2022 15:23:00 +0000 Received: from HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::b9ee:c838:1b7e:de61]) by HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::b9ee:c838:1b7e:de61%3]) with mapi id 15.20.4951.014; Thu, 3 Feb 2022 15:23:00 +0000 From: Zaheduzzaman Sarker To: Job Snijders CC: The IESG , "sidrops-chairs@ietf.org" , "morrowc@ops-netman.net" , "sidrops@ietf.org" , "draft-ietf-sidrops-6486bis@ietf.org" Thread-Topic: [Sidrops] Zaheduzzaman Sarker's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT) Thread-Index: AQHYGBxMTsW4oL7JlkK8f/9NTv+BIKyB8ceAgAAB2oA= Date: Thu, 3 Feb 2022 15:23:00 +0000 Message-ID: References: <164379626127.24070.9456287680446733998@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2300e0cf-179f-43ca-132f-08d9e729105c x-ms-traffictypediagnostic: VI1PR07MB5616:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c3/FCZKauQpvb8sbS09aQTh6iSawfmfd6t83nvbGwh+pEZy62vTo/ZXLUMjOERAvd/EXACpFFvCPstsWtzZA1x5N82AUs48GVfLUHgeRm9er57kkjN4K5I5AYBOG0PGE1WtaMX+0gpQ1sljFVTn8q7VVS+gVp9ni7OQYVf+GJhri7CDXzX5hhJkROvGPZ2X/R3qGaOxeoTz6Hl12Iws9OnjMAHyWr88M3FuFP80lt8RZNwyFMpQDd1bCeJwmnPCLl6fCuLCWh976H0rUtTUanNeYkS7pP3GQS1k2Rf3Dm5MrOcrY3vAY5We8yiOWJ2cYjz3/vs4kpZPJIRMFhV0A5Pwsxv+8+6/z00ebvag1lmw6atRwSlql+mz1ZO8+d+A8tmu7HkKhn2MzyG8siqckv6bCDPBoKRRPRDizBaDknH91Zi9Bp2K5QSbb0b0lOStk0YqUjHstmzrYGgQKer7KNJS2wXq881qDekPFe6mo5setgGhuh9oUrnKXWU+qmLxFulHYSolvE2259PucuTCh8jQ/y6rdw+KP73LNTI4UML0UVxiouK8uw34GgPX0cuJC/jS8kRcxm2f1g7KSOBDiDXCdIbMxuC/Q670AWrqsEhDF2mXA2pGK2tu7GZHFvdsYlXVhNGpb+VzUXmirH08TtJ75UEnBF60r+ve6vnZh3nefmizGMzMWv9viBBUDizkmU9BJR3ToKzRSR7OMTPbUGaFGiX1fsr/o+lmm6nyzUduAhGUdefVaKTEnnBEjKs6U0oqdkZCF9cuKNjLfdwteuCWMSJ2b+HgfsjfkM8NFt5uDTwU/WzEKxmdQdWVE6GoCX3HT+7hzZJw56RVbbFE0nNoN3ZlMbUcMCovuIULjk0BV1wENkQOWmaVdeOn3UtzAfCejSWUAOqz5xLS/kqfgf95DUtbP1/10Y+l6Ai2+ZeA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4187.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(33656002)(4326008)(66946007)(66476007)(64756008)(66446008)(8936002)(71200400001)(26005)(2616005)(186003)(8676002)(76116006)(66556008)(53546011)(2906002)(86362001)(5660300002)(966005)(122000001)(38100700002)(6486002)(508600001)(99936003)(38070700005)(316002)(54906003)(91956017)(6916009)(36756003)(6512007)(6506007)(82960400001)(44832011)(83380400001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?rOqP4CUQQwWZk3vzXrbTAVfEQwD4wc4vjZllrH2DW/E7fUgAwU12fQjwODAD?= =?us-ascii?Q?NvfYZCHCR+6iSmtjO/E2irndeM6nnXl82fAWZtzSmobcR7AlCCcMKJcDG4yZ?= =?us-ascii?Q?/bRvcP5wZTFWBO8U6yrw2ib5BT5OAAGe+4OxN/omomFtgkvn9QwrjbBFo9l3?= =?us-ascii?Q?0g/ZVFv4oNaCMIivCusZ1vIP4M4zTl8Azq3ICh+n4S7K4RM3eoTCPh6V0gky?= =?us-ascii?Q?kOyl8reuC7sdO/AnIWRxsrj3N48CyjrZeFSxsfE6Ed1wOHPmNj2ZX1FrP/IF?= =?us-ascii?Q?YvgidH6DRWChQhC+q23Snm030tb2xYQ+/I6mb24M4C4hTvQtqoIsI7MXho1n?= =?us-ascii?Q?je/rU2/3IgM4Rs5v8j6k5KkXBpPnf/zcd9pwkNgBKiEjsoXIoFlcnHpKmVWC?= =?us-ascii?Q?vfEqR4vXdzpwcGVyesky2xtwCbtuh2Z9tFQOacnuINI/CpuFCzhKfdaHS31Y?= =?us-ascii?Q?6vexl1dAJxFMgLCOlVpR/FlX2AVZexMVRei2o14i62csvTRRlIATBdCZexy6?= =?us-ascii?Q?GiYPYuJ4PdVYGb/HgHabAwut4geynqMPUMfBr4mORarqLqKBulVwyBellCHm?= =?us-ascii?Q?o/xR+Ke4NTFks0oa+4SEmX/lzBDazkV6S06lBhbouIsxPCIZb3ZNNccaBg/J?= =?us-ascii?Q?iQhG1UeoPeZ3x2O1qg0fTxQXyLXRjKSNO+dsUemFp8X8ewsGUPO4+k6ukuWc?= =?us-ascii?Q?+AfyBz+s8aM8832G4czWlwfBFDoOaJfh0kjt7K8BDNkj+yQ6wfHirBctkHQ2?= =?us-ascii?Q?qLB7SBOMBszeETyxWx8hxfTnYgA1ITTzlmFg1E188v63RZ130IMyaaM4bonf?= =?us-ascii?Q?ickU4gO06ao4Y2mgLslCtaAdwZF6bJZCT691BTHsFgTgv8z/vfe88qw6oMkA?= =?us-ascii?Q?UUkBwaljPZCqx27L+7CE1rmyZtFDpHhW1wjW4ijKnzaHJdTsiI9W9TYmgLu1?= =?us-ascii?Q?0ylRZJVlMHLEzjzs2DAg067EXFBNfFiIOOZ8nVjgS48LtCSL53bNZlzqOyhF?= =?us-ascii?Q?+A6q3rTA1BHy5uVjeGkD21bvdPF32OFudXFL+VlE2N5nP9tnqAaO2DVvBP2F?= =?us-ascii?Q?iSTvDblKE0gV7mHEIr/ZjaY+0VKjTSMWtDAdshH90hw9LqSzq+3uh8ZCniyt?= =?us-ascii?Q?q5QwTaESo/0KlmKK1s2HT0G2ZlVJBuDlFyv9nRWpC8zw8rwM18HUIMdj9E1s?= =?us-ascii?Q?OLFLk6zYEhL4uas9SbhsZFbTYZ1DznN8lcTZixFpByYlPYF9mW5KL62YPE5K?= =?us-ascii?Q?Vip+Vh37J2jzerVjs3rYyY9FlbqEEh6NhQSVvlimh8WZiawjGv6L9Lgvtsh9?= =?us-ascii?Q?0RzzOnzO9GDlqcQGgMMzAercCJsG8/qP//ZCDSpb5mVZRvcKADUvu9IV3DPs?= =?us-ascii?Q?XVxmEasBWcCOscPjX4F6qep/maRSKy+JFb8DMMZSIKLijtfEEACrmYtPCpU4?= =?us-ascii?Q?aNK0KKg9MBzt9pI20qxb9NYaNMCcIUh/a8Yw4mQInPzk8XEWkr+KFqnJN32b?= =?us-ascii?Q?/3Gsz7Q8danxy881egSpjAVZJi+TaCM7LqbWWHt6Jx6FNCYmgXCYOo4zPXms?= =?us-ascii?Q?2bHESyxj4rSfIIhUXI8KZ8v6qJqkUifE2QcMBayjDV5vZkFRL6CP1S+d6zvt?= =?us-ascii?Q?+37VQ1Sz4+GizEY49HBDmDAHSKz7n4r3dmqOb+k59fMX7AUw4oBqOxu+3YbU?= =?us-ascii?Q?H+2kXZa+x7+JT2stBfb2tRcjoN2jU0B8v+h6QWKDGKRkLssf6bhxmaC/aWaU?= =?us-ascii?Q?nqWiYLyHPA=3D=3D?= Content-Type: multipart/signed; boundary="Apple-Mail=_411B0F51-E422-455D-997E-264AA4E885FF"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4187.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2300e0cf-179f-43ca-132f-08d9e729105c X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2022 15:23:00.2062 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +Sdu6DzlP2DIJwVT3hOe5cnivn9DKSn6XLOtNYKkEdQPg0LWZeLrz83iwo4RNaE6EqvNlfxjLZT9LUbaLF3eiIb7SbxM5ypOZ+or42WsHHrSIQsTN914zxN7ZxISlV+S X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5616 Archived-At: X-Mailman-Approved-At: Thu, 03 Feb 2022 10:15:25 -0800 Subject: Re: [Sidrops] Zaheduzzaman Sarker's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 15:23:52 -0000 --Apple-Mail=_411B0F51-E422-455D-997E-264AA4E885FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for the pointer and fix. Great to see IETF last call making = things better. //Zahed > On 3 Feb 2022, at 16:16, Job Snijders wrote: >=20 > Dear Zaheduzzaman Sarker, >=20 > Thank you for the review. >=20 > On Wed, Feb 02, 2022 at 02:04:21AM -0800, Zaheduzzaman Sarker via = Datatracker wrote: >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Thanks for the efforts on this specification. It was a good read. >>=20 >> After reading the shepherd's writeup I was expecting an update to = 6486 but the >> document actually obsoletes 6486. Something happened between when the = shepherd >> writeup was written and when this doc went for publication, not = captured. Not a >> big deal I guess, would have been better to get this captured. >=20 > You are right that something happened: after shepherd write-up during > IETF Last-Call the observation was made that the document should > obsolete 6486 as it is a complete replacement. See the emails > before/after this message = https://mailarchive.ietf.org/arch/msg/sidrops/_Ys3mNuBs4AIDEi7aT4CkRj94ic/= > for more context about the change. >=20 >> Nits: >>=20 >> Section 4.2.1 : "The issuer MUST ensure that the value of this = field is more >> recent any previously-generated Manifest", missing "than" ? >=20 > This nit was addressed through > = https://mailarchive.ietf.org/arch/msg/sidrops/EYxcUtZLF7go2UBnOoOXqwn6bRY/= >=20 > Kind regards, >=20 > Job --Apple-Mail=_411B0F51-E422-455D-997E-264AA4E885FF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBf4w ggX6MIID4qADAgECAg8BdUoQAyUVYjB/ZVVBDvMwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMC U0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB IHYzMB4XDTIwMTAyMTA3MjkyNVoXDTIzMTAyMjA3MjkyNFowYjERMA8GA1UECgwIRXJpY3Nzb24x HDAaBgNVBAMME1phaGVkdXp6YW1hbiBTYXJrZXIxLzAtBgkqhkiG9w0BCQEWIHphaGVkdXp6YW1h bi5zYXJrZXJAZXJpY3Nzb24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmjJb Zy6kdvqWwiZanvVnqKsb990pSFndyIgFspP9mArDxvEX0oqrBugPRyJSp1KA0KDPo9L3SBHk7pbp hJDbJAxPdPAbyZ+DMHV/UtQSUUpp8rRoYNEA6Ew3OlG5Sz1Nhq9AcjSKeOZKunnJInh/y435NACo co2uP/6Gk0XBeB3qE645aIqpbsO3DCUMOWxWIjjTRFQ/TqoUjbIwfw+rO64Y3qEa96Ibj63AoDtt 3gwmtpFkVm5C44XfK7J4LyXIIz4TQqnfxlfoJ+ttFMfV1ZV1OvA7xXj0yO/6btsktlktpgMvow87 HPkSRtsLXQoRhU4E1zclEPWz5SzhUXuOvwIDAQABo4IBxjCCAcIwHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwHQYDVR0OBBYEFJlMp3EJ+P/dXOLqvbT718jDfw1mMA4GA1UdDwEB/wQE AwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzArBgNVHREEJDAigSB6YWhlZHV6emFt YW4uc2Fya2VyQGVyaWNzc29uLmNvbTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwDQYJKoZIhvcNAQELBQADggIBAD1OD1xt xE0jjc12/QXWWe8Cv2q1ZRn1PwacRWFJMyprPB6CiR6YBnmovYCyvCrNCqzsNaTpQLAQeKxwpmOg fZ1SrdyqQKjtCiAlQynqV+dX5VAA6kt/fM67jZbU+lmzw3/2mXNQKTnor1Ax2bJjtZB2DzvTmSPd EybZWxSfMMSsZHA4GLPGEHws+7fHeZ6RSRsAolXPTLGu7gxPkYDtaUzI9M8Z9GKz2UC/wNP2UieR 95h5TnKiqAWLqAxwzcu7GVWIdJ4rzgOenaNg56OM5q87+X90ZSAODWAPnxdDgVGspHbxt2g9cQYb pkKiHWrOuLIWd8B/oGbE1ruKqcFKC39aYkd7JRlHjkNfU/IpymDoGd3RYMtsJW2JvinuZMmMZ5F5 Xpw1yJuSPrq5tHbPx7S6hjqYhd9VkRLbKkprw9+HJZBrUrhrUx4HVF2/bo+WG9GCTdQUsm8JQt9B zpRh2ySNBQZfUn1WN3Q+lMcGSdItCNYH6HnXGrAmv+oDZ1pnp9z+NNmDoNMAHaFvwYCFd9/HvjJu 5kL90Fp3UEJQAk6X+2+ElrfNplUz16nAOBvxcY55R5eI9SDD8MmNfADekiMldSwB9LjMrqBhwWeE UblghhtceJ3iqg35LURo+KXdL3h0/IodZPBYoMLMhMbDdYokIUY+mWW5W1T1WzV9PyWqMYICyjCC AsYCAQEwWjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCDwF1ShADJRViMH9lVUEO8zANBglghkgBZQMEAgEFAKCC AUEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjIwMjAzMTUyMjU5 WjAvBgkqhkiG9w0BCQQxIgQgkvXYPtGMVibTiwr0WuhzvKl576DyXKHM5cfj0HYXjS4waQYJKwYB BAGCNxAEMVwwWjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVy aWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCDwF1ShADJRViMH9lVUEO8zBrBgsqhkiG9w0BCRAC CzFcoFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdUoQAyUVYjB/ZVVBDvMwDQYJKoZIhvcNAQELBQAEggEA KNUOr0ggfXXByKvkQT1ySs+4GQj/6/mWpgqQDJmQ8Zt82SpUi8vvHW/GwNTak84GwoWGneR1ZBLN cTRUz142UiAFKssbsY9COVydnn4nDD1fVp4C4phCmH8rmIme9o6jwwi5MlxJZlqds6QA7au1PIpv GU7VQ9wfOB/Vtgp/IebczTHksnwcp6z7zhbA5/FEi18E9sGnPqsik7N80GeiPkT1MW4CED+Ksr7t XVL1qPJnfDgqIQrDtGZc/w1JGKrx1M50GGZZswlSZLczCR78MPKMQ0IPIagMP3wTZA7VC6Xy4QrU 0MW+TLuTfQgkXirk/Z2lxW2/bc8oBJUXqtKX3AAAAAAAAA== --Apple-Mail=_411B0F51-E422-455D-997E-264AA4E885FF-- From nobody Mon Feb 7 01:23:45 2022 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3673A099E; Mon, 7 Feb 2022 01:23:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <164422581333.29125.7300500511439315638@ietfa.amsl.com> Date: Mon, 07 Feb 2022 01:23:33 -0800 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rov-timing-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2022 09:23:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Timing Parameters in the RPKI based Route Origin Validation Supply Chain Authors : Randy Bush Jay Borkenhagen Tim Bruijnzeels Job Snijders Filename : draft-ietf-sidrops-rpki-rov-timing-06.txt Pages : 10 Date : 2022-02-07 Abstract: This document explores, and makes recommendations for, timing of Resource Public Key Infrastructure publication of ROV data, their propagation, and their use in Relying Parties, caches, and routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-rov-timing/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rov-timing-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-rov-timing-06 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Feb 7 14:50:12 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE103A0EAF for ; Mon, 7 Feb 2022 14:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 orfZtlTpI0ls for ; Mon, 7 Feb 2022 14:50:00 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 AD6523A0EBD for ; Mon, 7 Feb 2022 14:49:59 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id i17so3746465lfg.11 for ; Mon, 07 Feb 2022 14:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=gi1hSd+03sidSjbq/ztRtF4muv1bgwSGsoFLryU+M0w=; b=S7D3oGs27eV8DAA+ZbVxvCr7bjWoypRVSHjHcFMWdrUMKIfV7jM1L3+EJ9+p0oYFY1 qPFkgwp/Ef8CMnBin/WLJHar6iR2+y8yWn5MsVsMFekjCSAnDw31UBwQbrTzoAkK57kU AZfP14OgLRhMza/tPWioUvzr1Q1EADBsHU6cHtlDekU/Szi6SMsjfU00l0qzuquqt2E3 NhLjGmtui1qJS81N8xAwvotSCcowEH9Q2C4zidu5R9wOHWJaSUU/EPCSDZQUsitVOxtD 8qc69y+YJxwENeShk5xi2uOkj59jknu8vbXYUapB5mF7tidBU0tVCzX0p76VHm2PNjUy WTvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gi1hSd+03sidSjbq/ztRtF4muv1bgwSGsoFLryU+M0w=; b=BZPv7Cj2lf9BrRT9V0/VcXo3PV2dNQXU7bXz2PSrFsTwqSNPzl9DYCwtyEAbaj7Id/ wTUg20vChCK2hrQO1A43kQwh6zipmtJ+XrBeI8NLA0f2qcgKh/KZj6UZv6kXFu0Usfxj v1V1bm2iCcqKMAj/w1mBI2zyTCwSVAeNEuEsK9mKThE3JE2/R1a7neoWolpVmCNirP9X A06c50g+3gSJ9TNeh2jZsl/d0ofGSnJXkGROhpBmt5eqDqEw84GDhaUjUb9hXYw/eIHR 72kI8zOfXTiLfr7amJROoq2AP+aqcB5d5vGRuqJSAEdUxVPcB7jqCjK/9y/4wNDOeVnf ta7w== X-Gm-Message-State: AOAM530Yucoo5fDHvbhnkGZaaYqsVeLGdL9OWCs0xrmLbI67iZAwUnNc qauX0aVuFK8ChSSnS5adb9Z0TGpGys79Ap0lb7RtuyH5n3U= X-Google-Smtp-Source: ABdhPJwrxee5CPj18OHpZlxePp5wgCV6qH3cQSIfaxQI/ryaWcBTyowM61UVWjO5N6dAbqPjw8BfDThjOwgJ2Z6xj+k= X-Received: by 2002:ac2:5a0c:: with SMTP id q12mr1166093lfn.488.1644274196445; Mon, 07 Feb 2022 14:49:56 -0800 (PST) MIME-Version: 1.0 From: Alberto Leiva Date: Mon, 7 Feb 2022 16:49:45 -0600 Message-ID: To: sidrops@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Sidrops] What should an RP do on different public key, same subject name? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2022 22:50:10 -0000 Hi. I'm maintaining FORT, an RP implementation. I found a validation FORT seems to be implementing incorrectly, and the RFCs are giving me trouble. Can I have some advice? RFC 6487: > Each distinct subordinate CA and > EE certified by the issuer MUST be identified using a subject name > that is unique per issuer. In this context, 'distinct' is defined as > an entity and a given public key. Bit awkward for my taste. Removing some redundancy: > Each distinct subordinate CA and EE certified by the issuer MUST have > a unique subject name. In this context, 'distinct' is defined as an > entity and a given public key. Trimming fat: > Each distinct child certified by the issuer MUST have a unique > subject name. In this context, 'distinct' is defined as an entity and > a given public key. Translation: > Sibling certificates MUST have different subject names. Among a > parent's children, siblings are identified by their [entity, public > key] tuple. ("Entity" is seemingly not defined by any relevant glossaries [if you're going to update these documents at some point, might I suggest this gets fixed], but from RFC 6484, we can surmise it means "INR Holder.") The requirement is kind of circular because an entity would normally be identified by its parent certificate and subject name... right? How else would an RPKI consumer identify the entity? Educated guess: > Sibling certificates MUST have different subject names. Among a > parent's children, siblings are identified by their [parent, subject > name, public key] tuple. Given that we've established that we're talking about siblings, the parent is always the same, so it becomes > Sibling certificates MUST have different subject names. Among a > parent's children, siblings are identified by their [subject name, > public key] tuple. Circular because of the double "subject name": > Given two siblings, if their [subject name, public key] is different, > then their subject names MUST also be different. In other words, given sibling certificates A and B, subject names a and b, public keys m and n, a != b and m != n, then - If A = [a, m] and B = [a, m], then no constraints must be imposed. (A = B) - If A = [a, m] and B = [a, n], then a != a. This makes no sense, and is thus illegal. - If A = [a, m] and B = [b, m], then a != b. Self-evident. - If A = [a, m] and B = [b, n], then a != b. Self-evident. So... assuming my several flights of fancy have so far been correct, the requirement can be reduced to > If two sibling certificates have different public keys, then they > MUST have different subject names as well. ie. this whole mess is just a reword of the (infinitely more comfortably articulated) immediately following RFC 6487 sentence: > An issuer SHOULD use a different subject name if the subject's key > pair has changed (i.e., when the CA issues a certificate as part of > re-keying the subject.) Except... the two requirements are actually contradicting each other: The former is defined as a MUST and the latter is a SHOULD. ------------------------------ Ok. That established, here's the point: Would it be reasonable for an RP implementation to trim branches off the tree if they violate the above rule? The point of this rule is to prevent broken key rollovers... right? I think? So, is a bad key rollover grounds to chop pieces off the Internet? Does this requirement exist to somehow simplify the work of RPs, or to be enforced by RPs? Are RPs supposed to care? I'm thinking about dumping a warning on syslog and keep going, but I'm not sure there'd be a point to it. (And which is it? MUST or SHOULD?) Thanks in advance, Alberto From nobody Tue Feb 8 02:09:11 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCCA3A0DE8 for ; Tue, 8 Feb 2022 02:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.821 X-Spam-Level: X-Spam-Status: No, score=0.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, KHOP_HELO_FCRDNS=0.399, MIME_BASE64_TEXT=1.741, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 HWOtd5sCfJVi for ; Tue, 8 Feb 2022 02:09:05 -0800 (PST) Received: from smtpproxy21.qq.com (smtpbg702.qq.com [203.205.195.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 662BD3A09C0 for ; Tue, 8 Feb 2022 02:09:04 -0800 (PST) X-QQ-mid: bizesmtp34t1644314939t9em6d83 Received: from DESKTOP-FGBHRHD (unknown [202.173.9.210]) by bizesmtp.qq.com (ESMTP) with id ; Tue, 08 Feb 2022 18:08:58 +0800 (CST) X-QQ-SSF: 01100000002000D0V000B00A0000000 X-QQ-FEAT: XcJ1Se6WjenIr2+Jmx3BDh9juEr07rkRFfIBAvypuuHevYG3YQz2wr7l708g6 pNp+jVJfwaAI1hz9RvYcbqfGzI2RugczsdCjJ88acFH02UjA+ZJLK+sRt1rCeWnDCeNesrR dXAEGAnDH+YyuFZBXOYbkkRiFVckws+MuKDcBeotTGB7Hhkt/+146QlrNeTwJREXb0Vuq4M P4Onooo2W44PZ4fG9b3LD0rNSg19xbf0LGl0IRpuSqOYu5pSHjle0ty63pBLjPKAo6HYn69 KKx2OJj38TtPNB3mtVD7MfX31zApl9hE8fzYRzulr2tmquFeQCaUxCdw6vH15bSwFH8bval skeNrlsDqGKD4P+Y9+X9qGGvIWmhg== X-QQ-GoodBg: 0 Date: Tue, 8 Feb 2022 18:09:00 +0800 From: "Di Ma" To: "Alberto Leiva" , sidrops References: X-Priority: 3 X-GUID: BCB30018-D68E-451A-90CD-440AC294CCF0 X-Has-Attach: no X-Mailer: Foxmail 7.2.23.116[cn] Mime-Version: 1.0 Message-ID: <202202081808595303458@juicybun.cn>+EF2B9598EC4EE51A Content-Type: multipart/alternative; boundary="----=_001_NextPart727432486318_=----" X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:juicybun.cn:qybgforeign:qybgforeign7 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [Sidrops] What should an RP do on different public key, same subject name? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2022 10:09:09 -0000 This is a multi-part message in MIME format. ------=_001_NextPart727432486318_=---- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 QWxiZXRvLA0KDQpHb29kIGNhdGNoIG9mIGluY29uc2lzdGVuY2Ugb2YgcmVxdWllbWVudHMgb24g c3ViamVjdCBuYW1lIG9mIFJQS0kgY2VydGlmaWNhdGUuDQoNCkFzIGZhciBhcyBJIGFtIGNvbmNl cm5lZCwgc3ViamVjdCBuYW1lIG9mIFJQS0kgY2VydGlmaWNhdGUgaXMgbm90IHVzZWQgZm9yIGlk ZW50aWZpY2F0aW9uLCB3aGljaCBpcyBkaWZmZXJlbnQgZnJvbSB0aG9zZSBpbiB3ZWIgUEtJLg0K DQpXaXRoIHRoaXMgdW5kZXJzdGFuZGluZywgRllJLCBSUFNUSVIyIGN1cnJlbnRseSBkb2VzIG5v dCBjaGVjayB0aGUgdW5pcXVlbmVzcyBvZiBzdWJqZWN0IG5hbWUgbmVpdGhlci4NCg0KRGkNCg0K IA0KRnJvbTogQWxiZXJ0byBMZWl2YQ0KRGF0ZTogMjAyMi0wMi0wOCAwNjo0OQ0KVG86IHNpZHJv cHMNClN1YmplY3Q6IFtTaWRyb3BzXSBXaGF0IHNob3VsZCBhbiBSUCBkbyBvbiBkaWZmZXJlbnQg cHVibGljIGtleSwgc2FtZSBzdWJqZWN0IG5hbWU/DQpIaS4gSSdtIG1haW50YWluaW5nIEZPUlQs IGFuIFJQIGltcGxlbWVudGF0aW9uLiBJIGZvdW5kIGEgdmFsaWRhdGlvbg0KRk9SVCBzZWVtcyB0 byBiZSBpbXBsZW1lbnRpbmcgaW5jb3JyZWN0bHksIGFuZCB0aGUgUkZDcyBhcmUgZ2l2aW5nIG1l DQp0cm91YmxlLiBDYW4gSSBoYXZlIHNvbWUgYWR2aWNlPw0KIA0KUkZDIDY0ODc6DQogDQo+IEVh Y2ggZGlzdGluY3Qgc3Vib3JkaW5hdGUgQ0EgYW5kDQo+IEVFIGNlcnRpZmllZCBieSB0aGUgaXNz dWVyIE1VU1QgYmUgaWRlbnRpZmllZCB1c2luZyBhIHN1YmplY3QgbmFtZQ0KPiB0aGF0IGlzIHVu aXF1ZSBwZXIgaXNzdWVyLiBJbiB0aGlzIGNvbnRleHQsICdkaXN0aW5jdCcgaXMgZGVmaW5lZCBh cw0KPiBhbiBlbnRpdHkgYW5kIGEgZ2l2ZW4gcHVibGljIGtleS4NCiANCkJpdCBhd2t3YXJkIGZv ciBteSB0YXN0ZS4gUmVtb3Zpbmcgc29tZSByZWR1bmRhbmN5Og0KIA0KPiBFYWNoIGRpc3RpbmN0 IHN1Ym9yZGluYXRlIENBIGFuZCBFRSBjZXJ0aWZpZWQgYnkgdGhlIGlzc3VlciBNVVNUIGhhdmUN Cj4gYSB1bmlxdWUgc3ViamVjdCBuYW1lLiBJbiB0aGlzIGNvbnRleHQsICdkaXN0aW5jdCcgaXMg ZGVmaW5lZCBhcyBhbg0KPiBlbnRpdHkgYW5kIGEgZ2l2ZW4gcHVibGljIGtleS4NCiANClRyaW1t aW5nIGZhdDoNCiANCj4gRWFjaCBkaXN0aW5jdCBjaGlsZCBjZXJ0aWZpZWQgYnkgdGhlIGlzc3Vl ciBNVVNUIGhhdmUgYSB1bmlxdWUNCj4gc3ViamVjdCBuYW1lLiBJbiB0aGlzIGNvbnRleHQsICdk aXN0aW5jdCcgaXMgZGVmaW5lZCBhcyBhbiBlbnRpdHkgYW5kDQo+IGEgZ2l2ZW4gcHVibGljIGtl eS4NCiANClRyYW5zbGF0aW9uOg0KIA0KPiBTaWJsaW5nIGNlcnRpZmljYXRlcyBNVVNUIGhhdmUg ZGlmZmVyZW50IHN1YmplY3QgbmFtZXMuIEFtb25nIGENCj4gcGFyZW50J3MgY2hpbGRyZW4sIHNp YmxpbmdzIGFyZSBpZGVudGlmaWVkIGJ5IHRoZWlyIFtlbnRpdHksIHB1YmxpYw0KPiBrZXldIHR1 cGxlLg0KIA0KKCJFbnRpdHkiIGlzIHNlZW1pbmdseSBub3QgZGVmaW5lZCBieSBhbnkgcmVsZXZh bnQgZ2xvc3NhcmllcyBbaWYNCnlvdSdyZSBnb2luZyB0byB1cGRhdGUgdGhlc2UgZG9jdW1lbnRz IGF0IHNvbWUgcG9pbnQsIG1pZ2h0IEkgc3VnZ2VzdA0KdGhpcyBnZXRzIGZpeGVkXSwgYnV0IGZy b20gUkZDIDY0ODQsIHdlIGNhbiBzdXJtaXNlIGl0IG1lYW5zICJJTlINCkhvbGRlci4iKQ0KIA0K VGhlIHJlcXVpcmVtZW50IGlzIGtpbmQgb2YgY2lyY3VsYXIgYmVjYXVzZSBhbiBlbnRpdHkgd291 bGQgbm9ybWFsbHkNCmJlIGlkZW50aWZpZWQgYnkgaXRzIHBhcmVudCBjZXJ0aWZpY2F0ZSBhbmQg c3ViamVjdCBuYW1lLi4uIHJpZ2h0PyBIb3cNCmVsc2Ugd291bGQgYW4gUlBLSSBjb25zdW1lciBp ZGVudGlmeSB0aGUgZW50aXR5Pw0KIA0KRWR1Y2F0ZWQgZ3Vlc3M6DQogDQo+IFNpYmxpbmcgY2Vy dGlmaWNhdGVzIE1VU1QgaGF2ZSBkaWZmZXJlbnQgc3ViamVjdCBuYW1lcy4gQW1vbmcgYQ0KPiBw YXJlbnQncyBjaGlsZHJlbiwgc2libGluZ3MgYXJlIGlkZW50aWZpZWQgYnkgdGhlaXIgW3BhcmVu dCwgc3ViamVjdA0KPiBuYW1lLCBwdWJsaWMga2V5XSB0dXBsZS4NCiANCkdpdmVuIHRoYXQgd2Un dmUgZXN0YWJsaXNoZWQgdGhhdCB3ZSdyZSB0YWxraW5nIGFib3V0IHNpYmxpbmdzLCB0aGUNCnBh cmVudCBpcyBhbHdheXMgdGhlIHNhbWUsIHNvIGl0IGJlY29tZXMNCiANCj4gU2libGluZyBjZXJ0 aWZpY2F0ZXMgTVVTVCBoYXZlIGRpZmZlcmVudCBzdWJqZWN0IG5hbWVzLiBBbW9uZyBhDQo+IHBh cmVudCdzIGNoaWxkcmVuLCBzaWJsaW5ncyBhcmUgaWRlbnRpZmllZCBieSB0aGVpciBbc3ViamVj dCBuYW1lLA0KPiBwdWJsaWMga2V5XSB0dXBsZS4NCiANCkNpcmN1bGFyIGJlY2F1c2Ugb2YgdGhl IGRvdWJsZSAic3ViamVjdCBuYW1lIjoNCiANCj4gR2l2ZW4gdHdvIHNpYmxpbmdzLCBpZiB0aGVp ciBbc3ViamVjdCBuYW1lLCBwdWJsaWMga2V5XSBpcyBkaWZmZXJlbnQsDQo+IHRoZW4gdGhlaXIg c3ViamVjdCBuYW1lcyBNVVNUIGFsc28gYmUgZGlmZmVyZW50Lg0KIA0KSW4gb3RoZXIgd29yZHMs IGdpdmVuIHNpYmxpbmcgY2VydGlmaWNhdGVzIEEgYW5kIEIsIHN1YmplY3QgbmFtZXMgYQ0KYW5k IGIsIHB1YmxpYyBrZXlzIG0gYW5kIG4sIGEgIT0gYiBhbmQgbSAhPSBuLCB0aGVuDQogDQotIElm IEEgPSBbYSwgbV0gYW5kIEIgPSBbYSwgbV0sIHRoZW4gbm8gY29uc3RyYWludHMgbXVzdCBiZSBp bXBvc2VkLiAoQSA9IEIpDQotIElmIEEgPSBbYSwgbV0gYW5kIEIgPSBbYSwgbl0sIHRoZW4gYSAh PSBhLiBUaGlzIG1ha2VzIG5vIHNlbnNlLCBhbmQNCmlzIHRodXMgaWxsZWdhbC4NCi0gSWYgQSA9 IFthLCBtXSBhbmQgQiA9IFtiLCBtXSwgdGhlbiBhICE9IGIuIFNlbGYtZXZpZGVudC4NCi0gSWYg QSA9IFthLCBtXSBhbmQgQiA9IFtiLCBuXSwgdGhlbiBhICE9IGIuIFNlbGYtZXZpZGVudC4NCiAN ClNvLi4uIGFzc3VtaW5nIG15IHNldmVyYWwgZmxpZ2h0cyBvZiBmYW5jeSBoYXZlIHNvIGZhciBi ZWVuIGNvcnJlY3QsDQp0aGUgcmVxdWlyZW1lbnQgY2FuIGJlIHJlZHVjZWQgdG8NCiANCj4gSWYg dHdvIHNpYmxpbmcgY2VydGlmaWNhdGVzIGhhdmUgZGlmZmVyZW50IHB1YmxpYyBrZXlzLCB0aGVu IHRoZXkNCj4gTVVTVCBoYXZlIGRpZmZlcmVudCBzdWJqZWN0IG5hbWVzIGFzIHdlbGwuDQogDQpp ZS4gdGhpcyB3aG9sZSBtZXNzIGlzIGp1c3QgYSByZXdvcmQgb2YgdGhlIChpbmZpbml0ZWx5IG1v cmUNCmNvbWZvcnRhYmx5IGFydGljdWxhdGVkKSBpbW1lZGlhdGVseSBmb2xsb3dpbmcgUkZDIDY0 ODcgc2VudGVuY2U6DQogDQo+IEFuIGlzc3VlciBTSE9VTEQgdXNlIGEgZGlmZmVyZW50IHN1Ympl Y3QgbmFtZSBpZiB0aGUgc3ViamVjdCdzIGtleQ0KPiBwYWlyIGhhcyBjaGFuZ2VkIChpLmUuLCB3 aGVuIHRoZSBDQSBpc3N1ZXMgYSBjZXJ0aWZpY2F0ZSBhcyBwYXJ0IG9mDQo+IHJlLWtleWluZyB0 aGUgc3ViamVjdC4pDQogDQpFeGNlcHQuLi4gdGhlIHR3byByZXF1aXJlbWVudHMgYXJlIGFjdHVh bGx5IGNvbnRyYWRpY3RpbmcgZWFjaCBvdGhlcjoNClRoZSBmb3JtZXIgaXMgZGVmaW5lZCBhcyBh IE1VU1QgYW5kIHRoZSBsYXR0ZXIgaXMgYSBTSE9VTEQuDQogDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiANCk9rLiBUaGF0IGVzdGFibGlzaGVkLCBoZXJlJ3MgdGhlIHBvaW50Og0K IA0KV291bGQgaXQgYmUgcmVhc29uYWJsZSBmb3IgYW4gUlAgaW1wbGVtZW50YXRpb24gdG8gdHJp bSBicmFuY2hlcyBvZmYNCnRoZSB0cmVlIGlmIHRoZXkgdmlvbGF0ZSB0aGUgYWJvdmUgcnVsZT8N ClRoZSBwb2ludCBvZiB0aGlzIHJ1bGUgaXMgdG8gcHJldmVudCBicm9rZW4ga2V5IHJvbGxvdmVy cy4uLiByaWdodD8gSQ0KdGhpbms/IFNvLCBpcyBhIGJhZCBrZXkgcm9sbG92ZXIgZ3JvdW5kcyB0 byBjaG9wIHBpZWNlcyBvZmYgdGhlDQpJbnRlcm5ldD8NCkRvZXMgdGhpcyByZXF1aXJlbWVudCBl eGlzdCB0byBzb21laG93IHNpbXBsaWZ5IHRoZSB3b3JrIG9mIFJQcywgb3IgdG8NCmJlIGVuZm9y Y2VkIGJ5IFJQcz8gQXJlIFJQcyBzdXBwb3NlZCB0byBjYXJlPw0KIA0KSSdtIHRoaW5raW5nIGFi b3V0IGR1bXBpbmcgYSB3YXJuaW5nIG9uIHN5c2xvZyBhbmQga2VlcCBnb2luZywgYnV0IEknbQ0K bm90IHN1cmUgdGhlcmUnZCBiZSBhIHBvaW50IHRvIGl0Lg0KIA0KKEFuZCB3aGljaCBpcyBpdD8g TVVTVCBvciBTSE9VTEQ/KQ0KIA0KVGhhbmtzIGluIGFkdmFuY2UsDQpBbGJlcnRvDQogDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU2lkcm9wcyBtYWls aW5nIGxpc3QNClNpZHJvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lkcm9wcw0KIA0K ------=_001_NextPart727432486318_=---- Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks:

 

A working group last call has been issued for draft-ietf-sidrops-roa- considerations-01, =93Problem Statement and Considerations for ROA containing Multiple Prefixes=94. Please reply t= o the list with your comments. The&nb= sp;WGLC will end o= n March 10th, 2022.

 =

The draft can be found at: https://datatracker.ietf.org/doc/dra= ft-ietf-sidrops-roa-considerations/.=

 =

Regards,

Nathalie, Chris & Keyur

 

 

--_000_BYAPR18MB26961DE9F15501CCA12ECCF1C13D9BYAPR18MB2696namp_-- From nobody Thu Feb 24 15:53:38 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A253A0945 for ; Thu, 24 Feb 2022 15:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.026 X-Spam-Level: X-Spam-Status: No, score=-3.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.351, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 K3veT3uCJGB2 for ; Thu, 24 Feb 2022 15:53:30 -0800 (PST) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on20710.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d04::710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FB23A0822 for ; Thu, 24 Feb 2022 15:53:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UV+MvXDNLZYJntetWQjs3JGqcWgMceq2FD5GP57+G5Be0FwpKGyJ11YNYuT9B6fghOQiSWdCoH/uFEyW1rY6QSxZ91B0EBCJBES/1smTXgDf6lR/c0Msr/UqFgOVhFWE+gHcQjTUjGJbM7bpsMGQf7pu/Mnq/6rfwMwILi0ctopvdJHiTcjjTxCTnRMPBD5Pr7mZpEcTT29nYwUxczBgdxF7Cu6oSG0F5O7nLI85Muj2AgwXoUJy/4TdJjgfPN6YyNTb6QhBv8GqsKJRq2gxqai31UvXV/lG1yaQSPDXDF5WbzOmeSbBRozXsKXM9FKMz22QOpA3wkrGTl2J8gSzxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dJQb/PwfOa8Kh22XDZGalFSBhjXo4vLaYm83WHITW2s=; b=Gv5KoJE+w7EGJW1IHxtaWWl23F33HpFXWDz1Nv/uKlWGZll/kfSKewKmrXVbgfjLh4gD1/63lFC5MyeAarKozPDuJGgRs9/HQNwsALuAODHmdz4eUdqBPj75L6ETqIdksJHIdsX+iui11oI2MCe9j4U/DlIQ1aW/nxabtJLRgQ1ig/Vp9yVeNapkq9vNvXie41DU0oFqKEKrbqX5GmSmRRqkpHolMRHEk7XdacZxyQzgXRmWcF9xlCKZwJhHl4fdbD8bw4JpHWM9HEhPzOnvQEpLVA+8blbbQg8539fDs2G7ieAa9VK4N5/2QR7xAfqDEzriardLJ9YBQinZFmEGqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dJQb/PwfOa8Kh22XDZGalFSBhjXo4vLaYm83WHITW2s=; b=nBpBFvLERbvk5pXzS8RF3dUeeyUM6LMyyaD9h2Jxd2jrHSTmoWVusCxpZiYuk+UXJxTlk6PZ8KVypLzihxUE7sf6+pg6CT/+hEbwhtfNo6wlwhezpfIbA9md5f8AwnyhvnIZVel3nQnkIRmszBmTDzjN2sj7JCaAxa27fsVh9E4= Received: from DM8PR09MB6294.namprd09.prod.outlook.com (2603:10b6:5:2e7::20) by DM8PR09MB7157.namprd09.prod.outlook.com (2603:10b6:5:2ef::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22; Thu, 24 Feb 2022 23:53:25 +0000 Received: from DM8PR09MB6294.namprd09.prod.outlook.com ([fe80::54cd:466f:98b6:49e6]) by DM8PR09MB6294.namprd09.prod.outlook.com ([fe80::54cd:466f:98b6:49e6%5]) with mapi id 15.20.4995.027; Thu, 24 Feb 2022 23:53:25 +0000 From: "Montgomery, Douglas C. (Fed)" To: Tim Bruijnzeels , Job Snijders CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] [routing-wg] misconceptions about ROV Thread-Index: AQHYJ4Vl6XzI7P0aSEeIDkLJO3o9JayexX2AgAB7eACAAALMAIAAB8OAgAAYuoCAAA5HgIAAfxmAgAAoMICAAC7LAIAAgrYAgABHDQCAABUpAIABO0gAgAAMnYCAAOoVFQ== Date: Thu, 24 Feb 2022 23:53:25 +0000 Message-ID: References: <015C9C28-4230-40D8-A9F2-7420B726C00F@juicybun.cn> <949277FD-27AF-40E8-B557-AA58C62BFEA7@apnic.net> <6D314C7A-8CEC-4B9B-8F80-6B1AC48037E2@nlnetlabs.nl> <85D947F4-E2A4-4FFE-86AF-2D129C49FB9C@psg.com> <8413F0CA-F50A-42B7-B0DA-19A0A90ABE6F@nlnetlabs.nl> <60B6D863-047D-40A6-80DD-95C05391A0BA@nlnetlabs.nl> In-Reply-To: <60B6D863-047D-40A6-80DD-95C05391A0BA@nlnetlabs.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nist.gov; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2a463b35-1010-4644-66a7-08d9f7f0d939 x-ms-traffictypediagnostic: DM8PR09MB7157:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SCUv0NerkWzCZrt+3Nz/XdA7T0Fd83jcX61FBVXJEFzt/YNZShB1OBjbLyxvc6dGcRcuET1XvypapEdVpREe50WF0Rca3qaUgrzz65tbaK/FaLNRlzGfP6GNgCff/qOvHCSNgj+J9SGm2PCWDNsD4+kxl77lwhPwtf8Npz8EV3OGnV58Lj6w0yhLm3NkOBCaCDZNOUIT2UNMUn650rKN9qqmv/AkQfv4L3QjRu4op9oE1Wfub6M5MpGyWjGZgQtr3es0xToI1QDm6oyDzTZvPYYnYn78p3cmi4OXTuoOeIDhtbH7X2xPalcoMPiEEr71qPSesUmfxnLeN6Yf6Dc3lRqitlWWsnTtgeR4uAUbhf1Sn/EFdDaLYGMyDG46Vt8lrOLa9fZ8e6QteQvF6PO4no+Gy49THPOwzlMIBV5mu04SW4PmExYIu2c2VMrg47/Zi+6iUB6TySof1UecAWQy8ZNKQq+il/jpZnlVa4z9NQY3NB6omkNuCyQdFBSWidxCE39dR4Xp7JqUDtjQ42lALzUqgGvkX3R4Smabu6xS0/rnLNsXRd8A7j0/HpwGfLpWiw8f4aFmIFZT+0GCn2PWVccZTmywBjmZvscRNMMaD25VNLYSDYMUXhqOtnIWlT1GODqodixZ0RWCd+UqURSXIhbMRI+0JDJMCYukzFCl65BNlOI48l2e2DNGu90IQz003TiL9yADFUfODi0SmbyoIfxkTBPQ2g0+S2C8w5YR2zk3KnQq9bg1cRlvsv89T4yoM3rtcGNMA2PVZVLU+Z1ueP1XC1KYG7UyFapGrJEBKoY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8PR09MB6294.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(38070700005)(186003)(66574015)(8936002)(30864003)(52536014)(83380400001)(82960400001)(2906002)(5660300002)(8676002)(45080400002)(91956017)(4326008)(66476007)(66446008)(64756008)(66946007)(33656002)(66556008)(76116006)(9686003)(966005)(6506007)(7696005)(508600001)(53546011)(71200400001)(38100700002)(166002)(122000001)(86362001)(55016003)(110136005)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?PFnjtup80nSGB8oEbd0HWBU3UlNrLe5qjepRzBVE8HLSy4UX9RsnIhGj?= =?Windows-1252?Q?oSpbD+n8YsdpYAi9M1+bjBvkhHG/idQLmhcySsxs7/ivXMbqE4Adu3jv?= =?Windows-1252?Q?32Or19z+AwSyZmEeOslDgwYLc9DTBZZwqshjRvGgKxJk39jctmXmyoLp?= =?Windows-1252?Q?HFkpUXkpFhS5u4ljDKkskL8uA4TQzMEuXpo8mEVFsOd1L761r1bsshCr?= =?Windows-1252?Q?U6ugmKHKGZVAqAxxFAi3yxflnAmfJKlL6UfY7gffCStxlAOY29FGLFV9?= =?Windows-1252?Q?IlIIlAfdhWwPaZptcgpH+NNIR4bpBt1n4FM13pJLhzBY5ZU3X5hK36pq?= =?Windows-1252?Q?ngHeJaJ4rtd2IfLf71kW80mStVy/qFRWwVWsu0cyfYACMdrebzZcPVUh?= =?Windows-1252?Q?OyGED2Pfd0hh6GGR1e3l1VB4AHtxZ85w5kDZ5uT73gG9lYDdhJqWqbkH?= =?Windows-1252?Q?X+cJZAOlDgiw9+bNAa3bpJTjvgW/YyFPcw6YHKXGDuW7RFc8Gx64/zHy?= =?Windows-1252?Q?V7FIZuYH3OWynHshdmdOpY/TGJtdzMNEW4Da1i5kkIRdq5DBstAKgD3L?= =?Windows-1252?Q?gHRaDhxUIcwGAh1pTYcpYqhJAwsW1dvHe10lseYVPhxYJZwM3pl1FJUL?= =?Windows-1252?Q?r++tjP4z3uFgkWKXPnUmxm2RHF/t49h3WwGh6sMi9YaC6JMKJfDolggP?= =?Windows-1252?Q?wB8nLUdGDmmvIewWT9Ctp+RFL6XZfvh94p9nEZDu7LLigLZJSdnPDhw5?= =?Windows-1252?Q?oKebnCgpgm4+QBp/DadHVO6f2X6HQ2AM5G8manJPFx4VqW8gn9Xgf7/u?= =?Windows-1252?Q?JqBoROLMHARqy8Z7phH5bb6y0dYo9++vNbym8VdtLWkz6U6bswBDZRnH?= =?Windows-1252?Q?bxOO5mFxiQcqra/sUW8GwG0Iw6dCfl/PmlJKFdjYcP66t8Xb2gmLrCFm?= =?Windows-1252?Q?E3EMuwGAFtJ1vFbetquTJdSOxvD7HEFlQa2wCN2FMvvPwPsHO9SEco4N?= =?Windows-1252?Q?M+AnMWlvYadROBgETv6wnmxXBHzjPY8Cc3QjEtD+lC8GXzhjOIzXIhbY?= =?Windows-1252?Q?OR97HnW59HuNcAMoyibd2xEwkgopJ2dqyVduoTaWRv13KiS3WkcyHQ2n?= =?Windows-1252?Q?qh1dct34PLXkB+sheQx4xdkGHDNJZb9/dykUE4V6x984MgKyXpfws/DK?= =?Windows-1252?Q?6gJcYCIUoCV9gH6uYvAz4jHwBDpcTAbWO9xF6Emxk28NKLAHlU4ZPRZk?= =?Windows-1252?Q?vPbL7EZIfI1YqTLIzGlzCVxY8YsYjYV278zuqasjxqFep0W/3jbaqhUh?= =?Windows-1252?Q?58CfDyIWYmKAAT5oO44bXWFE6d/ra37xxBWT1hqHOtFkYRFxFyfvmgul?= =?Windows-1252?Q?Q0CzQMFy9VGA40atzOAUn9ES5IfBG018WYdjeeVULQM8igXz5P1a3CTA?= =?Windows-1252?Q?W1Ai2VNB3DaUw2HCtnUiAHwe7gigWMbWrLbO6tEfdnA=3D?= Content-Type: multipart/alternative; boundary="_000_DM8PR09MB6294D4538DAA3C3094F0E661DE3D9DM8PR09MB6294namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8PR09MB6294.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a463b35-1010-4644-66a7-08d9f7f0d939 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2022 23:53:25.7327 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR09MB7157 Archived-At: Subject: Re: [Sidrops] [routing-wg] misconceptions about ROV X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 23:53:36 -0000 --_000_DM8PR09MB6294D4538DAA3C3094F0E661DE3D9DM8PR09MB6294namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable For what it is worth, I have long thought the ability to indicate, in a glo= bally accessible system, that BGPSec is being used on a given logical peeri= ng between two ASes is the only way address the down-grade attack on BGPsec= as currently specified and would increase the utility of BGPsec over multi= hop paths. I agree with Tim=92s point, as I understood it, that this information can= =92t just be local to a peering session, as I need to know if I received an= unsigned (BGP4 PATH) that appears to come from a sequence of ASes that all= stated that they were doing BGPsec with each other. I get Job=92s (I think) point that a simple mechanism at the AS level can= =92t deal with the scenario where I do BGPsec on some peering=92s with my n= eighbor but not on others with the same neighbor. Given that distinct peer= ing sessions between the same peers are not visible in BGP downstream of th= e ASes in question, there is not much to do about this other than wait unti= l all peering sessions between a given pair of ASes enable BGPsec. The utility of any optional security mechanism is significantly increased b= y having secure out of band mechanism to signal that it is operationally en= abled for use. Actually, in my mind DMARC is a useful general model becau= se you can both signal you are using a security mechanism, suggest how rece= ivers should treat failures, and provide a notification channel to send bac= k info on failures. The latter two allowing you to pilot the security mech= anism (policy=3Dmonitor) before you signal policy=3Dreject. We seem to create many security mechanisms (e.g., BGPsec, ROAs, MUD profile= s, etc) that don=92t have a safe means for individual users to globally tes= t/pilot them before going into production mode. That increases the risk/ba= rrier to entry to those who wish to enable the technologies. dougm -- DougM @ NIST From: Sidrops on behalf of Tim Bruijnzeels Date: Thursday, February 24, 2022 at 4:19 AM To: Job Snijders Cc: sidrops@ietf.org Subject: Re: [Sidrops] [routing-wg] misconceptions about ROV Hello Job, others > On 24 Feb 2022, at 09:31, Job Snijders wrote: > > Hello Tim, others, > >> What I meant here by "accept... on islands" is that the operator would >> have to know - somehow - where to enable BGPSec validation. >> >> I believe that the idea was that this would be done on a BGP session >> basis. E.g. providers would insist on BGPSec from customers, or peers >> between each other etc. > > "In order to indicate that a BGP speaker is willing to send BGPsec > UPDATE messages (for a particular address family), a BGP speaker > sends the BGPsec capability" > source: https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8205%23section-2.2&data=3D04%= 7C01%7Cdougm%40nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa47= 97a93e054655c61dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJ= WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&= sdata=3D1BEYOsez4uQzGJ8gu0rkKKHrBS%2BXYtvGWwLEU0V7VFU%3D&reserved=3D0 > > Indeed, it is an operator choice whether to enable BGPsec or not, and it > is choosen per-session. Luckily most large operators have automated the > provisioning of BGP sessions. > >> I wondered if (new) signed statements in the RPKI could be used to >> conclude that ASNs have pledged to use BGP Sec when possible. I.e. >> such ASNs would sign a path if they are the origin / or if the receive >> a signed path. >> >> The receiving router could then conclude that IFF all ASNs in a path >> had made these signed statements - BGPSec validation on *that* path >> could be performed. It would be an error if signatures were missing or >> invalid. >> >> This way operators would not have to enable this manually on a per >> session basis, and because it would be based on signed validated >> statements they could trust that it would be safe to apply for ASNs >> who issued those statements - without the need to know these ASNs >> first hand - e.g. across transit. >> >> It would still allow for path spoofing and signature removal by >> injecting an ASN that did not sign a statement that they would do >> BGPSec. However, the options would become more limited as more ASNs >> participate - and ASPA validation would further limit the available >> choices. >> >> As for how an ASN could sign such a statement.. one could overload >> existing router certificates but I think that is probably a bad idea - >> it could very well lead to timing issues when adopting. An alternative >> could be to have a new separate signed object for this, which would >> allow that BGPSec is tested first, before letting the world know. >> >> Just an idea.. hoping it might help. > > I am not sure it is helpful at this stage. > > It seems you overlook some deployment aspects, for example: within a > given Autonomous System (during the incremental deployment of BGPsec - > which may take years) there will be ASBRs that support BGPsec and ASBRs > that are unable to negotiate support for BGPsec. For example, it is > entirely possible that at a given moment in time only half the > adjacencies for 206238_15562$ are BGPsec capable, and half are not (yet). Not at all - any adjacencies that are not BGPSec capable would not issue any statement that they are capable. So stripping the signatures there would be entirely expected. I am talking about something else: signalling deployment beyond direct sessions in order to enable detection of downgrade attacks. If router can detect that the *entire* path is not only capable but also committed to do BGPSec then removal of signatures can be flagged as an attack. > See this posting for a similar story on RPKI ROV invalids: > https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmailm= an.nanog.org%2Fpipermail%2Fnanog%2F2021-April%2F213346.html&data=3D04%7= C01%7Cdougm%40nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa479= 7a93e054655c61dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJW= IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s= data=3DTom4cL9nHEw9PVbNGH21p2RkeTdcvo6xdxj57F2sjOQ%3D&reserved=3D0 > > Frankly speaking, wouldn't it make far more sense to implement the > specifications AS SPECIFIED AND PEER-REVIEWED BY MANY PEOPLE, > *before* advocating new object profiles? > > Especially since the CA side of BGPsec is so straight-forward and > simple to implement ... ? There is no need to shout Job.. I was trying to have a discussion about a possible way to help operational future deployment. This is in no way preventing the development and deployment of current standards. And should the idea be useful and accepted then of course it would be handled as a WG document, be peer-reviewed etc. I know - it's naive to think that that would be what the IETF is for. Fine. I will stop here. Discussion once again seems entirely pointless. > > Regards, > > Job > > ps. Since you asked, here are required reading materials: > > BGPsec Protocol Specification > https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8205&data=3D04%7C01%7Cdougm%40= nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61= dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D6ruh6AJ= PkmReg%2BEt5Yh9A7G6KrQJvlpzqXZ%2B%2B%2B9xLvw%3D&reserved=3D0 > > BGPsec Considerations for Autonomous System (AS) Migration > https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8206&data=3D04%7C01%7Cdougm%40= nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61= dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3Dc0Kh9Yd= XBICdNgVhka9zVtRMTWgyfjDnwXduHcR6c%2Bc%3D&reserved=3D0 > > BGPsec Operational Considerations > https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8207&data=3D04%7C01%7Cdougm%40= nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61= dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D%2F2AQr= HIqzvReQ0spKjNnMmRNFvmFpfSJayFvDrWDA5c%3D&reserved=3D0 > > BGPsec Algorithms, Key Formats, and Signature Formats > https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8208&data=3D04%7C01%7Cdougm%40= nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61= dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DRH8GcLn= RFf3CafW8%2FTFkaH936M3nE3%2BFlnZVY0IPo7c%3D&reserved=3D0 > > BGPsec Design Choices and Summary of Supporting Discussions > https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8374&data=3D04%7C01%7Cdougm%40= nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61= dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DamNinyr= ayWu0Skqw5TFepEpjS0mKQT6WAiDWuzawuVA%3D&reserved=3D0 > > Router Keying for BGPsec > https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8635&data=3D04%7C01%7Cdougm%40= nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61= dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DAQfk6fm= JvWo1lQPeFjqU61n8n0MWw%2BRjM%2Fun5R9UOpA%3D&reserved=3D0 Thank you Job - somehow I managed to find these documents myself. I did not ask about these. I asked about the downgrade issue. Randy was kind enough to answer. Tim > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fsidrops&data=3D04%7C01%7Cdougm%40nist.go= v%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7C1= %7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI= joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DGx6OU7d8kL0qGc= OyNcap%2FMppIWDaq82xlIKdwiDiGsE%3D&reserved=3D0 _______________________________________________ Sidrops mailing list Sidrops@ietf.org https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fsidrops&data=3D04%7C01%7Cdougm%40nist.gov%= 7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7= C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo= iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DGx6OU7d8kL0qGcOy= Ncap%2FMppIWDaq82xlIKdwiDiGsE%3D&reserved=3D0 --_000_DM8PR09MB6294D4538DAA3C3094F0E661DE3D9DM8PR09MB6294namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

For what it is worth, I have long thought the ability to indicate, in a gl= obally accessible system, that BGPSec is being used on a given logical peer= ing between two ASes is the only way address the down-grade attack on BGPsec as currently specified and would i= ncrease the utility of BGPsec over multi hop paths.

 

I agree with Tim=92s point, as I understood it, that this information can= =92t just be local to a peering session, as I need to know if I received an= unsigned (BGP4 PATH) that appears to come from a sequence of ASes that all stated that they were doing BGPsec with e= ach other.

 

I get Job=92s (I think) point that a simple mechanism at the AS level can= =92t deal with the scenario where I do BGPsec on some peering=92s with my n= eighbor but not on others with the same neighbor.  Given that distinct peering sessions between the same peers are not visibl= e in BGP downstream of the ASes in question, there is not much to do about = this other than wait until all peering sessions between a given pair of ASe= s enable BGPsec.

 

The utility of any optional security mechanism is significantly increased = by having secure out of band mechanism to signal that it is operationally e= nabled for use.   Actually, in my mind DMARC is a useful general model because you can both signal you are using = a security mechanism, suggest how receivers should treat failures, and prov= ide a notification channel to send back info on failures.  The latter = two allowing you to pilot the security mechanism (policy=3Dmonitor) before you signal policy=3Dreject.=

 

We seem to create many security mechanisms (e.g., BGPsec, ROAs, MUD profil= es, etc) that don=92t have a safe means for individual users to globally te= st/pilot them before going into production mode.  That increases the risk/barrier to entry to those who wish to = enable the technologies.

 

dougm

--

DougM @ NIST

 

 

From: Sidrops <sidrops= -bounces@ietf.org> on behalf of Tim Bruijnzeels <tim@nlnetlabs.nl>=
Date: Thursday, February 24, 2022 at 4:19 AM
To: Job Snijders <job=3D40fastly.com@dmarc.ietf.org>
Cc: sidrops@ietf.org <sidrops@ietf.org>
Subject: Re: [Sidrops] [routing-wg] misconceptions about ROV

Hello Job, others
> On 24 Feb 2022, at 09:31, Job Snijders <job=3D40fastly.com@dmarc.ie= tf.org> wrote:
>
> Hello Tim, others,
>
>> What I meant here by "accept... on islands" is that the = operator would
>> have to know - somehow - where to enable BGPSec validation.
>>
>> I believe that the idea was that this would be done on a BGP sessi= on
>> basis. E.g. providers would insist on BGPSec from customers, or pe= ers
>> between each other etc.
>
> "In order to indicate that a BGP speaker is willing to send BGPse= c
> UPDATE messages (for a particular address family), a BGP speaker
> sends the BGPsec capability"
> source: https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Frfc8205%23section-2.2&amp;data=3D04%7C01%7= Cdougm%40nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e= 054655c61dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM= C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sd= ata=3D1BEYOsez4uQzGJ8gu0rkKKHrBS%2BXYtvGWwLEU0V7VFU%3D&amp;reserved=3D0=
>
> Indeed, it is an operator choice whether to enable BGPsec or not, and = it
> is choosen per-session. Luckily most large operators have automated th= e
> provisioning of BGP sessions.
>
>> I wondered if (new) signed statements in the RPKI could be used to=
>> conclude that ASNs have pledged to use BGP Sec when possible. I.e.=
>> such ASNs would sign a path if they are the origin / or if the rec= eive
>> a signed path.
>>
>> The receiving router could then conclude that IFF all ASNs in a pa= th
>> had made these signed statements - BGPSec validation on *that* pat= h
>> could be performed. It would be an error if signatures were missin= g or
>> invalid.
>>
>> This way operators would not have to enable this manually on a per=
>> session basis, and because it would be based on signed validated >> statements they could trust that it would be safe to apply for ASN= s
>> who issued those statements - without the need to know these ASNs<= br> >> first hand - e.g. across transit.
>>
>> It would still allow for path spoofing and signature removal by >> injecting an ASN that did not sign a statement that they would do<= br> >> BGPSec. However, the options would become more limited as more ASN= s
>> participate - and ASPA validation would further limit the availabl= e
>> choices.
>>
>> As for how an ASN could sign such a statement.. one could overload=
>> existing router certificates but I think that is probably a bad id= ea -
>> it could very well lead to timing issues when adopting. An alterna= tive
>> could be to have a new separate signed object for this, which woul= d
>> allow that BGPSec is tested first, before letting the world know.<= br> >>
>> Just an idea.. hoping it might help.
>
> I am not sure it is helpful at this stage.
>
> It seems you overlook some deployment aspects, for example: within a > given Autonomous System (during the incremental deployment of BGPsec -=
> which may take years) there will be ASBRs that support BGPsec and ASBR= s
> that are unable to negotiate support for BGPsec. For example, it is > entirely possible that at a given moment in time only half the
> adjacencies for 206238_15562$ are BGPsec capable, and half are not (ye= t).

Not at all - any adjacencies that are not BGPSec capable would not issue any statement that they are capable. So stripping the signatures there
would be entirely expected.

I am talking about something else: signalling deployment beyond direct
sessions in order to enable detection of downgrade attacks. If router
can detect that the *entire* path is not only capable but also committed to do BGPSec then removal of signatures can be flagged as an attack.

> See this posting for a similar story on RPKI ROV invalids:
> https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmailman= .nanog.org%2Fpipermail%2Fnanog%2F2021-April%2F213346.html&amp;data=3D04= %7C01%7Cdougm%40nist.gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4= 797a93e054655c61dec%7C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8ey= JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&= ;amp;sdata=3DTom4cL9nHEw9PVbNGH21p2RkeTdcvo6xdxj57F2sjOQ%3D&amp;reserve= d=3D0
>
> Frankly speaking, wouldn't it make far more sense to implement the
> specifications AS SPECIFIED AND PEER-REVIEWED BY MANY PEOPLE,
> *before* advocating new object profiles?
>
> Especially since the CA side of BGPsec is so straight-forward and
> simple to implement ... ?

There is no need to shout Job..

I was trying to have a discussion about a possible way to help
operational future deployment. This is in no way preventing the
development and deployment of current standards. And should the
idea be useful and accepted then of course it would be handled
as a WG document, be peer-reviewed etc.

I know - it's naive to think that that would be what the IETF
is for. Fine. I will stop here. Discussion once again seems
entirely pointless.

>
> Regards,
>
> Job
>
> ps. Since you asked, here are required reading materials:
>
> BGPsec Protocol Specification
>        https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Frfc8205&amp;data=3D04%7C01%7Cdougm%40nist.= gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7= C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3D6ruh6AJP= kmReg%2BEt5Yh9A7G6KrQJvlpzqXZ%2B%2B%2B9xLvw%3D&amp;reserved=3D0
>
> BGPsec Considerations for Autonomous System (AS) Migration
>        https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Frfc8206&amp;data=3D04%7C01%7Cdougm%40nist.= gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7= C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3Dc0Kh9YdX= BICdNgVhka9zVtRMTWgyfjDnwXduHcR6c%2Bc%3D&amp;reserved=3D0
>
> BGPsec Operational Considerations
>        https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Frfc8207&amp;data=3D04%7C01%7Cdougm%40nist.= gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7= C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3D%2F2AQrH= IqzvReQ0spKjNnMmRNFvmFpfSJayFvDrWDA5c%3D&amp;reserved=3D0
>
> BGPsec Algorithms, Key Formats, and Signature Formats
>        https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Frfc8208&amp;data=3D04%7C01%7Cdougm%40nist.= gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7= C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3DRH8GcLnR= Ff3CafW8%2FTFkaH936M3nE3%2BFlnZVY0IPo7c%3D&amp;reserved=3D0
>
> BGPsec Design Choices and Summary of Supporting Discussions
>        https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Frfc8374&amp;data=3D04%7C01%7Cdougm%40nist.= gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7= C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3DamNinyra= yWu0Skqw5TFepEpjS0mKQT6WAiDWuzawuVA%3D&amp;reserved=3D0
>
> Router Keying for BGPsec
>        https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Frfc8635&amp;data=3D04%7C01%7Cdougm%40nist.= gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7= C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3DAQfk6fmJ= vWo1lQPeFjqU61n8n0MWw%2BRjM%2Fun5R9UOpA%3D&amp;reserved=3D0

Thank you Job - somehow I managed to find these documents myself.

I did not ask about these. I asked about the downgrade issue.
Randy was kind enough to answer.

Tim



>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=3D04%7C01%7Cdougm%40nist.= gov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7= C1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3DGx6OU7d8= kL0qGcOyNcap%2FMppIWDaq82xlIKdwiDiGsE%3D&amp;reserved=3D0

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org
h= ttps://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=3D04%7C01%7Cdougm%40nist.g= ov%7C7396569117474f31495d08d9f7767196%7C2ab5d82fd8fa4797a93e054655c61dec%7C= 1%7C0%7C637812911853664452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ= IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3DGx6OU7d8k= L0qGcOyNcap%2FMppIWDaq82xlIKdwiDiGsE%3D&amp;reserved=3D0=

--_000_DM8PR09MB6294D4538DAA3C3094F0E661DE3D9DM8PR09MB6294namp_-- From nobody Fri Feb 25 05:17:56 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264C23A0E47 for ; Fri, 25 Feb 2022 05:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_AFFORDABLE=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 gqX3DkKvU1QR for ; Fri, 25 Feb 2022 05:17:48 -0800 (PST) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 6E9153A0DD1 for ; Fri, 25 Feb 2022 05:17:48 -0800 (PST) Received: by mail-ej1-x633.google.com with SMTP id a23so10834592eju.3 for ; Fri, 25 Feb 2022 05:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=nuhqI+OACWWk0zICKmEzyuX8msOqgrE8DJsbYW9SwG4=; b=v+Hw/fsw1MrUEkXq2O/QHDDq+LglVUQoJdUX/Q39kFsse6Ml4A68z0xumN+UY8Eg8N x5ItsuO27WWRMQCPCSjPu0Tr9Qs3h3ZucQbFqeVrTI9Hi5TaEThcGKO/c7sjT08aXjxY WGOtROGWyhCb3/8WuzVJgtv2Q1l/a+TklRjt4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=nuhqI+OACWWk0zICKmEzyuX8msOqgrE8DJsbYW9SwG4=; b=6YSAA7WnUeZG1jFN5eLxyvNDe3VKZh/E2Kvw6sMw/dk7dX4SPGP6+CvxeRHcJz7T4I jjM5Et3s6G9nB9v9XTYofWd6scjH7tf6QcCRhNkyz+AB5OTN/nbTtWijhB4kkZeWW+7q Sx1FLDCE/unaX1DODFSVKxQDTheXK4byO1bw1c3mhlYAtCM4Yy2VBUGLdjP+R3TVe8B6 iru9VAc48yogW0DE4cwG0GFIMUqu0I8rh/LYbimxsjSdx4y7sPLd7l6PkrbgRVfkKSAw bFrsv0qS9lcp/cDbuJoTGcCZM+J8fIKPbMgmFsTtJHONUvqR0K+ztqGSHtdIPPBaR+4J kpcw== X-Gm-Message-State: AOAM530pPYS1j/uKyhRAZZvIsciqmGjmSnquewLWKbBH1P6eWiQJpbOe XEahtajQtjUMZ85MzCuYHBIdiCjYbVpvwC5bx9cDfbVIcVCttRoDGscY8nSlJrMK34Y1fylm0nw TIJzMJW3JJbNEkAxNsk/RCIPo4GnodgCCv8MghRCAOGdaD3VU7ExNJwQ= X-Google-Smtp-Source: ABdhPJwM9ZCo2zlcs49aVuPTOMJLRSHokwYDgf6qwQZByl2ICJpjuV+D8RhBaU4aXjTkC5x0VNw1Jg== X-Received: by 2002:a17:906:2486:b0:6cf:ced9:e4cc with SMTP id e6-20020a170906248600b006cfced9e4ccmr6007854ejb.201.1645795065186; Fri, 25 Feb 2022 05:17:45 -0800 (PST) Received: from snel ([2a10:3781:276:2:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id br20-20020a170906d15400b006cdd982fefesm604367ejb.116.2022.02.25.05.17.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Feb 2022 05:17:43 -0800 (PST) Date: Fri, 25 Feb 2022 14:17:41 +0100 From: Job Snijders To: sidrops@ietf.org Message-ID: References: <949277FD-27AF-40E8-B557-AA58C62BFEA7@apnic.net> <6D314C7A-8CEC-4B9B-8F80-6B1AC48037E2@nlnetlabs.nl> <85D947F4-E2A4-4FFE-86AF-2D129C49FB9C@psg.com> <8413F0CA-F50A-42B7-B0DA-19A0A90ABE6F@nlnetlabs.nl> <60B6D863-047D-40A6-80DD-95C05391A0BA@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] [routing-wg] misconceptions about ROV X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2022 13:17:54 -0000 Hi Doug, others, On Thu, Feb 24, 2022 at 11:53:25PM +0000, Montgomery, Douglas C. (Fed) wrote: > We seem to create many security mechanisms (e.g., BGPsec, ROAs, MUD > profiles, etc) that don’t have a safe means for individual users to > globally test/pilot them before going into production mode. I think the cake should be sliced up differently: the concept of "pilot testing" shouldn't be in the protocol specs, but in the approach to deployment. In my experience operators are happy to request additional ASNs & arrange separate IPv4/IPv6 space for pilot studies. Both AS and IPv6 INRs are extremely affordable, a fraction of the overall cost of studying a new Internet technology. At least, this was my experience with IPv6 a decade+ ago, and with RPKI ROV in recent years. I fully expect that early adoptors of BGPsec are able to construct appropriate pilot setups too. From that perspective I don't see the need to add new object profiles to facilitate BGPsec, because doing so would set the clock back. > That increases the risk/barrier to entry to those who wish to enable > the technologies. At some point the conceptual "are you sure?" confirmation dialogue boxes have to transform into something that is real. Cryptographic attestations only have meaning when Relying Parties actually honor the attestations: indeed, RPs have to exhibit willpower to discard invalid objects or routes, otherwise the attestations become worthless (or worse! read on below). I think one of the unforeseen and accidental obstacles towards global deployment of RPKI ROV was the following awkward dynamic: (1) the propaganda machine was thundering on all cylinders to promote ROA creation (2) many folks misconfigured their ROAs, resulting in the *crazy situation* that in its peak there were between 5,000 ~ 6,000 invalids BGP routes in the DFZ [0] (3) many folks didn't notice their ROA misconfigurations, because nobody was performing ROV invalid==reject. Also, there was no incentive to fix broken ROAs, because nobody was validating. (4) people became afraid to enable ROV on ingress EBGP, because there were so many invalids "I can't just reject 5K routes!". It is not hard to imagine how steps 1 -> 2 -> 3 -> 4 in an alternative universe could've resulted in complete disaster and dismissal of RPKI ROV. It took significant community effort to overcome the above downward spiral: people had to be taught what CA Intent is, that 'harsh' rejection of invalid information is exactly what makes the security mechanism work, and that the 5K invalids did not pose a risk to business [1] [2]. As for the misconfigured ROA creators: many learned the surprisingly positive consequences of making bad decisions. Sometimes operators have to touch the hot stove. :-) How the above observations potentially apply to BGPsec isn't certain yet, but all of us definitely have to consider what we can learn from the ROV experience when we collectively plan and labor the next phase of routing security. Kind regards, Job [0]: https://www.denog.de/media/DENOG11/day1_1_rpki-one-year-later_yPfR6rl.pdf [1]: https://mailman.nanog.org/pipermail/nanog/2019-February/099522.html [2]: https://storage.googleapis.com/site-media-prod/meetings/NANOG84/2488/20220214_Madory_Measuring_Rpki_Rov_v1.pdf From nobody Fri Feb 25 09:34:01 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4A03A11ED for ; Fri, 25 Feb 2022 09:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 hZZA14rUjdwp for ; Fri, 25 Feb 2022 09:33:42 -0800 (PST) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08on2061a.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e8b::61a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBAB63A11C6 for ; Fri, 25 Feb 2022 09:33:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fVl4GecwRgmhFhpqp5qbQItlyxScVIyBepboAYFeGdI5RGJhCpQIqZWqLZyJgCm0o1F3RIUS/Nl3s3e2ZeFzjcf2y2XgjRYk15pmj7VXZyNhOHHpp/860u+26M7OQn72Cu1nO8o59KAVyyVn1TB5CeRh9HubWJoyF63nZX+QseCtkdaUBRHe9tE0f3tn++MPfHPBC6UP66FXuaPwExd96N43lRAdH1UcexdkNnGQW4MYLP7Ni4vCKNL7e6f7l1cjyEWWi1Aa57OP4qya36/WlctXqvbozDIDuBV2JBMKImdWFhrKBi04PkEBVVpXdyA5WCBUmBV2ogjxkVGfPTJmCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TUwoVmqeVXDdwVKxZduQcu0GOrnk1z1mSnBPQnTHIg8=; b=mSpKRtw4dVpAedUUBx02sftq8OiOq4Tt7LG8T8IPN8upByixe/Y4rU2rPqUR8SDz2Hijt4ZwMCz3vAO5wRP0IWpELl8TLk8U/xcXenMcLml6Ccg137iYZo+5LcgOBrhNkE8r95gBlw76BkIpKJEg4j7Fyf6oSnXG2W7sp2xaoaAzLthe4ieAza3pPtAiH2OYIZ2Iztft+yS9nef1wvEyREOuQxqZSb9mhaG1vbm6GrTExgvnoy1EjHdEYmC6m/ESUAlEHcvuJvvweqW5W3gnIi+RYEwJ/4R6zvfZj5lLyhcAwz55C3XHbD38Q5SvoIf2c8zvIwdf4FBll+untmD2jA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TUwoVmqeVXDdwVKxZduQcu0GOrnk1z1mSnBPQnTHIg8=; b=uGuHR6CSF7YXebkP88HqFnlocM/JaOR2DMBwM772so/pBz921MvQvsrtbZu21Jx3tYK9YQogwNYsqCdl2HfVSVwuehQk2+Qekc9emQf+2H2+m9s7BVm+S0ypQ92Bbjed2az7gAGY3gxs3fBuNyHBooib9fUBI2MrlaxSxTegnHw= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by CH2PR18MB3238.namprd18.prod.outlook.com (2603:10b6:610:28::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.26; Fri, 25 Feb 2022 17:33:37 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::e5f5:6e1b:7ff5:2fc8]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::e5f5:6e1b:7ff5:2fc8%4]) with mapi id 15.20.5017.025; Fri, 25 Feb 2022 17:33:37 +0000 From: Keyur Patel To: "sidrops@ietf.org" Thread-Topic: Reminder about maintaining civility- misconceptions about ROV Thread-Index: AQHYKm2DydrU5Wtj206OMT80RM2nTA== Date: Fri, 25 Feb 2022 17:33:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arrcus.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f2a203dd-04d2-409d-0f5a-08d9f884f499 x-ms-traffictypediagnostic: CH2PR18MB3238:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +cCeRCs9VkuJmiPpBijjWdjy9IHaGzUjE90Z2BiP/Rj23Dg7VMiAV10yztzLZoLK9mdN22nOACt2t7RNiBctgo49ENZah1KML+UtOvq5Tyk1CT6AKyeBPvu4tZi8YsDP853X0CSRJc3ACm+f3D99DKnFA/wRFFPOAiOmYoyZKaEzJkXqhuyrTL5kJ3aybaDgk93yqkUrpKF6M18nWILvZJ+lA7Re/CwTlPkz32ht4zc0N4sMLLeTyKu63cAm8h5FvzyKOuw4i4eCqTafaichlKudoKjMq663mWH7aM9RoNLpz/DMKANNG5xBNqBNZhCyFJQRbNZMagxs0lHnXrQfux3lgtqH7T8vgRSbL2dlZV7PX7uNbSvGxvVf/HD+/FZ/IiMfkZy2alcgWqMkbNE9QraU2z1PgPygOZw+fEXU+WHfGgWDk/BfSCykeap0VDziObAuctz3IrxrYxFR6u4WKeJEv2KEusmWNnK2oCK/db/mnmJTZHKQCNjgzFN1KiYtlTguRfKAmSNWqD+qdsJ/jkCr3M+JAOd1MK7Uq4QpK14tFks99C4qPeBTFtvA04A8LhqcY3g9Ygp13WGGG893WLeA082rXNpIptCDx5vFFaRYNGvRj9zwiR9ZTlqJ7MAT4uS6N1JvCpzYSM6KbBee7eJH6QBFk086Re89wC1TUOLSeX9LShBQdS2JbPl92EKlIosCs3HXCMZlAp4kybhaOQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(39840400004)(346002)(136003)(376002)(396003)(366004)(55016003)(6506007)(86362001)(7696005)(52536014)(26005)(5660300002)(4744005)(38100700002)(9686003)(6916009)(76116006)(66946007)(186003)(71200400001)(33656002)(2906002)(316002)(8936002)(508600001)(8676002)(38070700005)(66446008)(122000001)(66476007)(66556008)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?pXI00S/R3o/XwYri5zkyErVjq5IAlJpgACZ1nrFy6lbypoSe9fUdd8elKLgi?= =?us-ascii?Q?wsw64K888vm8/yOm0pLORtm3L8GCeWg9sYgvWWGtXxbGMYliCkUR9vlh1Nwd?= =?us-ascii?Q?Iq9q+4zaESddaPoMoVCqJBuygtOtTHEBrgd66D+u07iSysaoikVUY5Xk9tnG?= =?us-ascii?Q?1nJdnVxratpYLwPXSfwYHUuV5JTUyZ6jkuxCLnP+Pi09ZD60f4JUWGehd31n?= =?us-ascii?Q?1yWivETbro55OvVDSVQWCiwr6kD7DVG1Uuq3kcQNPUwKo97cja+p1mSYpofw?= =?us-ascii?Q?rO2EnBop7HzbS0qOLBDnI4hwx+mks8667azlJpznGutgoRs8NoSBUyME+QMV?= =?us-ascii?Q?x7TdUiECD1fMGrE2FOL/Bnd95hvJdSo/wfUrasWwI4u5TNXIiDErlUtowEil?= =?us-ascii?Q?7EVtH/k0Rbt8IXudWXH3ajcHSiDSfH6u4VbS2PPyGXIySQsk8+aBpncoyNJY?= =?us-ascii?Q?5yL/+r9Hi3gXC94dsWrB26hg1+B+KyEOGxyQRGnB3RmvUr+3YJQTxnr/KbmZ?= =?us-ascii?Q?0BK7Z2+DR0YvMad4gnSJVMyHAY9Gd9j1Q0LOxrX3/nMX8PScOyHPvMGwCqBr?= =?us-ascii?Q?12eF428FcsBISxv0U7X73gC9QcoOZQlAwPcW0pk2XhE5KyhPP548w7IddrlJ?= =?us-ascii?Q?8Pt0NXtH3VY7CaZSuTvMlHIkJ69WeWaW0AqYeeiT/kktwD5VGcxoVh9Uy7u1?= =?us-ascii?Q?EMNnerJP/ks0IrLebiyRDDv+irpQE4xBX11IBE+m3eUYqKjlqZXvFCQ/upiG?= =?us-ascii?Q?xSpkegmedInaMe5yBva6+EFLe0yTvFOWxfQ/kqx40VPr+A7caJjZgD4bO4w2?= =?us-ascii?Q?SvHmHOtDX/kbDGL9fEfFJ7qO47WOIsP44if1brPGInhY4rXh4k6itPr4BdZU?= =?us-ascii?Q?Fwg+ewl3KqDwX6s0HWRs8k6e5uTgBKnV2G3JJTL9EIbPhxAt7ulUOWUHeoq+?= =?us-ascii?Q?7c0M3W7qBgAMnjf2UbKSoo0ro4ah4vXvmNFzekHWO+1jL5NUYt12jasrBPrZ?= =?us-ascii?Q?kBwOlaGKkFNMc2kof0BQKEAtBW2p19sRT6bVoEwin3IC9RrwCP3GFEFAgXqF?= =?us-ascii?Q?NDJys4pMFN35HCJXH80ycLp5Egc/N8RjNTwalAFuVQI8vefIJ2wV8LNg2/uz?= =?us-ascii?Q?UxeFC8fB1m+Dz2Zi/IPBCBTC6t9BGhxTINpsAsaFKyktkjpuvqqaFMD3C8SV?= =?us-ascii?Q?JrJy//LJ6yMzNqyE7atibPQk+kkkrcGgcppvEeNAw5JuFY4BhVIrmvOJp8+X?= =?us-ascii?Q?xer0TImbBAtvRnEDStUlWFdGobM1aEwF1e885XT5KTSdl8K990INBYFE4FdA?= =?us-ascii?Q?EHF1YZVMLSRsF5Fm4mZMe6TtJLp/a4fiksO/oFTwBecGE7X2EicNAZwAwFbM?= =?us-ascii?Q?GuR96282YuVT7tDcKyoRu6ThlAX21aIkyEwIhrdwr3KOJ8bugnqFJt8tDA3A?= =?us-ascii?Q?56v/gxg43gqC0ls0gTl2qufKyUSO5vEe8OBwqzptvHC/FflsQ00nPe2e77TK?= =?us-ascii?Q?kngLULTzwqrIrettFldjkAuv5JqkleNPrBBKYGntxNwBs4YT8hHxgv5VpFRl?= =?us-ascii?Q?2OWWDBfXY/TSv8W6Rmow/i09eSYzBESdXzu7DGP7yeFJJGz68gJFuEzPBG9X?= =?us-ascii?Q?Jku4gBBHlTyEXj0zW+snmwaNXxuswW8vUau3Tdb+5ZVc?= Content-Type: multipart/alternative; boundary="_000_BYAPR18MB2696BE0F3157A1A089F53657C13E9BYAPR18MB2696namp_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f2a203dd-04d2-409d-0f5a-08d9f884f499 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2022 17:33:37.1897 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NIh9hacjwXcMVViZGv1rh3IATQrqT7lhah+uymmDVQ0XGaNUknJuVKdvW/vNArBf1DNChqHUT3zJh5vOLq3PTQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR18MB3238 Archived-At: Subject: [Sidrops] Reminder about maintaining civility- misconceptions about ROV X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2022 17:33:58 -0000 --_000_BYAPR18MB2696BE0F3157A1A089F53657C13E9BYAPR18MB2696namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Working Group, This discussion thread has become a little heated. While the Chairs are pl= eased to see the discussions on the thread, we would like to remind all par= ticipants that civility is important to advance discussion in a beneficial = manner. It is okay to have dis-agreements as long as you preserve the code of condu= ct on an email conversation. Best Regards, Chris & Keyur --_000_BYAPR18MB2696BE0F3157A1A089F53657C13E9BYAPR18MB2696namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Work= ing Group,

 <= /span>

This di= scussion thread has become a little heated.  While the Chairs are plea= sed to see the discussions on the thread, we would like to remind all parti= cipants that civility is important to advance discussion in a beneficial manner.=

 <= /span>

It is o= kay to have dis-agreements as long as you preserve the code of conduct on a= n email conversation. 

 <= /span>

Best Re= gards,

Chris &= amp; Keyur

 

--_000_BYAPR18MB2696BE0F3157A1A089F53657C13E9BYAPR18MB2696namp_-- From nobody Fri Feb 25 15:56:14 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237B63A0B31; Fri, 25 Feb 2022 15:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 7YLFjWHl33BA; Fri, 25 Feb 2022 15:55:38 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F22D3A0B3C; Fri, 25 Feb 2022 15:55:36 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 21PNtQbw025959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Feb 2022 18:55:32 -0500 Date: Fri, 25 Feb 2022 15:55:26 -0800 From: Benjamin Kaduk To: Job Snijders Cc: The IESG , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-6486bis@ietf.org Message-ID: <20220225235526.GY12881@kduck.mit.edu> References: <164366773060.21391.16732854790829264927@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's Discuss on draft-ietf-sidrops-6486bis-09: (with DISCUSS and COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2022 23:55:43 -0000 Hi Job, My pleasure! Sorry to have taken a bit long to get back to you. On Fri, Feb 11, 2022 at 01:16:26PM +0100, Job Snijders wrote: > Dear Benjamin, > > To me it's always is a pleasure to receive your thorough reviews. Thank > you for sharing your insights! > > On Mon, Jan 31, 2022 at 02:22:11PM -0800, Benjamin Kaduk via Datatracker wrote: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > It looks like we may have a setup where a compliant RP and compliant > > CA/repository fail to interoperate. This is sufficiently surprising that > > I want to confirm that it's the intended behavior. In particular, both > > manifests and CRLs have thisUpdate and nextUpdate fields, and since > > issuing an update to one requires issuing an update to the other (though > > the CRL is always actually generated first), it is only natural for us to > > give guidance that the times in question should match between manifest and > > corresponding CRL. However, we do this only as RECOMMENDED/SHOULD-level > > guidance, and accompany it by guidance to RPs that they SHOULD NOT reject > > a manifest of the fields do not match the CRL. Accordingly, when a CA > > violates the first SHOULD and issues manifeset+CRL with mismatched > > thisUpdate/nextUpdate, and an RP violates the second SHOULD (NOT) and > > rejects such a setup, the RP will be unable to get any RPKI data for that > > CA. (As a tangent, we also have one place where we give related guidance > > that the validity period of the single-use EE cert that signs the manifest > > match the thisUpdate/nextUpdate period, which we might want to keep in > > mind if we make any changes in this space.) > > > > It looks like RFC 6486 had a conditional MUST-level requirement that *if* a > > manifest encompasses a CRL, then the "nextUpdate" fields MUST match (no > > guidance on thisUpdate), which we change to a statement of fact that each > > manifest does encompass a CRL and guidance that the "nextUpdate"s SHOULD > > match. > > Additionally, RFC 6486 had a MUST-level requirement for the validity > > period of the EE cert to exactly match the thisUpdate/nextUpdate time > > interval of the manifest, which we currently are relaxing to a SHOULD. > > > > Often in this scenario we would strengthen one of the SHOULDs to be a > > MUST so that interoperability is guaranteed, but I'm not sure that I see a > > clear argument for which requirement is better to make the MUST. > > I agree with your analysis and think your suggestion to reinforce one of > the two SHOULDs into a MUST is a reasonable way to resolve this friction. > From my perspective, upgrading some normative terms in this context > won't be perceived as controversial by the WG, as the current 'watered > down' text is the result of concerns in relationship to retaining > interopability with CAs 'in the field'. > > Some background on the ability for RP's to deploy a strict ("MUST") at > this point in time: https://mailarchive.ietf.org/arch/msg/sidrops/VNG77j05I2JXOwv4qkSy-DCgRNE/ > > One CA implementation rectified the lack of validity window alignment: > https://github.com/NLnetLabs/krill/commit/51c58ec58b266697dd1843a5504e79bfc385932d > There appears to be agreement enforcing alignment on the CA side 'going > forward', while RPs remain relaxed: > https://mailarchive.ietf.org/arch/msg/sidrops/W-SrezAc5Oa1HoTW0w64EdaD1gk/ > > Thus, I propose the following adjustments to resolve this DISCUSS. > > ----- section 4: Manifest Definition ---- > > OLD section 4.2.1 second paragraph: > Because a "one-time-use" EE certificate is employed to verify a > manifest, it is RECOMMENDED that the EE certificate have a validity > period that coincides with the interval from thisUpdate to nextUpdate > in the manifest, to prevent needless growth of the CA's CRL. > > NEW Section 4.2.1: > Because a "one-time-use" EE certificate is employed to verify a > manifest, the EE certificate MUST be issued with a validity period > that coincides with the interval from thisUpdate to nextUpdate in the > manifest, to prevent needless growth of the CA's CRL. > > ----- Section 5: Manifest Generation ---- > > OLD Section 5.1 last paragraph: > It is RECOMMENDED that the validity interval of the EE > certificate exactly match the thisUpdate and nextUpdate times of > the manifest. > Note: An RP MUST verify all mandated syntactic constraints, i.e., > constraints imposed on a CA via a "MUST". > > NEW section 5.1: > The validity interval of the EE certificate MUST exactly match > the thisUpdate and nextUpdate times specified in the manifest's > eContent. (An RP MUST NOT consider misalignment of the validity > interval misalignment in and of itself to be an error.) This seems like a good approach to me, thanks. In this last chunk, should we add a clause at the beginning of the parenthetical like "In order to remain compatible with implementations of a previous version of this specification", to motivate the "MUST NOT"? > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > My reading of the changes in the diff from RFC 6486 indicate that there is > > something of a fundamental shift in the processing model being made, but > > this does not seem to be mentioned specifically in the list of changes in > > Appendix B (or the introduction/abstract). Specifically, it seems that > > the old RFC 6486 model involved the manifest being a tool that's useful > > for the RP and SHOULD be used, but that ultimately the RP policy decides > > which signed objects from the repository to use and fundamentally places > > trust in the signatures on those objects; the new model in this draft > > seems to place the manifest as the primary control on what signed objects > > to use, with phrasing like "MUST use the current manifest"/"files not > > listed on the manifest MUST NOT be used" and the error-handling behavior > > in 6.6 being to fall back to the previous cached state (at a SHOULD-level > > requirement), which as I understand it would mean using the previous > > cached manifest. (Maybe I'm wrong about that last bit.) While the new > > focus doesn't seem problematic per se, and it's perfectly reasonable from > > a process perspective to make that sort of behavior change in a Proposed > > Standard, it seems that if this was a deliberate decision it ought to be > > emphasized a bit more. The final bullet point in the change list of > > removing the notion of "local policy" is perhaps related to this > > fundamental shift, but seems to only cover part of the shift. > > I appreciate the observations in the above text, but don't see an > actionable remark. However, I can provide a bit of background: > > A write-up on the /why/ of RPKI Manifests can be found here: > https://blog.apnic.net/2020/11/10/rpki-manifests-securely-declare-contents/ > > Manifests are the only way to verify the completeness of a SET of signed > objects. The notion of 'local policy' in the original RFC appears to > have been the result of an awkward compromise (this was before my time). > I think by now all implementers understand that just like car seatbelts, > Manifests are not optional, and never were optional. The background is much appreciated, thanks. My intention here was mostly to ask for another bullet point in the list of changes in Appendix B. In light of the above clarifiations, it might take the form of replacing the last bullet ("Removed the notion of 'local policy'") or it might be a standalone point. If replacing/modifying the existing item, maybe: * Clarified that use of a manifest is the only way to ensure that a consistent and complete view of a publication point's contents is used, removing the notion of "local policy" that modifies manifest processing and use. There might also be room for wording tweaks in the Abstract/Introduction to reflect this change of emphasis, but I'm inclined to say that the potential benefit is not really worth the effort of thinking about them. > > Section 3 > > > > The CA MUST sign only one manifest with each generated private key, > > and MUST generate a new key pair for each new version of the > > manifest. This form of use of the associated EE certificate is > > termed a "one-time-use" EE certificate [RFC6487] > > > > Not really a comment on *this* document (6486bis), but since RFC 6487 > > generically defines the "sequential use" EE certificate that we are > > disallowing for RPKI Manifest use, it seems reasonable to ask whether the > > issues that cause us to forbid sequential use in this context might also > > apply to other scenarios where "sequential use" certificates might have > > been used. (I did not make a survey of the RPKI specification corpus to > > investigate whether such scenarios are likely to exist.) > > I didn't perform an extensive survey either, but AFAIK the Manifest -bis > document is one of the few places to be so explicit about the use of > one-time-use certificates. I believe the primary motivation for this > requirement is that Manifests / CRLs are the "#1 top churning object" > type in the RPKI ecosystem. CRLs (and thus Manifests) generally have a > validity window measured in hours, whereas other object types such as > ROAs often times have a validity window of 12 to 18 months, or longer. > > I expect that going forward, where needed, new object types or -bis > documents will be mor explicit whether to "recycle keypairs" or mandate > one-time-use. > > As you highlighted, your above comment is not really a comment on *this* > document. Indeed, no action for this document, and thanks for the insight into the RPKI ecosystem. > > Section 4.2.1 > > > > fileHashAlg: > > This field contains the OID of the hash algorithm used to hash the > > files that the authority has placed into the repository. The hash > > algorithm used MUST conform to the RPKI Algorithms and Key Size > > Profile specification [RFC6485]. > > > > RFC 6485 has been obsoleted by RFC 7935. > > Correct, this has been rectified in my working copy, also noted in > https://mailarchive.ietf.org/arch/msg/sidrops/NzCcNzcN46FD7RgV3D5ULMnEhxs/ > > > Section 5.1 > > > > 2. Issue an EE certificate for this key pair. The CA MUST revoke > > the EE certificate used for the manifest being replaced. > > > > Do the mechanics of revocation still need to be undertaken even if the EE > > certificate in question has expired? > > No, in the wild one can observe how the property of expired Manifest EE > certificates is a helpful utility to prevent needless growth of CRLs. > Also, trimming of CRLs is permitted. Do you have suggested text to > capture that in a concise succinct manner? Or leave as-is? Maybe "revoke or otherwise ensure invalidity of"? > > Section 6.x > > > > The old RFC 6486 procedures allowed ("MAY") the RP to verify that each > > file at a publication point is listed in exactly one current manifest, > > which is no longer allowed. I think I can see how this was a problematic > > thing to try, but want to confirm that it is intentionally removed. > > Ack. > > > Similarly, RFC 6486 wanted a warning produced if there were objects > > present in the repository that are not listed in any manifest, which does > > not seem particularly useful and I do not mind seeing removed. > > Ack. > > > RFC 6486 also wanted a warning issued if a publication point contained > > both valid and invalid manifests; removing that guidance seems correct to > > me. > > Ack. > > > Section 6.3 > > > > The two "proceed to Section 6.4"s seem redundant (I suggest removing the > > last one). > > > > Section 6.5 > > > > the publication point. If the computed hash value of a file listed > > on the manifest does not match the hash value contained in the > > manifest, then the fetch has failed and the RP MUST proceed to > > Section 6.6; otherwise proceed to Section 6.6. > > > > This looks an awful lot like "if X; goto Y; else; goto Y", which could > > just be written as "goto Y". However, since 6.6 is the "failed fetches" > > processing, in the successful verification case perhaps we don't want to > > do that and should instead proceed to use the content of the files listed > > in the manifest. > > Nice catch! I'll remove the last sentnce. > > > Section 8 > > > > Perhaps it is sufficiently obvious so as to go without saying, but I trust > > that in a prolonged period of failed fetches, the human operator is > > expected to go figure out (via out of band channels) what's up with the > > CA/repository in question and whether an attack is underway. > > > > The requirement for every repository > > publication point to contain at least one manifest allows an RP to > > determine if the manifest itself has been occluded from view. [...] > > > > Do we want to say anything about how these properties change during a CA > > key rollover or if multiple "unrelated" CAs are publishing at the same > > publication point (the latter of which would be quite unusual, if I > > understand correctly)? > > Multiple 'repositories' can exist in a single rsync directory, akin to > how multiple CA Repositories can be fetched via a single RRDP > publication server. My preference would be to leave this as-is, I do not > recall a perception of ambiguity in the wider CA operator community abou > this aspect. Okay, let's leave it as-is, then. > > Section 9 > > > > I see that the latest update from IANA has the registry (entry) references > > being updated from RFC 6488 to [this document], which is great and > > obviates what I would otherwise have remarked upon. > > Ack. > > > Section 11.1 > > > > Now that we're obsoleting RFC 6486, that should probably bump it off into > > the Informative References section. > > Done! > > > RFCs 6482, 6493, 8209, and 8488 appear to not actually be referenced > > from anywhere and thus could probably be removed. > > Done, this was addressed in > https://mailarchive.ietf.org/arch/msg/sidrops/NzCcNzcN46FD7RgV3D5ULMnEhxs/ > > > Section 11.2 > > > > Do we really want to reference RFC 3370 ("CMS Algorithms") for "the CMS > > wrapper of the object" rather than something like RFC 5652 ("CMS")? > > Good suggestion, I've replaced 3370 with 5652. > > Please let me know if the suggested changes to Section 4 and 5 seem > appropriate, if so I'll make the changes and share a patchset. They look good; please go ahead and publish at your convenience. Thanks again, Ben From nobody Fri Feb 25 17:34:21 2022 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7755F3A0E06; Fri, 25 Feb 2022 17:29:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: sidrops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164583894944.24617.3285337457653079258@ietfa.amsl.com> Date: Fri, 25 Feb 2022 17:29:09 -0800 Archived-At: Subject: [Sidrops] sidrops - Requested session has been scheduled for IETF 113 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2022 01:29:12 -0000 Dear Nathalie Trenaman, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sidrops Session 1 (2:00 requested) Friday, 25 March 2022, Afternoon Session I 1230-1430 Room Name: Park Suite 9 size: 165 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/113/sessions/sidrops.ics Request Information: --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Nathalie Trenaman Number of Sessions: 1 Length of Session(s): Number of Attendees: 70 Conflicts to Avoid: People who must be present: Chris Morrow Keyur Patel Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Feb 26 16:25:44 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D55B3A0970; Sat, 26 Feb 2022 16:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no 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 FMVb2ZaVhb2x; Sat, 26 Feb 2022 16:25:39 -0800 (PST) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7473A096E; Sat, 26 Feb 2022 16:25:38 -0800 (PST) Received: from minas-ithil.hactrn.net (c-73-100-88-186.hsd1.ma.comcast.net [73.100.88.186]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) client-signature RSA-PSS (2048 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id A664F4E614; Sun, 27 Feb 2022 00:25:36 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 3516E2EA009D; Sat, 26 Feb 2022 19:25:36 -0500 (EST) Date: Sat, 26 Feb 2022 19:25:36 -0500 From: Rob Austein To: Benjamin Kaduk Cc: Job Snijders , The IESG , sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-6486bis@ietf.org In-Reply-To: <20220225235526.GY12881@kduck.mit.edu> References: <164366773060.21391.16732854790829264927@ietfa.amsl.com> <20220225235526.GY12881@kduck.mit.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Message-Id: <20220227002536.3516E2EA009D@minas-ithil.hactrn.net> Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's Discuss on draft-ietf-sidrops-6486bis-09: (with DISCUSS and COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2022 00:25:43 -0000 Apologies for jumping in late here, I've been distracted by $dayjob (which has not been RPKI for many years now) and only just saw this. I fear that I must object, strongly, to Job's proposed change: > > ----- section 4: Manifest Definition ---- > > > > OLD section 4.2.1 second paragraph: > > Because a "one-time-use" EE certificate is employed to verify a > > manifest, it is RECOMMENDED that the EE certificate have a validity > > period that coincides with the interval from thisUpdate to nextUpdate > > in the manifest, to prevent needless growth of the CA's CRL. > > > > NEW Section 4.2.1: > > Because a "one-time-use" EE certificate is employed to verify a > > manifest, the EE certificate MUST be issued with a validity period > > that coincides with the interval from thisUpdate to nextUpdate in the > > manifest, to prevent needless growth of the CA's CRL. > > > > ----- Section 5: Manifest Generation ---- > > > > OLD Section 5.1 last paragraph: > > It is RECOMMENDED that the validity interval of the EE > > certificate exactly match the thisUpdate and nextUpdate times of > > the manifest. > > Note: An RP MUST verify all mandated syntactic constraints, i.e., > > constraints imposed on a CA via a "MUST". > > > > NEW section 5.1: > > The validity interval of the EE certificate MUST exactly match > > the thisUpdate and nextUpdate times specified in the manifest's > > eContent. (An RP MUST NOT consider misalignment of the validity > > interval misalignment in and of itself to be an error.) This business of pinning the manifiest EE certificate's validity period to the manifest's thisUpdate/nextUpdate interval has always been a bad idea, I've objected to it in the WG before, and we have a long sad history of operational disasters resulting from implementations that followed that recommendation. The typical failure mode (demonstrated at least once each by three of the RIRs) is to pick a thisUpdate/nextUpdate cycle on the order of a day or so (reasonable), then go home for a long weekend, during which something breaks and no new updates occur. The manifest thisUpdate/nextUpdate semantics are (deliberately) very much like the CRL semantics: failure to issue a new manifest by the nextUpdate time does not automatically invalidate all the existing data, it's just a hint that something might be wrong. Think of it as a staleness indication. Slightly stale, log a warning but no big deal (yet). Gets stale enough, maybe you don't want to eat that. Certificate expiration, on the other hand, is a hard failure. When a manifest's EE certificate expires without being replaced, the data listed in the manifest is just gone. So when an RIR does this with the manifest directly under their root certificate, a large portion of the total database goes away. Oops. Manifests only have EE certificates because they're a patch on the side of X.509. If X.509 had allowed us to sign manifests using the CA certificate, as with CRLs, we would have done that. But it doesn't, so we have the manifest EE certificates, OK, but that's no reason to kill large portions of the database every time an operator near the root of the tree says "oops". All of this has been discussed before, and should be both in WG archives and in notes from face to face meetings (probably both the SIDR and SIDROPS WGs, not a new topic). My own RPKI CA implementation uses the validity interval of the parent CA certificate as the validity interval of the manifest EE certificate, and has for about fifteen years now. I'm not aware of any operational problems that have arisen as a result. Yes, there's a potential issue of a CRL getting too long, but if it happens at all, it happens at a predictable rate, and one can always rekey if it's really becoming big enough to be a problem. Job's proposed change makes the bad idea a requirement rather than just bad advice, hence my objection. From nobody Mon Feb 28 02:27:42 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5413A3A0E59 for ; Mon, 28 Feb 2022 02:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net 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 octzdsj62h6l for ; Mon, 28 Feb 2022 02:27:34 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6FC73A0E52 for ; Mon, 28 Feb 2022 02:27:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From:CC ; bh=5NXdwKrIEhzrnanXNF9pBccF+xT6yogqpwNouczUY70=; b=UquO3nFPM4k8Zx4Cjlwkp15g Gh/748M6xbsUWwTkaGZMXVw1uMuS/0X5Ql8PGQuHoSEljhVjUDL6kzasvZbcb2fXoKvp4J1SdUB2u bwlGtyhM6Qzx6ymWA471f1MUppiYZ0LJhnh7E/YZ+gJw54m1NigHpvLJgzRxQF9vBeQ81cWfbwi/q yqjfZd9ihMqx+q+bVRLn8IVvDE/5+1RMX9qZR7/zO1HlHHDp1JyBbNdJhHc7CS3djYgz26PvyIIn8 nW3eSwNsXtx9oJ4QkSdjKDAhEIYtLdl5JNmfHDbLFpBK13BYaxhXCbGXuwxbAhPF5rhosOzQAxzxf NjGFTSw3bg==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:54240) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nOdFc-0007mB-17 for sidrops@ietf.org; Mon, 28 Feb 2022 11:27:32 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nOdFb-0001e4-Te for sidrops@ietf.org; Mon, 28 Feb 2022 11:27:31 +0100 From: Nathalie Trenaman Content-Type: multipart/alternative; boundary="Apple-Mail=_8C760111-5F5D-41E2-931E-0F027D08B4E1" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-Id: <14F8EEE4-3407-45CC-BD68-602BDBD10093@ripe.net> Date: Mon, 28 Feb 2022 11:27:30 +0100 To: sidrops@ietf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) X-RIPE-Signature: 18706c59bce47014ab71a1af93a0d016f7a45ed75e5e284ecf2ea26954fe020f Archived-At: Subject: [Sidrops] Agenda sidrops IETF113 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2022 10:27:40 -0000 --Apple-Mail=_8C760111-5F5D-41E2-931E-0F027D08B4E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, IETF just finalised the agenda for IETF113 and we=E2=80=99ve been = allocated a slot on Friday 25 March, 11:30 - 13:30 UTC. I have published the 1st draft agenda here: = https://datatracker.ietf.org/doc/agenda-113-sidrops/ = Currently, there is still some space for agenda topics, so let us know = (sidrops-chairs@ietf.org ) if you want = to present. Also, I would like to ask speakers if they can let us know, if possible, = in advance if you will present on-site or remote.=20 Thanks, Nathalie --Apple-Mail=_8C760111-5F5D-41E2-931E-0F027D08B4E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,

IETF just = finalised the agenda for IETF113 and we=E2=80=99ve been allocated a slot = on Friday 25 March, 11:30 - 13:30 UTC.
I have = published the 1st draft agenda here: https://datatracker.ietf.org/doc/agenda-113-sidrops/
<= div class=3D"">
Currently, there is = still some space for agenda topics, so let us know (sidrops-chairs@ietf.org) if you want to = present.

Also, = I would like to ask speakers if they can let us know, if possible, in = advance if you will present on-site or remote. 

Thanks,
Nathalie


= --Apple-Mail=_8C760111-5F5D-41E2-931E-0F027D08B4E1-- From nobody Mon Feb 28 11:23:56 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54E13A12F6 for ; Mon, 28 Feb 2022 11:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no 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 xqPce0FsSM9R for ; Mon, 28 Feb 2022 11:23:47 -0800 (PST) Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473F73A14CE for ; Mon, 28 Feb 2022 11:23:43 -0800 (PST) Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 57A9514C402 for ; Mon, 28 Feb 2022 14:23:42 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 44E8814C29F for ; Mon, 28 Feb 2022 14:23:42 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Message-Id: <03FBC58E-8227-4007-8962-6DCC7F4F2C33@vigilsec.com> Date: Mon, 28 Feb 2022 12:53:47 -0500 To: SIDR Operations WG X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: [Sidrops] draft-ietf-sidrops-roa-considerations-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2022 19:23:54 -0000 I have a few comments on the document. Section 1: I find the first paragraph very confusing. The use of "must" = sent me down the wrong path. I think the first sentence should tell the = reader that we are talking about the RPKI. Then, it should explain the = choices facing the address space holder. Then, say that the document = will explore the pros and cons for the various choices. Then, recommend = the most desirable among the alternatives. Section 1: s/space[RFC6482].If/space [RFC6482]. If/ Section 2: Please use the modern language here: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Section 3: s/Ripencc/RIPENCC/ After reading to document, I ask the authors to consider dropping = "Problem Statement" from the title. Russ From nobody Mon Feb 28 14:32:05 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71563A1650 for ; Mon, 28 Feb 2022 14:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no 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 yWmMyUjy8c9L for ; Mon, 28 Feb 2022 14:32:02 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9ED3A1642 for ; Mon, 28 Feb 2022 14:32:02 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.93) (envelope-from ) id 1nOoYg-000hQS-SO; Mon, 28 Feb 2022 22:31:59 +0000 Date: Mon, 28 Feb 2022 14:31:58 -0800 Message-ID: From: Randy Bush To: Nathalie Trenaman Cc: sidrops@ietf.org In-Reply-To: <14F8EEE4-3407-45CC-BD68-602BDBD10093@ripe.net> References: <14F8EEE4-3407-45CC-BD68-602BDBD10093@ripe.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Agenda sidrops IETF113 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2022 22:32:04 -0000 to the best of my understanding draft-ymbk-sidrops-rov-no-rr draft-ietf-sidrops-8210bis are pretty much just going through the sausage machine of adoption and iesg submission, and are not in need of discussion or a sales pitch. if folk think otherwise, then please put on agenda and i will try to put something together. randy, who has work to do, and it ain't sales From nobody Mon Feb 28 23:56:49 2022 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB133A1988 for ; Mon, 28 Feb 2022 23:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Z1nJczNTIHJL for ; Mon, 28 Feb 2022 23:56:45 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id E83193A1989 for ; Mon, 28 Feb 2022 23:56:42 -0800 (PST) Received: from TestYJ-PC (unknown [218.241.103.136]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AJEXm10R1isCMlAA--.2204S2; Tue, 01 Mar 2022 15:56:37 +0800 (CST) Date: Tue, 1 Mar 2022 15:56:37 +0800 From: "Jiankang Yao" To: "Russ Housley" , "SIDR Operations WG" Cc: gggeng , =?utf-8?B?UmFuZHnCoEJ1c2g=?= , yanzhiwei References: <03FBC58E-8227-4007-8962-6DCC7F4F2C33@vigilsec.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.20.273[cn] Mime-Version: 1.0 Message-ID: <2022030115553677092368@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart872421341706_=----" X-CM-TRANSID: AQAAf0AJEXm10R1isCMlAA--.2204S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Kw1UCryxWrW7KFWrXrW5ZFb_yoW8Gw1fpw s5WFnxGF1ktr42gas7Aw1UAFyIy395Jay7JF13J3y7Ca4Fgr10qryUKwn8ZryUJ343WFW0 qr4UWws8J3y7uaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBlb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF0I0E 4I0vr24l5I8CrVC2j2CEjI02ccxYII8I67AEr4CY67k08wAv7VC0I7IYx2IY67AKxVWUJV WUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAK I48JM4xvF2IEb7IF0Fy264kE64k0F24lc2xSY4AK67AK6r4xMxAIw28IcxkI7VAKI48JMx C20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAF wI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20x vE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v2 0xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14 v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8vfO7UUUUU== X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-roa-considerations-01 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2022 07:56:47 -0000 This is a multi-part message in MIME format. ------=_001_NextPart872421341706_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IERlYXIgUnVzcywNCiAgIFRoYW5rcyBhIGxvdCBmb3IgeW91ciBraW5kIHJldmlldyBhbmQgZ3Jl YXQgY29tbWVudHMuDQogICBXZSBjby1hdXRob3JzIHdpbGwgZm9sbG93IHlvdXIgY29tbWVudHMg YW5kIHVwZGF0ZSB0aGVtIHRvIHRoZSBuZXcgdmVyc2lvbi4NCg0KVGhhbmtzLiANCg0KDQpKaWFu a2FuZyBZYW8NCiANCkZyb206IFJ1c3MgSG91c2xleQ0KRGF0ZTogMjAyMi0wMy0wMSAwMTo1Mw0K VG86IFNJRFIgT3BlcmF0aW9ucyBXRw0KU3ViamVjdDogW1NpZHJvcHNdIGRyYWZ0LWlldGYtc2lk cm9wcy1yb2EtY29uc2lkZXJhdGlvbnMtMDENCkkgaGF2ZSBhIGZldyBjb21tZW50cyBvbiB0aGUg ZG9jdW1lbnQuDQogDQpTZWN0aW9uIDE6IEkgZmluZCB0aGUgZmlyc3QgcGFyYWdyYXBoIHZlcnkg Y29uZnVzaW5nLiBUaGUgdXNlIG9mICJtdXN0IiBzZW50IG1lIGRvd24gdGhlIHdyb25nIHBhdGgu IEkgdGhpbmsgdGhlIGZpcnN0IHNlbnRlbmNlIHNob3VsZCB0ZWxsIHRoZSByZWFkZXIgdGhhdCB3 ZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgUlBLSS4gVGhlbiwgaXQgc2hvdWxkIGV4cGxhaW4gdGhl IGNob2ljZXMgZmFjaW5nIHRoZSBhZGRyZXNzIHNwYWNlIGhvbGRlci4gIFRoZW4sIHNheSB0aGF0 IHRoZSBkb2N1bWVudCB3aWxsIGV4cGxvcmUgdGhlIHByb3MgYW5kIGNvbnMgZm9yIHRoZSB2YXJp b3VzIGNob2ljZXMuICBUaGVuLCByZWNvbW1lbmQgdGhlIG1vc3QgZGVzaXJhYmxlIGFtb25nIHRo ZSBhbHRlcm5hdGl2ZXMuDQogDQpTZWN0aW9uIDE6IHMvc3BhY2VbUkZDNjQ4Ml0uSWYvc3BhY2Ug W1JGQzY0ODJdLiBJZi8NCiANClNlY3Rpb24gMjogUGxlYXNlIHVzZSB0aGUgbW9kZXJuIGxhbmd1 YWdlIGhlcmU6DQogDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJ UkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAi UkVDT01NRU5ERUQiLCAiTk9UIFJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZA0KICAgIk9QVElPTkFM IiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4N CiAgIEJDUCAxNCBbUkZDMjExOV0gW1JGQzgxNzRdIHdoZW4sIGFuZCBvbmx5IHdoZW4sIHRoZXkg YXBwZWFyIGluIGFsbA0KICAgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUuDQogDQpTZWN0aW9uIDM6 IHMvUmlwZW5jYy9SSVBFTkNDLw0KIA0KQWZ0ZXIgcmVhZGluZyB0byBkb2N1bWVudCwgSSBhc2sg dGhlIGF1dGhvcnMgdG8gY29uc2lkZXIgZHJvcHBpbmcgIlByb2JsZW0gU3RhdGVtZW50IiBmcm9t IHRoZSB0aXRsZS4NCiANClJ1c3MNCiANCiANCiANCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpTaWRyb3BzIG1haWxpbmcgbGlzdA0KU2lkcm9wc0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyb3BzDQogDQo= ------=_001_NextPart872421341706_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
 Dear Russ,
   Thanks a lot for your k= ind review and great comments.
   We co-authors will f= ollow your comments and update them to the new version.

Thanks. 
=0A
=0A
=0A
<= span>Jiankang Yao
 
<= div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm">
Date: 2022-03-01 = 01:53
Subject: [Sidrops] draft-ietf-sidro= ps-roa-considerations-01
I have a few comments = on the document.
=0A
 
=0A
Section 1: I find the fi= rst paragraph very confusing. The use of "must" sent me down the wrong pat= h. I think the first sentence should tell the reader that we are talking a= bout the RPKI. Then, it should explain the choices facing the address spac= e holder.  Then, say that the document will explore the pros and cons= for the various choices.  Then, recommend the most desirable among t= he alternatives.
=0A
 
=0A
Section 1: s/space[RFC64= 82].If/space [RFC6482]. If/
=0A
 
=0A
Section 2: Pl= ease use the modern language here:
=0A
 
=0A
 =   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=
=0A
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT REC= OMMENDED", "MAY", and
=0A
   "OPTIONAL" in this documen= t are to be interpreted as described in
=0A
   BCP 14 [= RFC2119] [RFC8174] when, and only when, they appear in all
=0A
&n= bsp;  capitals, as shown here.
=0A
 
=0A
Secti= on 3: s/Ripencc/RIPENCC/
=0A
 
=0A
After reading to= document, I ask the authors to consider dropping "Problem Statement" from= the title.
=0A
 
=0A
Russ
=0A
 =0A
 
=0A
 
=0A
_________________________= ______________________
=0A
Sidrops mailing list
=0A
Sidr= ops@ietf.org
=0A
https://www.ietf.org/mailman/listinfo/sidrops=0A
 
=0A
=0A ------=_001_NextPart872421341706_=------