From nobody Tue Aug 4 13:19:38 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E013A0AD6 for ; Tue, 4 Aug 2020 13:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 4854mBtkkAYr for ; Tue, 4 Aug 2020 13:19:35 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAF13A0A6D for ; Tue, 4 Aug 2020 13:19:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9B0CA300AF9 for ; Tue, 4 Aug 2020 16:19:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DoCoZa5d8p6l for ; Tue, 4 Aug 2020 16:19:31 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 452CB300AAB for ; Tue, 4 Aug 2020 16:19:31 -0400 (EDT) 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.15\)) Date: Tue, 4 Aug 2020 16:19:32 -0400 References: <93A15472-939F-4688-9487-CB9A582105D1@vigilsec.com> To: IETF STIR Mail List In-Reply-To: <93A15472-939F-4688-9487-CB9A582105D1@vigilsec.com> Message-Id: <67063985-FCA9-4274-8A3E-6DAF4BB716F9@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [stir] WGLC: draft-ietf-stir-cert-delegation-03 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 20:19:37 -0000 I reviewed draft-ietf-stir-cert-delegation-03 to see whether my comments = against the previous version were resolved. They were. While doing the review, I discovered two very minor editorial nits (see = below). This nits should not block progress to the IESG, but it should = be fixed with any other comments that come up during IETF Last Call. Nit in Section 5.1, para 1. The last sentence says: Authentication services SHOULD NOT use a delegate certificate without validating that its scope of authority is encompassed by that of its parent certificate, and if that certificate has a own parent, the entire certification path SHOULD be validated. It looks like you were interrupted while editing this sentence. Please = drop "own". In addition, there is an outdated reference; draft-ietf-acme-star has = been published as RFC 8739. Russ From nobody Wed Aug 5 08:56:32 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13C93A0CC9 for ; Wed, 5 Aug 2020 08:56:27 -0700 (PDT) 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=team.neustar header.b=oBjkp/EI; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=neustar.onmicrosoft.com header.b=l8bo2JD9 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 AEk-zM5Qjvsm for ; Wed, 5 Aug 2020 08:56:26 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 640653A0C7B for ; Wed, 5 Aug 2020 08:56:26 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 075FuEcq022058 for ; Wed, 5 Aug 2020 11:56:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=team-neustar; bh=r+XTYyExaEvT6zmzUluwQ/9kJikXIUDlK/sfYtpoHtM=; b=oBjkp/EI2hCFb5xQW3cmy/GbQH4SeNEv181FkWaDf8QBZ7mOjkQE4Li/Kr8zKbFbcg1i osYP/RK//J0D6SrKmIDjz3VnJudWBMQn8xuGa3fK5NcZMqDpzHF6WZ+Ith3xBBn0/x3k c3glx6dC4swqEs8mRbSt60wA0pAJYFw+g1XQSch7jJ+UOzYsbdovLLA1iB+iG2Jtusvy H4gS1psI+O6IvUbUmmdp58DrvBhps350DAFmVgaDZHv9dZqSafnSq+m4pCWTNGepEAsu 94a/e0wso7dQuJUbiCUVv/ot929n7B1AM57cQO2ZptDzLZo6aURk4YCb+tfPuGbEC3QX aQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-0018ba01.pphosted.com with ESMTP id 32n5dr2huw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 05 Aug 2020 11:56:24 -0400 Received: from m0078664.ppops.net (m0078664.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 075FuLaf022132 for ; Wed, 5 Aug 2020 11:56:21 -0400 Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2177.outbound.protection.outlook.com [104.47.57.177]) by mx0a-0018ba01.pphosted.com with ESMTP id 32n5dr2hug-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Aug 2020 11:56:15 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bwkpWuZmBE397LHqi6G+YfH3cuX4gk2ka8z0gc8GnECxE3duKo3dnbd9HHUgHkuALpoWcuCM7febJANUIcuCzedJ+YbfrbiG1mVFh3Ht5KpLywByH/xAIZsvXTC2McGAprj7eL3muPK9o+2NHVFI+LBt26ncqMWCtP1x5sLsBlZb5e/rzlT30243Sq6mcv5NtTehRXOP0jYXLmvW+4YVwz+4x/Q+7G9jvf4w9MALhR6a7ugQu2Qj1auarDdqRGqqJt65fqdv88LrpG15ZL6aUi208xUva9dUfHpQo0QHYPW4X3jLs4B3N/Dn2B/VE+apSiP24z3E4rUznlOrucLpAQ== 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-SenderADCheck; bh=5E1xGeUi7bVSMwviLjfprOPu8Gt5Kym/XTNjQeDdWXI=; b=YoOUaDvxSQqpfn7iA41C32E8vXBl1h5fbMEXBRmKFKT7BFlk727s7UhHSFOutg+7fYA2CmbXw9ggo901hjD2E3X0ORdF2Tpbq2+tcKvMv9Qu9nLO/LMoN9PENiZFVocJ0eBLU5H+f0ey7MDck3AaB6H+uz1oi3g07c5OHvkGKh0RR8uxaaLpEoDFT7qHNvQRKaIOHDHB0VTkD1B7651bfbHyDyYlGGpsIQM2DWJMpCE/fyZiSbwSEWEfeNnlPefcKq0WfdSARQZD1G/+Wet8tuKOVLRs1qTr43lTh/5QIhUoCn29spES3zqPHm5FRUorwSau+9Rhn9sr5LrknfvVxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.neustar; dmarc=pass action=none header.from=team.neustar; dkim=pass header.d=team.neustar; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.onmicrosoft.com; s=selector1-neustar-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5E1xGeUi7bVSMwviLjfprOPu8Gt5Kym/XTNjQeDdWXI=; b=l8bo2JD9VlxsPnrYW7Jco3D91lSc66W14M4D9xcqnzDyd/0M+MxYr43benKm8vNRG2aWp2NAT+YmQxliyjv5pXCJITDUqRY27+hkhiucSQzTYgkFLKxQFymNzrlH6R7PjgB8ilffXW0JM3QEiV9v456BZ6PWfUJzmYzPGewHQWE= Received: from BY5PR17MB3569.namprd17.prod.outlook.com (2603:10b6:a03:1b9::20) by BY5PR17MB3809.namprd17.prod.outlook.com (2603:10b6:a03:238::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.16; Wed, 5 Aug 2020 15:56:08 +0000 Received: from BY5PR17MB3569.namprd17.prod.outlook.com ([fe80::503b:2ce0:8d8b:6b15]) by BY5PR17MB3569.namprd17.prod.outlook.com ([fe80::503b:2ce0:8d8b:6b15%5]) with mapi id 15.20.3239.022; Wed, 5 Aug 2020 15:56:07 +0000 From: "Peterson, Jon" To: Russ Housley , IETF STIR Mail List Thread-Topic: [stir] WGLC: draft-ietf-stir-cert-delegation-03 Thread-Index: AQHWapyav6Uwc3LjkEeFoFQPTI8etqkpN0qA Date: Wed, 5 Aug 2020 15:56:07 +0000 Message-ID: References: <93A15472-939F-4688-9487-CB9A582105D1@vigilsec.com> <67063985-FCA9-4274-8A3E-6DAF4BB716F9@vigilsec.com> In-Reply-To: <67063985-FCA9-4274-8A3E-6DAF4BB716F9@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.17.200615 authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=team.neustar; x-originating-ip: [108.208.24.189] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: de87d1dd-72a8-43aa-386e-08d839581114 x-ms-traffictypediagnostic: BY5PR17MB3809: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ce/Cjkdd/NkwjM8fqNVxOSDLwNk/+6X/8yr3flThg1mVHQl7/gTItTs9B6s68PuNl7hH12W9oUz/fdtz9es4pjr0JSGcDRl2vHM591AxilQv6jk2CvJRvybXG0oVyutm9XNYedUvmnweyhk0MMZqBZt1+Q56oLWyGttTNs3IWdOpvSSWFIzdsLnBcB9Eqw4KWTbLX8Ann4/LBoLiBS+fdteNV7UAAM8HYlP6DObCsb9uTbFFXELo0MDpvjmtIi4XfYi/KRJ+pEusIUturh3eeDZMPx+p0bK2gAANkgcRKbhHcHZwrMD/iuL6MCc/Qgu9Gm1BivoITjV44DIqiS2gb1QzBMfJBH+lbPnCoHjp8FcjbHCHlMjvUjtaUpnld5thFal0rWAtVIYxLSkYNFDwySx3/Je9bakSkOQuUy6g3+6Fb18SD7I1USC57NxG7nV3TMkCzvIuvvscYvqGO7OuDw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR17MB3569.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(366004)(396003)(39860400002)(66556008)(76116006)(5660300002)(66946007)(64756008)(66476007)(66446008)(2906002)(71200400001)(478600001)(83380400001)(966005)(6512007)(186003)(6506007)(8936002)(110136005)(316002)(2616005)(6486002)(33656002)(86362001)(26005)(8676002)(46492007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Aeu4b/Y0YNu18Sg84F9cx9Cwk9DNRxrtWEXfxJDrd1XyQLOquoFLXzJmgJC08fja9tREeoHDqGuACmaT7dn7Cm20m+ZQHwnDy0Qonbl3DSJ9XuhcaMzatC5ZjiI24gaRIhADdjoI4MMkTqetKo7hbNnmKv3tbfFFV97/RP9dwRvuR/v3uyFCCwO6VQZbtX3UTm48csaXhQucFaooWC6D6cVHAp4EePR/UJ+Ohr7yn2OAZzAh86svob8ebG039i3jAW9jQz6VfLA3jwPvFauCmn5eboBUpi0bPjYB6aPbi7on6v40KBL9EjruEd0vqC31TUe3TymF/XU/62Q5Svs6xr6wsuXNlYPyFSws6bXV4wa0Bs59pbHrvgvWhBVqwqQNI1XvVQSTy3TyH3WWDUbEiE3QxJlMVffKLACUIOJZUHdQxNO7xvVKypKIapfrMA1pZmqQ+WaDUGmYsF/NlBWCJ9jfLu8s3Fd6OqSogk0RXCxGBKQPiP0QRlj68aaBAqGSiJMEtCOecOy3iWK2w1Pr5n2stp70lKfCX/+2mYXBmgQPR3BWD4UaFsktDbgnGq7BHF/CWOBG/f3+n5/Rv5EhCyUaV0HHrqH/DjV1Lsd0xktbUwxmMLaLdmHWd2AU7A5JjGAPlqK3jJXj9T0qv7idGg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2D0FF3E70C989F40980F7ED0DA40BF84@namprd17.prod.outlook.com> X-OriginatorOrg: team.neustar X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR17MB3569.namprd17.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: de87d1dd-72a8-43aa-386e-08d839581114 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2020 15:56:07.7529 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 73a2bbc1-f307-47c4-8f94-5f379c68bc30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 40IN+1zsQZNCHyn//gzkAekM/lHSCbMgSke4R3pw907/L9ILQ0CHStqXtQhtGfc42UN+3mqAUcimFvu+Zx2Qrh3ESZVnf7N0nxG1s3MLmF8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR17MB3809 Content-Transfer-Encoding: Quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-05_10:2020-08-03, 2020-08-05 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 priorityscore=1501 spamscore=0 clxscore=1015 mlxlogscore=953 suspectscore=0 phishscore=0 bulkscore=0 lowpriorityscore=0 impostorscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=2 engine=8.12.0-2006250000 definitions=main-2008050128 Archived-At: Subject: Re: [stir] WGLC: draft-ietf-stir-cert-delegation-03 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 15:56:32 -0000 Thanks Russ, we'll fix those on the way through IETF LC. Jon Peterson Neustar, Inc. =EF=BB=BFOn 8/4/20, 1:19 PM, "stir on behalf of Russ Housley" wrote: I reviewed draft-ietf-stir-cert-delegation-03 to see whether my comment= s against the previous version were resolved. They were. =20=20=20=20 While doing the review, I discovered two very minor editorial nits (see= below). This nits should not block progress to the IESG, but it should be= fixed with any other comments that come up during IETF Last Call. =20=20=20=20 Nit in Section 5.1, para 1. The last sentence says: =20=20=20=20 Authentication services SHOULD NOT use a delegate certificate without validating that its scope of authority is encompassed by that of its parent certificate, and if that certificate has a own parent, the entire certification path SHOULD be validated. =20=20=20=20 It looks like you were interrupted while editing this sentence. Please= drop "own". =20=20=20=20 In addition, there is an outdated reference; draft-ietf-acme-star has b= een published as RFC 8739. =20=20=20=20 Russ =20=20=20=20 _______________________________________________ stir mailing list stir@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/stir_= _;!!N14HnBHF!ozUFQyL-T3fi26Ha-fUn4wU9g1rAR0yO2RwdHHv_wCjE5pvkF377IlNh4qY$=20 =20=20=20=20 From nobody Wed Aug 5 09:36:31 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3756B3A0CC4 for ; Wed, 5 Aug 2020 09:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wneLow7hPiHq for ; Wed, 5 Aug 2020 09:36:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE643A0CC1 for ; Wed, 5 Aug 2020 09:36:28 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 075GaQKX036262 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 5 Aug 2020 11:36:27 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1596645388; bh=zkBkgjvoKh4yyicqWEE0KMB9bIk2JF/EcprpfJXkS2s=; h=Subject:References:To:From:Date:In-Reply-To; b=ssETH0dPTmry3UZMBZIYdAqGJ3D6jNMJu36PIg+UzyULn2aie1P6mSNBaVAetS+co Rlb1OX8dJcp1Iugzp8cWu8t/hyqykgr5hDBk2utYlSUOnTnXi0vii7YnlVSM+hxLL4 XJJwiCD5LO2sR0cqLNaI//waLKWTPu30tVWQz9N8= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local References: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> To: "stir@ietf.org" From: Robert Sparks X-Forwarded-Message-Id: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> Message-ID: <6d50b6f8-aa9f-fce3-897f-69703bcc29a6@nostrum.com> Date: Wed, 5 Aug 2020 11:36:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> Content-Type: multipart/alternative; boundary="------------880B65474447A5C5E6C9BE6F" Content-Language: en-US Archived-At: Subject: [stir] Fwd: [108all] Final reminder: IETF 108 meeting survey X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 16:36:30 -0000 This is a multi-part message in MIME format. --------------880B65474447A5C5E6C9BE6F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit If you haven't already participated in this survey, please consider doing so soon. -------- Forwarded Message -------- Subject: [108all] Final reminder: IETF 108 meeting survey Date: Wed, 5 Aug 2020 22:30:16 +1200 From: IETF Executive Director To: 108all@ietf.org Thank you very much to the ~230 people who have filled in the IETF 108 meeting survey as this data is crucial to helping us plan future meetings. We could still use another 70 or so responses and so this is a final reminder to please help us by taking a few minutes to complete the survey: https://www.surveymonkey.com/r/T3SL7JF Thanks in advance -- Jay Daley IETF Executive Director exec-director@ietf.org -- 108all mailing list 108all@ietf.org https://www.ietf.org/mailman/listinfo/108all --------------880B65474447A5C5E6C9BE6F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

If you haven't already participated in this survey, please consider doing so soon.



-------- Forwarded Message --------
Subject: [108all] Final reminder: IETF 108 meeting survey
Date: Wed, 5 Aug 2020 22:30:16 +1200
From: IETF Executive Director <exec-director@ietf.org>
To: 108all@ietf.org


Thank you very much to the ~230 people who have filled in the IETF 108 meeting survey as this data is crucial to helping us plan future meetings. We could still use another 70 or so responses and so this is a final reminder to please help us by taking a few minutes to complete the survey:

https://www.surveymonkey.com/r/T3SL7JF

Thanks in advance

-- 
Jay Daley
IETF Executive Director
exec-director@ietf.org


-- 
108all mailing list
108all@ietf.org
https://www.ietf.org/mailman/listinfo/108all
--------------880B65474447A5C5E6C9BE6F-- From nobody Wed Aug 5 10:56:26 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28FD3A0E7E for ; Wed, 5 Aug 2020 10:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiutcXvYuuYf for ; Wed, 5 Aug 2020 10:56:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C303E3A0E6E for ; Wed, 5 Aug 2020 10:56:17 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 075HuGLH012389 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 5 Aug 2020 12:56:17 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1596650177; bh=5GFacNNr0uA37W/fru+99Ns0N4Z1ji3K2IxKXyUPT/4=; h=To:From:Subject:Date; b=faHdGGg2qf2wKzrUv7w79DO0bNF7Nh5f8PgqD4Oie+AdfM35ble/2F+3up5IBON4Y YNRT4eHO3lCZ+Gk18+/fBKGj2rzD9b/XZKx5Ac+IF8mV74I6Pj/2D6WJEfVU5QSQxQ NRhvXmdW3HndffqqKRNn32fysu/zVlHcLtNPtEL4= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: "stir@ietf.org" From: Robert Sparks Message-ID: <4aaaa460-3c30-a475-f7ff-efe09672b94c@nostrum.com> Date: Wed, 5 Aug 2020 12:56:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [stir] Draft minutes: STIR at IETF108 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 17:56:24 -0000 The draft minutes are at https://codimd.ietf.org/notes-ietf-108-stir Please send any comments to the chairs. RjS From nobody Wed Aug 5 11:23:43 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A950A3A0DE9 for ; Wed, 5 Aug 2020 11:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 jZVs2aJCZobQ for ; Wed, 5 Aug 2020 11:23:41 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552583A0DD9 for ; Wed, 5 Aug 2020 11:23:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EBFD7300AFF for ; Wed, 5 Aug 2020 14:23:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gdziqdEEK_dZ for ; Wed, 5 Aug 2020 14:23:38 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id B818A300AA6 for ; Wed, 5 Aug 2020 14:23:37 -0400 (EDT) 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.15\)) Date: Wed, 5 Aug 2020 14:23:38 -0400 References: <93A15472-939F-4688-9487-CB9A582105D1@vigilsec.com> <67063985-FCA9-4274-8A3E-6DAF4BB716F9@vigilsec.com> To: IETF STIR Mail List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [stir] WGLC: draft-ietf-stir-cert-delegation-03 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 18:23:43 -0000 The shepherd writeup is here: = https://datatracker.ietf.org/doc/draft-ietf-stir-cert-delegation/shepherdw= riteup/ Please review and raise any concerns on the mail list. I will no pass this document to the IESG. I am sure that any issues = with the writeup will get sorted long before this dcument reached IETF = Last Call. Russ From nobody Wed Aug 5 11:24:59 2020 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B38F3A0DE9; Wed, 5 Aug 2020 11:24:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Russ Housley , stir-chairs@ietf.org, housley@vigilsec.com, stir@ietf.org, iesg-secretary@ietf.org Message-ID: <159665189742.10091.1108108625769571911@ietfa.amsl.com> Date: Wed, 05 Aug 2020 11:24:57 -0700 Archived-At: Subject: [stir] Publication has been requested for draft-ietf-stir-cert-delegation-03 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 18:24:58 -0000 Russ Housley has requested publication of draft-ietf-stir-cert-delegation-03 as Proposed Standard on behalf of the STIR working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-stir-cert-delegation/ From nobody Wed Aug 5 21:46:43 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8455E3A0E43 for ; Wed, 5 Aug 2020 21:46:42 -0700 (PDT) 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 FDaTPPlnWyOg for ; Wed, 5 Aug 2020 21:46:41 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 13C2F3A0E3D for ; Wed, 5 Aug 2020 21:46:40 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id h21so29081767qtp.11 for ; Wed, 05 Aug 2020 21:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YIsN9eH6+No1JAg7wsXV2im18gfwK03+DLBlQNsx3VY=; b=GZemGknQulV+OVy679Z3/iMlVprdlfnnMK9rMyld8axrRiRwKLh+EfwwT89GO48EUS hwB58jImoHPKJ90RqquRvpveKeEhV5uqu4h5y/kRE0aFYPPpj7L39pdomS3pdCz3dAHB ILVLEspbCvL4b2475K4aCtNuMK3zoS61o0z/I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YIsN9eH6+No1JAg7wsXV2im18gfwK03+DLBlQNsx3VY=; b=T+EjHfN5NGF9ZLGNfy+xTQlPodWLgmP/BRxkg6TFUZgtNkpPjxGw6K2CUVVRPi3A+s k1Opz24+VQ3LzLKG+NT/MW3uG4xmGhy4RM6fO8NZOm8T5abal67pSIMohZEfLgf+hrLo 4da9NPIXJyuD9DfcCeybMj33UezRHg8KnzQ0gdJ95k2cYYvXosFNkHWCjHSl1XbnjHTW c92tLydgvVSGVeBUzfjV9zA+MHR+aiQ9VWz06EAoof1+nB25CwlrRWesHyKRWWJwWbw1 shBZTaBNVv+KCeal7YWQsk1Y8a3/Y9y2T5H3z9jYv5+eGkAStfz7JtPoQxgaQp0Ulf+d X1gA== X-Gm-Message-State: AOAM533u/ewdOE2qm0txswGYBE49XgBGarIOoCHRcRs0Vpb+xWV3lOAb LDiGESLIj1u9PmOym1+HP2N2/a6wzDM= X-Google-Smtp-Source: ABdhPJyHaJkBQp6MDjNK8ibz/+vH+XvP+yzTnGCXvSHwySNGBknq1TjQOM1TB0+h0Wakrzh90e27ow== X-Received: by 2002:ac8:754e:: with SMTP id b14mr6912718qtr.282.1596689200084; Wed, 05 Aug 2020 21:46:40 -0700 (PDT) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id o48sm4189026qtf.14.2020.08.05.21.46.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2020 21:46:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Sean Turner In-Reply-To: Date: Thu, 6 Aug 2020 00:46:38 -0400 Cc: IETF STIR Mail List Content-Transfer-Encoding: quoted-printable Message-Id: <2C71E130-3845-4337-9C89-591DDC92355C@sn3rd.com> References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <41B1930A-2631-47D3-8693-62363B9C5639@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [stir] Call For Adoption of draft-peterson-stir-servprovider-oob X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 04:46:43 -0000 I support adoption. It=E2=80=99s a concise 8-pager (albeit missing = security considerations :). spt > On Jul 31, 2020, at 11:35, Russ Housley wrote: >=20 > Please take a look at draft-peterson-stir-servprovider-oob. Please = indicate whether you support adoption of this document by the STIR WG. = Please respond before 23 August 2020. If you support adoption, please = indicate whether you would review or implement. >=20 > This document can be found in the datatracker at = https://datatracker.ietf.org/doc/draft-peterson-stir-servprovider-oob/ >=20 > Russ & Robert >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Aug 5 22:37:50 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85293A0EBB for ; Wed, 5 Aug 2020 22:37:48 -0700 (PDT) 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 D5P2BzBrw56y for ; Wed, 5 Aug 2020 22:37:40 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 40D583A0E08 for ; Wed, 5 Aug 2020 22:37:35 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id t23so32402419qto.3 for ; Wed, 05 Aug 2020 22:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=d0S1gufHEIKZ+Aw/KCUuGPESkjChg2BSTKnT44znm8A=; b=VEAALFOf4MBj0lRaBSWO8Mr+HzTTCX7Sdthw+1jjxdGf3jwMj6MjCwge5ffktmsVFN Mre0uoZEZED+NfTUHhHO0KoM11oWaBHTS6j86ROjXU52+wvz6p5zLGgiTDdXpS9CkVbD SirX3pvuoz7HB+Um4i9/8r9JfUb6SyfVtKDxs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=d0S1gufHEIKZ+Aw/KCUuGPESkjChg2BSTKnT44znm8A=; b=U560ORnW+7aSNIejYDwQtEdSSEaavkZYSh1V8dl0zhz+KkaytrQRXklorr6pxWxvpj toUmz3C7dMYRdUg7KSdZmC3iYAbxRUs27YfyVihepRemKy6N6ar2xROJgqjlsN5c478A OVLVc4La2Wt4Zgeblx+1v0EG8qDZW+nKBpmCrXoF8WA1EESjaGQjF8gBSdI4XVyaXTsT BJwlUlgkJ352XO4/JueUJOr1SRSHT+3Seft43LMZzR+govWxIWb4vgbRZGqCqs9zEFLq T0l0aD9/CVuyBkNmQmOXj36JnBchr55Xy40quIIbp3j7I+nSqbYfZpgQCfU//Ce7k/Be /btQ== X-Gm-Message-State: AOAM532fDDJdpbRXUcrCZVp8iCHik3TZmMuRdej0Ztn766P2rzL9LFpL 36zPsv2vpDrUX68z3shcavvitq/W6/k= X-Google-Smtp-Source: ABdhPJwwwmll1J/awdxw7Mb/KNzhi2MKvlGluTJLu7Yu78f6ZVINJbQz7ElC+iZDLsNbNH+qouXduQ== X-Received: by 2002:ac8:22ea:: with SMTP id g39mr7231973qta.146.1596692253513; Wed, 05 Aug 2020 22:37:33 -0700 (PDT) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id l45sm2685286qtf.11.2020.08.05.22.37.32 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2020 22:37:32 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 6 Aug 2020 01:37:31 -0400 References: <8372C576-08B7-41C4-B021-38622BABAD25@vigilsec.com> <919FC584-18AF-4419-B174-B9FB37B6439D@vigilsec.com> To: IETF STIR Mail List In-Reply-To: <919FC584-18AF-4419-B174-B9FB37B6439D@vigilsec.com> Message-Id: <1CFC4EFA-1B05-4278-95EB-B9099328F1E7@sn3rd.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 05:37:49 -0000 Hi! Support moving this one along, and I think these are all minor. 0) I thought the security considerations was missing something about = compromise leading to misuse of network resources, but it=E2=80=99s the = 2nd paragraph of s1. That shows you which section I read first ;) Might = be worth repeating that s1 blurb in s8 or at least referring to it from = s8? Maybe: The security consideration enumerated in Section 1 and the security considerations discussed in [RFC8224], Section 12, are applicable. 1) I hit the nits button (also out of habit) there are a lot unused = references and they can be deleted: =3D=3D Unused Reference: 'RFC3261' is defined on line 275, but no = explicit reference was found in the text =3D=3D Unused Reference: 'RFC8226' is defined on line 305, but no = explicit reference was found in the text =3D=3D Unused Reference: 'RFC7340' is defined on line 322, but no = explicit reference was found in the text =3D=3D Unused Reference: 'RFC7375' is defined on line 327, but no = explicit reference was found in the text =3D=3D Unused Reference: 'RFC8126' is defined on line 331, but no = explicit reference was found in the text 2) Do the examples in s3.1, 3.2, and s4 match the order required in s5? = I.e., shouldn=E2=80=99t the examples be as follow to be in lexicographic = order: s3.1: { "dest":{["uri":"urn:service:sos"]}, "iat":1443208345, "orig":{"tn":"12155551212"}, "rph":{"ESorig":["esnet,x"]} } s3.2: { "dest":{["tn":"12155551212"]}, "iat":1443208345, "orig":{"tn":"12155551213"}, "rph":{"EScallback":["esnet,x"]} } s4: { "dest":{["tn":"12155551212"]}, "iat":1443208345, "orig":{"tn":"12155551213"}, "rph":{"EScallback":["esnet,x"]}, "sph":"psap-callback" } 3) In s3.2, there=E2=80=99s a reference to "r-values=E2=80=9D. What=E2=80=99= s that? 4) Should this =E2=80=9Cshould only=E2=80=9D be a SHOULD: The value of the "sph" claim key SHOULD be "psap-callback=E2=80=9D to match the SIP Priority header field value for authorized emergency services callbacks. 4) In s5, s/order,/order: 5) In s6, should the compact form for =E2=80=98rph=E2=80=99 PASSPORTS be = NOT RECOMMENDED, i.e., OLD: The use of the compact form of PASSporT is not specified in this document or recommended for 'rph' PASSporTs. NEW: The use of the compact form of PASSporT is not specified in this document and it is NOT RECOMMENDED for 'rph' PASSporTs. 6) 2119 and 8174 should be normative references. Cheers, spt > On Jul 31, 2020, at 11:29, Russ Housley wrote: >=20 >=20 > This is the STIR WG Last Call for "Assertion Values for a Resource = Priority Header Claim and a SIP Priority Header Claim in Support of = Emergency Services Networks=E2=80=9D = . Please review the document = and send your comments to the STIR WG mail list by 22 August 2020. >=20 > = https://datatracker.ietf.org/doc/draft-ietf-stir-rph-emergency-services/ >=20 > Thanks, > Robert & Russ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu Aug 6 05:47:53 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1653A0B9E for ; Thu, 6 Aug 2020 05:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 9xy69TaBcZ7W for ; Thu, 6 Aug 2020 05:47:46 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 95B713A0BA0 for ; Thu, 6 Aug 2020 05:47:46 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 076CgZAj015466; Thu, 6 Aug 2020 08:47:46 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 32rfm5a326-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Aug 2020 08:47:46 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 076CliYE017442; Thu, 6 Aug 2020 08:47:45 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 076Clepl017333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Aug 2020 08:47:41 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id D32AE4009E6C; Thu, 6 Aug 2020 12:47:40 +0000 (GMT) Received: from GAALPA1MSGEX1BB.ITServices.sbc.com (unknown [135.50.89.103]) by zlp30486.vci.att.com (Service) with ESMTPS id B5D154009E6B; Thu, 6 Aug 2020 12:47:40 +0000 (GMT) Received: from GAALPA1MSGEX1BE.ITServices.sbc.com (135.50.89.106) by GAALPA1MSGEX1BB.ITServices.sbc.com (135.50.89.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Thu, 6 Aug 2020 08:47:39 -0400 Received: from GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) by GAALPA1MSGEX1BE.ITServices.sbc.com ([135.50.89.106]) with mapi id 15.01.2044.004; Thu, 6 Aug 2020 08:47:39 -0400 From: "DOLLY, MARTIN C" To: Sean Turner , IETF STIR Mail List Thread-Topic: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02 Thread-Index: AQHWZ09yMxJg9WUBj0CEEJMLuBtdw6kq28qAgAA1C5A= Date: Thu, 6 Aug 2020 12:47:38 +0000 Message-ID: <368b707bae3847aaa83f16ad17b88d3a@att.com> References: <8372C576-08B7-41C4-B021-38622BABAD25@vigilsec.com> <919FC584-18AF-4419-B174-B9FB37B6439D@vigilsec.com> <1CFC4EFA-1B05-4278-95EB-B9099328F1E7@sn3rd.com> In-Reply-To: <1CFC4EFA-1B05-4278-95EB-B9099328F1E7@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.177.14] x-tm-snts-smtp: ACCFF10A467C56BA0249AAE705E3F8D0A13C5DF1DD7D903E9B4EC15D712B2B3B2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-06_06:2020-08-06, 2020-08-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 lowpriorityscore=0 clxscore=1011 mlxlogscore=999 phishscore=0 malwarescore=0 priorityscore=1501 mlxscore=0 impostorscore=0 adultscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008060091 Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 12:47:51 -0000 SSBzdXBwb3J0IGFzIHdlbGwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHN0 aXIgPHN0aXItYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFNlYW4gVHVybmVyDQpTZW50 OiBUaHVyc2RheSwgQXVndXN0IDYsIDIwMjAgMTozOCBBTQ0KVG86IElFVEYgU1RJUiBNYWlsIExp c3QgPHN0aXJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3N0aXJdIFdHIExhc3QgQ2FsbCBmb3Ig ZHJhZnQtaWV0Zi1zdGlyLXJwaC1lbWVyZ2VuY3ktc2VydmljZXMtMDINCg0KSGkhDQoNClN1cHBv cnQgbW92aW5nIHRoaXMgb25lIGFsb25nLCBhbmQgSSB0aGluayB0aGVzZSBhcmUgYWxsIG1pbm9y Lg0KDQowKSBJIHRob3VnaHQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdhcyBtaXNzaW5n IHNvbWV0aGluZyBhYm91dCBjb21wcm9taXNlIGxlYWRpbmcgdG8gbWlzdXNlIG9mIG5ldHdvcmsg cmVzb3VyY2VzLCBidXQgaXTigJlzIHRoZSAybmQgcGFyYWdyYXBoIG9mIHMxLiBUaGF0IHNob3dz IHlvdSB3aGljaCBzZWN0aW9uIEkgcmVhZCBmaXJzdCA7KSBNaWdodCBiZSB3b3J0aCByZXBlYXRp bmcgdGhhdCBzMSBibHVyYiBpbiBzOCBvciBhdCBsZWFzdCByZWZlcnJpbmcgdG8gaXQgZnJvbSBz OD8gTWF5YmU6DQoNCiAgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gZW51bWVyYXRlZCBpbg0K ICBTZWN0aW9uIDEgYW5kIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkaXNjdXNzZWQNCiAg aW4gW1JGQzgyMjRdLCBTZWN0aW9uIDEyLCBhcmUgYXBwbGljYWJsZS4NCg0KMSkgSSBoaXQgdGhl IG5pdHMgYnV0dG9uIChhbHNvIG91dCBvZiBoYWJpdCkgdGhlcmUgYXJlIGEgbG90IHVudXNlZCBy ZWZlcmVuY2VzIGFuZCB0aGV5IGNhbiBiZSBkZWxldGVkOg0KDQo9PSBVbnVzZWQgUmVmZXJlbmNl OiAnUkZDMzI2MScgaXMgZGVmaW5lZCBvbiBsaW5lIDI3NSwgYnV0IG5vIGV4cGxpY2l0DQogICBy ZWZlcmVuY2Ugd2FzIGZvdW5kIGluIHRoZSB0ZXh0DQoNCj09IFVudXNlZCBSZWZlcmVuY2U6ICdS RkM4MjI2JyBpcyBkZWZpbmVkIG9uIGxpbmUgMzA1LCBidXQgbm8gZXhwbGljaXQNCiAgIHJlZmVy ZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRleHQNCg0KPT0gVW51c2VkIFJlZmVyZW5jZTogJ1JGQzcz NDAnIGlzIGRlZmluZWQgb24gbGluZSAzMjIsIGJ1dCBubyBleHBsaWNpdA0KICAgcmVmZXJlbmNl IHdhcyBmb3VuZCBpbiB0aGUgdGV4dA0KDQo9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDNzM3NScg aXMgZGVmaW5lZCBvbiBsaW5lIDMyNywgYnV0IG5vIGV4cGxpY2l0DQogICByZWZlcmVuY2Ugd2Fz IGZvdW5kIGluIHRoZSB0ZXh0DQoNCj09IFVudXNlZCBSZWZlcmVuY2U6ICdSRkM4MTI2JyBpcyBk ZWZpbmVkIG9uIGxpbmUgMzMxLCBidXQgbm8gZXhwbGljaXQNCiAgIHJlZmVyZW5jZSB3YXMgZm91 bmQgaW4gdGhlIHRleHQNCg0KMikgRG8gdGhlIGV4YW1wbGVzIGluIHMzLjEsIDMuMiwgYW5kIHM0 IG1hdGNoIHRoZSBvcmRlciByZXF1aXJlZCBpbiBzNT8gSS5lLiwgc2hvdWxkbuKAmXQgdGhlIGV4 YW1wbGVzIGJlIGFzIGZvbGxvdyB0byBiZSBpbiBsZXhpY29ncmFwaGljIG9yZGVyOg0KDQpzMy4x Og0Kew0KICJkZXN0Ijp7WyJ1cmkiOiJ1cm46c2VydmljZTpzb3MiXX0sDQogImlhdCI6MTQ0MzIw ODM0NSwNCiAib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn0sDQogInJwaCI6eyJFU29yaWciOlsi ZXNuZXQseCJdfQ0KfQ0KDQpzMy4yOg0Kew0KICJkZXN0Ijp7WyJ0biI6IjEyMTU1NTUxMjEyIl19 LA0KICJpYXQiOjE0NDMyMDgzNDUsDQogIm9yaWciOnsidG4iOiIxMjE1NTU1MTIxMyJ9LA0KICJy cGgiOnsiRVNjYWxsYmFjayI6WyJlc25ldCx4Il19DQp9DQoNCnM0Og0Kew0KICJkZXN0Ijp7WyJ0 biI6IjEyMTU1NTUxMjEyIl19LA0KICJpYXQiOjE0NDMyMDgzNDUsDQogIm9yaWciOnsidG4iOiIx MjE1NTU1MTIxMyJ9LA0KICJycGgiOnsiRVNjYWxsYmFjayI6WyJlc25ldCx4Il19LA0KICJzcGgi OiJwc2FwLWNhbGxiYWNrIg0KfQ0KDQozKSBJbiBzMy4yLCB0aGVyZeKAmXMgYSByZWZlcmVuY2Ug dG8gInItdmFsdWVz4oCdLiBXaGF04oCZcyB0aGF0Pw0KDQo0KSBTaG91bGQgdGhpcyDigJxzaG91 bGQgb25seeKAnSBiZSBhIFNIT1VMRDoNCg0KIFRoZSB2YWx1ZSBvZiB0aGUgInNwaCIgY2xhaW0g a2V5IFNIT1VMRCBiZSAicHNhcC1jYWxsYmFja+KAnQ0KIHRvIG1hdGNoIHRoZSBTSVAgUHJpb3Jp dHkgaGVhZGVyIGZpZWxkIHZhbHVlIGZvciBhdXRob3JpemVkICBlbWVyZ2VuY3kgc2VydmljZXMg Y2FsbGJhY2tzLg0KDQo0KSBJbiBzNSwgcy9vcmRlciwvb3JkZXI6DQoNCjUpIEluIHM2LCBzaG91 bGQgdGhlIGNvbXBhY3QgZm9ybSBmb3Ig4oCYcnBo4oCZIFBBU1NQT1JUUyBiZSBOT1QgUkVDT01N RU5ERUQsIGkuZS4sDQoNCk9MRDoNCg0KICBUaGUgdXNlIG9mIHRoZSBjb21wYWN0IGZvcm0gb2Yg UEFTU3BvclQgaXMgbm90IHNwZWNpZmllZCBpbiB0aGlzDQogIGRvY3VtZW50IG9yIHJlY29tbWVu ZGVkIGZvciAncnBoJyBQQVNTcG9yVHMuDQoNCk5FVzoNCg0KICBUaGUgdXNlIG9mIHRoZSBjb21w YWN0IGZvcm0gb2YgUEFTU3BvclQgaXMgbm90IHNwZWNpZmllZCBpbiB0aGlzDQogIGRvY3VtZW50 IGFuZCBpdCBpcyBOT1QgUkVDT01NRU5ERUQgZm9yICdycGgnIFBBU1Nwb3JUcy4NCg0KNikgMjEx OSBhbmQgODE3NCBzaG91bGQgYmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMuDQoNCkNoZWVycywNCg0K c3B0DQoNCj4gT24gSnVsIDMxLCAyMDIwLCBhdCAxMToyOSwgUnVzcyBIb3VzbGV5IDxob3VzbGV5 QHZpZ2lsc2VjLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4gVGhpcyBpcyB0aGUgU1RJUiBXRyBMYXN0 IENhbGwgZm9yICJBc3NlcnRpb24gVmFsdWVzIGZvciBhIFJlc291cmNlIFByaW9yaXR5IEhlYWRl ciBDbGFpbSBhbmQgYSBTSVAgUHJpb3JpdHkgSGVhZGVyIENsYWltIGluIFN1cHBvcnQgb2YgRW1l cmdlbmN5IFNlcnZpY2VzIE5ldHdvcmtz4oCdIDxkcmFmdC1pZXRmLXN0aXItcnBoLWVtZXJnZW5j eS1zZXJ2aWNlcy0wMj4uICBQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCBhbmQgc2VuZCB5b3Vy IGNvbW1lbnRzIHRvIHRoZSBTVElSIFdHIG1haWwgbGlzdCBieSAyMiBBdWd1c3QgMjAyMC4NCj4g DQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f ZGF0YXRyYWNrZXIuaWV0Zi4NCj4gb3JnX2RvY19kcmFmdC0yRGlldGYtMkRzdGlyLTJEcnBoLTJE ZW1lcmdlbmN5LTJEc2VydmljZXNfJmQ9RHdJR2FRJmM9TA0KPiBGWVotbzlfSFVNZU1UU1FpY3Zq SWcmcj1HOXY4dUNTU1FoQ21wdzdJdEcwcjJnJm09cmMzQktEMEYxQTg2LUNScFljTnByDQo+IDNt czcwSHVRdEtOWTRDSERPd0xGaTQmcz13cmhmRkIwcy1FNHVPa3JpQnY5aDZkWGE3MjI2N0sxSjFm eXpfQmlCa05RJmUNCj4gPQ0KPiANCj4gVGhhbmtzLA0KPiBSb2JlcnQgJiBSdXNzDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzdGlyIG1h aWxpbmcgbGlzdA0KPiBzdGlyQGlldGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWwNCj4gbWFuX2xpc3Rp bmZvX3N0aXImZD1Ed0lHYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9Rzl2OHVDU1NRaENt cHc3SQ0KPiB0RzByMmcmbT1yYzNCS0QwRjFBODYtQ1JwWWNOcHIzbXM3MEh1UXRLTlk0Q0hET3dM Rmk0JnM9WktLc3I2dHNwVy1rYmZqDQo+IG5jb1A2aER6TzVzZ1RLNzNrenA3djhHcks5ejAmZT0N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnN0aXIg bWFpbGluZyBsaXN0DQpzdGlyQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3N0 aXImZD1Ed0lHYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9Rzl2OHVDU1NRaENtcHc3SXRH MHIyZyZtPXJjM0JLRDBGMUE4Ni1DUnBZY05wcjNtczcwSHVRdEtOWTRDSERPd0xGaTQmcz1aS0tz cjZ0c3BXLWtiZmpuY29QNmhEek81c2dUSzcza3pwN3Y4R3JLOXowJmU9IA0K From nobody Thu Aug 6 07:12:30 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B6D3A07A0 for ; Thu, 6 Aug 2020 07:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 kUBXAlJutOvz for ; Thu, 6 Aug 2020 07:12:27 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2061.outbound.protection.outlook.com [40.107.223.61]) (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 F404B3A079E for ; Thu, 6 Aug 2020 07:12:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HUDgnoC+FuiJxbOfpbehfCEvMy5Ww9e5DJm3OCCVTAm+0o63fRJpijsWnsLTSRxIM/Fqg4P6qBzMgL4vH5NZbuRerh+sqCTgo+QhcWQo+RrYB+dZWQ6YJqVDAgSOsAaZIec+hORI8obTxAATRJNnbcD9eA4Yi+KI2DXsls+duQYuSnFODyDsLdZAH8naFWlPGFCKbdOMvQiS5DJZssI33mnwypp6q8lH7Kfuux9rvgsu1AeMe3kybeohN3vzF99SI4BiadPpvc21msP13iPoJnQ9W40or8nCx8DC5kbL9gEuuM43g6jPo6MMXEaLKSMi1wePkJyqpXCN/eI/+PQtvQ== 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-SenderADCheck; bh=w1a7hjzDSABWYknljBVLpfGL8RbhDrXQNtaf4v1TuPs=; b=j7qVInQclSYvJRrFatjypxovMP5JHSLEkN9drBMAU4SF/mhq1Nj+/0c7n5XwCriHcqZmfW9u8nWPfn7gbEdU94ayzKzXI0z46koqhuBPyExNYlwJdtxS8A63hl2Y98J9G07YXvu7kFRKCPv90AAfuoQPrMIWvY9KKccLDQgWTWj66Yp8tq3nzicsQZ5+hBfegnuuvIoz4h+cuxNq509FPBf3kaGR+NDwDRliXVVASGk3V1pK7hUdp/EydqKPiV6gZ/xJ+eEt4rWji98eq6a39vlQYxnpWuiZDD7IENJQs7BhKvqzavfgzL7GEUWHz7SmRcZAZabNpwX/5yXOGCVHZw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; 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=w1a7hjzDSABWYknljBVLpfGL8RbhDrXQNtaf4v1TuPs=; b=aaSVXBebSMSmvLOJdbR+q7rhs/h4GTjfpMZZ6Zm6GCfDjd3oykSh2IQkdj/xcXggq46N3z15OQIPl9v0DXK/SYxbuLhUGnTTm1Cg4/SDsn8rMP90F4IfKKg6Df+3jcU/5CxDGkdLKsX3rcv21qDrbGyo9vixd33retuSWK7ONb4= Received: from BN8PR15MB3169.namprd15.prod.outlook.com (2603:10b6:408:72::24) by BN8PR15MB2995.namprd15.prod.outlook.com (2603:10b6:408:8a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.21; Thu, 6 Aug 2020 14:12:24 +0000 Received: from BN8PR15MB3169.namprd15.prod.outlook.com ([fe80::99aa:38de:92aa:2fcb]) by BN8PR15MB3169.namprd15.prod.outlook.com ([fe80::99aa:38de:92aa:2fcb%5]) with mapi id 15.20.3239.023; Thu, 6 Aug 2020 14:12:24 +0000 From: Hala Mowafy To: Russ Housley , IETF STIR Mail List CC: Theresa Reese Thread-Topic: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02 Thread-Index: AQHWZ0914uCK/pPHcEqSsDl9Y81rQqkrJ4og Date: Thu, 6 Aug 2020 14:12:24 +0000 Message-ID: References: <8372C576-08B7-41C4-B021-38622BABAD25@vigilsec.com> <919FC584-18AF-4419-B174-B9FB37B6439D@vigilsec.com> In-Reply-To: <919FC584-18AF-4419-B174-B9FB37B6439D@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [71.104.17.152] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7adbe2ca-f42b-4547-b77d-08d83a12be26 x-ms-traffictypediagnostic: BN8PR15MB2995: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3631; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ie6UGUVn+qK6zZ2iTXr7y6Ga4ZD8p+Je77fqye+GChSKqtJw0HkRAAjkqNwB/P14eTx479j3mWtYO304sOh91X2SmdNKZd+XitUJuGYGrUteZeizNOFVWzrA85PRJ97WKZAS8PJExZZwslSWx8EbK/k+AkuB8My702OdxRDPw/BVIRxo9lk8RHw4XohBUwRhj1Jgiuta0y9nALJvNo5RCOvkGdZ5WzJb9hgxwR/BZOjlA0W77nsavo/+/RvFPfX22q5muevVXpshsxwf0/3jBcdcBbz4QrWcG5+dAqsejztqXuUBwJpB3QYF+epj2cBZnmW78nNJ8fxR2Evv98JhEaTtV51bBZxwnXfPih1S1IHzKBRjzuJQHqeb3ZuOL8RF7wlOWLNXD070a8GU2u6/zg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR15MB3169.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(136003)(39860400002)(366004)(346002)(83380400001)(66446008)(64756008)(66476007)(66556008)(26005)(76116006)(8936002)(7696005)(110136005)(6506007)(107886003)(4326008)(53546011)(71200400001)(316002)(66946007)(9686003)(55016002)(478600001)(8676002)(966005)(33656002)(52536014)(86362001)(5660300002)(44832011)(186003)(4744005)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: RfUE6DS64f2+Qv62OtP7GT3HvEYnI7phFyuAMHkeNriI4vSf8o7rv9gM5Fl2+4m8wSlpPKpm2jkzgGv4aBEzdE9tAyOJ1/nGSW5p84f31O5FxONk4RPQ25hBOjwWr8fyuO9iJs3j+WBdKssN4NQH8q3n9OQY9+yPbgOCpalX9CjmDPszVYHxnIOq1C1Lwu2V1PUmAzQ/Z14ii3d6U42VImdrP3dSKTdVq3Ac6qv/HYuRpgmAoHtyELQ4hO9uTAW6m44enIQ+nuFURbw8b++8S15kqzkSeZQHmBL9IWCw7VnTqBS9hlNK0qCETcAdwYBCntAGrpQurJb7o8EUVi4kyrbd9Y72RLXHMrXF0UKC9dq4gFRwjvb7JM4xPrKo7vp3DuWk+iwB7DySlvYm+riC4CYH99jyFRz8fdDtBDS0lWjSmsb0ojWOQSDHva0R2bqO2TIcmUXsIj/Gj83/yZNAtwrOP8juLPhBswbheqDqspx5M7wAcfi+KNuBQBM+y5Vji6dh3qIwqXx1vOo0UBHsMI5Lt50Wv0QSshK16Ple4TiREVVyxMq/+0DYwC+Xmk3uXSFc5+/mvmloz7zzchzuAJCwRp5A/UKHuUlWaQoB8fxb5z3mUm5/mBwZFaQjpce/P8fJ8LQas8hwJNNwilGVFA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN8PR15MB3169.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7adbe2ca-f42b-4547-b77d-08d83a12be26 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2020 14:12:24.4607 (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: P7QvfO2U6YElOI3tufbxFfJqB+QVAj4g754Byb2ZGEG60lz5oHyaJCp7vSF3aFiB3pf5Ti/BLyhsxmPFeQ9SUXuYW0oIhd1FMUqvnOy7hUQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR15MB2995 Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 14:12:28 -0000 Ericsson supports moving this along. Hala -----Original Message----- From: stir On Behalf Of Russ Housley Sent: Friday, July 31, 2020 11:30 AM To: IETF STIR Mail List Subject: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02 This is the STIR WG Last Call for "Assertion Values for a Resource Priority= Header Claim and a SIP Priority Header Claim in Support of Emergency Servi= ces Networks" . Please review t= he document and send your comments to the STIR WG mail list by 22 August 20= 20. https://datatracker.ietf.org/doc/draft-ietf-stir-rph-emergency-services/ Thanks, Robert & Russ _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Thu Aug 6 07:18:36 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE53E3A077E for ; Thu, 6 Aug 2020 07:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 vCyE2qxblVVj for ; Thu, 6 Aug 2020 07:18:34 -0700 (PDT) Received: from gateway34.websitewelcome.com (gateway34.websitewelcome.com [192.185.149.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E763A0763 for ; Thu, 6 Aug 2020 07:18:33 -0700 (PDT) Received: from cm17.websitewelcome.com (cm17.websitewelcome.com [100.42.49.20]) by gateway34.websitewelcome.com (Postfix) with ESMTP id 7D7EFE1C41D for ; Thu, 6 Aug 2020 09:18:33 -0500 (CDT) Received: from box5527.bluehost.com ([162.241.218.19]) by cmsmtp with SMTP id 3gj3kU81kdbRz3gj3kVqBB; Thu, 06 Aug 2020 09:18:33 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=UY/wwOy9BxrSctOSzYGcMmdupJF+10vLPsRVBrOu4Sg=; b=oIT9xdQiJ/00JCZclzs+JRM1nY zxPpSY7Uf3eNVM3DUhTEBbwuo1FojqLBrb2xcTnyOe7Gcc5IlKo/WIRtDnBY7tblL/5wEe5BhcRZ+ l5qj1HF4zARhw+CNXwairD2nm; Received: from pool-100-36-18-145.washdc.fios.verizon.net ([100.36.18.145]:49933 helo=[192.168.1.156]) by box5527.bluehost.com with esmtpa (Exim 4.93) (envelope-from ) id 1k3gj3-0027lr-2F; Thu, 06 Aug 2020 08:18:33 -0600 User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Thu, 06 Aug 2020 10:18:30 -0400 From: Richard Shockey To: Sean Turner , IETF STIR Mail List Message-ID: <692801DA-E036-4F4B-B4D7-88E575DC9292@shockey.us> Thread-Topic: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02 References: <8372C576-08B7-41C4-B021-38622BABAD25@vigilsec.com> <919FC584-18AF-4419-B174-B9FB37B6439D@vigilsec.com> <1CFC4EFA-1B05-4278-95EB-B9099328F1E7@sn3rd.com> <368b707bae3847aaa83f16ad17b88d3a@att.com> In-Reply-To: <368b707bae3847aaa83f16ad17b88d3a@att.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5527.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.18.145 X-Source-L: No X-Exim-ID: 1k3gj3-0027lr-2F X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-18-145.washdc.fios.verizon.net ([192.168.1.156]) [100.36.18.145]:49933 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NTUyNy5ibHVlaG9zdC5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 14:18:36 -0000 +1 I support this as well.=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 =EF=BB=BFOn 8/6/20, 8:47 AM, "stir on behalf of DOLLY, MARTIN C" wrote: I support as well -----Original Message----- From: stir On Behalf Of Sean Turner Sent: Thursday, August 6, 2020 1:38 AM To: IETF STIR Mail List Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-serv= ices-02 Hi! Support moving this one along, and I think these are all minor. 0) I thought the security considerations was missing something about co= mpromise leading to misuse of network resources, but it=E2=80=99s the 2nd paragrap= h of s1. That shows you which section I read first ;) Might be worth repeati= ng that s1 blurb in s8 or at least referring to it from s8? Maybe: The security consideration enumerated in Section 1 and the security considerations discussed in [RFC8224], Section 12, are applicable. 1) I hit the nits button (also out of habit) there are a lot unused ref= erences and they can be deleted: =3D=3D Unused Reference: 'RFC3261' is defined on line 275, but no explicit reference was found in the text =3D=3D Unused Reference: 'RFC8226' is defined on line 305, but no explicit reference was found in the text =3D=3D Unused Reference: 'RFC7340' is defined on line 322, but no explicit reference was found in the text =3D=3D Unused Reference: 'RFC7375' is defined on line 327, but no explicit reference was found in the text =3D=3D Unused Reference: 'RFC8126' is defined on line 331, but no explicit reference was found in the text 2) Do the examples in s3.1, 3.2, and s4 match the order required in s5?= I.e., shouldn=E2=80=99t the examples be as follow to be in lexicographic order: s3.1: { "dest":{["uri":"urn:service:sos"]}, "iat":1443208345, "orig":{"tn":"12155551212"}, "rph":{"ESorig":["esnet,x"]} } s3.2: { "dest":{["tn":"12155551212"]}, "iat":1443208345, "orig":{"tn":"12155551213"}, "rph":{"EScallback":["esnet,x"]} } s4: { "dest":{["tn":"12155551212"]}, "iat":1443208345, "orig":{"tn":"12155551213"}, "rph":{"EScallback":["esnet,x"]}, "sph":"psap-callback" } 3) In s3.2, there=E2=80=99s a reference to "r-values=E2=80=9D. What=E2=80=99s that? 4) Should this =E2=80=9Cshould only=E2=80=9D be a SHOULD: The value of the "sph" claim key SHOULD be "psap-callback=E2=80=9D to match the SIP Priority header field value for authorized emergency= services callbacks. 4) In s5, s/order,/order: 5) In s6, should the compact form for =E2=80=98rph=E2=80=99 PASSPORTS be NOT RECOMM= ENDED, i.e., OLD: The use of the compact form of PASSporT is not specified in this document or recommended for 'rph' PASSporTs. NEW: The use of the compact form of PASSporT is not specified in this document and it is NOT RECOMMENDED for 'rph' PASSporTs. 6) 2119 and 8174 should be normative references. Cheers, spt > On Jul 31, 2020, at 11:29, Russ Housley wrote: >=20 >=20 > This is the STIR WG Last Call for "Assertion Values for a Resource Pr= iority Header Claim and a SIP Priority Header Claim in Support of Emergency = Services Networks=E2=80=9D . Please re= view the document and send your comments to the STIR WG mail list by 22 Augu= st 2020. >=20 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf= . > org_doc_draft-2Dietf-2Dstir-2Drph-2Demergency-2Dservices_&d=3DDwIGaQ&c=3D= L > FYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&m=3Drc3BKD0F1A86-CRpYcNp= r > 3ms70HuQtKNY4CHDOwLFi4&s=3DwrhfFB0s-E4uOkriBv9h6dXa72267K1J1fyz_BiBkNQ&= e > =3D >=20 > Thanks, > Robert & Russ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= l > man_listinfo_stir&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7= I > tG0r2g&m=3Drc3BKD0F1A86-CRpYcNpr3ms70HuQtKNY4CHDOwLFi4&s=3DZKKsr6tspW-kbf= j > ncoP6hDzO5sgTK73kzp7v8GrK9z0&e=3D _______________________________________________ stir mailing list stir@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_stir&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0r2g&= m=3Drc3BKD0F1A86-CRpYcNpr3ms70HuQtKNY4CHDOwLFi4&s=3DZKKsr6tspW-kbfjncoP6hDzO5sgT= K73kzp7v8GrK9z0&e=3D=20 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Thu Aug 6 09:03:48 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CAD3A0AEC for ; Thu, 6 Aug 2020 09:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.028 X-Spam-Level: X-Spam-Status: No, score=-3.028 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.949, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtDuTMl5JGo7 for ; Thu, 6 Aug 2020 09:03:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997213A0A82 for ; Thu, 6 Aug 2020 09:03:44 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 076G3f9i056409 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 6 Aug 2020 11:03:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1596729822; bh=ppHtfnmU5nGlhsUCYHNyILvM/vg8/nfFt5HdI5Aj2n8=; h=Subject:To:References:From:Date:In-Reply-To; b=EpndGtRKsudIJdCy9rxLA+PrsiUOJzusex9Bjb51g/koc8hirEdonNBriRsfgZhnD 5sdy9578kVpPhA2Cyo+TtX5KgxyC343tAp6TkpW+70w3+x/o44The7IvgJxj2WMO8J jTCF84vdBSSIQ/OCXab7CvRHxdSUmeVQxrw5Eibs= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: stir@ietf.org References: <8372C576-08B7-41C4-B021-38622BABAD25@vigilsec.com> <919FC584-18AF-4419-B174-B9FB37B6439D@vigilsec.com> <1CFC4EFA-1B05-4278-95EB-B9099328F1E7@sn3rd.com> <368b707bae3847aaa83f16ad17b88d3a@att.com> <692801DA-E036-4F4B-B4D7-88E575DC9292@shockey.us> From: Robert Sparks Message-ID: <2d6df956-653b-1838-6afd-b468dc8b98cd@nostrum.com> Date: Thu, 6 Aug 2020 11:03:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <692801DA-E036-4F4B-B4D7-88E575DC9292@shockey.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 16:03:47 -0000 It would be far more useful for me to hear "I have read this draft and see nothing that I think needs to change before sending it to IETF LC" than to hear +1 for support. Is that what the +1s so far mean? RjS On 8/6/20 9:18 AM, Richard Shockey wrote: > +1 I support this as well. > > — > Richard Shockey > > Shockey Consulting LLC > > Chairman of the Board SIP Forum > > www.shockey.us > > www.sipforum.org > > richardshockey.us > > Skype-Linkedin-Facebook –Twitter rshockey101 > > PSTN +1 703-593-2683 > > > > On 8/6/20, 8:47 AM, "stir on behalf of DOLLY, MARTIN C" wrote: > > I support as well > > -----Original Message----- > From: stir On Behalf Of Sean Turner > Sent: Thursday, August 6, 2020 1:38 AM > To: IETF STIR Mail List > Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02 > > Hi! > > Support moving this one along, and I think these are all minor. > > 0) I thought the security considerations was missing something about compromise leading to misuse of network resources, but it’s the 2nd paragraph of s1. That shows you which section I read first ;) Might be worth repeating that s1 blurb in s8 or at least referring to it from s8? Maybe: > > The security consideration enumerated in > Section 1 and the security considerations discussed > in [RFC8224], Section 12, are applicable. > > 1) I hit the nits button (also out of habit) there are a lot unused references and they can be deleted: > > == Unused Reference: 'RFC3261' is defined on line 275, but no explicit > reference was found in the text > > == Unused Reference: 'RFC8226' is defined on line 305, but no explicit > reference was found in the text > > == Unused Reference: 'RFC7340' is defined on line 322, but no explicit > reference was found in the text > > == Unused Reference: 'RFC7375' is defined on line 327, but no explicit > reference was found in the text > > == Unused Reference: 'RFC8126' is defined on line 331, but no explicit > reference was found in the text > > 2) Do the examples in s3.1, 3.2, and s4 match the order required in s5? I.e., shouldn’t the examples be as follow to be in lexicographic order: > > s3.1: > { > "dest":{["uri":"urn:service:sos"]}, > "iat":1443208345, > "orig":{"tn":"12155551212"}, > "rph":{"ESorig":["esnet,x"]} > } > > s3.2: > { > "dest":{["tn":"12155551212"]}, > "iat":1443208345, > "orig":{"tn":"12155551213"}, > "rph":{"EScallback":["esnet,x"]} > } > > s4: > { > "dest":{["tn":"12155551212"]}, > "iat":1443208345, > "orig":{"tn":"12155551213"}, > "rph":{"EScallback":["esnet,x"]}, > "sph":"psap-callback" > } > > 3) In s3.2, there’s a reference to "r-values”. What’s that? > > 4) Should this “should only” be a SHOULD: > > The value of the "sph" claim key SHOULD be "psap-callback” > to match the SIP Priority header field value for authorized emergency services callbacks. > > 4) In s5, s/order,/order: > > 5) In s6, should the compact form for ‘rph’ PASSPORTS be NOT RECOMMENDED, i.e., > > OLD: > > The use of the compact form of PASSporT is not specified in this > document or recommended for 'rph' PASSporTs. > > NEW: > > The use of the compact form of PASSporT is not specified in this > document and it is NOT RECOMMENDED for 'rph' PASSporTs. > > 6) 2119 and 8174 should be normative references. > > Cheers, > > spt > > > On Jul 31, 2020, at 11:29, Russ Housley wrote: > > > > > > This is the STIR WG Last Call for "Assertion Values for a Resource Priority Header Claim and a SIP Priority Header Claim in Support of Emergency Services Networks” . Please review the document and send your comments to the STIR WG mail list by 22 August 2020. > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf. > > org_doc_draft-2Dietf-2Dstir-2Drph-2Demergency-2Dservices_&d=DwIGaQ&c=L > > FYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rc3BKD0F1A86-CRpYcNpr > > 3ms70HuQtKNY4CHDOwLFi4&s=wrhfFB0s-E4uOkriBv9h6dXa72267K1J1fyz_BiBkNQ&e > > = > > > > Thanks, > > Robert & Russ > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > > man_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7I > > tG0r2g&m=rc3BKD0F1A86-CRpYcNpr3ms70HuQtKNY4CHDOwLFi4&s=ZKKsr6tspW-kbfj > > ncoP6hDzO5sgTK73kzp7v8GrK9z0&e= > > _______________________________________________ > stir mailing list > stir@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rc3BKD0F1A86-CRpYcNpr3ms70HuQtKNY4CHDOwLFi4&s=ZKKsr6tspW-kbfjncoP6hDzO5sgTK73kzp7v8GrK9z0&e= > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu Aug 6 11:32:17 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FAC3A0DAF for ; Thu, 6 Aug 2020 11:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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=brianrosen-net.20150623.gappssmtp.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 zYuTKwQfy_Ug for ; Thu, 6 Aug 2020 11:32:14 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 E1AC03A0DAE for ; Thu, 6 Aug 2020 11:32:13 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id s189so43392321iod.2 for ; Thu, 06 Aug 2020 11:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KjFhjprC8gZejSRfDVXnvxHLpnaWQJT7FkFtDCgVFmQ=; b=OprzI9b8icY/4FgKluuBtFPBQp9sUy5O4dlRkmf/S18iwpdEM8LKrw5ZKu+cCVSLtS TSVYXPW4lAGuiMQ8yjSeUwbED/aBRGwBEGjdXEDninbyeabIRWWyMncuYNm4d5lXaKHD WDEimbuVq5gHJ49dvUuXf8mBnjEsS3M84lEvslTWdx3hggD4btJzUms2BnhynV75FkmN f1J74RwSDDIES938X7n2kzxyH+WbMZOQaa5LqJ2db/e5laAzrx9GsdcjfPBss4uWuuNg 8nXlMqrWcDr3Q/3KggVYKNIuZelqP1HOoX2Rwvg/4Gv/D+q7lExAcsjrXBVAkBab7wqC +yhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KjFhjprC8gZejSRfDVXnvxHLpnaWQJT7FkFtDCgVFmQ=; b=XdPvzR0HT2zoJMneTElaLvTr4E4qTeaoqSHnjizbj6oJytC5+DCowH6WMqA30dNBr5 SyBGmq6k2zZyrqe85X5wBdARpm09Evb1hdErDdlmFJFidzUx58eDHFBbPvslAQU7EGA3 9lZvbVRBxPdgrafN87cQWSBRggBngwSywYzqE1utaySA1T8bDhSD1GIAHam9OCXLXGeu 3lEV0b3+fVTK93ILwdxy1N1rhb24MKlmE//+GYKanU3xCR5k5YCmFzxTJyl1JBQbnHkd CRiUufjxe/w8QakhvXn+gKztY1gUszNFsOpnWSLZr57TvtNkmk8j1wim096v/c31n3Uw bgkw== X-Gm-Message-State: AOAM532JTJShsCbNRl2RzgosBfS8DiCYRF0ko/BM9A92/rXs9dYA9WSa 4yeNSrge2pj4P46BoJ3w5KaDNa4kmJU= X-Google-Smtp-Source: ABdhPJzHPi0Ott17ANdKAxOcV63ZSdTEYiuM2M8o7c35/J0AIVo29yeHuCiv9o0dQjrm+rLywj0/VA== X-Received: by 2002:a5e:c311:: with SMTP id a17mr359493iok.12.1596738733172; Thu, 06 Aug 2020 11:32:13 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id m14sm4716683ild.4.2020.08.06.11.32.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Aug 2020 11:32:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Brian Rosen In-Reply-To: <919FC584-18AF-4419-B174-B9FB37B6439D@vigilsec.com> Date: Thu, 6 Aug 2020 14:32:10 -0400 Cc: IETF STIR Mail List Content-Transfer-Encoding: quoted-printable Message-Id: References: <8372C576-08B7-41C4-B021-38622BABAD25@vigilsec.com> <919FC584-18AF-4419-B174-B9FB37B6439D@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 18:32:16 -0000 We need to make a decision on what to reference for the emergency stuff. = I currently references my explanatory draft. We discussed in the = meeting on the rcd topic the proper separation of the stir mechanism = that defines the PASSporT and the SIP mechanism that shows how it=E2=80=99= s used. I will definitely create and push through a sip mechanism draft = updating RFC6881 to cover how we use RPH and Priority. But should I = push the explanatory draft through to an RFC so we can reference it? = I=E2=80=99m thinking not. If that=E2=80=99s what we decide, then the = reference would be to the mechanism document. The reference to urn:service:sos is RFC5031. Section 3.2 =E2=80=9CWhen using "EScallback" as the "rph" assertion = value, the "orig" claim of the PASSporT MUST represent the emergency = network telephone number. =E2=80=9C No idea what =E2=80=9Cemergency = network telephone number is=E2=80=9D. Maybe =E2=80=9Cthe telephone = number used by the emergency services for call back, or a country or = region specific dial string=E2=80=9D. I believe that won=E2=80=99t = conflict with any text on authority (i.e. who has authority for a dial = string would be determined by the same authorities who handle telephone = numbers in a country or region).=20 Other than that, I=E2=80=99ve reviewed it and think it=E2=80=99s ready = to go. Brian > On Jul 31, 2020, at 11:29 AM, Russ Housley = wrote: >=20 >=20 > This is the STIR WG Last Call for "Assertion Values for a Resource = Priority Header Claim and a SIP Priority Header Claim in Support of = Emergency Services Networks=E2=80=9D = . Please review the document = and send your comments to the STIR WG mail list by 22 August 2020. >=20 > = https://datatracker.ietf.org/doc/draft-ietf-stir-rph-emergency-services/ >=20 > Thanks, > Robert & Russ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu Aug 6 13:44:16 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697273A0ECA for ; Thu, 6 Aug 2020 13:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRhe-j8FZPpJ for ; Thu, 6 Aug 2020 13:44:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2F03A0EC2 for ; Thu, 6 Aug 2020 13:44:14 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 076KiAx4070280 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Aug 2020 15:44:11 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1596746653; bh=eMbQf6dvkeUp4sYv+43KXAMFEZzkobWVL3gfYdcNcTg=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=lylFgp4vWwoDDq+AVKAsdJ4J69Hs8PRo5uo/+X4C68Is/0/DiGxs7IyNI/kKc+6nl RDzBxjbWd9YtJN/C2yh26FOiIPHkJ6KvgvMWR5VnKNZ67rFLpSBUkIXTt37nmDixzF T6BefPODFNYXVxm2UKv5RjB/tF3eGUXZ4yIlYaos= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <36279CF2-3272-4D9F-BDE4-BA6362785D6A@nostrum.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_346E0C74-F075-4A94-9C36-1FF8FCEC9749" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 6 Aug 2020 15:44:04 -0500 In-Reply-To: Cc: Russ Housley To: IETF STIR Mail List References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <41B1930A-2631-47D3-8693-62363B9C5639@vigilsec.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [stir] Call For Adoption of draft-peterson-stir-servprovider-oob X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 20:44:15 -0000 --Apple-Mail=_346E0C74-F075-4A94-9C36-1FF8FCEC9749 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 on both points. Ben. > On Jul 31, 2020, at 10:56 AM, Mary Barnes = wrote: >=20 > I support the adoption and am willing to review. >=20 > Regards, > Mary.=20 >=20 > On Fri, Jul 31, 2020 at 10:36 AM Russ Housley > wrote: > Please take a look at draft-peterson-stir-servprovider-oob. Please = indicate whether you support adoption of this document by the STIR WG. = Please respond before 23 August 2020. If you support adoption, please = indicate whether you would review or implement. >=20 > This document can be found in the datatracker at = https://datatracker.ietf.org/doc/draft-peterson-stir-servprovider-oob/ = >=20 > Russ & Robert >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir = > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_346E0C74-F075-4A94-9C36-1FF8FCEC9749 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1 = on both points.

Ben.

On Jul 31, 2020, at 10:56 AM, = Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

I support the adoption and am willing to review.

Regards,
Mary. 

On Fri, Jul = 31, 2020 at 10:36 AM Russ Housley <housley@vigilsec.com> wrote:
Please take a look at = draft-peterson-stir-servprovider-oob. Please indicate whether you = support adoption of this document by the STIR WG.  Please respond = before 23 August 2020.  If you support adoption, please indicate = whether you would review or implement.

This document can be found in the datatracker at https://datatracker.ietf.org/doc/draft-peterson-stir-servprovid= er-oob/

Russ & Robert

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_346E0C74-F075-4A94-9C36-1FF8FCEC9749-- From nobody Wed Aug 12 06:04:28 2020 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2013A12C1; Wed, 12 Aug 2020 06:04:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk CC: housley@vigilsec.com, draft-ietf-stir-cert-delegation@ietf.org, stir@ietf.org, Russ Housley , superuser@gmail.com, stir-chairs@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159723745572.24677.665284821071317149@ietfa.amsl.com> Date: Wed, 12 Aug 2020 06:04:16 -0700 Archived-At: Subject: [stir] Last Call: (STIR Certificate Delegation) to Proposed Standard X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 13:04:23 -0000 The IESG has received a request from the Secure Telephone Identity Revisited WG (stir) to consider the following document: - 'STIR Certificate Delegation' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-08-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing. This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-stir-cert-delegation/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Aug 14 10:21:56 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A9C3A118F; Fri, 14 Aug 2020 10:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_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=metaswitch.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 hnZkg-w31icR; Fri, 14 Aug 2020 10:21:53 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700107.outbound.protection.outlook.com [40.107.70.107]) (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 102A23A11A0; Fri, 14 Aug 2020 10:21:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R6LEJpcUqIm6ELHH3isK5RW+3aDsfLKENepsEorG0LO2VcxrpK905IxsGXJTn78SPFaJ0SOZs/Kj7u/ZkOTftwij8Zqvrr29Ib6eWDZj0KmprKWd2BfV7lLse8WObXzbqajsGsftIi4iDaRPiWUU8x6S2IqwncKrCsb7IM78tp4DxMDx+i94XFz6EUgLwWr1Yy23ROHR1BeKLZ1mStyB4IqLxmWWvAuKbfS10YcjqfRIM+5qy/QBgW0LOi8dW5mOdbf+YDNi/5sCseNKMaYjLW0BpLNnbVpt10BlUKcJS7fxM+egGxUggYbvFw6YaQiDwQ9F7vPlbtuXhAFJilP8/w== 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-SenderADCheck; bh=8y50RBThEYTzNoGpXAlS6/fNPAYzDviuuh79bI+QbwI=; b=V79+hmnt4l81Efln7YOxY4o+Ue9MNKVwDnzelDe+DJolRKJjA3+IZEic4Ae2zx9qglIGSjq8UMM/WsB6m6Fz05Fk7iO8i56k+l/HaXnKo1AeDecfyRdOiHj6aIFmV9hdd4TD/ctXxV9fz8RLpW+w4D1P5cFeAmPHhJmRM+AlaJYjuvxZ2F1j4c3E+Bmb/DBPTCcbyBJRWSD93HK1ZJQTvmBYGY6yWLsqnSW4E2BAFjGN6r+B+8g7YFCIzxV2LDPobsB/dTi387dbcJlmKg5NOBkF40Li5lp/uDWJ/RWWTDawobY5o9Q0qxB0cl/FmwzGN4nrvoKkhl+Lpnv/MUDDLg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=metaswitch.com; dmarc=pass action=none header.from=metaswitch.com; dkim=pass header.d=metaswitch.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8y50RBThEYTzNoGpXAlS6/fNPAYzDviuuh79bI+QbwI=; b=r3tJf3Kj5c0kXAsmhmRzmaJl3LIbxVnSCjTeTyHe22ePl8dbbr/Mmq5JLomveLWr9rmKiCYiJIbFR8HB/zuht98IHQHoW4lrFdSr3GvSVVtYdtz9nhDRNqhUOc6LcjZwxNBvDA+KG1+HW9SVWdW8RpheMyFpOMNVFAj/H97nki0= Received: from BYAPR02MB5189.namprd02.prod.outlook.com (2603:10b6:a03:62::29) by BYAPR02MB4711.namprd02.prod.outlook.com (2603:10b6:a03:49::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.20; Fri, 14 Aug 2020 17:21:40 +0000 Received: from BYAPR02MB5189.namprd02.prod.outlook.com ([fe80::d4d5:e9b6:c079:2718]) by BYAPR02MB5189.namprd02.prod.outlook.com ([fe80::d4d5:e9b6:c079:2718%7]) with mapi id 15.20.3261.026; Fri, 14 Aug 2020 17:21:40 +0000 From: Jack Rickard To: "draft-ietf-stir-rph-emergency-services@ietf.org" , "stir@ietf.org" Thread-Topic: Review of draft-ietf-stir-rph-emergency-services Thread-Index: AdZrPXk4d/f2kRt0QXimDVa1DUwOuw== Date: Fri, 14 Aug 2020 17:21:39 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [84.92.33.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f1c14b5d-99c2-4f2d-f866-08d8407681d1 x-ms-traffictypediagnostic: BYAPR02MB4711: x-ld-processed: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UC32eoiiz1Y/MzuoRz/cTkGWmzRFFTW5RPBh7LnyGD5e/tvK5NTuRKtsSwjSeAS5KwX9ZfP5PpD/SkyTChI4wRl8iSeOxynta2E9CijWnELxfpYHLOHZP+7NoRctBd+zjw4GWV9C1lioK8X6Qe9LWHUCciUt6VTHcP5lkO49DnQw9WcYTAPI2EVwYPiSXxs6bQ0NjP9u+h/6rcVLQG4+S3W04P+M7AZ7qLA/UJDF0RtFZfVJ2h8cOTWvQRmoUmjzmiDMI5unupPRS8Q+kqarmbpJLg1c5lCy187vbamCMnzwJMV40JGnZXo4LrsLEgUWsIJV2bWGOxe9w68GO0XqAw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR02MB5189.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(376002)(366004)(136003)(39850400004)(6506007)(71200400001)(55016002)(9686003)(110136005)(83380400001)(316002)(8936002)(8676002)(450100002)(2906002)(7696005)(66446008)(186003)(66946007)(478600001)(33656002)(5660300002)(52536014)(26005)(86362001)(66556008)(66476007)(64756008)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Oi7I3ndaSFp8Q2g/TJGPEQB5QGFb2dQqg3dBrd76plkWJa0JUgSEHfLcKyxzcaSFbNGT7D67AN6N3YPmg2/5fL3YEW7XoY8BaVLLWDAd3CyoOGbYeB3Bs8XsfTqobMOtf99Z0jE+GohXgCqouG5eZ6XJ5zrxwH7pr2/IrLTD6D4UP5muKeQ5Ae5TuME+nLEP8hpph5n5ZmeWlgTtpZ0D/zYVrGRcfLU+wHo+8E7Zni9G+TmLVzA2Z/iirLFDsOch+/1A9nDV5ED/o73lbpS2byVddoftfvUYPsAieGU1gJJrG5xg/xVwfqlMNsihso8jUgt4dbda9wG54Oy2uAYFFimrihxAZdwknGIpq/M4RDj1iCBpUos69o9xB63PE/qoTyoRSn4EpoLyf2zprm622vMF2AI1Kpiw9FqC+TNqBOagNJEIzv9Gj6nLS58a5V/qhsRBKFCkLNkauZ4qJo5hEU2x+RKnbYmxdsmlr8msdJEBiRdZJMyxMBuG7T7I9DS+y5GxPmcM6I3/Z8POxQ3Kt2RWi7lVti+PY3TAnNdg6UwqaDIjb5McrlO2BrmsA2UdMVr31CTQva8GQTFBpKDhC61anIus0KaUWKk1d/0Zmw1orUOUfPJ2heNX1elj8xJEgazAnitYkr7Jr42Y0n7pUA== Content-Type: multipart/alternative; boundary="_000_BYAPR02MB51891E95480910389FE0FDC7F3400BYAPR02MB5189namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR02MB5189.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f1c14b5d-99c2-4f2d-f866-08d8407681d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 17:21:39.6717 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zSMGHxSJSOLoZwRti1YtICHXpgbDcJtr20hONz5qVj+HUzlNp7dbxqbismURg3Lshr/HIKSm6qjPi0QZInGx+g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB4711 Archived-At: Subject: [stir] Review of draft-ietf-stir-rph-emergency-services X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 17:21:55 -0000 --_000_BYAPR02MB51891E95480910389FE0FDC7F3400BYAPR02MB5189namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed draft-ietf-stir-rph-emergency-services-02 and have some con= cerns and questions. I don't believe this spec is implementable in its curr= ent form. Thanks, Jack Why are "ESorig" and "EScallback" distinct? They seem to serve a very similar purpose with the only difference being wh= ether orig or dest should be the emergency services. I don't believe there'= s any check that can be done to validate: When using "ESorig" as the "rph" assertion value, the "orig" claim of the PASSporT MUST represent the calling party number that initiates the call to emergency services. This (and the equivalent statement for EScallback) don't seem possible to m= e to check (barring the standard orig/dest checking). This would make the check "at least one of the parties should be the emerge= ncy services" enough to validate that this was a reasonable call. Why have them at all rather than just using auth? This is very possibly an issue with my understanding, but I'm not clear on = why "ESorig" and "EScallback" even need to exist. "esnet.0" etc. are SIP Re= source Priority headers, so should be included in the "auth" field anyway b= y the RPH spec. This spec appears to apply extra constraints (that a one of= the callers must be the emergency services) for the "esnet" namespace but = it's not clear why entirely separate claims are needed. In a similar vein, what should a verifier do if it receives a call containi= ng an invalid "ESorig" or "EScallback" value or the passport is invalid/unt= rusted, I'm assuming the behaviour is the same as for auth but this isn't c= lear. Although stripping the fact that this is an emergency call is potenti= ally dangerous. Specify the type of the "ESorig" and "EScallback" claims. This specification currently doesn't specify the type of the new fields, th= ere are only examples and this isn't enough. It looks like they both follow= the same scheme as the rph "auth" claim, however "esnet,x" doesn't quite f= it into that due to the comma and that x isn't a valid priority value. Why is sph limited to psap-callback? What should the verifier do if it isn'= t that? What should it do if it is? I'm not entirely clear on the purpose of the sph claim, however, it seems o= dd that it doesn't cover the full range of possible values for the SIP Prio= rity Header. Is there a reason that it doesn't cover the "non-urgent", "nor= mal", "urgent", or "emergency" values? There is also no verifier behaviour defined here, should the verifier remov= e the Priority header if it receives an invite with no passports signing fo= r it? That seems dangerous to me but would be consistent with rph. Alternat= ively, what should the verifier do if it receives an invite with a valid pa= ssport claiming sph but with no Priority header should it add it in? I'm no= t sure the spec needs to be too prescriptive here, however some mention of = verifier behaviour and the associated security considerations would be usef= ul. Should the spec be stronger about the compact form? Section 3 currently states The use of the compact form of PASSporT is not specified in this document. However, a compact-form passport following this spec would be hard to verif= y as it introduces multiple possible rph variants, I think this spec could = go further and say you shouldn't/mustn't. What is the requirement of these new parameters. As I understand it, the passport spec allows you to create a passport conta= ining whatever JWT fields you want and verifiers should just ignore any fie= lds they don't understand. Unless the "ppt" claim is set, which indicates t= hat verifiers should discard it if they don't recognise that passport type.= As this spec adds additional fields to an existing passport type it isn't = immediately clear what the behaviour should be. Specifically, is an rph pas= sport containing only "rph.ESorig" valid now (where it wouldn't be before b= ecause auth isn't present), is an rph passport containing no rph and only s= ph valid, and what does a non-rph passport with sph or ESorig set mean? --_000_BYAPR02MB51891E95480910389FE0FDC7F3400BYAPR02MB5189namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed draft-ietf-stir-rph-emergency-servic= es-02 and have some concerns and questions. I don't believe this spec is im= plementable in its current form.

 

Thanks,

Jack

 

Why are "ESorig" and "EScallback&q= uot; distinct?

They seem to serve a very similar purpose with the o= nly difference being whether orig or dest should be the emergency services.= I don't believe there's any check that can be done to validate:=

   When using "E= Sorig" as the "rph" assertion value, the "orig" cl= aim of

   the PASSporT MUST = represent the calling party number that initiates

   the call to emerge= ncy services.

This (and the equivalent statement for EScallback) d= on't seem possible to me to check (barring the standard orig/dest checking)= .

This would make the check "at least one of the = parties should be the emergency services" enough to validate that this= was a reasonable call.

 

 

Why have them at all rather than just using auth?=

This is very possibly an issue with my understanding= , but I'm not clear on why "ESorig" and "EScallback" ev= en need to exist. "esnet.0" etc. are SIP Resource Priority header= s, so should be included in the "auth" field anyway by the RPH sp= ec. This spec appears to apply extra constraints (that a one of the callers mu= st be the emergency services) for the "esnet" namespace but it's = not clear why entirely separate claims are needed.

 

In a similar vein, what should a verifier do if it r= eceives a call containing an invalid "ESorig" or "EScallback= " value or the passport is invalid/untrusted, I'm assuming the behavio= ur is the same as for auth but this isn't clear. Although stripping the fact that this is an emergency call is potentially dangerous= .

 

 

Specify the type of the "ESorig" and &q= uot;EScallback" claims.

This specification currently doesn't specify the typ= e of the new fields, there are only examples and this isn't enough. It look= s like they both follow the same scheme as the rph "auth" claim, = however "esnet,x" doesn't quite fit into that due to the comma and that x isn't a valid priority value.

 

 

Why is sph limited to psap-callback? What should = the verifier do if it isn't that? What should it do if it is?

I'm not entirely clear on the purpose of the sph cla= im, however, it seems odd that it doesn't cover the full range of possible = values for the SIP Priority Header. Is there a reason that it doesn't cover= the "non-urgent", "normal", "urgent", or "emergency" values?

There is also no verifier behaviour defined here, sh= ould the verifier remove the Priority header if it receives an invite with = no passports signing for it? That seems dangerous to me but would be consis= tent with rph. Alternatively, what should the verifier do if it receives an invite with a valid passport clai= ming sph but with no Priority header should it add it in? I'm not sure the = spec needs to be too prescriptive here, however some mention of verifier be= haviour and the associated security considerations would be useful.



Should the spec be stronger about the compact form?

Section 3 currently states

   The use of the compact form of PASSporT is not specified =
in this
   document.

However, a compact-form passport following this spec= would be hard to verify as it introduces multiple possible rph variants, I= think this spec could go further and say you shouldn't/mustn't.=



What is the requirement of these new parameters.

As I understand it, the passport spec allows you to = create a passport containing whatever JWT fields you want and verifiers sho= uld just ignore any fields they don't understand. Unless the "ppt"= ; claim is set, which indicates that verifiers should discard it if they don't recognise that passport type. As this spec= adds additional fields to an existing passport type it isn't immediately c= lear what the behaviour should be. Specifically, is an rph passport contain= ing only "rph.ESorig" valid now (where it wouldn't be before because auth isn't present), is an rph passpo= rt containing no rph and only sph valid, and what does a non-rph passport w= ith sph or ESorig set mean?

 

--_000_BYAPR02MB51891E95480910389FE0FDC7F3400BYAPR02MB5189namp_-- From nobody Mon Aug 17 07:36:57 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2F93A166E for ; Mon, 17 Aug 2020 07:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 Dy2AKSj5Nyo2 for ; Mon, 17 Aug 2020 07:36:54 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109E33A1664 for ; Mon, 17 Aug 2020 07:36:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 82042300B75 for ; Mon, 17 Aug 2020 10:36:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1zjBmmVVAM9F for ; Mon, 17 Aug 2020 10:36:49 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id EF763300AA4 for ; Mon, 17 Aug 2020 10:36:48 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Mon, 17 Aug 2020 10:36:49 -0400 References: <8372C576-08B7-41C4-B021-38622BABAD25@vigilsec.com> <919FC584-18AF-4419-B174-B9FB37B6439D@vigilsec.com> To: IETF STIR Mail List In-Reply-To: <919FC584-18AF-4419-B174-B9FB37B6439D@vigilsec.com> Message-Id: <16089772-528A-462E-B3CF-AAAC6C3A8F2A@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 14:36:56 -0000 I am confused by the last sentence of the Introduction (Section 1). It = says: In addition, the PASSPorT claims and values defined in this document are intended for use in environments where there are means to verify that the signer of the SIP 'Resource-Priority' and 'Priority' header fields is authoritative. The signer signs the PASSPorT. The PASSPorT includes claims, and each = claim has a value. By construction, the values are expected to match = the SIP 'Resource-Priority' header field and the SIP 'Priority' header = field. Is this saying that the PASSPorT must be authoritative for these = claims if they are present? In Section 3.1, I expected a MUST statement that says what appears in = the value of the "ESorig" value. It says what MUST appear on other = claims around the "rph" claim, but it only gives an example of a value = that matches an SIP 'Resource-Priority' header field. Likewise in Section 3.2, I expected a MUST statement that says what = appears in the value of the "EScallback" value. It says what MUST = appear on other claims around the "rph" claim, but it only gives an = example of a value that matches an SIP 'Resource-Priority' header field. In Section 3.2, I believe that the last paragraph applies to both the = "ESorig" value and the "EScallback" value, so it probably belongs in = Section 3 or a separate subsection. Section 4 says: Therefore, we define a new claim key as part of the "rph" PASSporT, = ... I think it would be more clear to say: Therefore, we define a new claim key to be used in a PASSporT that = includes "rph" claim, ... Section 6 should use RFC 2119 wording: The use of the compact form of PASSporT is not specified in this document. Use of the compact form of PASSporT is NOT RECOMMENDED for a PASSporT that includes a "rph" claim. I think that the Security Considerations (Section 8) should say someting = about the consequences of a PASSPorT that includes the "rph" or "sph" = claim that is signed by a party that is not authoritative for the SIP = 'Resource-Priority' header field and the SIP 'Priority' header field. Russ (No Hats) > On Jul 31, 2020, at 11:29 AM, Russ Housley = wrote: >=20 >=20 > This is the STIR WG Last Call for "Assertion Values for a Resource = Priority Header Claim and a SIP Priority Header Claim in Support of = Emergency Services Networks=E2=80=9D = . Please review the document = and send your comments to the STIR WG mail list by 22 August 2020. >=20 > = https://datatracker.ietf.org/doc/draft-ietf-stir-rph-emergency-services/ >=20 > Thanks, > Robert & Russ From nobody Tue Aug 18 14:30:38 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA273A0D05 for ; Tue, 18 Aug 2020 14:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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=brianrosen-net.20150623.gappssmtp.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 GK-z1RcF7eKH for ; Tue, 18 Aug 2020 14:30:35 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 2904E3A0D01 for ; Tue, 18 Aug 2020 14:30:35 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id v6so22570330iow.11 for ; Tue, 18 Aug 2020 14:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ojnR54SqThJXQpCDe6BAhqnrBHpIRdYZUrVNvaZTBe4=; b=hoPvbDgd4V32nHAjlDQQXqGbME+p5PzevTi8KugFYQr3BfJ0YoOWuvwpAXSB6mS28U ZLr9JHoSNJueF5fYOUQ+PwkGQHYrspqrocGOJQspodvcsWZh08+68tMzYpHWh8Ak0DW2 eXsiT3CVrXBDnvXM4oyOYRyrsxswYpF+MQHBaPivn2/1Q2SomX3m/k2aaYj1Sap4+fEl nz6ogiNzdiuY7MHvHlcQoWm/5UvmXzzbB/lXAXSEbsoj6zvUyxNnYytRA0U03ZXnemBs luA/JrYgU13laCWRkVQrPcVIUe4Tw7/N8vPcESyPexPEYHZAIW2dhytRWcyK5u/Merfy MnTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ojnR54SqThJXQpCDe6BAhqnrBHpIRdYZUrVNvaZTBe4=; b=NOPvKCH5nPrHm81cgWEPSsw6KSEJ2afxZfd+7Xg6OHo6tkLXafOpnrgkUk1d7CaLzK TS1BqJP3bH79ZLFL+IvYMkW8oxbr9+WVouPo6mz+kxot7lqKhem3fnU+o6mmr3VvsDee jbFYrXKZf1o1lUN8fwYg6GF+T5EvoK7G9mE617JZx6ykCqdvBEOBEtML7kZr/spg+60k MxOLhysiH+L8wWq0vxBw7TfLy1UP9i7lUipqOh9h3hBa0vGqVNQ38LDSrkIX1fN5K0HB fZ2h4jWkUUHVcSpq63c+aPWzOtDYwmnNAXekiuW0l9TvlqBGyeYbAZQz1YUK14PKaX+E rd2w== X-Gm-Message-State: AOAM531MAkeGXgTjl9GQ2Nf6H0/zdulmQw1SV1Wl0Bc8wNM6VsBgJDs5 YrsyEACgDxmSwG7T9jKR0JeAzQ== X-Google-Smtp-Source: ABdhPJyD6h5h9FoMDBJOisPpCQU9B0DT34+kLQp2uVsb2m5LLWraSwxcQUVKRLtNkwv9lfjXj7pp4g== X-Received: by 2002:a02:84c1:: with SMTP id f59mr21121532jai.106.1597786234203; Tue, 18 Aug 2020 14:30:34 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id r3sm12170596iov.22.2020.08.18.14.30.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Aug 2020 14:30:33 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_77435808-EA6D-48BC-AA6A-8D74B0029E8F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 18 Aug 2020 17:30:32 -0400 In-Reply-To: Cc: "draft-ietf-stir-rph-emergency-services@ietf.org" , "stir@ietf.org" To: Jack Rickard References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [stir] Review of draft-ietf-stir-rph-emergency-services X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 21:30:37 -0000 --Apple-Mail=_77435808-EA6D-48BC-AA6A-8D74B0029E8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Let=E2=80=99s keep the two use cases separate: ESorig is an emergency call (user to authority). EScallback is a call from authority to user. For ESorg, the call is marked with a Request-URI of urn:service:sos. = The =E2=80=9CTo=E2=80=9D field is ignored in routing and handling the = call. That=E2=80=99s how you know this is an emergency call. For stir = purposes, the =46rom is an ordinary identifier, and gets treated in the = normal way. However, the rph value can only be used by a valid = emergency call, and a valid emergency call is a Request URI of = urn:service:sos, and a valid From. So you don=E2=80=99t have any = knowledge of emergency services identifiers, only the Request URI of = urn:service:sos. =20 For EScallback, the marking is a distinguished value in SIP Priority. = If a call has that value, it=E2=80=99s a call back. The originating = service provider knows who are the authorities who are allowed to place = call backs, so the check is what is in SIP Priority, and one of the = allowed authorities in From. As a practical matter, in most cases, the = call will be signed by the emergency authorities themselves, who will be = able to get appropriate credentials for this purpose. In most cases = I=E2=80=99m aware of, the To in an emergency call won=E2=80=99t match = the =46rom in a Callback, but it=E2=80=99s possible for that to happen, = and we want to allow it. Esnet is a Resource Priority Header namespace, not a SIP Priority value. = We=E2=80=99re allowing emergency calls and call backs to use rph, and = we=E2=80=99re protecting against malicious use of it. So unless the = call has urn:service:sos in Request URI, or the right SIP Priority in a = call back (and from an authorized authority) they can=E2=80=99t use rph = with the esnet namespace. Generally, unless under attack, emergency = calls go through even if there isn=E2=80=99t a passport. Many networks = won=E2=80=99t offer actual priority to emergency calls, but the = emergency services networks (ESInets) will. =20 If a call arrives anywhere with an rph using esnet, and isn=E2=80=99t an = emergency call, with the appropriate passport, any intermediary can = refuse to give it any priority, The emergency authorities may accept a = call without a valid passport, but they might treat it with much more = suspicion than they would any other call. For call backs, the network may have special behavior. For example, it = may send the call to the device that placed the emergency call, rather = than, for example, voice mail. The network has to be able to trust that = SIP Priority is set appropriately. It will also have rph using esnet, = and the network can grant it appropriate priority if it has that = capability, and would not allow esnet otherwise. The only value in covering other uses of SIP Priority is to protect = against middle boxes modifying it. We don=E2=80=99t really have use = cases for that. It probably wouldn=E2=80=99t hurt to allow it though. Does that help? Brian > On Aug 14, 2020, at 1:21 PM, Jack Rickard = wrote: >=20 > I have reviewed draft-ietf-stir-rph-emergency-services-02 and have = some concerns and questions. I don't believe this spec is implementable = in its current form. > =20 > Thanks, > Jack > =20 > Why are "ESorig" and "EScallback" distinct? > They seem to serve a very similar purpose with the only difference = being whether orig or dest should be the emergency services. I don't = believe there's any check that can be done to validate: > When using "ESorig" as the "rph" assertion value, the "orig" claim = of > the PASSporT MUST represent the calling party number that initiates > the call to emergency services. > This (and the equivalent statement for EScallback) don't seem possible = to me to check (barring the standard orig/dest checking).. > This would make the check "at least one of the parties should be the = emergency services" enough to validate that this was a reasonable call. > =20 > =20 > Why have them at all rather than just using auth? > This is very possibly an issue with my understanding, but I'm not = clear on why "ESorig" and "EScallback" even need to exist. "esnet.0" = etc. are SIP Resource Priority headers, so should be included in the = "auth" field anyway by the RPH spec. This spec appears to apply extra = constraints (that a one of the callers must be the emergency services) = for the "esnet" namespace but it's not clear why entirely separate = claims are needed. > =20 > In a similar vein, what should a verifier do if it receives a call = containing an invalid "ESorig" or "EScallback" value or the passport is = invalid/untrusted, I'm assuming the behaviour is the same as for auth = but this isn't clear. Although stripping the fact that this is an = emergency call is potentially dangerous.. > =20 > =20 > Specify the type of the "ESorig" and "EScallback" claims. > This specification currently doesn't specify the type of the new = fields, there are only examples and this isn't enough. It looks like = they both follow the same scheme as the rph "auth" claim, however = "esnet,x" doesn't quite fit into that due to the comma and that x isn't = a valid priority value. > =20 > =20 > Why is sph limited to psap-callback? What should the verifier do if it = isn't that? What should it do if it is? > I'm not entirely clear on the purpose of the sph claim, however, it = seems odd that it doesn't cover the full range of possible values for = the SIP Priority Header. Is there a reason that it doesn't cover the = "non-urgent", "normal", "urgent", or "emergency" values? > There is also no verifier behaviour defined here, should the verifier = remove the Priority header if it receives an invite with no passports = signing for it? That seems dangerous to me but would be consistent with = rph. Alternatively, what should the verifier do if it receives an invite = with a valid passport claiming sph but with no Priority header should it = add it in? I'm not sure the spec needs to be too prescriptive here, = however some mention of verifier behaviour and the associated security = considerations would be useful. >=20 >=20 > Should the spec be stronger about the compact form? > Section 3 currently states > The use of the compact form of PASSporT is not specified in this > document. > However, a compact-form passport following this spec would be hard to = verify as it introduces multiple possible rph variants, I think this = spec could go further and say you shouldn't/mustn't. >=20 >=20 > What is the requirement of these new parameters. > As I understand it, the passport spec allows you to create a passport = containing whatever JWT fields you want and verifiers should just ignore = any fields they don't understand. Unless the "ppt" claim is set, which = indicates that verifiers should discard it if they don't recognise that = passport type. As this spec adds additional fields to an existing = passport type it isn't immediately clear what the behaviour should be. = Specifically, is an rph passport containing only "rph.ESorig" valid now = (where it wouldn't be before because auth isn't present), is an rph = passport containing no rph and only sph valid, and what does a non-rph = passport with sph or ESorig set mean? > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir = --Apple-Mail=_77435808-EA6D-48BC-AA6A-8D74B0029E8F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Let=E2=80=99s keep the two use cases separate:
ESorig is an emergency call (user to authority).
EScallback is a call from authority to user.

For ESorg, the call is = marked with a Request-URI of urn:service:sos.  The =E2=80=9CTo=E2=80=9D= field is ignored in routing and handling the call.  That=E2=80=99s = how you know this is an emergency call.   For stir purposes, the = =46rom is an ordinary identifier, and gets treated in the normal way. =  However, the rph value can only be used by a valid emergency call, = and a valid emergency call is a Request URI of urn:service:sos, and a = valid From.  So you don=E2=80=99t have any knowledge of emergency = services identifiers, only the Request URI of urn:service:sos. =   

For= EScallback, the marking is a distinguished value in SIP Priority. =  If a call has that value, it=E2=80=99s a call back.  The = originating service provider knows who are the authorities who are = allowed to place call backs, so the check is what is in SIP Priority, = and one of the allowed authorities in From.  As a practical matter, = in most cases, the call will be signed by the emergency authorities = themselves, who will be able to get appropriate credentials for this = purpose.  In most cases I=E2=80=99m aware of, the To in an = emergency call won=E2=80=99t match the =46rom in a Callback, but it=E2=80=99= s possible for that to happen, and we want to allow it.

Esnet is a Resource = Priority Header namespace, not a SIP Priority value.  We=E2=80=99re = allowing emergency calls and call backs to use rph, and we=E2=80=99re = protecting against malicious use of it.  So unless the call has = urn:service:sos in Request URI, or the right SIP Priority in a call back = (and from an authorized authority) they can=E2=80=99t use rph with the = esnet namespace.  Generally, unless under attack, emergency calls = go through even if there isn=E2=80=99t a passport.  Many networks = won=E2=80=99t offer actual priority to emergency calls, but the = emergency services networks (ESInets) will.  

If a call arrives = anywhere with an rph using esnet, and isn=E2=80=99t an emergency call, = with the appropriate passport,  any intermediary can refuse to give = it any priority,  The emergency authorities may accept a call = without a valid passport, but they might treat it with much more = suspicion than they would any other call.

For call backs, the network may have = special behavior.  For example, it may send the call to the device = that placed the emergency call, rather than, for example, voice mail. =  The network has to be able to trust that SIP Priority is set = appropriately.  It will also have rph using esnet, and the network = can grant it appropriate priority if it has that capability, and would = not allow esnet otherwise.

The only value in covering other uses of SIP Priority is to = protect against middle boxes modifying it.  We don=E2=80=99t really = have use cases for that.  It probably wouldn=E2=80=99t hurt to = allow it though.

Does that help?

Brian


On Aug = 14, 2020, at 1:21 PM, Jack Rickard <Jack.Rickard=3D40metaswitch.com@dmarc.ietf.org> = wrote:

I have reviewed = draft-ietf-stir-rph-emergency-services-02 and have some concerns and = questions. I don't believe this spec is implementable in its current = form.
 
Thanks,
Jack
 
Why are = "ESorig" and "EScallback" distinct?
They seem to serve a very similar purpose with = the only difference being whether orig or dest should be the emergency = services. I don't believe there's any check that can be done to = validate:
   When using "ESorig" as the "rph" assertion = value, the "orig" claim of
   the PASSporT MUST = represent the calling party number that initiates
   the call to emergency services.
This (and the = equivalent statement for EScallback) don't seem possible to me to check = (barring the standard orig/dest checking)..
This would make the check = "at least one of the parties should be the emergency services" enough to = validate that this was a reasonable call.
 
 
Why have them at all rather than = just using auth?
This = is very possibly an issue with my understanding, but I'm not clear on = why "ESorig" and "EScallback" even need to exist. "esnet.0" etc. are SIP = Resource Priority headers, so should be included in the "auth" field = anyway by the RPH spec. This spec appears to apply extra constraints = (that a one of the callers must be the emergency services) for the = "esnet" namespace but it's not clear why entirely separate claims are = needed.
 
In a similar vein, what = should a verifier do if it receives a call containing an invalid = "ESorig" or "EScallback" value or the passport is invalid/untrusted, I'm = assuming the behaviour is the same as for auth but this isn't clear. = Although stripping the fact that this is an emergency call is = potentially dangerous..
 
 
Specify the = type of the "ESorig" and "EScallback" claims.
This specification = currently doesn't specify the type of the new fields, there are only = examples and this isn't enough. It looks like they both follow the same = scheme as the rph "auth" claim, however "esnet,x" doesn't quite fit into = that due to the comma and that x isn't a valid priority value.
 
 
Why is sph = limited to psap-callback? What should the verifier do if it isn't that? = What should it do if it is?
I'm not entirely clear on the purpose of the sph = claim, however, it seems odd that it doesn't cover the full range of = possible values for the SIP Priority Header. Is there a reason that it = doesn't cover the "non-urgent", "normal", "urgent", or "emergency" = values?
There is also no = verifier behaviour defined here, should the verifier remove the Priority = header if it receives an invite with no passports signing for it? That = seems dangerous to me but would be consistent with rph. Alternatively, = what should the verifier do if it receives an invite with a valid = passport claiming sph but with no Priority header should it add it in? = I'm not sure the spec needs to be too prescriptive here, however some = mention of verifier behaviour and the associated security considerations = would be useful.


Should the = spec be stronger about the compact form?
Section 3 currently = states
   The use of the compact form of PASSporT is not =
specified in this
   document.
However, a compact-form passport following this = spec would be hard to verify as it introduces multiple possible rph = variants, I think this spec could go further and say you = shouldn't/mustn't.


What is the requirement of = these new parameters.
As = I understand it, the passport spec allows you to create a passport = containing whatever JWT fields you want and verifiers should just ignore = any fields they don't understand. Unless the "ppt" claim is set, which = indicates that verifiers should discard it if they don't recognise that = passport type. As this spec adds additional fields to an existing = passport type it isn't immediately clear what the behaviour should be. = Specifically, is an rph passport containing only "rph.ESorig" valid now = (where it wouldn't be before because auth isn't present), is an rph = passport containing no rph and only sph valid, and what does a non-rph = passport with sph or ESorig set mean?
 
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_77435808-EA6D-48BC-AA6A-8D74B0029E8F-- From nobody Tue Aug 18 14:46:03 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B29A3A0DD3 for ; Tue, 18 Aug 2020 14:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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=brianrosen-net.20150623.gappssmtp.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 9QDCNC7Uxn8u for ; Tue, 18 Aug 2020 14:46:00 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0: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 EB5043A0DC8 for ; Tue, 18 Aug 2020 14:45:59 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id p18so15142830ilm.7 for ; Tue, 18 Aug 2020 14:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HXfOWbPspfHmOO04Ss4YLW3Af8lUcTwe2dsjl6zBfsE=; b=GS2Nds98Ng9yK8QOyd3DsemKB5xmj7zZqE8K+pe/Z1CuAcE+DOeU8lDVIZXt9wW7Hb lXh3RIFkqjbY/ZRDQubYd4m4xfjR8amDQvmYXHLD7lAabCSxcPqjrDHjDnDLLxAdeGkU 6d+oS4D67NVKrSB81o1xQ81TvU1+tVTvW9WgmTROZ/DX0znZndVSSZ2YBr/lHpMLfBuM my+dcLugBRjpMTIciIrtmTbUAnL2/X9Ym4/GNZOYJ5Rp5yAdM34FFaqWThjhB8Lpk31s HrJcF5/52cazUxkiZZBThFF7JXcgiH8LeRHLSVPS6yKR6F8Y4fJ42o6Y4FnJpp91ow7p T6Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HXfOWbPspfHmOO04Ss4YLW3Af8lUcTwe2dsjl6zBfsE=; b=dlQP53l2fQAa+ZJp4WFYLmRwrO335I/8YAzmyizILn0JlLdo0Ix4MSNjhQKBxbxsZR hwwDOspch2+NIJuImFHXN49XHKGx6lx3SPDtZQMU7oBnvqH1XsLjsr3dbv5T3Qw4h470 tUIPyV86vWoJYHVdsMUMP6MWFi8p4810DVhd1g0tEIEhmMjMdrfnuzWJg5I+Xluki6gm 6tI9DQTzVkcailnjJCfmzMRi85JJF3pOh7kKsgwy3FFmHQ6RIgNCupb0x4qZbMqXL9wq iMhQp0BNEVrVoBPowsg+oGhQE3BKVcM6FG2n0exlpbmj54gC742KiSVAb0LBxqFY6GVj kZKg== X-Gm-Message-State: AOAM531jpdOxS3IS9x/vLSAVKlFoCXLNrHaHgi6BubDMwSMDo69NuJho KBT6DNDW5FPcnDxXIoPlAiNK3jvCzPpkLjZ9 X-Google-Smtp-Source: ABdhPJzDv9oLjK6A6/rNRDo+0r7mL3jLWDwb6FS1YgWrz4HOH1yqMOA1OB8ofc7PSrWFb79TYuFnqw== X-Received: by 2002:a05:6e02:de5:: with SMTP id m5mr19365787ilj.85.1597787159167; Tue, 18 Aug 2020 14:45:59 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id c76sm12622423ill.63.2020.08.18.14.45.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Aug 2020 14:45:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Brian Rosen In-Reply-To: <16089772-528A-462E-B3CF-AAAC6C3A8F2A@vigilsec.com> Date: Tue, 18 Aug 2020 17:45:57 -0400 Cc: IETF STIR Mail List Content-Transfer-Encoding: quoted-printable Message-Id: <1D18963E-CD70-4B23-99DA-67D5E0071107@brianrosen.net> References: <8372C576-08B7-41C4-B021-38622BABAD25@vigilsec.com> <919FC584-18AF-4419-B174-B9FB37B6439D@vigilsec.com> <16089772-528A-462E-B3CF-AAAC6C3A8F2A@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 21:46:02 -0000 See my reply to Jack for more info. For an emergency call, we are protecting the use of rph with the esnet = namespace to be limited to emergency calls. So the signer checks =46rom = as usual, and checks Request URI to see that it is urn:service:sos, and = if so, checks rph to see that it is esnet.1 SIP Priority is not used = with emergency calls. It could modify rph if it wanted to and then = sign, or refuse to put in the claim. For a call back, the signer has to know that the calling entity is an = allowed authority (or it may be that the authority signs its own calls). = That permits SIP Priority to use the call back marking. rph must be = esnet.0 or get modified as above to get the claim. > On Aug 17, 2020, at 10:36 AM, Russ Housley = wrote: >=20 > I am confused by the last sentence of the Introduction (Section 1). = It says: >=20 > In addition, the PASSPorT claims and values defined in > this document are intended for use in environments where there are > means to verify that the signer of the SIP 'Resource-Priority' and > 'Priority' header fields is authoritative. >=20 > The signer signs the PASSPorT. The PASSPorT includes claims, and each = claim has a value. By construction, the values are expected to match = the SIP 'Resource-Priority' header field and the SIP 'Priority' header = field. Is this saying that the PASSPorT must be authoritative for these = claims if they are present? >=20 >=20 > In Section 3.1, I expected a MUST statement that says what appears in = the value of the "ESorig" value. It says what MUST appear on other = claims around the "rph" claim, but it only gives an example of a value = that matches an SIP 'Resource-Priority' header field. >=20 >=20 > Likewise in Section 3.2, I expected a MUST statement that says what = appears in the value of the "EScallback" value. It says what MUST = appear on other claims around the "rph" claim, but it only gives an = example of a value that matches an SIP 'Resource-Priority' header field. >=20 >=20 > In Section 3.2, I believe that the last paragraph applies to both the = "ESorig" value and the "EScallback" value, so it probably belongs in = Section 3 or a separate subsection. >=20 >=20 > Section 4 says: >=20 > Therefore, we define a new claim key as part of the "rph" PASSporT, = ... >=20 > I think it would be more clear to say: >=20 > Therefore, we define a new claim key to be used in a PASSporT that = includes "rph" claim, ... >=20 >=20 > Section 6 should use RFC 2119 wording: >=20 > The use of the compact form of PASSporT is not specified in this > document. Use of the compact form of PASSporT is NOT > RECOMMENDED for a PASSporT that includes a "rph" claim. >=20 >=20 > I think that the Security Considerations (Section 8) should say = someting about the consequences of a PASSPorT that includes the "rph" or = "sph" claim that is signed by a party that is not authoritative for the = SIP 'Resource-Priority' header field and the SIP 'Priority' header = field. >=20 > Russ > (No Hats) >=20 >=20 >> On Jul 31, 2020, at 11:29 AM, Russ Housley = wrote: >>=20 >>=20 >> This is the STIR WG Last Call for "Assertion Values for a Resource = Priority Header Claim and a SIP Priority Header Claim in Support of = Emergency Services Networks=E2=80=9D = . Please review the document = and send your comments to the STIR WG mail list by 22 August 2020. >>=20 >> = https://datatracker.ietf.org/doc/draft-ietf-stir-rph-emergency-services/ >>=20 >> Thanks, >> Robert & Russ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Aug 19 04:19:30 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED113A0406; Wed, 19 Aug 2020 04:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, HTTPS_HTTP_MISMATCH=0.1, 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=metaswitch.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 J75lw6CFl4Dd; Wed, 19 Aug 2020 04:19:25 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2104.outbound.protection.outlook.com [40.107.94.104]) (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 6684F3A043A; Wed, 19 Aug 2020 04:19:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WA4lvbVwPm1iLGT7XAwQqxL4yrxTftut4A77mWHNHKOEdK0NlIzliXvkEuRob3QKR8+0mcgYXVn3R8NwBDSP/lRK0ZEdrPX45RwOS/QRp4pCkNdJ8r5vj4kHlgt0K7s/xzL7BIWfXwMAEjE75KJWDNXiprLtq7/PH6vW/ZY0kj1b9ipQL7zOGbo4Q/bJiLtWGO6+QY39pkm1sAH/OgmKyPGrcjQQOYwE7Ww4eqtyxcMzpjqmdQyr8IH1cKnfRWflUK/WfmhUAxEhPjsCBOyzdTB+bnbRywtiMxBk+rtWs4EQGfzo+InmF5pXlg9644KzRRsF+cg/fW/5VeuG66rUgw== 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-SenderADCheck; bh=484NmkYRAcBU+6csuInkUKVK8hVmABiWNzYneABogts=; b=E27Mi8SwNzWYO2f09yC0rbJ7tnAUABPSJU37UU9K8Mp8WRu0ANLe7gHtFdYfScHtJfu8PVcwEDEGs8iuof7HwVqonDmimI93RLRRVSzKh+lj3Sjls+7vDQ5795/3e/OewS7Ojc+dwXWj9ItrMfB19yDa/SvIcADHTEPCRqxa70dSHrwDPg3kT7xMBe8ekmj9wy+HzdPd2jqhQnaUwIv7bXzB9Q85ELhoM6HkiwUG1VEtBhU74to5cOItKlDAKZA7QKJYKRub+o85bbrRrnm9bggNtgzraYNzc1Upabru4S0msEsTyz7vP+CMkInCQbs2Wmm2Nmc2St8SH4SAdqQUKA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=metaswitch.com; dmarc=pass action=none header.from=metaswitch.com; dkim=pass header.d=metaswitch.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=484NmkYRAcBU+6csuInkUKVK8hVmABiWNzYneABogts=; b=Dy9UqZmu66/8xRya9OKLsb8grILkjuoG/Wr5eQmZU8SLyGyvrPPg8/elzQusH+cOriSWiv3zPmekL3w49AxiADu/ruspN+eizm3es5yfdgAvDOVu7y7BGVxa+UvZYRA8eb+XVGTxAqYIy1i+VOBQaIBDnI+0G4PzKU67SFE/4AY= Received: from BYAPR02MB5189.namprd02.prod.outlook.com (2603:10b6:a03:62::29) by BY5PR02MB6292.namprd02.prod.outlook.com (2603:10b6:a03:1b0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Wed, 19 Aug 2020 11:19:18 +0000 Received: from BYAPR02MB5189.namprd02.prod.outlook.com ([fe80::d4d5:e9b6:c079:2718]) by BYAPR02MB5189.namprd02.prod.outlook.com ([fe80::d4d5:e9b6:c079:2718%7]) with mapi id 15.20.3283.028; Wed, 19 Aug 2020 11:19:18 +0000 From: Jack Rickard To: Brian Rosen CC: "draft-ietf-stir-rph-emergency-services@ietf.org" , "stir@ietf.org" Thread-Topic: [stir] Review of draft-ietf-stir-rph-emergency-services Thread-Index: AdZrPXk4d/f2kRt0QXimDVa1DUwOuwKaVPgAABiWh4A= Date: Wed, 19 Aug 2020 11:19:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [84.92.33.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7b8e3ab9-67a1-4f55-d522-08d84431b6f1 x-ms-traffictypediagnostic: BY5PR02MB6292: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bTBlbNWOnuSaGhckdE2jzjfKTuUbNhfwL9GkVe5xqpOWRroXOXTWWn1feo4q7sw1Pm4JTAsg2jafEbuAblWVyCOlyVQszuemKmh9+46pJaNerMUlWbRKXKU0qM4INaNN9YZsVLDmQ38EBoB3FmWK2c0FnhNPAi2p5egtC4cZcHgMxx8X6Pai4TS1OdnpkaRot1Yxc0n3z7aynrzdcVWXD7EXnFmRyKEMsyj2il4xTq/gL5EZBCBkSSMveHrr/28cfMDnI6mfjwqZn127tRvXFAg0MwRzn+DLD76PM94BCFA4v9KeFxqNQgJYl7a09yU80qMD7vTv+NFj79uS6jaQRJsvROSF496tMT9uEmNezvBVKX8/DY5CYkzoQFShVw7iqSZ50nmdvYEuAz/8EKRGAw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR02MB5189.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(366004)(39850400004)(376002)(396003)(64756008)(66446008)(71200400001)(5660300002)(66556008)(8936002)(966005)(66476007)(8676002)(66946007)(26005)(52536014)(53546011)(6506007)(55016002)(76116006)(478600001)(2906002)(316002)(9686003)(86362001)(7696005)(54906003)(33656002)(166002)(6916009)(77540400001)(186003)(4326008)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: z8F26CqNGU9LiG+2TqMg9+rUAjNxsgqFy1JPIbN3G/O+XhkAXDgYKTokugqRrBQibaNePxtAz3nhjT3wUq6gSwQ3QMd1SVe0S3iy/N60/0B6WNuYJ7jCRscYIQFp2c95DPJTWBzSQ/Tlv0pKXAJwW7tj7CkLXD9cqONP3LKFwPTMY6UmtchhRHUJ+2VV4whpClRiMAQTyUhWcvDSMjASmKhrrYmZRpaLH0NSDUanpAy3pe5/ryJucz40nPOMeTBpir9veYzFFJ53uX+vFbCUI5V2kBCjGaDIVS9rHWy6TCK7Bvzl1UHMvC6F0etiN9GEuppx1XrgQQTWm7i/LQ42xTXHxvuR95+9C8Yn44MjvXcfJns2j9klWN4z5g5EHA95/eQDziJWI7GLqNtrouFev2b5P3TB0g0GAGDyqXUKMYWQj3/zFySO4DBCFtc506n9XKjkwKGr6N+3MnqwG9fMH3tDVWBm4eodd6WW1UDPlYmnBTogXxi7dQjRMaeNIzVsmINZso5/L7vLVWFaNmPuZUnqev3PqrJEr0h3XMFEMHhM1pfFc67SzyU/U1FB1sEpyCICJ6jenCvO1vX+YULFy6CCf3yCreEuGFTITD5b491QiuREGa4bX8PUgGqqZ62xXjewySVn4Teea+M5zYtY7w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR02MB5189BE4C40E7A72BCFC8BD03F35D0BYAPR02MB5189namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR02MB5189.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7b8e3ab9-67a1-4f55-d522-08d84431b6f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2020 11:19:18.4364 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vEFFLB7y4qoZiT/4niXWvqpdXHdOSYIpkO+9jTAkIa6sMqN4ORen8xo3VixAiWBz7t9a+1xbKfmdjE2w3L3eDw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR02MB6292 Archived-At: Subject: Re: [stir] Review of draft-ietf-stir-rph-emergency-services X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 11:19:28 -0000 --_000_BYAPR02MB5189BE4C40E7A72BCFC8BD03F35D0BYAPR02MB5189namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCB0aGF0J3MgcmVhbGx5IHVzZWZ1bCwgaG93ZXZlciwgSSdtIG5vdCBjb252aW5jZWQu DQoNCkZvciBFU29yaWcsIGFzIGZhciBhcyBJIGtub3cgdGhpcyBpc24ndCBjdXJyZW50bHkgYWx3 YXlzIHRoZSBjYXNlLCBJIGFtIGF3YXJlIG9mIHNpdHVhdGlvbnMgd2hlcmUgZW1lcmdlbmN5IGNh bGxzIGp1c3QgbG9vayBsaWtlIG5vcm1hbCBjYWxscyB3aXRoIGEgbnVtYmVyIG9mIDkxMS4gSSdt IGFsc28gc3RpbGwgdW5jbGVhciBhYm91dCB3aGF0IGFmZmVjdCB0aGlzIGhhcywgYXMgeW91IGNh biBjdXJyZW50bHkgYWxyZWFkeSBzaWduIGVtZXJnZW5jeSBjYWxscyB1c2luZyB0aGUgc3RhbmRh cmQgbWVjaGFuaXNtcyAoYmFycmluZyB0aGUgd2hvbGUgInVybjpzZXJ2aWNlOnNvcyIgdG4gd2hp Y2ggSSBkb24ndCBiZWxpZXZlIGlzIHN0YW5kYXJkaXNlZCBmb3IgU1RJUiB5ZXQ/KSAgYnkgcHV0 dGluZyAiZXNuZXQuMCIgaW4gdGhlIGF1dGggZmllbGQgb2YgYW4gcnBoIHBhc3Nwb3J0Lg0KDQpG b3IgRVNjYWxsYmFjaywgaWYgdGhlIHNwaCBhbmQgInJwaC5hdXRoIiBjbGFpbXMgY292ZXIgdGhl aXMgZW50aXJlbHkgd2h5IGlzIEVTY2FsbGJhY2sgbmVlZGVkPyBJJ20gYWxzbyBzdGlsbCB1bmNs ZWFyIHdoYXQgdGhlIHZlcmlmaWNhdGlvbiBzZXJ2aWNlIGJlaGF2aW91ciBpcyBoZXJlLg0KDQpJ J20gc3RpbGwgdW5jbGVhciBhcyB0byBob3cgdGhpcyBzcGVjIGhlbHBzIHdpdGggYWxsb3dpbmcg YW5kIHByZXZlbnRpbmcgbWFsaWNpb3VzIHVzZSBvZiBlbWVyZ2VuY3kgY2FsbHMuIFlvdSBjYW4g YWxyZWFkeSBwdXQgZXNuZXQgcmVzb3VyY2UgcHJpb3JpdHkgcGFpcnMgaW4gdGhlICJycGguYXV0 aCIgY2xhaW0gYW5kIHRoYXQgc2VlbXMgdG8gcHJvdmlkZSBhcyBtdWNoIHNlY3VyaXR5IGFzIHRo aXMgZG9lcy4gSSBkbyBhZ3JlZSB0aGUgc3BoIGNsYWltIGRvZXMgcHJvdmlkZSB2YWx1ZSwgaG93 ZXZlci4NCg0KSSBkaWQganVzdCByZWFsaXNlIHRoYXQgdGhlIGVzbmV0IFJlc291cmNlIFByaW9y aXR5IG5lZWRzIHRvIGJlIGluIHRoZSAicnBoLmF1dGgiIGNsYWltIG9yIHRoZSBsb2dpYyBmcm9t IHRoYXQgcmZjIHdpbGwga2ljayBpbiBhbmQgcmVtb3ZlIGl0LCBhcyBwZXI6DQpSRkMgODQ0Mywg c2VjdGlvbiA0LjINCiAgIEluIHN1Y2ggc2NlbmFyaW9zLCB0aGUgU0lQICdSZXNvdXJjZS1Qcmlv cml0eScgaGVhZGVyIGZpZWxkIFNIT1VMRCBiZQ0KICAgc3RyaXBwZWQgZnJvbSB0aGUgU0lQIHJl cXVlc3QsIGFuZCB0aGUgbmV0d29yayBlbnRpdGllcyBzaG91bGQgdHJlYXQNCiAgIHRoZSBjYWxs IGFzIGFuIG9yZGluYXJ5IGNhbGwuDQoNCkknbGwgbm90ZSB0aGF0IHNvbWUgb2YgbXkgcXVlc3Rp b25zIGFuZCBjb25jZXJucyBoYXZlbid0IGJlZW4gYWRkcmVzc2VkIHlldCwgSSdtIGhhcHB5IHRv IHJlc29sdmUgdGhpcyBmaXJzdCwganVzdCBtYWtpbmcgYSBub3RlIHNvIHRoYXQgdGhleSBkb24n dCBnZXQgbG9zdC9JIGRvbid0IGZvcmdldCBhYm91dCB0aGVtLg0KSmFjaw0KDQpGcm9tOiBCcmlh biBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+DQpTZW50OiAxOCBBdWd1c3QgMjAyMCAyMjozMQ0K VG86IEphY2sgUmlja2FyZCA8SmFjay5SaWNrYXJkQG1ldGFzd2l0Y2guY29tPg0KQ2M6IGRyYWZ0 LWlldGYtc3Rpci1ycGgtZW1lcmdlbmN5LXNlcnZpY2VzQGlldGYub3JnOyBzdGlyQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW3N0aXJdIFJldmlldyBvZiBkcmFmdC1pZXRmLXN0aXItcnBoLWVtZXJn ZW5jeS1zZXJ2aWNlcw0KDQpMZXTigJlzIGtlZXAgdGhlIHR3byB1c2UgY2FzZXMgc2VwYXJhdGU6 DQpFU29yaWcgaXMgYW4gZW1lcmdlbmN5IGNhbGwgKHVzZXIgdG8gYXV0aG9yaXR5KS4NCkVTY2Fs bGJhY2sgaXMgYSBjYWxsIGZyb20gYXV0aG9yaXR5IHRvIHVzZXIuDQoNCkZvciBFU29yZywgdGhl IGNhbGwgaXMgbWFya2VkIHdpdGggYSBSZXF1ZXN0LVVSSSBvZiB1cm46c2VydmljZTpzb3MuICBU aGUg4oCcVG/igJ0gZmllbGQgaXMgaWdub3JlZCBpbiByb3V0aW5nIGFuZCBoYW5kbGluZyB0aGUg Y2FsbC4gIFRoYXTigJlzIGhvdyB5b3Uga25vdyB0aGlzIGlzIGFuIGVtZXJnZW5jeSBjYWxsLiAg IEZvciBzdGlyIHB1cnBvc2VzLCB0aGUgRnJvbSBpcyBhbiBvcmRpbmFyeSBpZGVudGlmaWVyLCBh bmQgZ2V0cyB0cmVhdGVkIGluIHRoZSBub3JtYWwgd2F5LiAgSG93ZXZlciwgdGhlIHJwaCB2YWx1 ZSBjYW4gb25seSBiZSB1c2VkIGJ5IGEgdmFsaWQgZW1lcmdlbmN5IGNhbGwsIGFuZCBhIHZhbGlk IGVtZXJnZW5jeSBjYWxsIGlzIGEgUmVxdWVzdCBVUkkgb2YgdXJuOnNlcnZpY2U6c29zLCBhbmQg YSB2YWxpZCBGcm9tLiAgU28geW91IGRvbuKAmXQgaGF2ZSBhbnkga25vd2xlZGdlIG9mIGVtZXJn ZW5jeSBzZXJ2aWNlcyBpZGVudGlmaWVycywgb25seSB0aGUgUmVxdWVzdCBVUkkgb2YgdXJuOnNl cnZpY2U6c29zLg0KDQpGb3IgRVNjYWxsYmFjaywgdGhlIG1hcmtpbmcgaXMgYSBkaXN0aW5ndWlz aGVkIHZhbHVlIGluIFNJUCBQcmlvcml0eS4gIElmIGEgY2FsbCBoYXMgdGhhdCB2YWx1ZSwgaXTi gJlzIGEgY2FsbCBiYWNrLiAgVGhlIG9yaWdpbmF0aW5nIHNlcnZpY2UgcHJvdmlkZXIga25vd3Mg d2hvIGFyZSB0aGUgYXV0aG9yaXRpZXMgd2hvIGFyZSBhbGxvd2VkIHRvIHBsYWNlIGNhbGwgYmFj a3MsIHNvIHRoZSBjaGVjayBpcyB3aGF0IGlzIGluIFNJUCBQcmlvcml0eSwgYW5kIG9uZSBvZiB0 aGUgYWxsb3dlZCBhdXRob3JpdGllcyBpbiBGcm9tLiAgQXMgYSBwcmFjdGljYWwgbWF0dGVyLCBp biBtb3N0IGNhc2VzLCB0aGUgY2FsbCB3aWxsIGJlIHNpZ25lZCBieSB0aGUgZW1lcmdlbmN5IGF1 dGhvcml0aWVzIHRoZW1zZWx2ZXMsIHdobyB3aWxsIGJlIGFibGUgdG8gZ2V0IGFwcHJvcHJpYXRl IGNyZWRlbnRpYWxzIGZvciB0aGlzIHB1cnBvc2UuICBJbiBtb3N0IGNhc2VzIEnigJltIGF3YXJl IG9mLCB0aGUgVG8gaW4gYW4gZW1lcmdlbmN5IGNhbGwgd29u4oCZdCBtYXRjaCB0aGUgRnJvbSBp biBhIENhbGxiYWNrLCBidXQgaXTigJlzIHBvc3NpYmxlIGZvciB0aGF0IHRvIGhhcHBlbiwgYW5k IHdlIHdhbnQgdG8gYWxsb3cgaXQuDQoNCkVzbmV0IGlzIGEgUmVzb3VyY2UgUHJpb3JpdHkgSGVh ZGVyIG5hbWVzcGFjZSwgbm90IGEgU0lQIFByaW9yaXR5IHZhbHVlLiAgV2XigJlyZSBhbGxvd2lu ZyBlbWVyZ2VuY3kgY2FsbHMgYW5kIGNhbGwgYmFja3MgdG8gdXNlIHJwaCwgYW5kIHdl4oCZcmUg cHJvdGVjdGluZyBhZ2FpbnN0IG1hbGljaW91cyB1c2Ugb2YgaXQuICBTbyB1bmxlc3MgdGhlIGNh bGwgaGFzIHVybjpzZXJ2aWNlOnNvcyBpbiBSZXF1ZXN0IFVSSSwgb3IgdGhlIHJpZ2h0IFNJUCBQ cmlvcml0eSBpbiBhIGNhbGwgYmFjayAoYW5kIGZyb20gYW4gYXV0aG9yaXplZCBhdXRob3JpdHkp IHRoZXkgY2Fu4oCZdCB1c2UgcnBoIHdpdGggdGhlIGVzbmV0IG5hbWVzcGFjZS4gIEdlbmVyYWxs eSwgdW5sZXNzIHVuZGVyIGF0dGFjaywgZW1lcmdlbmN5IGNhbGxzIGdvIHRocm91Z2ggZXZlbiBp ZiB0aGVyZSBpc27igJl0IGEgcGFzc3BvcnQuICBNYW55IG5ldHdvcmtzIHdvbuKAmXQgb2ZmZXIg YWN0dWFsIHByaW9yaXR5IHRvIGVtZXJnZW5jeSBjYWxscywgYnV0IHRoZSBlbWVyZ2VuY3kgc2Vy dmljZXMgbmV0d29ya3MgKEVTSW5ldHMpIHdpbGwuDQoNCklmIGEgY2FsbCBhcnJpdmVzIGFueXdo ZXJlIHdpdGggYW4gcnBoIHVzaW5nIGVzbmV0LCBhbmQgaXNu4oCZdCBhbiBlbWVyZ2VuY3kgY2Fs bCwgd2l0aCB0aGUgYXBwcm9wcmlhdGUgcGFzc3BvcnQsICBhbnkgaW50ZXJtZWRpYXJ5IGNhbiBy ZWZ1c2UgdG8gZ2l2ZSBpdCBhbnkgcHJpb3JpdHksICBUaGUgZW1lcmdlbmN5IGF1dGhvcml0aWVz IG1heSBhY2NlcHQgYSBjYWxsIHdpdGhvdXQgYSB2YWxpZCBwYXNzcG9ydCwgYnV0IHRoZXkgbWln aHQgdHJlYXQgaXQgd2l0aCBtdWNoIG1vcmUgc3VzcGljaW9uIHRoYW4gdGhleSB3b3VsZCBhbnkg b3RoZXIgY2FsbC4NCg0KRm9yIGNhbGwgYmFja3MsIHRoZSBuZXR3b3JrIG1heSBoYXZlIHNwZWNp YWwgYmVoYXZpb3IuICBGb3IgZXhhbXBsZSwgaXQgbWF5IHNlbmQgdGhlIGNhbGwgdG8gdGhlIGRl dmljZSB0aGF0IHBsYWNlZCB0aGUgZW1lcmdlbmN5IGNhbGwsIHJhdGhlciB0aGFuLCBmb3IgZXhh bXBsZSwgdm9pY2UgbWFpbC4gIFRoZSBuZXR3b3JrIGhhcyB0byBiZSBhYmxlIHRvIHRydXN0IHRo YXQgU0lQIFByaW9yaXR5IGlzIHNldCBhcHByb3ByaWF0ZWx5LiAgSXQgd2lsbCBhbHNvIGhhdmUg cnBoIHVzaW5nIGVzbmV0LCBhbmQgdGhlIG5ldHdvcmsgY2FuIGdyYW50IGl0IGFwcHJvcHJpYXRl IHByaW9yaXR5IGlmIGl0IGhhcyB0aGF0IGNhcGFiaWxpdHksIGFuZCB3b3VsZCBub3QgYWxsb3cg ZXNuZXQgb3RoZXJ3aXNlLg0KDQpUaGUgb25seSB2YWx1ZSBpbiBjb3ZlcmluZyBvdGhlciB1c2Vz IG9mIFNJUCBQcmlvcml0eSBpcyB0byBwcm90ZWN0IGFnYWluc3QgbWlkZGxlIGJveGVzIG1vZGlm eWluZyBpdC4gIFdlIGRvbuKAmXQgcmVhbGx5IGhhdmUgdXNlIGNhc2VzIGZvciB0aGF0LiAgSXQg cHJvYmFibHkgd291bGRu4oCZdCBodXJ0IHRvIGFsbG93IGl0IHRob3VnaC4NCg0KRG9lcyB0aGF0 IGhlbHA/DQoNCkJyaWFuDQoNCg0KDQpPbiBBdWcgMTQsIDIwMjAsIGF0IDE6MjEgUE0sIEphY2sg Umlja2FyZCA8SmFjay5SaWNrYXJkPTQwbWV0YXN3aXRjaC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFp bHRvOkphY2suUmlja2FyZD00MG1ldGFzd2l0Y2guY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6 DQoNCkkgaGF2ZSByZXZpZXdlZCBkcmFmdC1pZXRmLXN0aXItcnBoLWVtZXJnZW5jeS1zZXJ2aWNl cy0wMiBhbmQgaGF2ZSBzb21lIGNvbmNlcm5zIGFuZCBxdWVzdGlvbnMuIEkgZG9uJ3QgYmVsaWV2 ZSB0aGlzIHNwZWMgaXMgaW1wbGVtZW50YWJsZSBpbiBpdHMgY3VycmVudCBmb3JtLg0KDQpUaGFu a3MsDQpKYWNrDQoNCldoeSBhcmUgIkVTb3JpZyIgYW5kICJFU2NhbGxiYWNrIiBkaXN0aW5jdD8N ClRoZXkgc2VlbSB0byBzZXJ2ZSBhIHZlcnkgc2ltaWxhciBwdXJwb3NlIHdpdGggdGhlIG9ubHkg ZGlmZmVyZW5jZSBiZWluZyB3aGV0aGVyIG9yaWcgb3IgZGVzdCBzaG91bGQgYmUgdGhlIGVtZXJn ZW5jeSBzZXJ2aWNlcy4gSSBkb24ndCBiZWxpZXZlIHRoZXJlJ3MgYW55IGNoZWNrIHRoYXQgY2Fu IGJlIGRvbmUgdG8gdmFsaWRhdGU6DQogICBXaGVuIHVzaW5nICJFU29yaWciIGFzIHRoZSAicnBo IiBhc3NlcnRpb24gdmFsdWUsIHRoZSAib3JpZyIgY2xhaW0gb2YNCiAgIHRoZSBQQVNTcG9yVCBN VVNUIHJlcHJlc2VudCB0aGUgY2FsbGluZyBwYXJ0eSBudW1iZXIgdGhhdCBpbml0aWF0ZXMNCiAg IHRoZSBjYWxsIHRvIGVtZXJnZW5jeSBzZXJ2aWNlcy4NClRoaXMgKGFuZCB0aGUgZXF1aXZhbGVu dCBzdGF0ZW1lbnQgZm9yIEVTY2FsbGJhY2spIGRvbid0IHNlZW0gcG9zc2libGUgdG8gbWUgdG8g Y2hlY2sgKGJhcnJpbmcgdGhlIHN0YW5kYXJkIG9yaWcvZGVzdCBjaGVja2luZykuLg0KVGhpcyB3 b3VsZCBtYWtlIHRoZSBjaGVjayAiYXQgbGVhc3Qgb25lIG9mIHRoZSBwYXJ0aWVzIHNob3VsZCBi ZSB0aGUgZW1lcmdlbmN5IHNlcnZpY2VzIiBlbm91Z2ggdG8gdmFsaWRhdGUgdGhhdCB0aGlzIHdh cyBhIHJlYXNvbmFibGUgY2FsbC4NCg0KDQpXaHkgaGF2ZSB0aGVtIGF0IGFsbCByYXRoZXIgdGhh biBqdXN0IHVzaW5nIGF1dGg/DQpUaGlzIGlzIHZlcnkgcG9zc2libHkgYW4gaXNzdWUgd2l0aCBt eSB1bmRlcnN0YW5kaW5nLCBidXQgSSdtIG5vdCBjbGVhciBvbiB3aHkgIkVTb3JpZyIgYW5kICJF U2NhbGxiYWNrIiBldmVuIG5lZWQgdG8gZXhpc3QuICJlc25ldC4wIiBldGMuIGFyZSBTSVAgUmVz b3VyY2UgUHJpb3JpdHkgaGVhZGVycywgc28gc2hvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSAiYXV0 aCIgZmllbGQgYW55d2F5IGJ5IHRoZSBSUEggc3BlYy4gVGhpcyBzcGVjIGFwcGVhcnMgdG8gYXBw bHkgZXh0cmEgY29uc3RyYWludHMgKHRoYXQgYSBvbmUgb2YgdGhlIGNhbGxlcnMgbXVzdCBiZSB0 aGUgZW1lcmdlbmN5IHNlcnZpY2VzKSBmb3IgdGhlICJlc25ldCIgbmFtZXNwYWNlIGJ1dCBpdCdz IG5vdCBjbGVhciB3aHkgZW50aXJlbHkgc2VwYXJhdGUgY2xhaW1zIGFyZSBuZWVkZWQuDQoNCklu IGEgc2ltaWxhciB2ZWluLCB3aGF0IHNob3VsZCBhIHZlcmlmaWVyIGRvIGlmIGl0IHJlY2VpdmVz IGEgY2FsbCBjb250YWluaW5nIGFuIGludmFsaWQgIkVTb3JpZyIgb3IgIkVTY2FsbGJhY2siIHZh bHVlIG9yIHRoZSBwYXNzcG9ydCBpcyBpbnZhbGlkL3VudHJ1c3RlZCwgSSdtIGFzc3VtaW5nIHRo ZSBiZWhhdmlvdXIgaXMgdGhlIHNhbWUgYXMgZm9yIGF1dGggYnV0IHRoaXMgaXNuJ3QgY2xlYXIu IEFsdGhvdWdoIHN0cmlwcGluZyB0aGUgZmFjdCB0aGF0IHRoaXMgaXMgYW4gZW1lcmdlbmN5IGNh bGwgaXMgcG90ZW50aWFsbHkgZGFuZ2Vyb3VzLi4NCg0KDQpTcGVjaWZ5IHRoZSB0eXBlIG9mIHRo ZSAiRVNvcmlnIiBhbmQgIkVTY2FsbGJhY2siIGNsYWltcy4NClRoaXMgc3BlY2lmaWNhdGlvbiBj dXJyZW50bHkgZG9lc24ndCBzcGVjaWZ5IHRoZSB0eXBlIG9mIHRoZSBuZXcgZmllbGRzLCB0aGVy ZSBhcmUgb25seSBleGFtcGxlcyBhbmQgdGhpcyBpc24ndCBlbm91Z2guIEl0IGxvb2tzIGxpa2Ug dGhleSBib3RoIGZvbGxvdyB0aGUgc2FtZSBzY2hlbWUgYXMgdGhlIHJwaCAiYXV0aCIgY2xhaW0s IGhvd2V2ZXIgImVzbmV0LHgiIGRvZXNuJ3QgcXVpdGUgZml0IGludG8gdGhhdCBkdWUgdG8gdGhl IGNvbW1hIGFuZCB0aGF0IHggaXNuJ3QgYSB2YWxpZCBwcmlvcml0eSB2YWx1ZS4NCg0KDQpXaHkg aXMgc3BoIGxpbWl0ZWQgdG8gcHNhcC1jYWxsYmFjaz8gV2hhdCBzaG91bGQgdGhlIHZlcmlmaWVy IGRvIGlmIGl0IGlzbid0IHRoYXQ/IFdoYXQgc2hvdWxkIGl0IGRvIGlmIGl0IGlzPw0KSSdtIG5v dCBlbnRpcmVseSBjbGVhciBvbiB0aGUgcHVycG9zZSBvZiB0aGUgc3BoIGNsYWltLCBob3dldmVy LCBpdCBzZWVtcyBvZGQgdGhhdCBpdCBkb2Vzbid0IGNvdmVyIHRoZSBmdWxsIHJhbmdlIG9mIHBv c3NpYmxlIHZhbHVlcyBmb3IgdGhlIFNJUCBQcmlvcml0eSBIZWFkZXIuIElzIHRoZXJlIGEgcmVh c29uIHRoYXQgaXQgZG9lc24ndCBjb3ZlciB0aGUgIm5vbi11cmdlbnQiLCAibm9ybWFsIiwgInVy Z2VudCIsIG9yICJlbWVyZ2VuY3kiIHZhbHVlcz8NClRoZXJlIGlzIGFsc28gbm8gdmVyaWZpZXIg YmVoYXZpb3VyIGRlZmluZWQgaGVyZSwgc2hvdWxkIHRoZSB2ZXJpZmllciByZW1vdmUgdGhlIFBy aW9yaXR5IGhlYWRlciBpZiBpdCByZWNlaXZlcyBhbiBpbnZpdGUgd2l0aCBubyBwYXNzcG9ydHMg c2lnbmluZyBmb3IgaXQ/IFRoYXQgc2VlbXMgZGFuZ2Vyb3VzIHRvIG1lIGJ1dCB3b3VsZCBiZSBj b25zaXN0ZW50IHdpdGggcnBoLiBBbHRlcm5hdGl2ZWx5LCB3aGF0IHNob3VsZCB0aGUgdmVyaWZp ZXIgZG8gaWYgaXQgcmVjZWl2ZXMgYW4gaW52aXRlIHdpdGggYSB2YWxpZCBwYXNzcG9ydCBjbGFp bWluZyBzcGggYnV0IHdpdGggbm8gUHJpb3JpdHkgaGVhZGVyIHNob3VsZCBpdCBhZGQgaXQgaW4/ IEknbSBub3Qgc3VyZSB0aGUgc3BlYyBuZWVkcyB0byBiZSB0b28gcHJlc2NyaXB0aXZlIGhlcmUs IGhvd2V2ZXIgc29tZSBtZW50aW9uIG9mIHZlcmlmaWVyIGJlaGF2aW91ciBhbmQgdGhlIGFzc29j aWF0ZWQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd291bGQgYmUgdXNlZnVsLg0KDQoNClNob3Vs ZCB0aGUgc3BlYyBiZSBzdHJvbmdlciBhYm91dCB0aGUgY29tcGFjdCBmb3JtPw0KU2VjdGlvbiAz IGN1cnJlbnRseSBzdGF0ZXMNCg0KICAgVGhlIHVzZSBvZiB0aGUgY29tcGFjdCBmb3JtIG9mIFBB U1Nwb3JUIGlzIG5vdCBzcGVjaWZpZWQgaW4gdGhpcw0KDQogICBkb2N1bWVudC4NCkhvd2V2ZXIs IGEgY29tcGFjdC1mb3JtIHBhc3Nwb3J0IGZvbGxvd2luZyB0aGlzIHNwZWMgd291bGQgYmUgaGFy ZCB0byB2ZXJpZnkgYXMgaXQgaW50cm9kdWNlcyBtdWx0aXBsZSBwb3NzaWJsZSBycGggdmFyaWFu dHMsIEkgdGhpbmsgdGhpcyBzcGVjIGNvdWxkIGdvIGZ1cnRoZXIgYW5kIHNheSB5b3Ugc2hvdWxk bid0L211c3RuJ3QuDQoNCg0KV2hhdCBpcyB0aGUgcmVxdWlyZW1lbnQgb2YgdGhlc2UgbmV3IHBh cmFtZXRlcnMuDQpBcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBwYXNzcG9ydCBzcGVjIGFsbG93cyB5 b3UgdG8gY3JlYXRlIGEgcGFzc3BvcnQgY29udGFpbmluZyB3aGF0ZXZlciBKV1QgZmllbGRzIHlv dSB3YW50IGFuZCB2ZXJpZmllcnMgc2hvdWxkIGp1c3QgaWdub3JlIGFueSBmaWVsZHMgdGhleSBk b24ndCB1bmRlcnN0YW5kLiBVbmxlc3MgdGhlICJwcHQiIGNsYWltIGlzIHNldCwgd2hpY2ggaW5k aWNhdGVzIHRoYXQgdmVyaWZpZXJzIHNob3VsZCBkaXNjYXJkIGl0IGlmIHRoZXkgZG9uJ3QgcmVj b2duaXNlIHRoYXQgcGFzc3BvcnQgdHlwZS4gQXMgdGhpcyBzcGVjIGFkZHMgYWRkaXRpb25hbCBm aWVsZHMgdG8gYW4gZXhpc3RpbmcgcGFzc3BvcnQgdHlwZSBpdCBpc24ndCBpbW1lZGlhdGVseSBj bGVhciB3aGF0IHRoZSBiZWhhdmlvdXIgc2hvdWxkIGJlLiBTcGVjaWZpY2FsbHksIGlzIGFuIHJw aCBwYXNzcG9ydCBjb250YWluaW5nIG9ubHkgInJwaC5FU29yaWciIHZhbGlkIG5vdyAod2hlcmUg aXQgd291bGRuJ3QgYmUgYmVmb3JlIGJlY2F1c2UgYXV0aCBpc24ndCBwcmVzZW50KSwgaXMgYW4g cnBoIHBhc3Nwb3J0IGNvbnRhaW5pbmcgbm8gcnBoIGFuZCBvbmx5IHNwaCB2YWxpZCwgYW5kIHdo YXQgZG9lcyBhIG5vbi1ycGggcGFzc3BvcnQgd2l0aCBzcGggb3IgRVNvcmlnIHNldCBtZWFuPw0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3RpciBt YWlsaW5nIGxpc3QNCnN0aXJAaWV0Zi5vcmc8bWFpbHRvOnN0aXJAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXI8aHR0cHM6Ly9uYW0wMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3Jn JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3RpciZkYXRhPTAyJTdDMDElN0NKYWNrLlJpY2thcmQl NDBtZXRhc3dpdGNoLmNvbSU3QzFkYTZiNThjZmFkYjQ4YTZjZWYzMDhkODQzYmRmNDRlJTdDOWQ5 ZTU2ZWJmNjEzNGRkYmIyN2JiZmNkZjE0YjJjZGIlN0MxJTdDMCU3QzYzNzMzMzgzMDQ1NDc1NTA3 OCZzZGF0YT1wRlJrY3lvMzd3MGVWR3o4NldZbWhpaWpIUGVSWU1BNTcwS0V4T1U5dWlzJTNEJnJl c2VydmVkPTA+DQoNCg== --_000_BYAPR02MB5189BE4C40E7A72BCFC8BD03F35D0BYAPR02MB5189namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglm b250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsIHRoYXQncyByZWFsbHkgdXNlZnVsLCBob3dldmVy LCBJJ20gbm90IGNvbnZpbmNlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Rm9yIEVTb3JpZywgYXMgZmFyIGFzIEkga25vdyB0 aGlzIGlzbid0IGN1cnJlbnRseSBhbHdheXMgdGhlIGNhc2UsIEkgYW0gYXdhcmUgb2Ygc2l0dWF0 aW9ucyB3aGVyZSBlbWVyZ2VuY3kgY2FsbHMganVzdCBsb29rIGxpa2Ugbm9ybWFsIGNhbGxzIHdp dGggYSBudW1iZXIgb2YgOTExLiBJJ20gYWxzbyBzdGlsbCB1bmNsZWFyIGFib3V0IHdoYXQNCiBh ZmZlY3QgdGhpcyBoYXMsIGFzIHlvdSBjYW4gY3VycmVudGx5IGFscmVhZHkgc2lnbiBlbWVyZ2Vu Y3kgY2FsbHMgdXNpbmcgdGhlIHN0YW5kYXJkIG1lY2hhbmlzbXMgKGJhcnJpbmcgdGhlIHdob2xl ICZxdW90O3VybjpzZXJ2aWNlOnNvcyZxdW90OyB0biB3aGljaCBJIGRvbid0IGJlbGlldmUgaXMg c3RhbmRhcmRpc2VkIGZvciBTVElSIHlldD8pJm5ic3A7IGJ5IHB1dHRpbmcgJnF1b3Q7ZXNuZXQu MCZxdW90OyBpbiB0aGUgYXV0aCBmaWVsZCBvZiBhbiBycGggcGFzc3BvcnQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkZvciBF U2NhbGxiYWNrLCBpZiB0aGUgc3BoIGFuZCAmcXVvdDtycGguYXV0aCZxdW90OyBjbGFpbXMgY292 ZXIgdGhlaXMgZW50aXJlbHkgd2h5IGlzIEVTY2FsbGJhY2sgbmVlZGVkPyBJJ20gYWxzbyBzdGls bCB1bmNsZWFyIHdoYXQgdGhlIHZlcmlmaWNhdGlvbiBzZXJ2aWNlIGJlaGF2aW91ciBpcyBoZXJl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5JJ20gc3RpbGwgdW5jbGVhciBhcyB0byBob3cgdGhpcyBzcGVjIGhlbHBzIHdpdGgg YWxsb3dpbmcgYW5kIHByZXZlbnRpbmcgbWFsaWNpb3VzIHVzZSBvZiBlbWVyZ2VuY3kgY2FsbHMu IFlvdSBjYW4gYWxyZWFkeSBwdXQgZXNuZXQgcmVzb3VyY2UgcHJpb3JpdHkgcGFpcnMgaW4gdGhl ICZxdW90O3JwaC5hdXRoJnF1b3Q7IGNsYWltIGFuZCB0aGF0IHNlZW1zDQogdG8gcHJvdmlkZSBh cyBtdWNoIHNlY3VyaXR5IGFzIHRoaXMgZG9lcy4gSSBkbyBhZ3JlZSB0aGUgc3BoIGNsYWltIGRv ZXMgcHJvdmlkZSB2YWx1ZSwgaG93ZXZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBkaWQganVzdCByZWFsaXNlIHRoYXQg dGhlIGVzbmV0IFJlc291cmNlIFByaW9yaXR5IG5lZWRzIHRvIGJlIGluIHRoZSAmcXVvdDtycGgu YXV0aCZxdW90OyBjbGFpbSBvciB0aGUgbG9naWMgZnJvbSB0aGF0IHJmYyB3aWxsIGtpY2sgaW4g YW5kIHJlbW92ZSBpdCwgYXMgcGVyOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UkZDIDg0 NDMsIHNlY3Rpb24gNC4yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBJbiBzdWNoIHNjZW5hcmlvcywgdGhlIFNJUCAnUmVz b3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCBTSE9VTEQgYmU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHN0cmlwcGVk IGZyb20gdGhlIFNJUCByZXF1ZXN0LCBhbmQgdGhlIG5ldHdvcmsgZW50aXRpZXMgc2hvdWxkIHRy ZWF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyB0aGUgY2FsbCBhcyBhbiBvcmRpbmFyeSBjYWxsLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JJ2xsIG5v dGUgdGhhdCBzb21lIG9mIG15IHF1ZXN0aW9ucyBhbmQgY29uY2VybnMgaGF2ZW4ndCBiZWVuIGFk ZHJlc3NlZCB5ZXQsIEknbSBoYXBweSB0byByZXNvbHZlIHRoaXMgZmlyc3QsIGp1c3QgbWFraW5n IGEgbm90ZSBzbyB0aGF0IHRoZXkgZG9uJ3QgZ2V0IGxvc3QvSSBkb24ndCBmb3JnZXQgYWJvdXQg dGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkphY2s8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQnJpYW4gUm9zZW4gJmx0O2Jy QGJyaWFucm9zZW4ubmV0Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDE4IEF1Z3VzdCAyMDIwIDIy OjMxPGJyPg0KPGI+VG86PC9iPiBKYWNrIFJpY2thcmQgJmx0O0phY2suUmlja2FyZEBtZXRhc3dp dGNoLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYtc3Rpci1ycGgtZW1lcmdlbmN5 LXNlcnZpY2VzQGlldGYub3JnOyBzdGlyQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbc3Rpcl0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtc3Rpci1ycGgtZW1lcmdlbmN5LXNlcnZpY2Vz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxl dOKAmXMga2VlcCB0aGUgdHdvIHVzZSBjYXNlcyBzZXBhcmF0ZTogPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RVNvcmlnIGlzIGFuIGVtZXJnZW5jeSBjYWxsICh1 c2VyIHRvIGF1dGhvcml0eSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5FU2NhbGxiYWNrIGlzIGEgY2FsbCBmcm9tIGF1dGhvcml0eSB0byB1c2Vy LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G b3IgRVNvcmcsIHRoZSBjYWxsIGlzIG1hcmtlZCB3aXRoIGEgUmVxdWVzdC1VUkkgb2YgdXJuOnNl cnZpY2U6c29zLiAmbmJzcDtUaGUg4oCcVG/igJ0gZmllbGQgaXMgaWdub3JlZCBpbiByb3V0aW5n IGFuZCBoYW5kbGluZyB0aGUgY2FsbC4gJm5ic3A7VGhhdOKAmXMgaG93IHlvdSBrbm93IHRoaXMg aXMgYW4gZW1lcmdlbmN5IGNhbGwuICZuYnNwOyBGb3Igc3RpciBwdXJwb3NlcywgdGhlIEZyb20g aXMgYW4gb3JkaW5hcnkgaWRlbnRpZmllciwgYW5kDQogZ2V0cyB0cmVhdGVkIGluIHRoZSBub3Jt YWwgd2F5LiAmbmJzcDtIb3dldmVyLCB0aGUgcnBoIHZhbHVlIGNhbiBvbmx5IGJlIHVzZWQgYnkg YSB2YWxpZCBlbWVyZ2VuY3kgY2FsbCwgYW5kIGEgdmFsaWQgZW1lcmdlbmN5IGNhbGwgaXMgYSBS ZXF1ZXN0IFVSSSBvZiB1cm46c2VydmljZTpzb3MsIGFuZCBhIHZhbGlkIEZyb20uICZuYnNwO1Nv IHlvdSBkb27igJl0IGhhdmUgYW55IGtub3dsZWRnZSBvZiBlbWVyZ2VuY3kgc2VydmljZXMgaWRl bnRpZmllcnMsIG9ubHkgdGhlDQogUmVxdWVzdCBVUkkgb2YgdXJuOnNlcnZpY2U6c29zLiAmbmJz cDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Rm9yIEVTY2FsbGJhY2ssIHRoZSBtYXJraW5nIGlzIGEgZGlzdGluZ3Vpc2hlZCB2YWx1 ZSBpbiBTSVAgUHJpb3JpdHkuICZuYnNwO0lmIGEgY2FsbCBoYXMgdGhhdCB2YWx1ZSwgaXTigJlz IGEgY2FsbCBiYWNrLiAmbmJzcDtUaGUgb3JpZ2luYXRpbmcgc2VydmljZSBwcm92aWRlciBrbm93 cyB3aG8gYXJlIHRoZSBhdXRob3JpdGllcyB3aG8gYXJlIGFsbG93ZWQgdG8gcGxhY2UgY2FsbCBi YWNrcywgc28gdGhlIGNoZWNrIGlzIHdoYXQNCiBpcyBpbiBTSVAgUHJpb3JpdHksIGFuZCBvbmUg b2YgdGhlIGFsbG93ZWQgYXV0aG9yaXRpZXMgaW4gRnJvbS4gJm5ic3A7QXMgYSBwcmFjdGljYWwg bWF0dGVyLCBpbiBtb3N0IGNhc2VzLCB0aGUgY2FsbCB3aWxsIGJlIHNpZ25lZCBieSB0aGUgZW1l cmdlbmN5IGF1dGhvcml0aWVzIHRoZW1zZWx2ZXMsIHdobyB3aWxsIGJlIGFibGUgdG8gZ2V0IGFw cHJvcHJpYXRlIGNyZWRlbnRpYWxzIGZvciB0aGlzIHB1cnBvc2UuICZuYnNwO0luIG1vc3QgY2Fz ZXMgSeKAmW0gYXdhcmUNCiBvZiwgdGhlIFRvIGluIGFuIGVtZXJnZW5jeSBjYWxsIHdvbuKAmXQg bWF0Y2ggdGhlIEZyb20gaW4gYSBDYWxsYmFjaywgYnV0IGl04oCZcyBwb3NzaWJsZSBmb3IgdGhh dCB0byBoYXBwZW4sIGFuZCB3ZSB3YW50IHRvIGFsbG93IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Fc25ldCBpcyBhIFJlc291cmNlIFBy aW9yaXR5IEhlYWRlciBuYW1lc3BhY2UsIG5vdCBhIFNJUCBQcmlvcml0eSB2YWx1ZS4gJm5ic3A7 V2XigJlyZSBhbGxvd2luZyBlbWVyZ2VuY3kgY2FsbHMgYW5kIGNhbGwgYmFja3MgdG8gdXNlIHJw aCwgYW5kIHdl4oCZcmUgcHJvdGVjdGluZyBhZ2FpbnN0IG1hbGljaW91cyB1c2Ugb2YgaXQuICZu YnNwO1NvIHVubGVzcyB0aGUgY2FsbCBoYXMgdXJuOnNlcnZpY2U6c29zIGluIFJlcXVlc3QgVVJJ LA0KIG9yIHRoZSByaWdodCBTSVAgUHJpb3JpdHkgaW4gYSBjYWxsIGJhY2sgKGFuZCBmcm9tIGFu IGF1dGhvcml6ZWQgYXV0aG9yaXR5KSB0aGV5IGNhbuKAmXQgdXNlIHJwaCB3aXRoIHRoZSBlc25l dCBuYW1lc3BhY2UuICZuYnNwO0dlbmVyYWxseSwgdW5sZXNzIHVuZGVyIGF0dGFjaywgZW1lcmdl bmN5IGNhbGxzIGdvIHRocm91Z2ggZXZlbiBpZiB0aGVyZSBpc27igJl0IGEgcGFzc3BvcnQuICZu YnNwO01hbnkgbmV0d29ya3Mgd29u4oCZdCBvZmZlciBhY3R1YWwgcHJpb3JpdHkNCiB0byBlbWVy Z2VuY3kgY2FsbHMsIGJ1dCB0aGUgZW1lcmdlbmN5IHNlcnZpY2VzIG5ldHdvcmtzIChFU0luZXRz KSB3aWxsLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SWYgYSBjYWxsIGFycml2ZXMgYW55d2hlcmUgd2l0aCBhbiBycGggdXNpbmcg ZXNuZXQsIGFuZCBpc27igJl0IGFuIGVtZXJnZW5jeSBjYWxsLCB3aXRoIHRoZSBhcHByb3ByaWF0 ZSBwYXNzcG9ydCwgJm5ic3A7YW55IGludGVybWVkaWFyeSBjYW4gcmVmdXNlIHRvIGdpdmUgaXQg YW55IHByaW9yaXR5LCAmbmJzcDtUaGUgZW1lcmdlbmN5IGF1dGhvcml0aWVzIG1heSBhY2NlcHQg YSBjYWxsIHdpdGhvdXQgYSB2YWxpZCBwYXNzcG9ydCwNCiBidXQgdGhleSBtaWdodCB0cmVhdCBp dCB3aXRoIG11Y2ggbW9yZSBzdXNwaWNpb24gdGhhbiB0aGV5IHdvdWxkIGFueSBvdGhlciBjYWxs LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G b3IgY2FsbCBiYWNrcywgdGhlIG5ldHdvcmsgbWF5IGhhdmUgc3BlY2lhbCBiZWhhdmlvci4gJm5i c3A7Rm9yIGV4YW1wbGUsIGl0IG1heSBzZW5kIHRoZSBjYWxsIHRvIHRoZSBkZXZpY2UgdGhhdCBw bGFjZWQgdGhlIGVtZXJnZW5jeSBjYWxsLCByYXRoZXIgdGhhbiwgZm9yIGV4YW1wbGUsIHZvaWNl IG1haWwuICZuYnNwO1RoZSBuZXR3b3JrIGhhcyB0byBiZSBhYmxlIHRvIHRydXN0IHRoYXQgU0lQ IFByaW9yaXR5IGlzIHNldA0KIGFwcHJvcHJpYXRlbHkuICZuYnNwO0l0IHdpbGwgYWxzbyBoYXZl IHJwaCB1c2luZyBlc25ldCwgYW5kIHRoZSBuZXR3b3JrIGNhbiBncmFudCBpdCBhcHByb3ByaWF0 ZSBwcmlvcml0eSBpZiBpdCBoYXMgdGhhdCBjYXBhYmlsaXR5LCBhbmQgd291bGQgbm90IGFsbG93 IGVzbmV0IG90aGVyd2lzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIG9ubHkgdmFsdWUgaW4gY292ZXJpbmcgb3RoZXIgdXNlcyBvZiBT SVAgUHJpb3JpdHkgaXMgdG8gcHJvdGVjdCBhZ2FpbnN0IG1pZGRsZSBib3hlcyBtb2RpZnlpbmcg aXQuICZuYnNwO1dlIGRvbuKAmXQgcmVhbGx5IGhhdmUgdXNlIGNhc2VzIGZvciB0aGF0LiAmbmJz cDtJdCBwcm9iYWJseSB3b3VsZG7igJl0IGh1cnQgdG8gYWxsb3cgaXQgdGhvdWdoLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzIHRoYXQg aGVscD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QnJpYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gQXVnIDE0LCAyMDIwLCBhdCAxOjIxIFBNLCBKYWNrIFJpY2thcmQgJmx0OzxhIGhyZWY9Im1h aWx0bzpKYWNrLlJpY2thcmQ9NDBtZXRhc3dpdGNoLmNvbUBkbWFyYy5pZXRmLm9yZyI+SmFjay5S aWNrYXJkPTQwbWV0YXN3aXRjaC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSByZXZpZXdl ZCBkcmFmdC1pZXRmLXN0aXItcnBoLWVtZXJnZW5jeS1zZXJ2aWNlcy0wMiBhbmQgaGF2ZSBzb21l IGNvbmNlcm5zIGFuZCBxdWVzdGlvbnMuIEkgZG9uJ3QgYmVsaWV2ZSB0aGlzIHNwZWMgaXMgaW1w bGVtZW50YWJsZSBpbiBpdHMgY3VycmVudCBmb3JtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KYWNrPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPldoeSBhcmUgJnF1b3Q7RVNvcmln JnF1b3Q7IGFuZCAmcXVvdDtFU2NhbGxiYWNrJnF1b3Q7IGRpc3RpbmN0PzwvYj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXkgc2VlbSB0byBz ZXJ2ZSBhIHZlcnkgc2ltaWxhciBwdXJwb3NlIHdpdGggdGhlIG9ubHkgZGlmZmVyZW5jZSBiZWlu ZyB3aGV0aGVyIG9yaWcgb3IgZGVzdCBzaG91bGQgYmUgdGhlIGVtZXJnZW5jeSBzZXJ2aWNlcy4g SSBkb24ndCBiZWxpZXZlIHRoZXJlJ3MgYW55IGNoZWNrIHRoYXQgY2FuIGJlIGRvbmUgdG8gdmFs aWRhdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFdoZW4gdXNpbmcgJnF1b3Q7RVNvcmlnJnF1b3Q7IGFz IHRoZSAmcXVvdDtycGgmcXVvdDsgYXNzZXJ0aW9uIHZhbHVlLCB0aGUgJnF1b3Q7b3JpZyZxdW90 OyBjbGFpbSBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhlIFBBU1Nwb3JUIE1VU1QgcmVw cmVzZW50IHRoZSBjYWxsaW5nIHBhcnR5IG51bWJlciB0aGF0IGluaXRpYXRlczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgdGhlIGNhbGwgdG8gZW1lcmdlbmN5IHNlcnZpY2VzLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgKGFu ZCB0aGUgZXF1aXZhbGVudCBzdGF0ZW1lbnQgZm9yIEVTY2FsbGJhY2spIGRvbid0IHNlZW0gcG9z c2libGUgdG8gbWUgdG8gY2hlY2sgKGJhcnJpbmcgdGhlIHN0YW5kYXJkIG9yaWcvZGVzdCBjaGVj a2luZykuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhpcyB3b3VsZCBtYWtlIHRoZSBjaGVjayAmcXVvdDthdCBsZWFzdCBvbmUgb2YgdGhlIHBh cnRpZXMgc2hvdWxkIGJlIHRoZSBlbWVyZ2VuY3kgc2VydmljZXMmcXVvdDsgZW5vdWdoIHRvIHZh bGlkYXRlIHRoYXQgdGhpcyB3YXMgYSByZWFzb25hYmxlIGNhbGwuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+V2h5IGhhdmUgdGhlbSBh dCBhbGwgcmF0aGVyIHRoYW4ganVzdCB1c2luZyBhdXRoPzwvYj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgdmVyeSBwb3NzaWJseSBh biBpc3N1ZSB3aXRoIG15IHVuZGVyc3RhbmRpbmcsIGJ1dCBJJ20gbm90IGNsZWFyIG9uIHdoeSAm cXVvdDtFU29yaWcmcXVvdDsgYW5kICZxdW90O0VTY2FsbGJhY2smcXVvdDsgZXZlbiBuZWVkIHRv IGV4aXN0LiAmcXVvdDtlc25ldC4wJnF1b3Q7IGV0Yy4gYXJlIFNJUCBSZXNvdXJjZSBQcmlvcml0 eSBoZWFkZXJzLCBzbyBzaG91bGQgYmUgaW5jbHVkZWQgaW4gdGhlICZxdW90O2F1dGgmcXVvdDsg ZmllbGQgYW55d2F5IGJ5IHRoZSBSUEggc3BlYy4NCiBUaGlzIHNwZWMgYXBwZWFycyB0byBhcHBs eSBleHRyYSBjb25zdHJhaW50cyAodGhhdCBhIG9uZSBvZiB0aGUgY2FsbGVycyBtdXN0IGJlIHRo ZSBlbWVyZ2VuY3kgc2VydmljZXMpIGZvciB0aGUgJnF1b3Q7ZXNuZXQmcXVvdDsgbmFtZXNwYWNl IGJ1dCBpdCdzIG5vdCBjbGVhciB3aHkgZW50aXJlbHkgc2VwYXJhdGUgY2xhaW1zIGFyZSBuZWVk ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkluIGEgc2ltaWxhciB2ZWluLCB3aGF0IHNob3VsZCBhIHZlcmlmaWVyIGRvIGlmIGl0IHJlY2Vp dmVzIGEgY2FsbCBjb250YWluaW5nIGFuIGludmFsaWQgJnF1b3Q7RVNvcmlnJnF1b3Q7IG9yICZx dW90O0VTY2FsbGJhY2smcXVvdDsgdmFsdWUgb3IgdGhlIHBhc3Nwb3J0IGlzIGludmFsaWQvdW50 cnVzdGVkLCBJJ20gYXNzdW1pbmcgdGhlIGJlaGF2aW91ciBpcyB0aGUgc2FtZSBhcyBmb3IgYXV0 aCBidXQgdGhpcyBpc24ndCBjbGVhci4gQWx0aG91Z2gNCiBzdHJpcHBpbmcgdGhlIGZhY3QgdGhh dCB0aGlzIGlzIGFuIGVtZXJnZW5jeSBjYWxsIGlzIHBvdGVudGlhbGx5IGRhbmdlcm91cy4uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ U3BlY2lmeSB0aGUgdHlwZSBvZiB0aGUgJnF1b3Q7RVNvcmlnJnF1b3Q7IGFuZCAmcXVvdDtFU2Nh bGxiYWNrJnF1b3Q7IGNsYWltcy48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNwZWNpZmljYXRpb24gY3VycmVudGx5IGRvZXNuJ3Qg c3BlY2lmeSB0aGUgdHlwZSBvZiB0aGUgbmV3IGZpZWxkcywgdGhlcmUgYXJlIG9ubHkgZXhhbXBs ZXMgYW5kIHRoaXMgaXNuJ3QgZW5vdWdoLiBJdCBsb29rcyBsaWtlIHRoZXkgYm90aCBmb2xsb3cg dGhlIHNhbWUgc2NoZW1lIGFzIHRoZSBycGggJnF1b3Q7YXV0aCZxdW90OyBjbGFpbSwgaG93ZXZl ciAmcXVvdDtlc25ldCx4JnF1b3Q7IGRvZXNuJ3QgcXVpdGUgZml0IGludG8gdGhhdA0KIGR1ZSB0 byB0aGUgY29tbWEgYW5kIHRoYXQgeCBpc24ndCBhIHZhbGlkIHByaW9yaXR5IHZhbHVlLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPldo eSBpcyBzcGggbGltaXRlZCB0byBwc2FwLWNhbGxiYWNrPyBXaGF0IHNob3VsZCB0aGUgdmVyaWZp ZXIgZG8gaWYgaXQgaXNuJ3QgdGhhdD8gV2hhdCBzaG91bGQgaXQgZG8gaWYgaXQgaXM/PC9iPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIG5v dCBlbnRpcmVseSBjbGVhciBvbiB0aGUgcHVycG9zZSBvZiB0aGUgc3BoIGNsYWltLCBob3dldmVy LCBpdCBzZWVtcyBvZGQgdGhhdCBpdCBkb2Vzbid0IGNvdmVyIHRoZSBmdWxsIHJhbmdlIG9mIHBv c3NpYmxlIHZhbHVlcyBmb3IgdGhlIFNJUCBQcmlvcml0eSBIZWFkZXIuIElzIHRoZXJlIGEgcmVh c29uIHRoYXQgaXQgZG9lc24ndCBjb3ZlciB0aGUgJnF1b3Q7bm9uLXVyZ2VudCZxdW90OywgJnF1 b3Q7bm9ybWFsJnF1b3Q7LCAmcXVvdDt1cmdlbnQmcXVvdDssDQogb3IgJnF1b3Q7ZW1lcmdlbmN5 JnF1b3Q7IHZhbHVlcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZXJlIGlzIGFsc28gbm8gdmVyaWZpZXIgYmVoYXZpb3VyIGRlZmluZWQgaGVy ZSwgc2hvdWxkIHRoZSB2ZXJpZmllciByZW1vdmUgdGhlIFByaW9yaXR5IGhlYWRlciBpZiBpdCBy ZWNlaXZlcyBhbiBpbnZpdGUgd2l0aCBubyBwYXNzcG9ydHMgc2lnbmluZyBmb3IgaXQ/IFRoYXQg c2VlbXMgZGFuZ2Vyb3VzIHRvIG1lIGJ1dCB3b3VsZCBiZSBjb25zaXN0ZW50IHdpdGggcnBoLiBB bHRlcm5hdGl2ZWx5LCB3aGF0DQogc2hvdWxkIHRoZSB2ZXJpZmllciBkbyBpZiBpdCByZWNlaXZl cyBhbiBpbnZpdGUgd2l0aCBhIHZhbGlkIHBhc3Nwb3J0IGNsYWltaW5nIHNwaCBidXQgd2l0aCBu byBQcmlvcml0eSBoZWFkZXIgc2hvdWxkIGl0IGFkZCBpdCBpbj8gSSdtIG5vdCBzdXJlIHRoZSBz cGVjIG5lZWRzIHRvIGJlIHRvbyBwcmVzY3JpcHRpdmUgaGVyZSwgaG93ZXZlciBzb21lIG1lbnRp b24gb2YgdmVyaWZpZXIgYmVoYXZpb3VyIGFuZCB0aGUgYXNzb2NpYXRlZCBzZWN1cml0eQ0KIGNv bnNpZGVyYXRpb25zIHdvdWxkIGJlIHVzZWZ1bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxicj4NCjwvYj48YnI+DQo8Yj5TaG91bGQgdGhl IHNwZWMgYmUgc3Ryb25nZXIgYWJvdXQgdGhlIGNvbXBhY3QgZm9ybT88L2I+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDMgY3VycmVu dGx5IHN0YXRlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGUg dXNlIG9mIHRoZSBjb21wYWN0IGZvcm0gb2YgUEFTU3BvclQgaXMgbm90IHNwZWNpZmllZCBpbiB0 aGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGRvY3VtZW50LjxvOnA+PC9v OnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgYSBjb21wYWN0 LWZvcm0gcGFzc3BvcnQgZm9sbG93aW5nIHRoaXMgc3BlYyB3b3VsZCBiZSBoYXJkIHRvIHZlcmlm eSBhcyBpdCBpbnRyb2R1Y2VzIG11bHRpcGxlIHBvc3NpYmxlIHJwaCB2YXJpYW50cywgSSB0aGlu ayB0aGlzIHNwZWMgY291bGQgZ28gZnVydGhlciBhbmQgc2F5IHlvdSBzaG91bGRuJ3QvbXVzdG4n dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi Pjxicj4NCjxicj4NCldoYXQgaXMgdGhlIHJlcXVpcmVtZW50IG9mIHRoZXNlIG5ldyBwYXJhbWV0 ZXJzLjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFzIEkgdW5kZXJzdGFuZCBpdCwgdGhlIHBhc3Nwb3J0IHNwZWMgYWxsb3dzIHlvdSB0byBj cmVhdGUgYSBwYXNzcG9ydCBjb250YWluaW5nIHdoYXRldmVyIEpXVCBmaWVsZHMgeW91IHdhbnQg YW5kIHZlcmlmaWVycyBzaG91bGQganVzdCBpZ25vcmUgYW55IGZpZWxkcyB0aGV5IGRvbid0IHVu ZGVyc3RhbmQuIFVubGVzcyB0aGUgJnF1b3Q7cHB0JnF1b3Q7IGNsYWltIGlzIHNldCwgd2hpY2gg aW5kaWNhdGVzIHRoYXQgdmVyaWZpZXJzDQogc2hvdWxkIGRpc2NhcmQgaXQgaWYgdGhleSBkb24n dCByZWNvZ25pc2UgdGhhdCBwYXNzcG9ydCB0eXBlLiBBcyB0aGlzIHNwZWMgYWRkcyBhZGRpdGlv bmFsIGZpZWxkcyB0byBhbiBleGlzdGluZyBwYXNzcG9ydCB0eXBlIGl0IGlzbid0IGltbWVkaWF0 ZWx5IGNsZWFyIHdoYXQgdGhlIGJlaGF2aW91ciBzaG91bGQgYmUuIFNwZWNpZmljYWxseSwgaXMg YW4gcnBoIHBhc3Nwb3J0IGNvbnRhaW5pbmcgb25seSAmcXVvdDtycGguRVNvcmlnJnF1b3Q7IHZh bGlkIG5vdw0KICh3aGVyZSBpdCB3b3VsZG4ndCBiZSBiZWZvcmUgYmVjYXVzZSBhdXRoIGlzbid0 IHByZXNlbnQpLCBpcyBhbiBycGggcGFzc3BvcnQgY29udGFpbmluZyBubyBycGggYW5kIG9ubHkg c3BoIHZhbGlkLCBhbmQgd2hhdCBkb2VzIGEgbm9uLXJwaCBwYXNzcG9ydCB3aXRoIHNwaCBvciBF U29yaWcgc2V0IG1lYW4/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj4mbmJzcDs8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3RpciBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnN0aXJAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnN0aXJAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJo dHRwczovL25hbTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzdGlyJmFtcDtkYXRh PTAyJTdDMDElN0NKYWNrLlJpY2thcmQlNDBtZXRhc3dpdGNoLmNvbSU3QzFkYTZiNThjZmFkYjQ4 YTZjZWYzMDhkODQzYmRmNDRlJTdDOWQ5ZTU2ZWJmNjEzNGRkYmIyN2JiZmNkZjE0YjJjZGIlN0Mx JTdDMCU3QzYzNzMzMzgzMDQ1NDc1NTA3OCZhbXA7c2RhdGE9cEZSa2N5bzM3dzBlVkd6ODZXWW1o aWlqSFBlUllNQTU3MEtFeE9VOXVpcyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BYAPR02MB5189BE4C40E7A72BCFC8BD03F35D0BYAPR02MB5189namp_-- From nobody Wed Aug 19 06:40:40 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AA13A0A1D for ; Wed, 19 Aug 2020 06:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 258m83TdQELH for ; Wed, 19 Aug 2020 06:40:35 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 AEC8D3A09E8 for ; Wed, 19 Aug 2020 06:40:35 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id t15so24798114iob.3 for ; Wed, 19 Aug 2020 06:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Y6ETAtKIh0STo+zyUdtUxPEiTdXXquuFcz8U/Qm9Zo0=; b=WEcjSGNbtl4lgusfu/9ukj2ztIxHZ2KiRQ3gcVe6erhkqUM7yzH+3MspYIJqG1TE8R 5bnPD/vls7DlcmpMfZW1WD17/lwB6kS9Z4J3qqfHTEHWbJccKvBntEjNlzI8Y5uif967 MKxbJSYo2EN4R/nHP2XuyvS/etLKXLXdEeI6Hv+z/NElG6dERgwOGdBypZ5mMJRpIIW2 Jl0n/MTFih3SSVSgwZUI+sRz3CwiJSnatQNWOMZen1jauxlA4+BEm7O1B1UFqUYU7Vvh Z1AJNaQbsxlHph/3TsrQqjSxzh5iKRPkLPm4GuvHZ0wdF+TXfjYF0GiYFEZ4oHsq4OOw uqBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Y6ETAtKIh0STo+zyUdtUxPEiTdXXquuFcz8U/Qm9Zo0=; b=SlOcidOuj6R3xj+LdpQrlM/b5+zeyE1Z552Tbd4ocxF+xZiQrwSkYld9F1Ygyqip6r F11IXV7AtXvedGVyWPgJDEtsSDBKvtikD3eMjughaVIK1vvHCjL9UiTgJWNua3SYvTTv rR6OHT3MBX9dp5SRHgv6hoYcx/GE7qjW9Kf2ADNpKuOFwkkT1MuJhrc+rC8cLp8R5QzZ eW5BrX2qP11Ffvb2MHmrG+qqQrM+8J261M5pDBChU9dAxQxkLzuznvQohNMGBvvbIjRk 08Cv4Ne9wfKm1/o5CDWC3ZLOuaZEO+pZEV7knXnlOV56DI1Ra1N5zkShBw11D2vVaxdB 9WMA== X-Gm-Message-State: AOAM532cpUgi4FylztR70bLLjo8tXUn1cqxDsikzrH5tCqIgVV2VbX/S QSHvtgL6v26sQVyTSP3LQ/D1yQ== X-Google-Smtp-Source: ABdhPJwTLmIFPj9agIdiPRmzZZhh6uxsfcxLBq4HzMwb0OHZxSq6KQe9H98w5/rlKK8o/vzsR6qW2g== X-Received: by 2002:a02:6a6b:: with SMTP id m43mr24533849jaf.79.1597844433950; Wed, 19 Aug 2020 06:40:33 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id q17sm6612250ilt.10.2020.08.19.06.40.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Aug 2020 06:40:33 -0700 (PDT) From: Brian Rosen Message-Id: <959DCC43-1686-49D3-9195-719CF65C9EE9@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_837A9307-A8B9-4AA6-AE53-A3EC061FD54B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 19 Aug 2020 09:40:27 -0400 In-Reply-To: Cc: "draft-ietf-stir-rph-emergency-services@ietf.org" , "stir@ietf.org" To: Jack Rickard References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [stir] Review of draft-ietf-stir-rph-emergency-services X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 13:40:39 -0000 --Apple-Mail=_837A9307-A8B9-4AA6-AE53-A3EC061FD54B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 About 20% of the US has now upgraded to NG9-1-1, although most service = providers haven=E2=80=99t yet. The wireless carriers are moving towards = it; testing is underway. =20 I will have a companion document in sipcore that handles the signaling = aspects of this mechanism. For the older E911 system, none of stir = really helps because the existing system is built on the older Class 4 = switches (=E2=80=9CSelective Routers=E2=80=9D). All of this mechanism = is for NG9-1-1 and the equivalent services in the rest of the world, = based on IETF standards (RFC6881, RFC5222, and several others). =20 > On Aug 19, 2020, at 7:19 AM, Jack Rickard = wrote: >=20 > Thanks, that's really useful, however, I'm not convinced. > =20 > For ESorig, as far as I know this isn't currently always the case, I = am aware of situations where emergency calls just look like normal calls = with a number of 911. I'm also still unclear about what affect this has, = as you can currently already sign emergency calls using the standard = mechanisms (barring the whole "urn:service:sos" tn which I don't believe = is standardised for STIR yet?) by putting "esnet.0" in the auth field = of an rph passport. > =20 > For EScallback, if the sph and "rph.auth" claims cover theis entirely = why is EScallback needed? I'm also still unclear what the verification = service behaviour is here. > =20 > I'm still unclear as to how this spec helps with allowing and = preventing malicious use of emergency calls. You can already put esnet = resource priority pairs in the "rph.auth" claim and that seems to = provide as much security as this does. I do agree the sph claim does = provide value, however. > =20 > I did just realise that the esnet Resource Priority needs to be in the = "rph.auth" claim or the logic from that rfc will kick in and remove it, = as per: > RFC 8443, section 4.2 > In such scenarios, the SIP 'Resource-Priority' header field SHOULD = be > stripped from the SIP request, and the network entities should = treat > the call as an ordinary call. > =20 > I'll note that some of my questions and concerns haven't been = addressed yet, I'm happy to resolve this first, just making a note so = that they don't get lost/I don't forget about them. > Jack > =20 > From: Brian Rosen =20 > Sent: 18 August 2020 22:31 > To: Jack Rickard > Cc: draft-ietf-stir-rph-emergency-services@ietf.org; stir@ietf.org > Subject: Re: [stir] Review of draft-ietf-stir-rph-emergency-services > =20 > Let=E2=80=99s keep the two use cases separate:=20 > ESorig is an emergency call (user to authority). > EScallback is a call from authority to user. > =20 > For ESorg, the call is marked with a Request-URI of urn:service:sos. = The =E2=80=9CTo=E2=80=9D field is ignored in routing and handling the = call. That=E2=80=99s how you know this is an emergency call. For stir = purposes, the =46rom is an ordinary identifier, and gets treated in the = normal way. However, the rph value can only be used by a valid = emergency call, and a valid emergency call is a Request URI of = urn:service:sos, and a valid From. So you don=E2=80=99t have any = knowledge of emergency services identifiers, only the Request URI of = urn:service:sos. =20 > =20 > For EScallback, the marking is a distinguished value in SIP Priority. = If a call has that value, it=E2=80=99s a call back. The originating = service provider knows who are the authorities who are allowed to place = call backs, so the check is what is in SIP Priority, and one of the = allowed authorities in From. As a practical matter, in most cases, the = call will be signed by the emergency authorities themselves, who will be = able to get appropriate credentials for this purpose. In most cases = I=E2=80=99m aware of, the To in an emergency call won=E2=80=99t match = the =46rom in a Callback, but it=E2=80=99s possible for that to happen, = and we want to allow it. > =20 > Esnet is a Resource Priority Header namespace, not a SIP Priority = value. We=E2=80=99re allowing emergency calls and call backs to use = rph, and we=E2=80=99re protecting against malicious use of it. So = unless the call has urn:service:sos in Request URI, or the right SIP = Priority in a call back (and from an authorized authority) they can=E2=80=99= t use rph with the esnet namespace. Generally, unless under attack, = emergency calls go through even if there isn=E2=80=99t a passport. Many = networks won=E2=80=99t offer actual priority to emergency calls, but the = emergency services networks (ESInets) will. =20 > =20 > If a call arrives anywhere with an rph using esnet, and isn=E2=80=99t = an emergency call, with the appropriate passport, any intermediary can = refuse to give it any priority, The emergency authorities may accept a = call without a valid passport, but they might treat it with much more = suspicion than they would any other call. > =20 > For call backs, the network may have special behavior. For example, = it may send the call to the device that placed the emergency call, = rather than, for example, voice mail. The network has to be able to = trust that SIP Priority is set appropriately. It will also have rph = using esnet, and the network can grant it appropriate priority if it has = that capability, and would not allow esnet otherwise. > =20 > The only value in covering other uses of SIP Priority is to protect = against middle boxes modifying it. We don=E2=80=99t really have use = cases for that. It probably wouldn=E2=80=99t hurt to allow it though. > =20 > Does that help? > =20 > Brian > =20 >=20 >=20 > On Aug 14, 2020, at 1:21 PM, Jack Rickard = > wrote: > =20 > I have reviewed draft-ietf-stir-rph-emergency-services-02 and have = some concerns and questions. I don't believe this spec is implementable = in its current form. > =20 > Thanks, > Jack > =20 > Why are "ESorig" and "EScallback" distinct? > They seem to serve a very similar purpose with the only difference = being whether orig or dest should be the emergency services. I don't = believe there's any check that can be done to validate: > When using "ESorig" as the "rph" assertion value, the "orig" claim = of > the PASSporT MUST represent the calling party number that initiates > the call to emergency services. > This (and the equivalent statement for EScallback) don't seem possible = to me to check (barring the standard orig/dest checking).. > This would make the check "at least one of the parties should be the = emergency services" enough to validate that this was a reasonable call. > =20 > =20 > Why have them at all rather than just using auth? > This is very possibly an issue with my understanding, but I'm not = clear on why "ESorig" and "EScallback" even need to exist. "esnet.0" = etc. are SIP Resource Priority headers, so should be included in the = "auth" field anyway by the RPH spec. This spec appears to apply extra = constraints (that a one of the callers must be the emergency services) = for the "esnet" namespace but it's not clear why entirely separate = claims are needed. > =20 > In a similar vein, what should a verifier do if it receives a call = containing an invalid "ESorig" or "EScallback" value or the passport is = invalid/untrusted, I'm assuming the behaviour is the same as for auth = but this isn't clear. Although stripping the fact that this is an = emergency call is potentially dangerous.. > =20 > =20 > Specify the type of the "ESorig" and "EScallback" claims. > This specification currently doesn't specify the type of the new = fields, there are only examples and this isn't enough. It looks like = they both follow the same scheme as the rph "auth" claim, however = "esnet,x" doesn't quite fit into that due to the comma and that x isn't = a valid priority value. > =20 > =20 > Why is sph limited to psap-callback? What should the verifier do if it = isn't that? What should it do if it is? > I'm not entirely clear on the purpose of the sph claim, however, it = seems odd that it doesn't cover the full range of possible values for = the SIP Priority Header. Is there a reason that it doesn't cover the = "non-urgent", "normal", "urgent", or "emergency" values? > There is also no verifier behaviour defined here, should the verifier = remove the Priority header if it receives an invite with no passports = signing for it? That seems dangerous to me but would be consistent with = rph. Alternatively, what should the verifier do if it receives an invite = with a valid passport claiming sph but with no Priority header should it = add it in? I'm not sure the spec needs to be too prescriptive here, = however some mention of verifier behaviour and the associated security = considerations would be useful. >=20 >=20 > Should the spec be stronger about the compact form? > Section 3 currently states > The use of the compact form of PASSporT is not specified in this > document. > However, a compact-form passport following this spec would be hard to = verify as it introduces multiple possible rph variants, I think this = spec could go further and say you shouldn't/mustn't. >=20 >=20 > What is the requirement of these new parameters. > As I understand it, the passport spec allows you to create a passport = containing whatever JWT fields you want and verifiers should just ignore = any fields they don't understand. Unless the "ppt" claim is set, which = indicates that verifiers should discard it if they don't recognise that = passport type. As this spec adds additional fields to an existing = passport type it isn't immediately clear what the behaviour should be. = Specifically, is an rph passport containing only "rph.ESorig" valid now = (where it wouldn't be before because auth isn't present), is an rph = passport containing no rph and only sph valid, and what does a non-rph = passport with sph or ESorig set mean? > =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir = --Apple-Mail=_837A9307-A8B9-4AA6-AE53-A3EC061FD54B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 About= 20% of the US has now upgraded to NG9-1-1, although most service = providers haven=E2=80=99t yet.  The wireless carriers are moving = towards it; testing is underway.  
I will have a = companion document in sipcore that handles the signaling aspects of this = mechanism.  For the older E911 system, none of stir really helps = because the existing system is built on the older Class 4 switches = (=E2=80=9CSelective Routers=E2=80=9D).  All of this mechanism is = for NG9-1-1 and the equivalent services in the rest of the world, based = on IETF standards (RFC6881, RFC5222, and several others). =  

On Aug 19, 2020, at 7:19 AM, Jack Rickard = <Jack.Rickard@metaswitch.com> wrote:

Thanks, = that's really useful, however, I'm not convinced.
 
For ESorig, as far as I know this isn't currently always the = case, I am aware of situations where emergency calls just look like = normal calls with a number of 911. I'm also still unclear about what = affect this has, as you can currently already sign emergency calls using = the standard mechanisms (barring the whole "urn:service:sos" tn which I = don't believe is standardised for STIR yet?)  by putting "esnet.0" = in the auth field of an rph passport.
 
For EScallback, if the sph and "rph.auth" claims cover theis = entirely why is EScallback needed? I'm also still unclear what the = verification service behaviour is here.
 
I'm still unclear as to how this spec helps with allowing and = preventing malicious use of emergency calls. You can already put esnet = resource priority pairs in the "rph.auth" claim and that seems to = provide as much security as this does. I do agree the sph claim does = provide value, however.
 
I did just realise that the esnet Resource Priority needs to = be in the "rph.auth" claim or the logic from that rfc will kick in and = remove it, as per:
RFC 8443, section 4.2
   In such scenarios, the = SIP 'Resource-Priority' header field SHOULD be
   stripped from the SIP request, and the network = entities should treat
   the call as an = ordinary call.
 
I'll note that some of my questions and concerns haven't been = addressed yet, I'm happy to resolve this first, just making a note so = that they don't get lost/I don't forget about them.
Jack
 
From: Brian Rosen <br@brianrosen.net> 
Sent: 18 = August 2020 22:31
To: Jack Rickard <Jack.Rickard@metaswitch.com>
Cc: draft-ietf-stir-rph-emergency-services@ietf.org; stir@ietf.org
Subject: Re: [stir] Review of = draft-ietf-stir-rph-emergency-services
 
Let=E2=80=99s keep the two use cases = separate: 
ESorig is = an emergency call (user to authority).
EScallback = is a call from authority to user.
 
For = ESorg, the call is marked with a Request-URI of urn:service:sos. =  The =E2=80=9CTo=E2=80=9D field is ignored in routing and handling = the call.  That=E2=80=99s how you know this is an emergency call. =   For stir purposes, the =46rom is an ordinary identifier, and gets = treated in the normal way.  However, the rph value can only be used = by a valid emergency call, and a valid emergency call is a Request URI = of urn:service:sos, and a valid From.  So you don=E2=80=99t have = any knowledge of emergency services identifiers, only the Request URI of = urn:service:sos.   
 
For = EScallback, the marking is a distinguished value in SIP Priority. =  If a call has that value, it=E2=80=99s a call back.  The = originating service provider knows who are the authorities who are = allowed to place call backs, so the check is what is in SIP Priority, = and one of the allowed authorities in From.  As a practical matter, = in most cases, the call will be signed by the emergency authorities = themselves, who will be able to get appropriate credentials for this = purpose.  In most cases I=E2=80=99m aware of, the To in an = emergency call won=E2=80=99t match the =46rom in a Callback, but it=E2=80=99= s possible for that to happen, and we want to allow it.
 
Esnet = is a Resource Priority Header namespace, not a SIP Priority value. =  We=E2=80=99re allowing emergency calls and call backs to use rph, = and we=E2=80=99re protecting against malicious use of it.  So = unless the call has urn:service:sos in Request URI, or the right SIP = Priority in a call back (and from an authorized authority) they can=E2=80=99= t use rph with the esnet namespace.  Generally, unless under = attack, emergency calls go through even if there isn=E2=80=99t a = passport.  Many networks won=E2=80=99t offer actual priority to = emergency calls, but the emergency services networks (ESInets) will. =  
 
If a call arrives anywhere with an rph = using esnet, and isn=E2=80=99t an emergency call, with the appropriate = passport,  any intermediary can refuse to give it any priority, =  The emergency authorities may accept a call without a valid = passport, but they might treat it with much more suspicion than they = would any other call.
 
For = call backs, the network may have special behavior.  For example, it = may send the call to the device that placed the emergency call, rather = than, for example, voice mail.  The network has to be able to trust = that SIP Priority is set appropriately.  It will also have rph = using esnet, and the network can grant it appropriate priority if it has = that capability, and would not allow esnet otherwise.
 
The = only value in covering other uses of SIP Priority is to protect against = middle boxes modifying it.  We don=E2=80=99t really have use cases = for that.  It probably wouldn=E2=80=99t hurt to allow it = though.
 
Does that help?
 
Brian
 


On = Aug 14, 2020, at 1:21 PM, Jack Rickard <Jack.Rickard=3D40metaswitch.com@dmarc.ietf.org> = wrote:
 
I have reviewed = draft-ietf-stir-rph-emergency-services-02 and have some concerns and = questions. I don't believe this spec is implementable in its current = form.
 
Thanks,
Jack
 
Why are "ESorig" and "EScallback" distinct?
They seem = to serve a very similar purpose with the only difference being whether = orig or dest should be the emergency services. I don't believe there's = any check that can be done to validate:
   When using "ESorig" as the "rph" assertion = value, the "orig" claim of
   the = PASSporT MUST represent the calling party number that = initiates
   the call to emergency = services.
This (and the equivalent statement for = EScallback) don't seem possible to me to check (barring the standard = orig/dest checking)..
This would make the check "at least one = of the parties should be the emergency services" enough to validate that = this was a reasonable call.
 
 
Why have them at all rather than just using auth?
This is = very possibly an issue with my understanding, but I'm not clear on why = "ESorig" and "EScallback" even need to exist. "esnet.0" etc. are SIP = Resource Priority headers, so should be included in the "auth" field = anyway by the RPH spec. This spec appears to apply extra constraints = (that a one of the callers must be the emergency services) for the = "esnet" namespace but it's not clear why entirely separate claims are = needed.
 
In a similar vein, what should a = verifier do if it receives a call containing an invalid "ESorig" or = "EScallback" value or the passport is invalid/untrusted, I'm assuming = the behaviour is the same as for auth but this isn't clear. Although = stripping the fact that this is an emergency call is potentially = dangerous..
 
 
Specify the type of the "ESorig" and "EScallback" = claims.
This specification currently doesn't specify the = type of the new fields, there are only examples and this isn't enough. = It looks like they both follow the same scheme as the rph "auth" claim, = however "esnet,x" doesn't quite fit into that due to the comma and that = x isn't a valid priority value.
 
 
Why is sph limited to psap-callback? What should the verifier = do if it isn't that? What should it do if it is?
I'm not = entirely clear on the purpose of the sph claim, however, it seems odd = that it doesn't cover the full range of possible values for the SIP = Priority Header. Is there a reason that it doesn't cover the = "non-urgent", "normal", "urgent", or "emergency" values?
There is = also no verifier behaviour defined here, should the verifier remove the = Priority header if it receives an invite with no passports signing for = it? That seems dangerous to me but would be consistent with rph. = Alternatively, what should the verifier do if it receives an invite with = a valid passport claiming sph but with no Priority header should it add = it in? I'm not sure the spec needs to be too prescriptive here, however = some mention of verifier behaviour and the associated security = considerations would be useful.


Should the spec be stronger about the compact = form?
Section 3 currently states
   The use of the compact form of PASSporT is not =
specified in this
   document.
However, a compact-form passport = following this spec would be hard to verify as it introduces multiple = possible rph variants, I think this spec could go further and say you = shouldn't/mustn't.


What = is the requirement of these new parameters.
As I = understand it, the passport spec allows you to create a passport = containing whatever JWT fields you want and verifiers should just ignore = any fields they don't understand. Unless the "ppt" claim is set, which = indicates that verifiers should discard it if they don't recognise that = passport type. As this spec adds additional fields to an existing = passport type it isn't immediately clear what the behaviour should be. = Specifically, is an rph passport containing only "rph.ESorig" valid now = (where it wouldn't be before because auth isn't present), is an rph = passport containing no rph and only sph valid, and what does a non-rph = passport with sph or ESorig set mean?
 
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_837A9307-A8B9-4AA6-AE53-A3EC061FD54B-- From nobody Thu Aug 20 10:30:39 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812743A0D82; Thu, 20 Aug 2020 10:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=metaswitch.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 f02dIEviA3QK; Thu, 20 Aug 2020 10:30:35 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2114.outbound.protection.outlook.com [40.107.243.114]) (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 4C83F3A0D76; Thu, 20 Aug 2020 10:30:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EzX8lVml/y3p36c52fE97j06h6ZuKFsYeS9QHmC1IXLbF3tTTWVY+Ihg7TzKEyZZLGnUvmZLMRRy/vGY7YxYFtnx3/gHYsU12XOnXv95puvdOR/OOD2KPWSz8J0fP/uctlq5A+HT4KKVaGebKU+RThHA35roeBTPUnY7hlH6ieMHPNfCDqJgGGbE0cTZk9vmK5u+lx4iZhkhhHOXs57d7P2q5KnlwZjLaFGNAS7FFp6KZihWFS8pJx8+miV1U+FPrlreRuFNZy1fSVcE2WC7J8HtBiHK+c54O8IVOJGm1ZtXpR+E3c2rUsclkEaEOse1PqS69ByZYPjpEPjz8QxGYg== 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-SenderADCheck; bh=bwkgA1nX10ZJIPFyVNxOY75P3H3aNyoY+udflVPyy2o=; b=JcwGCCh10tZXHdLKX97fRO3XiUkgG2SNPMKcW5p5RlP52Q3jHNunveCzDes9BJT0vs9TPfmnmkIWHRWqgOeTRNKSV1Q6zhiQrFKhb/Bb6YKBqlETHbIMHfavoi4juNCAYGqi83Tl67HYIeKghFjoIQpNkgcAQlKqK887AX+tsJADLYuyv7ydSu2v1TgLV6Pv0MbP9mbSdzHEi0PEts8Al5qlR3BYL19PnTYlHaj2RuJVWQgFgipBRLuVsnylL/2Dn+ETKumFn/DLlMk+cdFXtgw/YtggXlQvQRPD3b3/dBI6bewf/Qhdo1qPNUiPTvK3zCBhTU1rk3Da++oOrG7qZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=metaswitch.com; dmarc=pass action=none header.from=metaswitch.com; dkim=pass header.d=metaswitch.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bwkgA1nX10ZJIPFyVNxOY75P3H3aNyoY+udflVPyy2o=; b=oFshL2IqPJeLtRJBnGWcwuZcSo6BNP7xzhsq/EUv1FJ0pNt/vayxudZtCpx4cBBdoUemqiVd+kAKAkreQFN4Lv2TThp3d1KMBlxchldZ8sLfZLevCwbo3G49bpBaWraKkmzy6ACm7xhVgG0ryMaWmYH4mBcgH0DeMIJIP6LO4QU= Received: from BYAPR02MB5189.namprd02.prod.outlook.com (2603:10b6:a03:62::29) by BYAPR02MB5431.namprd02.prod.outlook.com (2603:10b6:a03:a0::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Thu, 20 Aug 2020 17:30:21 +0000 Received: from BYAPR02MB5189.namprd02.prod.outlook.com ([fe80::d4d5:e9b6:c079:2718]) by BYAPR02MB5189.namprd02.prod.outlook.com ([fe80::d4d5:e9b6:c079:2718%7]) with mapi id 15.20.3283.028; Thu, 20 Aug 2020 17:30:21 +0000 From: Jack Rickard To: Brian Rosen CC: "draft-ietf-stir-rph-emergency-services@ietf.org" , "stir@ietf.org" Thread-Topic: [stir] Review of draft-ietf-stir-rph-emergency-services Thread-Index: AdZrPXk4d/f2kRt0QXimDVa1DUwOuwKaVPgAABiWh4AACUk0gAA5+/HQ Date: Thu, 20 Aug 2020 17:30:21 +0000 Message-ID: References: <959DCC43-1686-49D3-9195-719CF65C9EE9@brianrosen.net> In-Reply-To: <959DCC43-1686-49D3-9195-719CF65C9EE9@brianrosen.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [84.92.33.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4378cc88-d34a-457a-ba08-08d8452eb6f7 x-ms-traffictypediagnostic: BYAPR02MB5431: x-ld-processed: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: T6qsHyg4cJVgQ/UIbxM//9qm08mFGf22/dRL4yhR/fjIIDuaYhIvWGS6ybvOCNZ0zD7Y3MRSeA2z0nu/YxXlXTrmE4hO8c7p0KhVijIBxAWOXpBHubz6zxa0ONY8BwUhF1/S6l1IYiYOH+1s+D5wxzVNZO4uv8jCmEldpSNgYzBgb4yG6wmPufGK+IFNUl/CLS3taMW2lmwU2rKCEjsplF28RiLspKtNfTkMaIb+xHBRfpT7pBrDWGblAkPrucXau55pXz30iYxLH1g623X+qiJxi1IAApLhqw7UDhGgGXUisJDGp1rDJui5ytzD/ypFKPJOd3kiMk/4QiySvYnc5KUVX/NOwDhK145kEP4U4bzHZo7jH0tNCVSQ7J20IIhQMnBuOx11wBmLLST9fK+U3Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR02MB5189.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39850400004)(346002)(136003)(396003)(366004)(8676002)(52536014)(83380400001)(26005)(6916009)(53546011)(77540400001)(71200400001)(166002)(8936002)(6506007)(86362001)(76116006)(66946007)(66446008)(64756008)(66556008)(66476007)(186003)(2906002)(478600001)(33656002)(966005)(55016002)(30864003)(7696005)(9686003)(316002)(5660300002)(4326008)(54906003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: PCDRNJbQTkZgWUnXOzLoW8DQXmZEV+9ExJyY5/1MRLDz/ZJGmeKwrJSqmuzEHX3OwzhARSTZXx4hE/mf3+V2cqDE5hyJwh4p63vI/PIIfzqbi8TCX1kHf6qzNErR1z5I8bGT7MMH+EYe9OYL7OrIB+jMI4ZojYtF2JYcTj4vWxYib1PjkUs4Mymm6WNetJcoxwpxzNChl32iyYOYWPyr+Hu2hAAzZmXMoQo5/Ernpx599xFLk+Qsj1AGmPtpft1g0LM5ofPeVyKGv/oERLZypC1lngJnHzVQP7f1wp883xYYOhYaFqiK/m7MFSlxA3GPobWpsfnd/U1ZqK0PHO1u04gWjWzYm2q0lgNFzKOr9QKPEXP+PHYYd+SYD7r69vDc7obRCCezIjD/eGO8Ti83xl8pmdKcgRx+ui6ei8WXQ0fcKGzSMsmokwErKs+FrxoKlS264TyG6RH/mt2qJqvhNrCu8Gb7wDXHkiJDZrRyPhSMmUTk532RVnZna+544UgC35U4R1+ttsRZ685kmpZBy9DolFgT38BW9R/07KOvIgO+THaFpi98ng5logW4OgwapSSwx52Kc85P6OsaRl7mVIvR4dX53u7zxL5vgA2l94W0qlm9MlE/fx/O81a6sBWF2DsRj9UC5MsvvfoqAemUSQ== Content-Type: multipart/alternative; boundary="_000_BYAPR02MB5189D7055FCD08B0F926B9ADF35A0BYAPR02MB5189namp_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR02MB5189.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4378cc88-d34a-457a-ba08-08d8452eb6f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2020 17:30:21.1836 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ObQBJyFE+N5G1KuZ6UjMDGNfFP/h1n45FhXqz4s5uVw+V0W4aOXOv4A/lHFD8lhlNOH+rbmIhGEJE2P+2HFgQw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB5431 Archived-At: Subject: Re: [stir] Review of draft-ietf-stir-rph-emergency-services X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 17:30:39 -0000 --_000_BYAPR02MB5189D7055FCD08B0F926B9ADF35A0BYAPR02MB5189namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQncyBub3QgY2xlYXIgdGhhdCB0aGlzIHNwZWMgcmVsaWVzIG9uIHRoYXQsIGFuZCBJJ20gbm90 IHN1cmUgdGhhdCBpdCBzaG91bGQ/IFRvIG1lIGl0IHNlZW1zIGxpa2UgdGhpcyBjb3VsZCBiZSBt b3JlIHdpZGVseSBhcHBsaWNhYmxlLg0KDQpXb3VsZCB5b3UgYmUgYWJsZSB0byBhZGRyZXNzLCBm cm9tIGEgdmVyaWZpY2F0aW9uIHNlcnZpY2UncyBwb2ludCBvZiB2aWV3LCB3aGF0IGl0IHNob3Vs ZCBkbz8gSSB0aGluayB0aGF0IHdpbGwgY2xlYXIgdXAgd2h5ICJFc29yaWciIGFuZCAiRVNjYWxs YmFjayIgYXJlIHVzZWZ1bCBhYm92ZSBwbGFpbiAiYXV0aCIuDQpJIHRoaW5rIHRoZSBzcGVjIHdv dWxkIGJlbmVmaXQgZnJvbSB0aGF0IHNlY3Rpb24gYXMgd2VsbCBTZWN0aW9uIDQgb2YgUkZDIDg0 NDMgYW5kIHNlY3Rpb24gMTEgb2YgZHJhZnQtaWV0Zi1zdGlyLXBhc3Nwb3J0LXJjZC0wNiBhcmUg Ym90aCBpbmNyZWRpYmx5IHVzZWZ1bC4NCg0KVGhhbmtzLA0KSmFjaw0KDQpGcm9tOiBCcmlhbiBS b3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+DQpTZW50OiAxOSBBdWd1c3QgMjAyMCAxNDo0MA0KVG86 IEphY2sgUmlja2FyZCA8SmFjay5SaWNrYXJkQG1ldGFzd2l0Y2guY29tPg0KQ2M6IGRyYWZ0LWll dGYtc3Rpci1ycGgtZW1lcmdlbmN5LXNlcnZpY2VzQGlldGYub3JnOyBzdGlyQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3N0aXJdIFJldmlldyBvZiBkcmFmdC1pZXRmLXN0aXItcnBoLWVtZXJnZW5j eS1zZXJ2aWNlcw0KDQpOT1RFOiBNZXNzYWdlIGlzIGZyb20gYW4gZXh0ZXJuYWwgc2VuZGVyDQpB Ym91dCAyMCUgb2YgdGhlIFVTIGhhcyBub3cgdXBncmFkZWQgdG8gTkc5LTEtMSwgYWx0aG91Z2gg bW9zdCBzZXJ2aWNlIHByb3ZpZGVycyBoYXZlbuKAmXQgeWV0LiAgVGhlIHdpcmVsZXNzIGNhcnJp ZXJzIGFyZSBtb3ZpbmcgdG93YXJkcyBpdDsgdGVzdGluZyBpcyB1bmRlcndheS4NCkkgd2lsbCBo YXZlIGEgY29tcGFuaW9uIGRvY3VtZW50IGluIHNpcGNvcmUgdGhhdCBoYW5kbGVzIHRoZSBzaWdu YWxpbmcgYXNwZWN0cyBvZiB0aGlzIG1lY2hhbmlzbS4gIEZvciB0aGUgb2xkZXIgRTkxMSBzeXN0 ZW0sIG5vbmUgb2Ygc3RpciByZWFsbHkgaGVscHMgYmVjYXVzZSB0aGUgZXhpc3Rpbmcgc3lzdGVt IGlzIGJ1aWx0IG9uIHRoZSBvbGRlciBDbGFzcyA0IHN3aXRjaGVzICjigJxTZWxlY3RpdmUgUm91 dGVyc+KAnSkuICBBbGwgb2YgdGhpcyBtZWNoYW5pc20gaXMgZm9yIE5HOS0xLTEgYW5kIHRoZSBl cXVpdmFsZW50IHNlcnZpY2VzIGluIHRoZSByZXN0IG9mIHRoZSB3b3JsZCwgYmFzZWQgb24gSUVU RiBzdGFuZGFyZHMgKFJGQzY4ODEsIFJGQzUyMjIsIGFuZCBzZXZlcmFsIG90aGVycykuDQoNCg0K T24gQXVnIDE5LCAyMDIwLCBhdCA3OjE5IEFNLCBKYWNrIFJpY2thcmQgPEphY2suUmlja2FyZEBt ZXRhc3dpdGNoLmNvbTxtYWlsdG86SmFjay5SaWNrYXJkQG1ldGFzd2l0Y2guY29tPj4gd3JvdGU6 DQoNClRoYW5rcywgdGhhdCdzIHJlYWxseSB1c2VmdWwsIGhvd2V2ZXIsIEknbSBub3QgY29udmlu Y2VkLg0KDQpGb3IgRVNvcmlnLCBhcyBmYXIgYXMgSSBrbm93IHRoaXMgaXNuJ3QgY3VycmVudGx5 IGFsd2F5cyB0aGUgY2FzZSwgSSBhbSBhd2FyZSBvZiBzaXR1YXRpb25zIHdoZXJlIGVtZXJnZW5j eSBjYWxscyBqdXN0IGxvb2sgbGlrZSBub3JtYWwgY2FsbHMgd2l0aCBhIG51bWJlciBvZiA5MTEu IEknbSBhbHNvIHN0aWxsIHVuY2xlYXIgYWJvdXQgd2hhdCBhZmZlY3QgdGhpcyBoYXMsIGFzIHlv dSBjYW4gY3VycmVudGx5IGFscmVhZHkgc2lnbiBlbWVyZ2VuY3kgY2FsbHMgdXNpbmcgdGhlIHN0 YW5kYXJkIG1lY2hhbmlzbXMgKGJhcnJpbmcgdGhlIHdob2xlICJ1cm46c2VydmljZTpzb3MiIHRu IHdoaWNoIEkgZG9uJ3QgYmVsaWV2ZSBpcyBzdGFuZGFyZGlzZWQgZm9yIFNUSVIgeWV0PykgIGJ5 IHB1dHRpbmcgImVzbmV0LjAiIGluIHRoZSBhdXRoIGZpZWxkIG9mIGFuIHJwaCBwYXNzcG9ydC4N Cg0KRm9yIEVTY2FsbGJhY2ssIGlmIHRoZSBzcGggYW5kICJycGguYXV0aCIgY2xhaW1zIGNvdmVy IHRoZWlzIGVudGlyZWx5IHdoeSBpcyBFU2NhbGxiYWNrIG5lZWRlZD8gSSdtIGFsc28gc3RpbGwg dW5jbGVhciB3aGF0IHRoZSB2ZXJpZmljYXRpb24gc2VydmljZSBiZWhhdmlvdXIgaXMgaGVyZS4N Cg0KSSdtIHN0aWxsIHVuY2xlYXIgYXMgdG8gaG93IHRoaXMgc3BlYyBoZWxwcyB3aXRoIGFsbG93 aW5nIGFuZCBwcmV2ZW50aW5nIG1hbGljaW91cyB1c2Ugb2YgZW1lcmdlbmN5IGNhbGxzLiBZb3Ug Y2FuIGFscmVhZHkgcHV0IGVzbmV0IHJlc291cmNlIHByaW9yaXR5IHBhaXJzIGluIHRoZSAicnBo LmF1dGgiIGNsYWltIGFuZCB0aGF0IHNlZW1zIHRvIHByb3ZpZGUgYXMgbXVjaCBzZWN1cml0eSBh cyB0aGlzIGRvZXMuIEkgZG8gYWdyZWUgdGhlIHNwaCBjbGFpbSBkb2VzIHByb3ZpZGUgdmFsdWUs IGhvd2V2ZXIuDQoNCkkgZGlkIGp1c3QgcmVhbGlzZSB0aGF0IHRoZSBlc25ldCBSZXNvdXJjZSBQ cmlvcml0eSBuZWVkcyB0byBiZSBpbiB0aGUgInJwaC5hdXRoIiBjbGFpbSBvciB0aGUgbG9naWMg ZnJvbSB0aGF0IHJmYyB3aWxsIGtpY2sgaW4gYW5kIHJlbW92ZSBpdCwgYXMgcGVyOg0KUkZDIDg0 NDMsIHNlY3Rpb24gNC4yDQogICBJbiBzdWNoIHNjZW5hcmlvcywgdGhlIFNJUCAnUmVzb3VyY2Ut UHJpb3JpdHknIGhlYWRlciBmaWVsZCBTSE9VTEQgYmUNCiAgIHN0cmlwcGVkIGZyb20gdGhlIFNJ UCByZXF1ZXN0LCBhbmQgdGhlIG5ldHdvcmsgZW50aXRpZXMgc2hvdWxkIHRyZWF0DQogICB0aGUg Y2FsbCBhcyBhbiBvcmRpbmFyeSBjYWxsLg0KDQpJJ2xsIG5vdGUgdGhhdCBzb21lIG9mIG15IHF1 ZXN0aW9ucyBhbmQgY29uY2VybnMgaGF2ZW4ndCBiZWVuIGFkZHJlc3NlZCB5ZXQsIEknbSBoYXBw eSB0byByZXNvbHZlIHRoaXMgZmlyc3QsIGp1c3QgbWFraW5nIGEgbm90ZSBzbyB0aGF0IHRoZXkg ZG9uJ3QgZ2V0IGxvc3QvSSBkb24ndCBmb3JnZXQgYWJvdXQgdGhlbS4NCkphY2sNCg0KRnJvbTog QnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PG1haWx0bzpickBicmlhbnJvc2VuLm5ldD4+ DQpTZW50OiAxOCBBdWd1c3QgMjAyMCAyMjozMQ0KVG86IEphY2sgUmlja2FyZCA8SmFjay5SaWNr YXJkQG1ldGFzd2l0Y2guY29tPG1haWx0bzpKYWNrLlJpY2thcmRAbWV0YXN3aXRjaC5jb20+Pg0K Q2M6IGRyYWZ0LWlldGYtc3Rpci1ycGgtZW1lcmdlbmN5LXNlcnZpY2VzQGlldGYub3JnPG1haWx0 bzpkcmFmdC1pZXRmLXN0aXItcnBoLWVtZXJnZW5jeS1zZXJ2aWNlc0BpZXRmLm9yZz47IHN0aXJA aWV0Zi5vcmc8bWFpbHRvOnN0aXJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3N0aXJdIFJldmll dyBvZiBkcmFmdC1pZXRmLXN0aXItcnBoLWVtZXJnZW5jeS1zZXJ2aWNlcw0KDQpMZXTigJlzIGtl ZXAgdGhlIHR3byB1c2UgY2FzZXMgc2VwYXJhdGU6DQpFU29yaWcgaXMgYW4gZW1lcmdlbmN5IGNh bGwgKHVzZXIgdG8gYXV0aG9yaXR5KS4NCkVTY2FsbGJhY2sgaXMgYSBjYWxsIGZyb20gYXV0aG9y aXR5IHRvIHVzZXIuDQoNCkZvciBFU29yZywgdGhlIGNhbGwgaXMgbWFya2VkIHdpdGggYSBSZXF1 ZXN0LVVSSSBvZiB1cm46c2VydmljZTpzb3MuICBUaGUg4oCcVG/igJ0gZmllbGQgaXMgaWdub3Jl ZCBpbiByb3V0aW5nIGFuZCBoYW5kbGluZyB0aGUgY2FsbC4gIFRoYXTigJlzIGhvdyB5b3Uga25v dyB0aGlzIGlzIGFuIGVtZXJnZW5jeSBjYWxsLiAgIEZvciBzdGlyIHB1cnBvc2VzLCB0aGUgRnJv bSBpcyBhbiBvcmRpbmFyeSBpZGVudGlmaWVyLCBhbmQgZ2V0cyB0cmVhdGVkIGluIHRoZSBub3Jt YWwgd2F5LiAgSG93ZXZlciwgdGhlIHJwaCB2YWx1ZSBjYW4gb25seSBiZSB1c2VkIGJ5IGEgdmFs aWQgZW1lcmdlbmN5IGNhbGwsIGFuZCBhIHZhbGlkIGVtZXJnZW5jeSBjYWxsIGlzIGEgUmVxdWVz dCBVUkkgb2YgdXJuOnNlcnZpY2U6c29zLCBhbmQgYSB2YWxpZCBGcm9tLiAgU28geW91IGRvbuKA mXQgaGF2ZSBhbnkga25vd2xlZGdlIG9mIGVtZXJnZW5jeSBzZXJ2aWNlcyBpZGVudGlmaWVycywg b25seSB0aGUgUmVxdWVzdCBVUkkgb2YgdXJuOnNlcnZpY2U6c29zLg0KDQpGb3IgRVNjYWxsYmFj aywgdGhlIG1hcmtpbmcgaXMgYSBkaXN0aW5ndWlzaGVkIHZhbHVlIGluIFNJUCBQcmlvcml0eS4g IElmIGEgY2FsbCBoYXMgdGhhdCB2YWx1ZSwgaXTigJlzIGEgY2FsbCBiYWNrLiAgVGhlIG9yaWdp bmF0aW5nIHNlcnZpY2UgcHJvdmlkZXIga25vd3Mgd2hvIGFyZSB0aGUgYXV0aG9yaXRpZXMgd2hv IGFyZSBhbGxvd2VkIHRvIHBsYWNlIGNhbGwgYmFja3MsIHNvIHRoZSBjaGVjayBpcyB3aGF0IGlz IGluIFNJUCBQcmlvcml0eSwgYW5kIG9uZSBvZiB0aGUgYWxsb3dlZCBhdXRob3JpdGllcyBpbiBG cm9tLiAgQXMgYSBwcmFjdGljYWwgbWF0dGVyLCBpbiBtb3N0IGNhc2VzLCB0aGUgY2FsbCB3aWxs IGJlIHNpZ25lZCBieSB0aGUgZW1lcmdlbmN5IGF1dGhvcml0aWVzIHRoZW1zZWx2ZXMsIHdobyB3 aWxsIGJlIGFibGUgdG8gZ2V0IGFwcHJvcHJpYXRlIGNyZWRlbnRpYWxzIGZvciB0aGlzIHB1cnBv c2UuICBJbiBtb3N0IGNhc2VzIEnigJltIGF3YXJlIG9mLCB0aGUgVG8gaW4gYW4gZW1lcmdlbmN5 IGNhbGwgd29u4oCZdCBtYXRjaCB0aGUgRnJvbSBpbiBhIENhbGxiYWNrLCBidXQgaXTigJlzIHBv c3NpYmxlIGZvciB0aGF0IHRvIGhhcHBlbiwgYW5kIHdlIHdhbnQgdG8gYWxsb3cgaXQuDQoNCkVz bmV0IGlzIGEgUmVzb3VyY2UgUHJpb3JpdHkgSGVhZGVyIG5hbWVzcGFjZSwgbm90IGEgU0lQIFBy aW9yaXR5IHZhbHVlLiAgV2XigJlyZSBhbGxvd2luZyBlbWVyZ2VuY3kgY2FsbHMgYW5kIGNhbGwg YmFja3MgdG8gdXNlIHJwaCwgYW5kIHdl4oCZcmUgcHJvdGVjdGluZyBhZ2FpbnN0IG1hbGljaW91 cyB1c2Ugb2YgaXQuICBTbyB1bmxlc3MgdGhlIGNhbGwgaGFzIHVybjpzZXJ2aWNlOnNvcyBpbiBS ZXF1ZXN0IFVSSSwgb3IgdGhlIHJpZ2h0IFNJUCBQcmlvcml0eSBpbiBhIGNhbGwgYmFjayAoYW5k IGZyb20gYW4gYXV0aG9yaXplZCBhdXRob3JpdHkpIHRoZXkgY2Fu4oCZdCB1c2UgcnBoIHdpdGgg dGhlIGVzbmV0IG5hbWVzcGFjZS4gIEdlbmVyYWxseSwgdW5sZXNzIHVuZGVyIGF0dGFjaywgZW1l cmdlbmN5IGNhbGxzIGdvIHRocm91Z2ggZXZlbiBpZiB0aGVyZSBpc27igJl0IGEgcGFzc3BvcnQu ICBNYW55IG5ldHdvcmtzIHdvbuKAmXQgb2ZmZXIgYWN0dWFsIHByaW9yaXR5IHRvIGVtZXJnZW5j eSBjYWxscywgYnV0IHRoZSBlbWVyZ2VuY3kgc2VydmljZXMgbmV0d29ya3MgKEVTSW5ldHMpIHdp bGwuDQoNCklmIGEgY2FsbCBhcnJpdmVzIGFueXdoZXJlIHdpdGggYW4gcnBoIHVzaW5nIGVzbmV0 LCBhbmQgaXNu4oCZdCBhbiBlbWVyZ2VuY3kgY2FsbCwgd2l0aCB0aGUgYXBwcm9wcmlhdGUgcGFz c3BvcnQsICBhbnkgaW50ZXJtZWRpYXJ5IGNhbiByZWZ1c2UgdG8gZ2l2ZSBpdCBhbnkgcHJpb3Jp dHksICBUaGUgZW1lcmdlbmN5IGF1dGhvcml0aWVzIG1heSBhY2NlcHQgYSBjYWxsIHdpdGhvdXQg YSB2YWxpZCBwYXNzcG9ydCwgYnV0IHRoZXkgbWlnaHQgdHJlYXQgaXQgd2l0aCBtdWNoIG1vcmUg c3VzcGljaW9uIHRoYW4gdGhleSB3b3VsZCBhbnkgb3RoZXIgY2FsbC4NCg0KRm9yIGNhbGwgYmFj a3MsIHRoZSBuZXR3b3JrIG1heSBoYXZlIHNwZWNpYWwgYmVoYXZpb3IuICBGb3IgZXhhbXBsZSwg aXQgbWF5IHNlbmQgdGhlIGNhbGwgdG8gdGhlIGRldmljZSB0aGF0IHBsYWNlZCB0aGUgZW1lcmdl bmN5IGNhbGwsIHJhdGhlciB0aGFuLCBmb3IgZXhhbXBsZSwgdm9pY2UgbWFpbC4gIFRoZSBuZXR3 b3JrIGhhcyB0byBiZSBhYmxlIHRvIHRydXN0IHRoYXQgU0lQIFByaW9yaXR5IGlzIHNldCBhcHBy b3ByaWF0ZWx5LiAgSXQgd2lsbCBhbHNvIGhhdmUgcnBoIHVzaW5nIGVzbmV0LCBhbmQgdGhlIG5l dHdvcmsgY2FuIGdyYW50IGl0IGFwcHJvcHJpYXRlIHByaW9yaXR5IGlmIGl0IGhhcyB0aGF0IGNh cGFiaWxpdHksIGFuZCB3b3VsZCBub3QgYWxsb3cgZXNuZXQgb3RoZXJ3aXNlLg0KDQpUaGUgb25s eSB2YWx1ZSBpbiBjb3ZlcmluZyBvdGhlciB1c2VzIG9mIFNJUCBQcmlvcml0eSBpcyB0byBwcm90 ZWN0IGFnYWluc3QgbWlkZGxlIGJveGVzIG1vZGlmeWluZyBpdC4gIFdlIGRvbuKAmXQgcmVhbGx5 IGhhdmUgdXNlIGNhc2VzIGZvciB0aGF0LiAgSXQgcHJvYmFibHkgd291bGRu4oCZdCBodXJ0IHRv IGFsbG93IGl0IHRob3VnaC4NCg0KRG9lcyB0aGF0IGhlbHA/DQoNCkJyaWFuDQoNCg0KDQoNCk9u IEF1ZyAxNCwgMjAyMCwgYXQgMToyMSBQTSwgSmFjayBSaWNrYXJkIDxKYWNrLlJpY2thcmQ9NDBt ZXRhc3dpdGNoLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86SmFjay5SaWNrYXJkPTQwbWV0YXN3 aXRjaC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KSSBoYXZlIHJldmlld2VkIGRyYWZ0 LWlldGYtc3Rpci1ycGgtZW1lcmdlbmN5LXNlcnZpY2VzLTAyIGFuZCBoYXZlIHNvbWUgY29uY2Vy bnMgYW5kIHF1ZXN0aW9ucy4gSSBkb24ndCBiZWxpZXZlIHRoaXMgc3BlYyBpcyBpbXBsZW1lbnRh YmxlIGluIGl0cyBjdXJyZW50IGZvcm0uDQoNClRoYW5rcywNCkphY2sNCg0KV2h5IGFyZSAiRVNv cmlnIiBhbmQgIkVTY2FsbGJhY2siIGRpc3RpbmN0Pw0KVGhleSBzZWVtIHRvIHNlcnZlIGEgdmVy eSBzaW1pbGFyIHB1cnBvc2Ugd2l0aCB0aGUgb25seSBkaWZmZXJlbmNlIGJlaW5nIHdoZXRoZXIg b3JpZyBvciBkZXN0IHNob3VsZCBiZSB0aGUgZW1lcmdlbmN5IHNlcnZpY2VzLiBJIGRvbid0IGJl bGlldmUgdGhlcmUncyBhbnkgY2hlY2sgdGhhdCBjYW4gYmUgZG9uZSB0byB2YWxpZGF0ZToNCiAg IFdoZW4gdXNpbmcgIkVTb3JpZyIgYXMgdGhlICJycGgiIGFzc2VydGlvbiB2YWx1ZSwgdGhlICJv cmlnIiBjbGFpbSBvZg0KICAgdGhlIFBBU1Nwb3JUIE1VU1QgcmVwcmVzZW50IHRoZSBjYWxsaW5n IHBhcnR5IG51bWJlciB0aGF0IGluaXRpYXRlcw0KICAgdGhlIGNhbGwgdG8gZW1lcmdlbmN5IHNl cnZpY2VzLg0KVGhpcyAoYW5kIHRoZSBlcXVpdmFsZW50IHN0YXRlbWVudCBmb3IgRVNjYWxsYmFj aykgZG9uJ3Qgc2VlbSBwb3NzaWJsZSB0byBtZSB0byBjaGVjayAoYmFycmluZyB0aGUgc3RhbmRh cmQgb3JpZy9kZXN0IGNoZWNraW5nKS4uDQpUaGlzIHdvdWxkIG1ha2UgdGhlIGNoZWNrICJhdCBs ZWFzdCBvbmUgb2YgdGhlIHBhcnRpZXMgc2hvdWxkIGJlIHRoZSBlbWVyZ2VuY3kgc2VydmljZXMi IGVub3VnaCB0byB2YWxpZGF0ZSB0aGF0IHRoaXMgd2FzIGEgcmVhc29uYWJsZSBjYWxsLg0KDQoN CldoeSBoYXZlIHRoZW0gYXQgYWxsIHJhdGhlciB0aGFuIGp1c3QgdXNpbmcgYXV0aD8NClRoaXMg aXMgdmVyeSBwb3NzaWJseSBhbiBpc3N1ZSB3aXRoIG15IHVuZGVyc3RhbmRpbmcsIGJ1dCBJJ20g bm90IGNsZWFyIG9uIHdoeSAiRVNvcmlnIiBhbmQgIkVTY2FsbGJhY2siIGV2ZW4gbmVlZCB0byBl eGlzdC4gImVzbmV0LjAiIGV0Yy4gYXJlIFNJUCBSZXNvdXJjZSBQcmlvcml0eSBoZWFkZXJzLCBz byBzaG91bGQgYmUgaW5jbHVkZWQgaW4gdGhlICJhdXRoIiBmaWVsZCBhbnl3YXkgYnkgdGhlIFJQ SCBzcGVjLiBUaGlzIHNwZWMgYXBwZWFycyB0byBhcHBseSBleHRyYSBjb25zdHJhaW50cyAodGhh dCBhIG9uZSBvZiB0aGUgY2FsbGVycyBtdXN0IGJlIHRoZSBlbWVyZ2VuY3kgc2VydmljZXMpIGZv ciB0aGUgImVzbmV0IiBuYW1lc3BhY2UgYnV0IGl0J3Mgbm90IGNsZWFyIHdoeSBlbnRpcmVseSBz ZXBhcmF0ZSBjbGFpbXMgYXJlIG5lZWRlZC4NCg0KSW4gYSBzaW1pbGFyIHZlaW4sIHdoYXQgc2hv dWxkIGEgdmVyaWZpZXIgZG8gaWYgaXQgcmVjZWl2ZXMgYSBjYWxsIGNvbnRhaW5pbmcgYW4gaW52 YWxpZCAiRVNvcmlnIiBvciAiRVNjYWxsYmFjayIgdmFsdWUgb3IgdGhlIHBhc3Nwb3J0IGlzIGlu dmFsaWQvdW50cnVzdGVkLCBJJ20gYXNzdW1pbmcgdGhlIGJlaGF2aW91ciBpcyB0aGUgc2FtZSBh cyBmb3IgYXV0aCBidXQgdGhpcyBpc24ndCBjbGVhci4gQWx0aG91Z2ggc3RyaXBwaW5nIHRoZSBm YWN0IHRoYXQgdGhpcyBpcyBhbiBlbWVyZ2VuY3kgY2FsbCBpcyBwb3RlbnRpYWxseSBkYW5nZXJv dXMuLg0KDQoNClNwZWNpZnkgdGhlIHR5cGUgb2YgdGhlICJFU29yaWciIGFuZCAiRVNjYWxsYmFj ayIgY2xhaW1zLg0KVGhpcyBzcGVjaWZpY2F0aW9uIGN1cnJlbnRseSBkb2Vzbid0IHNwZWNpZnkg dGhlIHR5cGUgb2YgdGhlIG5ldyBmaWVsZHMsIHRoZXJlIGFyZSBvbmx5IGV4YW1wbGVzIGFuZCB0 aGlzIGlzbid0IGVub3VnaC4gSXQgbG9va3MgbGlrZSB0aGV5IGJvdGggZm9sbG93IHRoZSBzYW1l IHNjaGVtZSBhcyB0aGUgcnBoICJhdXRoIiBjbGFpbSwgaG93ZXZlciAiZXNuZXQseCIgZG9lc24n dCBxdWl0ZSBmaXQgaW50byB0aGF0IGR1ZSB0byB0aGUgY29tbWEgYW5kIHRoYXQgeCBpc24ndCBh IHZhbGlkIHByaW9yaXR5IHZhbHVlLg0KDQoNCldoeSBpcyBzcGggbGltaXRlZCB0byBwc2FwLWNh bGxiYWNrPyBXaGF0IHNob3VsZCB0aGUgdmVyaWZpZXIgZG8gaWYgaXQgaXNuJ3QgdGhhdD8gV2hh dCBzaG91bGQgaXQgZG8gaWYgaXQgaXM/DQpJJ20gbm90IGVudGlyZWx5IGNsZWFyIG9uIHRoZSBw dXJwb3NlIG9mIHRoZSBzcGggY2xhaW0sIGhvd2V2ZXIsIGl0IHNlZW1zIG9kZCB0aGF0IGl0IGRv ZXNuJ3QgY292ZXIgdGhlIGZ1bGwgcmFuZ2Ugb2YgcG9zc2libGUgdmFsdWVzIGZvciB0aGUgU0lQ IFByaW9yaXR5IEhlYWRlci4gSXMgdGhlcmUgYSByZWFzb24gdGhhdCBpdCBkb2Vzbid0IGNvdmVy IHRoZSAibm9uLXVyZ2VudCIsICJub3JtYWwiLCAidXJnZW50Iiwgb3IgImVtZXJnZW5jeSIgdmFs dWVzPw0KVGhlcmUgaXMgYWxzbyBubyB2ZXJpZmllciBiZWhhdmlvdXIgZGVmaW5lZCBoZXJlLCBz aG91bGQgdGhlIHZlcmlmaWVyIHJlbW92ZSB0aGUgUHJpb3JpdHkgaGVhZGVyIGlmIGl0IHJlY2Vp dmVzIGFuIGludml0ZSB3aXRoIG5vIHBhc3Nwb3J0cyBzaWduaW5nIGZvciBpdD8gVGhhdCBzZWVt cyBkYW5nZXJvdXMgdG8gbWUgYnV0IHdvdWxkIGJlIGNvbnNpc3RlbnQgd2l0aCBycGguIEFsdGVy bmF0aXZlbHksIHdoYXQgc2hvdWxkIHRoZSB2ZXJpZmllciBkbyBpZiBpdCByZWNlaXZlcyBhbiBp bnZpdGUgd2l0aCBhIHZhbGlkIHBhc3Nwb3J0IGNsYWltaW5nIHNwaCBidXQgd2l0aCBubyBQcmlv cml0eSBoZWFkZXIgc2hvdWxkIGl0IGFkZCBpdCBpbj8gSSdtIG5vdCBzdXJlIHRoZSBzcGVjIG5l ZWRzIHRvIGJlIHRvbyBwcmVzY3JpcHRpdmUgaGVyZSwgaG93ZXZlciBzb21lIG1lbnRpb24gb2Yg dmVyaWZpZXIgYmVoYXZpb3VyIGFuZCB0aGUgYXNzb2NpYXRlZCBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyB3b3VsZCBiZSB1c2VmdWwuDQoNCg0KU2hvdWxkIHRoZSBzcGVjIGJlIHN0cm9uZ2VyIGFi b3V0IHRoZSBjb21wYWN0IGZvcm0/DQpTZWN0aW9uIDMgY3VycmVudGx5IHN0YXRlcw0KDQogICBU aGUgdXNlIG9mIHRoZSBjb21wYWN0IGZvcm0gb2YgUEFTU3BvclQgaXMgbm90IHNwZWNpZmllZCBp biB0aGlzDQoNCiAgIGRvY3VtZW50Lg0KSG93ZXZlciwgYSBjb21wYWN0LWZvcm0gcGFzc3BvcnQg Zm9sbG93aW5nIHRoaXMgc3BlYyB3b3VsZCBiZSBoYXJkIHRvIHZlcmlmeSBhcyBpdCBpbnRyb2R1 Y2VzIG11bHRpcGxlIHBvc3NpYmxlIHJwaCB2YXJpYW50cywgSSB0aGluayB0aGlzIHNwZWMgY291 bGQgZ28gZnVydGhlciBhbmQgc2F5IHlvdSBzaG91bGRuJ3QvbXVzdG4ndC4NCg0KDQpXaGF0IGlz IHRoZSByZXF1aXJlbWVudCBvZiB0aGVzZSBuZXcgcGFyYW1ldGVycy4NCkFzIEkgdW5kZXJzdGFu ZCBpdCwgdGhlIHBhc3Nwb3J0IHNwZWMgYWxsb3dzIHlvdSB0byBjcmVhdGUgYSBwYXNzcG9ydCBj b250YWluaW5nIHdoYXRldmVyIEpXVCBmaWVsZHMgeW91IHdhbnQgYW5kIHZlcmlmaWVycyBzaG91 bGQganVzdCBpZ25vcmUgYW55IGZpZWxkcyB0aGV5IGRvbid0IHVuZGVyc3RhbmQuIFVubGVzcyB0 aGUgInBwdCIgY2xhaW0gaXMgc2V0LCB3aGljaCBpbmRpY2F0ZXMgdGhhdCB2ZXJpZmllcnMgc2hv dWxkIGRpc2NhcmQgaXQgaWYgdGhleSBkb24ndCByZWNvZ25pc2UgdGhhdCBwYXNzcG9ydCB0eXBl LiBBcyB0aGlzIHNwZWMgYWRkcyBhZGRpdGlvbmFsIGZpZWxkcyB0byBhbiBleGlzdGluZyBwYXNz cG9ydCB0eXBlIGl0IGlzbid0IGltbWVkaWF0ZWx5IGNsZWFyIHdoYXQgdGhlIGJlaGF2aW91ciBz aG91bGQgYmUuIFNwZWNpZmljYWxseSwgaXMgYW4gcnBoIHBhc3Nwb3J0IGNvbnRhaW5pbmcgb25s eSAicnBoLkVTb3JpZyIgdmFsaWQgbm93ICh3aGVyZSBpdCB3b3VsZG4ndCBiZSBiZWZvcmUgYmVj YXVzZSBhdXRoIGlzbid0IHByZXNlbnQpLCBpcyBhbiBycGggcGFzc3BvcnQgY29udGFpbmluZyBu byBycGggYW5kIG9ubHkgc3BoIHZhbGlkLCBhbmQgd2hhdCBkb2VzIGEgbm9uLXJwaCBwYXNzcG9y dCB3aXRoIHNwaCBvciBFU29yaWcgc2V0IG1lYW4/DQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpzdGlyIG1haWxpbmcgbGlzdA0Kc3RpckBpZXRmLm9y ZzxtYWlsdG86c3RpckBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3RpcjxodHRwczovL25hbTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZz dGlyJmRhdGE9MDIlN0MwMSU3Q0phY2suUmlja2FyZCU0MG1ldGFzd2l0Y2guY29tJTdDMmJjM2Q3 ZTRlNmFhNGY4NWViZWIwOGQ4NDQ0NTczMzAlN0M5ZDllNTZlYmY2MTM0ZGRiYjI3YmJmY2RmMTRi MmNkYiU3QzElN0MwJTdDNjM3MzM0NDEyMzc1ODk5ODA1JnNkYXRhPWprWmx5V3JxQ05wYnFQQXJz QlpOcnlXJTJCV2pUeWxKWSUyRkg4NmIxYndNTERRJTNEJnJlc2VydmVkPTA+DQoNCg== --_000_BYAPR02MB5189D7055FCD08B0F926B9ADF35A0BYAPR02MB5189namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUki Ow0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5h cHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNw YWNlO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ SXQncyBub3QgY2xlYXIgdGhhdCB0aGlzIHNwZWMgcmVsaWVzIG9uIHRoYXQsIGFuZCBJJ20gbm90 IHN1cmUgdGhhdCBpdCBzaG91bGQ/IFRvIG1lIGl0IHNlZW1zIGxpa2UgdGhpcyBjb3VsZCBiZSBt b3JlIHdpZGVseSBhcHBsaWNhYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Xb3VsZCB5b3UgYmUgYWJsZSB0byBhZGRyZXNz LCBmcm9tIGEgdmVyaWZpY2F0aW9uIHNlcnZpY2UncyBwb2ludCBvZiB2aWV3LCB3aGF0IGl0IHNo b3VsZCBkbz8gSSB0aGluayB0aGF0IHdpbGwgY2xlYXIgdXAgd2h5ICZxdW90O0Vzb3JpZyZxdW90 OyBhbmQgJnF1b3Q7RVNjYWxsYmFjayZxdW90OyBhcmUgdXNlZnVsIGFib3ZlIHBsYWluICZxdW90 O2F1dGgmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHRoaW5rIHRoZSBzcGVj IHdvdWxkIGJlbmVmaXQgZnJvbSB0aGF0IHNlY3Rpb24gYXMgd2VsbCBTZWN0aW9uIDQgb2YgUkZD IDg0NDMgYW5kIHNlY3Rpb24gMTEgb2YgZHJhZnQtaWV0Zi1zdGlyLXBhc3Nwb3J0LXJjZC0wNiBh cmUgYm90aCBpbmNyZWRpYmx5IHVzZWZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+SmFjazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiPiBCcmlhbiBSb3NlbiAmbHQ7YnJAYnJpYW5yb3Nlbi5uZXQmZ3Q7DQo8 YnI+DQo8Yj5TZW50OjwvYj4gMTkgQXVndXN0IDIwMjAgMTQ6NDA8YnI+DQo8Yj5Ubzo8L2I+IEph Y2sgUmlja2FyZCAmbHQ7SmFjay5SaWNrYXJkQG1ldGFzd2l0Y2guY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gZHJhZnQtaWV0Zi1zdGlyLXJwaC1lbWVyZ2VuY3ktc2VydmljZXNAaWV0Zi5vcmc7IHN0 aXJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzdGlyXSBSZXZpZXcgb2YgZHJh ZnQtaWV0Zi1zdGlyLXJwaC1lbWVyZ2VuY3ktc2VydmljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5n PSIwIiBjZWxscGFkZGluZz0iMCIgYWxpZ249ImxlZnQiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lk dGg6MTAwLjAlO2JvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQg c3R5bGU9ImJhY2tncm91bmQ6IzkxMEExOTtwYWRkaW5nOjMuMHB0IDEuNXB0IDMuMHB0IDEuNXB0 Ij48L3RkPg0KPHRkIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlO2JhY2tncm91bmQ6 I0ZERjJGNDtwYWRkaW5nOjMuMHB0IDMuNzVwdCAzLjBwdCAxMS4yNXB0O3dvcmQtd3JhcDpicmVh ay13b3JkIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTtt c28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21z by1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhv cml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMjEyMTIxIj5OT1RFOiBNZXNzYWdlIGlzIGZyb20gYW4gZXh0ZXJuYWwgc2VuZGVy PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2hpdGUiPkFi b3V0IDIwJSBvZiB0aGUgVVMgaGFzIG5vdyB1cGdyYWRlZCB0byBORzktMS0xLCBhbHRob3VnaCBt b3N0IHNlcnZpY2UgcHJvdmlkZXJzIGhhdmVu4oCZdCB5ZXQuICZuYnNwO1RoZSB3aXJlbGVzcyBj YXJyaWVycyBhcmUgbW92aW5nIHRvd2FyZHMgaXQ7IHRlc3RpbmcgaXMgdW5kZXJ3YXkuICZuYnNw Ow0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg d2lsbCBoYXZlIGEgY29tcGFuaW9uIGRvY3VtZW50IGluIHNpcGNvcmUgdGhhdCBoYW5kbGVzIHRo ZSBzaWduYWxpbmcgYXNwZWN0cyBvZiB0aGlzIG1lY2hhbmlzbS4gJm5ic3A7Rm9yIHRoZSBvbGRl ciBFOTExIHN5c3RlbSwgbm9uZSBvZiBzdGlyIHJlYWxseSBoZWxwcyBiZWNhdXNlIHRoZSBleGlz dGluZyBzeXN0ZW0gaXMgYnVpbHQgb24gdGhlIG9sZGVyIENsYXNzIDQgc3dpdGNoZXMgKOKAnFNl bGVjdGl2ZSBSb3V0ZXJz4oCdKS4NCiAmbmJzcDtBbGwgb2YgdGhpcyBtZWNoYW5pc20gaXMgZm9y IE5HOS0xLTEgYW5kIHRoZSBlcXVpdmFsZW50IHNlcnZpY2VzIGluIHRoZSByZXN0IG9mIHRoZSB3 b3JsZCwgYmFzZWQgb24gSUVURiBzdGFuZGFyZHMgKFJGQzY4ODEsIFJGQzUyMjIsIGFuZCBzZXZl cmFsIG90aGVycykuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXVnIDE5LCAyMDIwLCBhdCA3OjE5IEFNLCBKYWNr IFJpY2thcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpKYWNrLlJpY2thcmRAbWV0YXN3aXRjaC5jb20i PkphY2suUmlja2FyZEBtZXRhc3dpdGNoLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLCB0aGF0J3MgcmVhbGx5IHVz ZWZ1bCwgaG93ZXZlciwgSSdtIG5vdCBjb252aW5jZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBFU29yaWcsIGFzIGZhciBhcyBJIGtu b3cgdGhpcyBpc24ndCBjdXJyZW50bHkgYWx3YXlzIHRoZSBjYXNlLCBJIGFtIGF3YXJlIG9mIHNp dHVhdGlvbnMgd2hlcmUgZW1lcmdlbmN5IGNhbGxzIGp1c3QgbG9vayBsaWtlIG5vcm1hbCBjYWxs cyB3aXRoIGEgbnVtYmVyIG9mIDkxMS4gSSdtIGFsc28gc3RpbGwgdW5jbGVhciBhYm91dCB3aGF0 IGFmZmVjdCB0aGlzIGhhcywgYXMgeW91IGNhbiBjdXJyZW50bHkNCiBhbHJlYWR5IHNpZ24gZW1l cmdlbmN5IGNhbGxzIHVzaW5nIHRoZSBzdGFuZGFyZCBtZWNoYW5pc21zIChiYXJyaW5nIHRoZSB3 aG9sZSAmcXVvdDt1cm46c2VydmljZTpzb3MmcXVvdDsgdG4gd2hpY2ggSSBkb24ndCBiZWxpZXZl IGlzIHN0YW5kYXJkaXNlZCBmb3IgU1RJUiB5ZXQ/KSZuYnNwOyBieSBwdXR0aW5nICZxdW90O2Vz bmV0LjAmcXVvdDsgaW4gdGhlIGF1dGggZmllbGQgb2YgYW4gcnBoIHBhc3Nwb3J0LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgRVNjYWxs YmFjaywgaWYgdGhlIHNwaCBhbmQgJnF1b3Q7cnBoLmF1dGgmcXVvdDsgY2xhaW1zIGNvdmVyIHRo ZWlzIGVudGlyZWx5IHdoeSBpcyBFU2NhbGxiYWNrIG5lZWRlZD8gSSdtIGFsc28gc3RpbGwgdW5j bGVhciB3aGF0IHRoZSB2ZXJpZmljYXRpb24gc2VydmljZSBiZWhhdmlvdXIgaXMgaGVyZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIHN0 aWxsIHVuY2xlYXIgYXMgdG8gaG93IHRoaXMgc3BlYyBoZWxwcyB3aXRoIGFsbG93aW5nIGFuZCBw cmV2ZW50aW5nIG1hbGljaW91cyB1c2Ugb2YgZW1lcmdlbmN5IGNhbGxzLiBZb3UgY2FuIGFscmVh ZHkgcHV0IGVzbmV0IHJlc291cmNlIHByaW9yaXR5IHBhaXJzIGluIHRoZSAmcXVvdDtycGguYXV0 aCZxdW90OyBjbGFpbSBhbmQgdGhhdCBzZWVtcyB0byBwcm92aWRlIGFzIG11Y2ggc2VjdXJpdHkg YXMgdGhpcyBkb2VzLg0KIEkgZG8gYWdyZWUgdGhlIHNwaCBjbGFpbSBkb2VzIHByb3ZpZGUgdmFs dWUsIGhvd2V2ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgZGlkIGp1c3QgcmVhbGlzZSB0aGF0IHRoZSBlc25ldCBSZXNvdXJjZSBQcmlv cml0eSBuZWVkcyB0byBiZSBpbiB0aGUgJnF1b3Q7cnBoLmF1dGgmcXVvdDsgY2xhaW0gb3IgdGhl IGxvZ2ljIGZyb20gdGhhdCByZmMgd2lsbCBraWNrIGluIGFuZCByZW1vdmUgaXQsIGFzIHBlcjo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJGQyA4 NDQzLCBzZWN0aW9uIDQuMjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBJbiBzdWNoIHNjZW5hcmlvcywgdGhl IFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCBTSE9VTEQgYmU8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IHN0cmlwcGVkIGZyb20gdGhlIFNJUCByZXF1ZXN0LCBhbmQgdGhlIG5l dHdvcmsgZW50aXRpZXMgc2hvdWxkIHRyZWF0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGUg Y2FsbCBhcyBhbiBvcmRpbmFyeSBjYWxsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdsbCBub3RlIHRoYXQgc29tZSBvZiBteSBx dWVzdGlvbnMgYW5kIGNvbmNlcm5zIGhhdmVuJ3QgYmVlbiBhZGRyZXNzZWQgeWV0LCBJJ20gaGFw cHkgdG8gcmVzb2x2ZSB0aGlzIGZpcnN0LCBqdXN0IG1ha2luZyBhIG5vdGUgc28gdGhhdCB0aGV5 IGRvbid0IGdldCBsb3N0L0kgZG9uJ3QgZm9yZ2V0IGFib3V0IHRoZW0uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KYWNrPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5CcmlhbiBSb3NlbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Ij5ickBicmlhbnJvc2VuLm5ldDwvYT4mZ3Q7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNl bnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4x OCBBdWd1c3QgMjAyMCAyMjozMTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SmFjayBSaWNrYXJkICZsdDs8YSBocmVmPSJtYWls dG86SmFjay5SaWNrYXJkQG1ldGFzd2l0Y2guY29tIj5KYWNrLlJpY2thcmRAbWV0YXN3aXRjaC5j b208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc3Rpci1ycGgtZW1l cmdlbmN5LXNlcnZpY2VzQGlldGYub3JnIj5kcmFmdC1pZXRmLXN0aXItcnBoLWVtZXJnZW5jeS1z ZXJ2aWNlc0BpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86c3RpckBpZXRmLm9yZyI+c3Rp ckBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtzdGlyXSBSZXZpZXcgb2YgZHJhZnQtaWV0 Zi1zdGlyLXJwaC1lbWVyZ2VuY3ktc2VydmljZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TGV04oCZcyBrZWVwIHRoZSB0d28gdXNlIGNhc2VzIHNlcGFyYXRlOjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FU29yaWcgaXMgYW4gZW1lcmdlbmN5 IGNhbGwgKHVzZXIgdG8gYXV0aG9yaXR5KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVTY2FsbGJhY2sgaXMgYSBjYWxs IGZyb20gYXV0aG9yaXR5IHRvIHVzZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBF U29yZywgdGhlIGNhbGwgaXMgbWFya2VkIHdpdGggYSBSZXF1ZXN0LVVSSSBvZiB1cm46c2Vydmlj ZTpzb3MuICZuYnNwO1RoZSDigJxUb+KAnSBmaWVsZCBpcyBpZ25vcmVkIGluIHJvdXRpbmcgYW5k IGhhbmRsaW5nIHRoZSBjYWxsLiAmbmJzcDtUaGF04oCZcyBob3cgeW91IGtub3cgdGhpcyBpcyBh biBlbWVyZ2VuY3kgY2FsbC4gJm5ic3A7IEZvciBzdGlyIHB1cnBvc2VzLCB0aGUgRnJvbSBpcyBh biBvcmRpbmFyeSBpZGVudGlmaWVyLCBhbmQNCiBnZXRzIHRyZWF0ZWQgaW4gdGhlIG5vcm1hbCB3 YXkuICZuYnNwO0hvd2V2ZXIsIHRoZSBycGggdmFsdWUgY2FuIG9ubHkgYmUgdXNlZCBieSBhIHZh bGlkIGVtZXJnZW5jeSBjYWxsLCBhbmQgYSB2YWxpZCBlbWVyZ2VuY3kgY2FsbCBpcyBhIFJlcXVl c3QgVVJJIG9mIHVybjpzZXJ2aWNlOnNvcywgYW5kIGEgdmFsaWQgRnJvbS4gJm5ic3A7U28geW91 IGRvbuKAmXQgaGF2ZSBhbnkga25vd2xlZGdlIG9mIGVtZXJnZW5jeSBzZXJ2aWNlcyBpZGVudGlm aWVycywgb25seSB0aGUNCiBSZXF1ZXN0IFVSSSBvZiB1cm46c2VydmljZTpzb3MuICZuYnNwOyZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgRVNjYWxsYmFjaywgdGhlIG1hcmtp bmcgaXMgYSBkaXN0aW5ndWlzaGVkIHZhbHVlIGluIFNJUCBQcmlvcml0eS4gJm5ic3A7SWYgYSBj YWxsIGhhcyB0aGF0IHZhbHVlLCBpdOKAmXMgYSBjYWxsIGJhY2suICZuYnNwO1RoZSBvcmlnaW5h dGluZyBzZXJ2aWNlIHByb3ZpZGVyIGtub3dzIHdobyBhcmUgdGhlIGF1dGhvcml0aWVzIHdobyBh cmUgYWxsb3dlZCB0byBwbGFjZSBjYWxsIGJhY2tzLCBzbyB0aGUgY2hlY2sgaXMgd2hhdA0KIGlz IGluIFNJUCBQcmlvcml0eSwgYW5kIG9uZSBvZiB0aGUgYWxsb3dlZCBhdXRob3JpdGllcyBpbiBG cm9tLiAmbmJzcDtBcyBhIHByYWN0aWNhbCBtYXR0ZXIsIGluIG1vc3QgY2FzZXMsIHRoZSBjYWxs IHdpbGwgYmUgc2lnbmVkIGJ5IHRoZSBlbWVyZ2VuY3kgYXV0aG9yaXRpZXMgdGhlbXNlbHZlcywg d2hvIHdpbGwgYmUgYWJsZSB0byBnZXQgYXBwcm9wcmlhdGUgY3JlZGVudGlhbHMgZm9yIHRoaXMg cHVycG9zZS4gJm5ic3A7SW4gbW9zdCBjYXNlcyBJ4oCZbSBhd2FyZQ0KIG9mLCB0aGUgVG8gaW4g YW4gZW1lcmdlbmN5IGNhbGwgd29u4oCZdCBtYXRjaCB0aGUgRnJvbSBpbiBhIENhbGxiYWNrLCBi dXQgaXTigJlzIHBvc3NpYmxlIGZvciB0aGF0IHRvIGhhcHBlbiwgYW5kIHdlIHdhbnQgdG8gYWxs b3cgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVzbmV0IGlzIGEgUmVzb3VyY2UgUHJp b3JpdHkgSGVhZGVyIG5hbWVzcGFjZSwgbm90IGEgU0lQIFByaW9yaXR5IHZhbHVlLiAmbmJzcDtX ZeKAmXJlIGFsbG93aW5nIGVtZXJnZW5jeSBjYWxscyBhbmQgY2FsbCBiYWNrcyB0byB1c2UgcnBo LCBhbmQgd2XigJlyZSBwcm90ZWN0aW5nIGFnYWluc3QgbWFsaWNpb3VzIHVzZSBvZiBpdC4gJm5i c3A7U28gdW5sZXNzIHRoZSBjYWxsIGhhcyB1cm46c2VydmljZTpzb3MgaW4gUmVxdWVzdCBVUkks DQogb3IgdGhlIHJpZ2h0IFNJUCBQcmlvcml0eSBpbiBhIGNhbGwgYmFjayAoYW5kIGZyb20gYW4g YXV0aG9yaXplZCBhdXRob3JpdHkpIHRoZXkgY2Fu4oCZdCB1c2UgcnBoIHdpdGggdGhlIGVzbmV0 IG5hbWVzcGFjZS4gJm5ic3A7R2VuZXJhbGx5LCB1bmxlc3MgdW5kZXIgYXR0YWNrLCBlbWVyZ2Vu Y3kgY2FsbHMgZ28gdGhyb3VnaCBldmVuIGlmIHRoZXJlIGlzbuKAmXQgYSBwYXNzcG9ydC4gJm5i c3A7TWFueSBuZXR3b3JrcyB3b27igJl0IG9mZmVyIGFjdHVhbCBwcmlvcml0eQ0KIHRvIGVtZXJn ZW5jeSBjYWxscywgYnV0IHRoZSBlbWVyZ2VuY3kgc2VydmljZXMgbmV0d29ya3MgKEVTSW5ldHMp IHdpbGwuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBhIGNhbGwgYXJyaXZl cyBhbnl3aGVyZSB3aXRoIGFuIHJwaCB1c2luZyBlc25ldCwgYW5kIGlzbuKAmXQgYW4gZW1lcmdl bmN5IGNhbGwsIHdpdGggdGhlIGFwcHJvcHJpYXRlIHBhc3Nwb3J0LCAmbmJzcDthbnkgaW50ZXJt ZWRpYXJ5IGNhbiByZWZ1c2UgdG8gZ2l2ZSBpdCBhbnkgcHJpb3JpdHksICZuYnNwO1RoZSBlbWVy Z2VuY3kgYXV0aG9yaXRpZXMgbWF5IGFjY2VwdCBhIGNhbGwgd2l0aG91dCBhIHZhbGlkIHBhc3Nw b3J0LA0KIGJ1dCB0aGV5IG1pZ2h0IHRyZWF0IGl0IHdpdGggbXVjaCBtb3JlIHN1c3BpY2lvbiB0 aGFuIHRoZXkgd291bGQgYW55IG90aGVyIGNhbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkZvciBjYWxsIGJhY2tzLCB0aGUgbmV0d29yayBtYXkgaGF2ZSBzcGVjaWFsIGJlaGF2aW9yLiAm bmJzcDtGb3IgZXhhbXBsZSwgaXQgbWF5IHNlbmQgdGhlIGNhbGwgdG8gdGhlIGRldmljZSB0aGF0 IHBsYWNlZCB0aGUgZW1lcmdlbmN5IGNhbGwsIHJhdGhlciB0aGFuLCBmb3IgZXhhbXBsZSwgdm9p Y2UgbWFpbC4gJm5ic3A7VGhlIG5ldHdvcmsgaGFzIHRvIGJlIGFibGUgdG8gdHJ1c3QgdGhhdCBT SVAgUHJpb3JpdHkgaXMgc2V0DQogYXBwcm9wcmlhdGVseS4gJm5ic3A7SXQgd2lsbCBhbHNvIGhh dmUgcnBoIHVzaW5nIGVzbmV0LCBhbmQgdGhlIG5ldHdvcmsgY2FuIGdyYW50IGl0IGFwcHJvcHJp YXRlIHByaW9yaXR5IGlmIGl0IGhhcyB0aGF0IGNhcGFiaWxpdHksIGFuZCB3b3VsZCBub3QgYWxs b3cgZXNuZXQgb3RoZXJ3aXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgb25seSB2 YWx1ZSBpbiBjb3ZlcmluZyBvdGhlciB1c2VzIG9mIFNJUCBQcmlvcml0eSBpcyB0byBwcm90ZWN0 IGFnYWluc3QgbWlkZGxlIGJveGVzIG1vZGlmeWluZyBpdC4gJm5ic3A7V2UgZG9u4oCZdCByZWFs bHkgaGF2ZSB1c2UgY2FzZXMgZm9yIHRoYXQuICZuYnNwO0l0IHByb2JhYmx5IHdvdWxkbuKAmXQg aHVydCB0byBhbGxvdyBpdCB0aG91Z2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMg dGhhdCBoZWxwPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmlhbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBdWcgMTQsIDIwMjAsIGF0IDE6MjEgUE0s IEphY2sgUmlja2FyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkphY2suUmlja2FyZD00MG1ldGFzd2l0 Y2guY29tQGRtYXJjLmlldGYub3JnIj5KYWNrLlJpY2thcmQ9NDBtZXRhc3dpdGNoLmNvbUBkbWFy Yy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHJldmll d2VkIGRyYWZ0LWlldGYtc3Rpci1ycGgtZW1lcmdlbmN5LXNlcnZpY2VzLTAyIGFuZCBoYXZlIHNv bWUgY29uY2VybnMgYW5kIHF1ZXN0aW9ucy4gSSBkb24ndCBiZWxpZXZlIHRoaXMgc3BlYyBpcyBp bXBsZW1lbnRhYmxlIGluIGl0cyBjdXJyZW50IGZvcm0uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphY2s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ V2h5IGFyZSAmcXVvdDtFU29yaWcmcXVvdDsgYW5kICZxdW90O0VTY2FsbGJhY2smcXVvdDsgZGlz dGluY3Q/PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhleSBzZWVtIHRvIHNlcnZlIGEgdmVyeSBzaW1pbGFyIHB1 cnBvc2Ugd2l0aCB0aGUgb25seSBkaWZmZXJlbmNlIGJlaW5nIHdoZXRoZXIgb3JpZyBvciBkZXN0 IHNob3VsZCBiZSB0aGUgZW1lcmdlbmN5IHNlcnZpY2VzLiBJIGRvbid0IGJlbGlldmUgdGhlcmUn cyBhbnkgY2hlY2sgdGhhdCBjYW4gYmUgZG9uZSB0byB2YWxpZGF0ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgV2hlbiB1c2luZyAmcXVvdDtFU29yaWcmcXVvdDsgYXMgdGhlICZx dW90O3JwaCZxdW90OyBhc3NlcnRpb24gdmFsdWUsIHRoZSAmcXVvdDtvcmlnJnF1b3Q7IGNsYWlt IG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGUgUEFTU3BvclQg TVVTVCByZXByZXNlbnQgdGhlIGNhbGxpbmcgcGFydHkgbnVtYmVyIHRoYXQgaW5pdGlhdGVzPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGUgY2FsbCB0byBlbWVyZ2Vu Y3kgc2VydmljZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyAoYW5kIHRoZSBlcXVpdmFsZW50IHN0 YXRlbWVudCBmb3IgRVNjYWxsYmFjaykgZG9uJ3Qgc2VlbSBwb3NzaWJsZSB0byBtZSB0byBjaGVj ayAoYmFycmluZyB0aGUgc3RhbmRhcmQgb3JpZy9kZXN0IGNoZWNraW5nKS4uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGlzIHdvdWxkIG1ha2UgdGhlIGNoZWNrICZxdW90O2F0IGxlYXN0IG9uZSBvZiB0aGUgcGFydGll cyBzaG91bGQgYmUgdGhlIGVtZXJnZW5jeSBzZXJ2aWNlcyZxdW90OyBlbm91Z2ggdG8gdmFsaWRh dGUgdGhhdCB0aGlzIHdhcyBhIHJlYXNvbmFibGUgY2FsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5XaHkgaGF2ZSB0aGVtIGF0IGFsbCByYXRoZXIgdGhh biBqdXN0IHVzaW5nIGF1dGg/PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyB2ZXJ5IHBvc3NpYmx5IGFu IGlzc3VlIHdpdGggbXkgdW5kZXJzdGFuZGluZywgYnV0IEknbSBub3QgY2xlYXIgb24gd2h5ICZx dW90O0VTb3JpZyZxdW90OyBhbmQgJnF1b3Q7RVNjYWxsYmFjayZxdW90OyBldmVuIG5lZWQgdG8g ZXhpc3QuICZxdW90O2VzbmV0LjAmcXVvdDsgZXRjLiBhcmUgU0lQIFJlc291cmNlIFByaW9yaXR5 IGhlYWRlcnMsIHNvIHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgJnF1b3Q7YXV0aCZxdW90OyBm aWVsZCBhbnl3YXkgYnkgdGhlIFJQSCBzcGVjLg0KIFRoaXMgc3BlYyBhcHBlYXJzIHRvIGFwcGx5 IGV4dHJhIGNvbnN0cmFpbnRzICh0aGF0IGEgb25lIG9mIHRoZSBjYWxsZXJzIG11c3QgYmUgdGhl IGVtZXJnZW5jeSBzZXJ2aWNlcykgZm9yIHRoZSAmcXVvdDtlc25ldCZxdW90OyBuYW1lc3BhY2Ug YnV0IGl0J3Mgbm90IGNsZWFyIHdoeSBlbnRpcmVseSBzZXBhcmF0ZSBjbGFpbXMgYXJlIG5lZWRl ZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gYSBzaW1pbGFyIHZlaW4sIHdoYXQgc2hv dWxkIGEgdmVyaWZpZXIgZG8gaWYgaXQgcmVjZWl2ZXMgYSBjYWxsIGNvbnRhaW5pbmcgYW4gaW52 YWxpZCAmcXVvdDtFU29yaWcmcXVvdDsgb3IgJnF1b3Q7RVNjYWxsYmFjayZxdW90OyB2YWx1ZSBv ciB0aGUgcGFzc3BvcnQgaXMgaW52YWxpZC91bnRydXN0ZWQsIEknbSBhc3N1bWluZyB0aGUgYmVo YXZpb3VyIGlzIHRoZSBzYW1lIGFzIGZvciBhdXRoIGJ1dCB0aGlzIGlzbid0IGNsZWFyLiBBbHRo b3VnaA0KIHN0cmlwcGluZyB0aGUgZmFjdCB0aGF0IHRoaXMgaXMgYW4gZW1lcmdlbmN5IGNhbGwg aXMgcG90ZW50aWFsbHkgZGFuZ2Vyb3VzLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5TcGVjaWZ5IHRoZSB0eXBlIG9mIHRoZSAmcXVvdDtFU29yaWcmcXVv dDsgYW5kICZxdW90O0VTY2FsbGJhY2smcXVvdDsgY2xhaW1zLjwvYj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg c3BlY2lmaWNhdGlvbiBjdXJyZW50bHkgZG9lc24ndCBzcGVjaWZ5IHRoZSB0eXBlIG9mIHRoZSBu ZXcgZmllbGRzLCB0aGVyZSBhcmUgb25seSBleGFtcGxlcyBhbmQgdGhpcyBpc24ndCBlbm91Z2gu IEl0IGxvb2tzIGxpa2UgdGhleSBib3RoIGZvbGxvdyB0aGUgc2FtZSBzY2hlbWUgYXMgdGhlIHJw aCAmcXVvdDthdXRoJnF1b3Q7IGNsYWltLCBob3dldmVyICZxdW90O2VzbmV0LHgmcXVvdDsgZG9l c24ndCBxdWl0ZSBmaXQgaW50byB0aGF0DQogZHVlIHRvIHRoZSBjb21tYSBhbmQgdGhhdCB4IGlz bid0IGEgdmFsaWQgcHJpb3JpdHkgdmFsdWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+V2h5IGlzIHNwaCBsaW1pdGVkIHRvIHBzYXAtY2FsbGJhY2s/IFdo YXQgc2hvdWxkIHRoZSB2ZXJpZmllciBkbyBpZiBpdCBpc24ndCB0aGF0PyBXaGF0IHNob3VsZCBp dCBkbyBpZiBpdCBpcz88L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gbm90IGVudGlyZWx5IGNsZWFyIG9uIHRo ZSBwdXJwb3NlIG9mIHRoZSBzcGggY2xhaW0sIGhvd2V2ZXIsIGl0IHNlZW1zIG9kZCB0aGF0IGl0 IGRvZXNuJ3QgY292ZXIgdGhlIGZ1bGwgcmFuZ2Ugb2YgcG9zc2libGUgdmFsdWVzIGZvciB0aGUg U0lQIFByaW9yaXR5IEhlYWRlci4gSXMgdGhlcmUgYSByZWFzb24gdGhhdCBpdCBkb2Vzbid0IGNv dmVyIHRoZSAmcXVvdDtub24tdXJnZW50JnF1b3Q7LCAmcXVvdDtub3JtYWwmcXVvdDssICZxdW90 O3VyZ2VudCZxdW90OywNCiBvciAmcXVvdDtlbWVyZ2VuY3kmcXVvdDsgdmFsdWVzPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlcmUgaXMgYWxzbyBubyB2ZXJpZmllciBiZWhhdmlvdXIgZGVmaW5lZCBoZXJlLCBzaG91 bGQgdGhlIHZlcmlmaWVyIHJlbW92ZSB0aGUgUHJpb3JpdHkgaGVhZGVyIGlmIGl0IHJlY2VpdmVz IGFuIGludml0ZSB3aXRoIG5vIHBhc3Nwb3J0cyBzaWduaW5nIGZvciBpdD8gVGhhdCBzZWVtcyBk YW5nZXJvdXMgdG8gbWUgYnV0IHdvdWxkIGJlIGNvbnNpc3RlbnQgd2l0aCBycGguIEFsdGVybmF0 aXZlbHksIHdoYXQNCiBzaG91bGQgdGhlIHZlcmlmaWVyIGRvIGlmIGl0IHJlY2VpdmVzIGFuIGlu dml0ZSB3aXRoIGEgdmFsaWQgcGFzc3BvcnQgY2xhaW1pbmcgc3BoIGJ1dCB3aXRoIG5vIFByaW9y aXR5IGhlYWRlciBzaG91bGQgaXQgYWRkIGl0IGluPyBJJ20gbm90IHN1cmUgdGhlIHNwZWMgbmVl ZHMgdG8gYmUgdG9vIHByZXNjcmlwdGl2ZSBoZXJlLCBob3dldmVyIHNvbWUgbWVudGlvbiBvZiB2 ZXJpZmllciBiZWhhdmlvdXIgYW5kIHRoZSBhc3NvY2lhdGVkIHNlY3VyaXR5DQogY29uc2lkZXJh dGlvbnMgd291bGQgYmUgdXNlZnVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGJyPg0KPC9iPjxicj4NCjxiPlNo b3VsZCB0aGUgc3BlYyBiZSBzdHJvbmdlciBhYm91dCB0aGUgY29tcGFjdCBmb3JtPzwvYj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlNlY3Rpb24gMyBjdXJyZW50bHkgc3RhdGVzPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHByZT4mbmJzcDsmbmJzcDsgVGhlIHVzZSBvZiB0aGUgY29tcGFjdCBmb3JtIG9m IFBBU1Nwb3JUIGlzIG5vdCBzcGVjaWZpZWQgaW4gdGhpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBkb2N1bWVudC48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyLCBhIGNvbXBhY3QtZm9ybSBwYXNzcG9ydCBmb2xs b3dpbmcgdGhpcyBzcGVjIHdvdWxkIGJlIGhhcmQgdG8gdmVyaWZ5IGFzIGl0IGludHJvZHVjZXMg bXVsdGlwbGUgcG9zc2libGUgcnBoIHZhcmlhbnRzLCBJIHRoaW5rIHRoaXMgc3BlYyBjb3VsZCBn byBmdXJ0aGVyIGFuZCBzYXkgeW91IHNob3VsZG4ndC9tdXN0bid0LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGJy Pg0KPGJyPg0KV2hhdCBpcyB0aGUgcmVxdWlyZW1lbnQgb2YgdGhlc2UgbmV3IHBhcmFtZXRlcnMu PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QXMgSSB1bmRlcnN0YW5kIGl0LCB0aGUgcGFzc3BvcnQgc3BlYyBhbGxv d3MgeW91IHRvIGNyZWF0ZSBhIHBhc3Nwb3J0IGNvbnRhaW5pbmcgd2hhdGV2ZXIgSldUIGZpZWxk cyB5b3Ugd2FudCBhbmQgdmVyaWZpZXJzIHNob3VsZCBqdXN0IGlnbm9yZSBhbnkgZmllbGRzIHRo ZXkgZG9uJ3QgdW5kZXJzdGFuZC4gVW5sZXNzIHRoZSAmcXVvdDtwcHQmcXVvdDsgY2xhaW0gaXMg c2V0LCB3aGljaCBpbmRpY2F0ZXMgdGhhdCB2ZXJpZmllcnMNCiBzaG91bGQgZGlzY2FyZCBpdCBp ZiB0aGV5IGRvbid0IHJlY29nbmlzZSB0aGF0IHBhc3Nwb3J0IHR5cGUuIEFzIHRoaXMgc3BlYyBh ZGRzIGFkZGl0aW9uYWwgZmllbGRzIHRvIGFuIGV4aXN0aW5nIHBhc3Nwb3J0IHR5cGUgaXQgaXNu J3QgaW1tZWRpYXRlbHkgY2xlYXIgd2hhdCB0aGUgYmVoYXZpb3VyIHNob3VsZCBiZS4gU3BlY2lm aWNhbGx5LCBpcyBhbiBycGggcGFzc3BvcnQgY29udGFpbmluZyBvbmx5ICZxdW90O3JwaC5FU29y aWcmcXVvdDsgdmFsaWQgbm93DQogKHdoZXJlIGl0IHdvdWxkbid0IGJlIGJlZm9yZSBiZWNhdXNl IGF1dGggaXNuJ3QgcHJlc2VudCksIGlzIGFuIHJwaCBwYXNzcG9ydCBjb250YWluaW5nIG5vIHJw aCBhbmQgb25seSBzcGggdmFsaWQsIGFuZCB3aGF0IGRvZXMgYSBub24tcnBoIHBhc3Nwb3J0IHdp dGggc3BoIG9yIEVTb3JpZyBzZXQgbWVhbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPiZuYnNwOzwvYj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpzdGlyIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 c3RpckBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+c3RpckBpZXRmLm9yZzwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vbmFtMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnN0aXImYW1wO2RhdGE9MDIlN0MwMSU3Q0phY2su Umlja2FyZCU0MG1ldGFzd2l0Y2guY29tJTdDMmJjM2Q3ZTRlNmFhNGY4NWViZWIwOGQ4NDQ0NTcz MzAlN0M5ZDllNTZlYmY2MTM0ZGRiYjI3YmJmY2RmMTRiMmNkYiU3QzElN0MwJTdDNjM3MzM0NDEy Mzc1ODk5ODA1JmFtcDtzZGF0YT1qa1pseVdycUNOcGJxUEFyc0JaTnJ5VyUyQldqVHlsSlklMkZI ODZiMWJ3TUxEUSUzRCZhbXA7cmVzZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_BYAPR02MB5189D7055FCD08B0F926B9ADF35A0BYAPR02MB5189namp_-- From nobody Sat Aug 22 15:36:00 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CAE3A0941 for ; Sat, 22 Aug 2020 15:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 1_zbbov48Ly2 for ; Sat, 22 Aug 2020 15:35:57 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5553A0911 for ; Sat, 22 Aug 2020 15:35:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 63DB4300B55 for ; Sat, 22 Aug 2020 18:35:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6jZ2uUzjymLd for ; Sat, 22 Aug 2020 18:35:53 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 2B33F300AA6 for ; Sat, 22 Aug 2020 18:35:53 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Sat, 22 Aug 2020 18:35:54 -0400 References: <8372C576-08B7-41C4-B021-38622BABAD25@vigilsec.com> <919FC584-18AF-4419-B174-B9FB37B6439D@vigilsec.com> To: IETF STIR Mail List In-Reply-To: <919FC584-18AF-4419-B174-B9FB37B6439D@vigilsec.com> Message-Id: <2594EDCF-C5D3-4C77-BDD4-7CE230A63282@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2020 22:35:59 -0000 WG Last Call is over. I saw many comments that need to responses. Russ > On Jul 31, 2020, at 11:29 AM, Russ Housley = wrote: >=20 >=20 > This is the STIR WG Last Call for "Assertion Values for a Resource = Priority Header Claim and a SIP Priority Header Claim in Support of = Emergency Services Networks=E2=80=9D = . Please review the document = and send your comments to the STIR WG mail list by 22 August 2020. >=20 > = https://datatracker.ietf.org/doc/draft-ietf-stir-rph-emergency-services/ >=20 > Thanks, > Robert & Russ From nobody Sun Aug 23 14:03:16 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225F13A0E5B for ; Sun, 23 Aug 2020 14:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 Yg1nwjjTAYBJ for ; Sun, 23 Aug 2020 14:03:12 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4FC33A0E09 for ; Sun, 23 Aug 2020 14:03:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1F574300B69 for ; Sun, 23 Aug 2020 17:03:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BoD2GY23sUoa for ; Sun, 23 Aug 2020 17:03:08 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id C9964300A9E for ; Sun, 23 Aug 2020 17:03:08 -0400 (EDT) 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.15\)) Date: Sun, 23 Aug 2020 17:03:08 -0400 References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <41B1930A-2631-47D3-8693-62363B9C5639@vigilsec.com> To: IETF STIR Mail List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [stir] Call For Adoption of draft-peterson-stir-servprovider-oob X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2020 21:03:14 -0000 Few people have spoken, but everyone that did speak was supportive. So, = this document is adopted by the STIR WG as the staring point for = protocol work on the out-of-band conveyance of PASSporTs by service = providers. Russ > On Jul 31, 2020, at 11:35 AM, Russ Housley = wrote: >=20 > Please take a look at draft-peterson-stir-servprovider-oob. Please = indicate whether you support adoption of this document by the STIR WG. = Please respond before 23 August 2020. If you support adoption, please = indicate whether you would review or implement. >=20 > This document can be found in the datatracker at = https://datatracker.ietf.org/doc/draft-peterson-stir-servprovider-oob/ >=20 > Russ & Robert >=20 From nobody Mon Aug 24 04:00:36 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793B43A0CB1 for ; Mon, 24 Aug 2020 04:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 (1024-bit key) header.d=signalwire.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 vy9WKV5Ai6ZA for ; Mon, 24 Aug 2020 04:00:32 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 353963A0CB3 for ; Mon, 24 Aug 2020 04:00:32 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id z22so7843636oid.1 for ; Mon, 24 Aug 2020 04:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=signalwire.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6uKI5s1AmfMWbYT7sg8qmDEkfCvcg8L/NtJtxx3MsgM=; b=HUBh6mvq6K6fmpqKrAd+Q+BLEjGGhLoAT3/P5Pp1JLCJW7tP6ch90R7I1MY2tFcFx5 iiRV3D35iw1r9m+gGtiOY/hYnuC9kZEeyVNdfVcorEUrIcYhRSa7sOOH1L1R3JEewgjO gFQao2mtrIooYpJvTedKUw9y3T4caoaqXNnWc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6uKI5s1AmfMWbYT7sg8qmDEkfCvcg8L/NtJtxx3MsgM=; b=Y/HHJ+3mSto5bgmTcTexJkHCOTHR5HY8Q6IvLoL0PZ4z1WsytS6c2+G637Hvg5dF/0 kZ+yTfTNoqIFrj44Y0AaiV3TVDbJwNpkSiA6LZVAeI5GHPp2EF1Z6hPgeXeASCQi1VDu l83E9o6CUyXVLeaS1l/yYdzIgZ1R6USB971ZZUaucQ9zftKCsOdDkdzw5oCq3wNSMuvO GUTihJ/gCJdfZofMBp+zJ7rbV8Leo/S2PPDOSITVfVj1VcLCmuDKqvfb/v88J6kteGV4 MHDQEm/IW6x8E4tAnfkU43VwA0fZPAfBLDghF/2Z1/4wXDIY8Zu4QvmY/BIpuWq7N9ES DW5g== X-Gm-Message-State: AOAM530AqzTDzvz8zYuO/InlQut/bn73qcaOVuKoRS3ncaq1xDI8MQBq FfU6/Un5fpWfch1w7iRlq4u3slIcKEPmPw96eu/TD490mgmTM42PP3WiVpqzOjKGUaX4kv/5+1R bWSiiDW4bxZpTG/cF6DLmZg== X-Google-Smtp-Source: ABdhPJwFfF5HgcwW1Nt4fXz4IC+gMN/fbiTYBSLi60x2wdRGMUoos7mlu00iZZXWGwNvLfe/abPVC6Oir/rFU7Phq9g= X-Received: by 2002:aca:c6c9:: with SMTP id w192mr2816296oif.28.1598266831401; Mon, 24 Aug 2020 04:00:31 -0700 (PDT) MIME-Version: 1.0 References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <41B1930A-2631-47D3-8693-62363B9C5639@vigilsec.com> In-Reply-To: From: Piotr Gregor Date: Mon, 24 Aug 2020 11:59:55 +0100 Message-ID: To: Russ Housley Cc: IETF STIR Mail List Content-Type: multipart/alternative; boundary="000000000000be0a4a05ad9d7ee8" Archived-At: Subject: Re: [stir] Call For Adoption of draft-peterson-stir-servprovider-oob X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 11:00:34 -0000 --000000000000be0a4a05ad9d7ee8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am also reviewing this document (and draft-ietf-stir-oob), cause it's relevant to software defined telecoms, like us (SignalWire). Trying to figure out how businesses like us best fit into this (how they can provide STIR-Shaken to their clients) and willing to help! all the best, Piotr --=20 =C2=A0=C2=A0*|*=C2=A0 Ask me about=C2=A0SignalWire Work ,=C2=A0 our new digital office alternative. --000000000000be0a4a05ad9d7ee8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am also reviewing this document (and draft-ietf-stir-oob= ), cause it's relevant to software defined telecoms, like us (SignalWir= e).
Trying to figure out how businesses like us best fit into this (how= they can provide STIR-Shaken to their clients) and willing to help!
<= div>
all the best,
Piotr

=C2=A0=C2=A0|= =C2=A0 Ask me about=C2=A0SignalWire Work,= =C2=A0our new digital office alternative.
--000000000000be0a4a05ad9d7ee8-- From nobody Mon Aug 24 17:09:28 2020 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D273A0ADE for ; Mon, 24 Aug 2020 17:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 (1024-bit key) header.d=signalwire.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 eSD5DCPcHm9W for ; Mon, 24 Aug 2020 17:09:25 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 1DDB03A0ADD for ; Mon, 24 Aug 2020 17:09:25 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id h3so10035624oie.11 for ; Mon, 24 Aug 2020 17:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=signalwire.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pF8xpqM6TxpDkAVCOvkPm9JvZLjUL0zKosBzmh9J1hU=; b=dqdFKKzefKh/V1ORie+iiVeuEx7hCFQBzZg/I0YOeEg3JEE4HOqFwZsu8mVSAipnHy dJ3z+9LmHiT5RCsn2b0cTrctO0eRU5A/KL4nopSVEocY3u5ghJb2DGVOllh/WqLtvC0W 27CfPg+Ow3mwDoauijWwehRdBoKmhfr5odj6Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pF8xpqM6TxpDkAVCOvkPm9JvZLjUL0zKosBzmh9J1hU=; b=VcAzIpuyP5eFW+q++eaQq6FNUsnMACrSc6QkJoTRTsjG/AyFtEVHyvtXImmNDaMQDy LiqNEYgwbTy5L6rmWRM34y02Sqgt5UWu7Cw67Yd5g2/u8RIMEvq2XIcoR0ZG0gt4vp+p Kxl30Wk21uS8/8F2/Q4mMwgr0k/h2P1kMVCcPKq6h3OUwvNBHrX68Qjh+h4sVhKcE8Hv n8rOANux9YTGSaQCmwB+gKTjjq19WDMvb0iwVkWLOcbVXEl9KIvfClijJnpvOenhVhcf cLJdjvhq6aTrEntDKXQSjadKqIkbsFvvlw+tYWCAYdDQLq+/dNXXOy/cJjD2B85GlTGf PU3A== X-Gm-Message-State: AOAM530PMbdTrc+IE+PXt/xTJ+agEKNZisCi9Y8Ru3ju7v//p4AJ4oa9 ChWnP/xCPD5p+q1XImBNoCuxZlsCrpB9T0Ms5ZkPYGj1iQjloNiaz0Fdxu6hfutZfVZBQETaGTp 2hgZPFhwSeFoZLw== X-Google-Smtp-Source: ABdhPJyizWcl10qyXjcXZezDEAdxJSCBcfHM4vf7FgXBNgmaR3fzjRUOs+cmX4vCULM5PEDdtkk8aQnR20OFoshkidI= X-Received: by 2002:aca:c0c1:: with SMTP id q184mr1280327oif.56.1598314164332; Mon, 24 Aug 2020 17:09:24 -0700 (PDT) MIME-Version: 1.0 References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <41B1930A-2631-47D3-8693-62363B9C5639@vigilsec.com> In-Reply-To: From: Piotr Gregor Date: Tue, 25 Aug 2020 01:08:48 +0100 Message-ID: To: Russ Housley Cc: IETF STIR Mail List , jon.peterson@team.neustar, ekr@rtfm.com Content-Type: multipart/alternative; boundary="00000000000001467d05ada884a0" Archived-At: Subject: Re: [stir] Call For Adoption of draft-peterson-stir-servprovider-oob X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 00:09:27 -0000 --00000000000001467d05ada884a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe there is an error in draft-ietf-stir-oob-07, here in section 9 it is said that call originates for destination 2.222.555.2222 but then 2.222.222.2222 appears in places I highlighted: 9 . Example HTTPS Interface to the CPS (...) Assume that an authentication service has created the following PASSporT for a call to the telephone number 2.222.555.2222 (...) Through some discovery mechanism (see Section 10 ), the authentication service discovers the network location of a web service that acts as the CPS for 2.222.555.2222. (...) Having concluded the numbered steps in Section 8.1 , including acquiring any token (per Section 6.1 ) needed to store the PASSporT at the CPS, the authentication service then stores the encrypted PASSporT: Rescorla & Peterson Expires September 10, 2020 [Page 20] ------------------------------ Internet-Draf= t STIR Out-of-Band March 2020 POST /cps/2.222.555.2222/ppts HTTP/1.1 Host: cps.example.com (...) The web service assigns a new location for this encrypted PASSporT in the collection, returning a 201 OK with the location of /cps/2.222.222.2222/ppts/ppt1. ^^^^^^^^^^^^^^^^^^^^^^ ->>>>>>>>>>>>> should be /cps/2.222.555.2222/ppts/ppt1 Now the authentication service can place the call, which may be signaled by various protocols. Once the call arrives at the terminating side, a verification service contacts its CPS to ask for the set of incoming calls for its telephone number (2.222.222.2222). ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ->>>>>>>>>>>>> should be 2.222.555.2222 GET /cps/2.222.555.2222/ppts Host: cps.example.com This returns to the verification service a list of the PASSporTs currently in the collection, which currently consists of only /cps/2.222.222.2222/ppts/ppt1. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ->>>>>>>>>>>>> should be /cps/2.222.555.2222/ppts/ppt1 The verification service then sends a new GET for /cps/2.222.555.2222/ppts/ppt1/ which yields: (...) cheers, Piotr --=20 =C2=A0=C2=A0*|*=C2=A0 Ask me about=C2=A0SignalWire Work ,=C2=A0 our new digital office alternative. --00000000000001467d05ada884a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe there is an error in draft-ietf-stir-oob-07, her= e in section 9 it is said that call originates for destination=C2=A02.222.5= 55.2222
but then=C2=A02.222.222.2222 appears in places I highlighted:

9.  Example HTTPS Interface to the =
CPS

(...)
   Assume that an authentication service has created the following
   PASSporT for a call to the telephone number 2.222.555.2222 
(...)
   Through some discovery mechanism (see Section 10), =
the authentication
   service discovers the network location of a web service that acts as
   the CPS for 2.222.555.2222.
(...)
   Having concluded the numbered steps in Section 8.1=
, including
   acquiring any token (per Section 6.1) needed to st=
ore the PASSporT at
   the CPS, the authentication service then stores the encrypted
   PASSporT:



Rescorla & Peterson    Expires S=
eptember 10, 2020              [Page 20]
 
Internet-Draft              STIR Out=
-of-Band                  March 2020


      POST /cps/2.222.555.2222/ppts HTTP/1.1
      Host: cps.exampl=
e.com
(...)

   The web service assigns a new location for this encrypted PASSporT in
   the collection, returning a 201 OK with the location of
   /cps/2.222.222.2222/ppts/ppt1.  
^^^^^^=
^^^^^^^^^^^^^^^^
->>>>>>=
>>>>>>> should be /cps/2.222.555.2222/ppts/ppt1
<= pre style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-bef= ore:page;color:rgb(0,0,0)">

= 
Now the authentication service can
   place the call, which may be signaled by various protocols.  Once the
   call arrives at the terminating side, a verification service contacts
   its CPS to ask for the set of incoming calls for its telephone number
   (2.222.222.2222).
^^^^^^^^^^^^^^^^^^^^^=
^^^^^^
->&g=
t;>>>>>>>>>>> should be 2.222.555.2222

      GET /cps/2.222.555.2222/ppts
      Host: cps.exampl=
e.com

   This returns to the verification service a list of the PASSporTs
   currently in the collection, which currently consists of only
   /cps/2.222.222.2222/ppts/ppt1.
^^^^^^^^=
^^^^^^^^^^^^^^^^^^^^^^^^^^^
->>>&=
gt;>>>>>>>>> should be /cps/2.222.555.2222/ppts/=
ppt1

  The verification service then sends a
   new GET for /cps/2.222.555.2222/ppts/ppt1/ which yields:
(...)

cheers,
Piotr





=C2=A0=C2=A0|=
=C2=A0 Ask me about=C2=A0SignalWire Work,=
=C2=A0our new digital office alternative.

--00000000000001467d05ada884a0--


From nobody Tue Aug 25 08:15:04 2020
Return-Path: 
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957A73A0E27 for ; Tue, 25 Aug 2020 08:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.105
X-Spam-Level: 
X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 v6AzbLqgF7O8 for ; Tue, 25 Aug 2020 08:15:00 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 5C68A3A0E19 for ; Tue, 25 Aug 2020 08:15:00 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id i2so5962236qtb.8 for ; Tue, 25 Aug 2020 08:15:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VZdeUuHC5kB8pUlfeHQHklORGaz6fdrdAgr+isVg5R8=; b=j3TUwhjsPlYtIXxHB0PE7ZmJ7y0aVhcTsi4WvN5itEhLXIzxgLj70q5qZuSgJLZbZC +MWMlIZP1jc/2s+sMohnA/FZKhd3OH/qG8lGOoeOG6dgyBh7y2uI34Nj3H9vlpkp1b7A t+3KLDV549mEGM7MF608tBDtkJ3xcW+HPkIOjryoywP2o6c4OXQOiHtwJXBdEswhTyyW KWJt5YLT5E6Z8XNYj9vfrMFeZyJ8XxV01pKfBkzYUWCLDvSSubXfqa2T5t8iZgUpG/Im bmWvUTTneVrqu93pIBeHExv103xHSttzqH132uvBQTh5jJTT3Sp9SZr17pShtbt7BSmx ApEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VZdeUuHC5kB8pUlfeHQHklORGaz6fdrdAgr+isVg5R8=; b=eK2HsBksOJXl+aQ+N+U6UNUs1IWgZ1Ri3EeDXg7qhxTXunuOTCj0043jf18Sljv/1d RDwOTa/JRdIHNQww3Lv2iE7ckWW5aQXUmSLNqXj8VKBrI0FLqSbvb+MrVAqnSJwoR05W uQGFNtIHwrPsktSVJynEwLiOFdwLzGWAiMQWA4eNDUUchrZUQ3M0t14JHr0wRaoVWWgs GUhPLhLmOamwueu0eFZRc7VEj+UOYi1A7lKPf66hFQ4NNg+QY0gElKqrGdIYpNh6T7at FsA89jQAtsjkxMxOu4lOzgwyTcf3URX8qSZ27xo2Z0Idxuz+EmksD7RjnYpas5EjySe+ G02Q==
X-Gm-Message-State: AOAM531TVmOw/sg2ORb1lN3vApBCBZ0FKHkulrVZcq+4A+VazEHi8ZPN KgkUT5v+oMV1NI5v6/BvLg/UyQ==
X-Google-Smtp-Source: ABdhPJxES9JnMEtW7HhfR2sytTIj4fTgjQhnYtkzhtS3G5wXTB1BLgegufYLiU2Jy2EopC+3glmBkw==
X-Received: by 2002:ac8:5685:: with SMTP id h5mr10116094qta.378.1598368499354;  Tue, 25 Aug 2020 08:14:59 -0700 (PDT)
Received: from ?IPv6:2607:fb90:6088:d6d3:c909:1b18:6467:10ec? ([2607:fb90:6088:d6d3:c909:1b18:6467:10ec]) by smtp.gmail.com with ESMTPSA id 95sm13776874qtc.29.2020.08.25.08.14.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Aug 2020 08:14:58 -0700 (PDT)
From: Chris Wendt 
Message-Id: <14ACD074-FD66-4161-AC7A-ADB07127BE2D@chriswendt.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A7F25D06-57D2-41F0-A6ED-AC3487DF6F4F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Tue, 25 Aug 2020 11:14:54 -0400
In-Reply-To: 
Cc: Brian Rosen , "draft-ietf-stir-rph-emergency-services@ietf.org" ,  "stir@ietf.org" 
To: Jack Rickard 
References:    <959DCC43-1686-49D3-9195-719CF65C9EE9@brianrosen.net> 
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: 
Subject: Re: [stir] Review of draft-ietf-stir-rph-emergency-services
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Aug 2020 15:15:04 -0000

--Apple-Mail=_A7F25D06-57D2-41F0-A6ED-AC3487DF6F4F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Jack,

I think we still want to keep =E2=80=9Cauth=E2=80=9D and =
=E2=80=9CESorig/ESCallback=E2=80=9D as separate and distinct key/value =
objects, i see your comments as maybe disagreement stylistically but =
didn=E2=80=99t see anything to suggest that it wouldn=E2=80=99t work.  =
The reasoning though is that =E2=80=9Cauth=E2=80=9D is intended to be =
specific to priority services only, not extensible for other =
applications.  And the fact of the matter is key/values are cheap, no =
reason we can=E2=80=99t have new values and be explicit about the =
intent.  This document is specific to 911 and emergency services and to =
extend the key/values defined for =E2=80=98rph=E2=80=99 claim and =
=E2=80=98rph=E2=80=99 PASSporT extension.

I will make this clearer in the document and explicitly say that =
=E2=80=9Cauth=E2=80=9D should not be used for emergency services =
purposes of using resource priority header.

I think it would also make sense to make it clear that that this =
document extends 8443 and linking the documents.

For compact form, we think it would confuse folks to add provisions for =
compact form or allow it for little gain, and therefore prefer to leave =
it undefined.

Thanks.

-Chris

> On Aug 20, 2020, at 1:30 PM, Jack Rickard =
 wrote:
>=20
> It's not clear that this spec relies on that, and I'm not sure that it =
should? To me it seems like this could be more widely applicable.
> =20
> Would you be able to address, from a verification service's point of =
view, what it should do? I think that will clear up why "Esorig" and =
"EScallback" are useful above plain "auth".
> I think the spec would benefit from that section as well Section 4 of =
RFC 8443 and section 11 of draft-ietf-stir-passport-rcd-06 are both =
incredibly useful.
> =20
> Thanks,
> Jack
> =20
> From: Brian Rosen >=20
> Sent: 19 August 2020 14:40
> To: Jack Rickard >
> Cc: draft-ietf-stir-rph-emergency-services@ietf.org =
; stir@ietf.org =

> Subject: Re: [stir] Review of draft-ietf-stir-rph-emergency-services
> =20
> NOTE: Message is from an external sender
> About 20% of the US has now upgraded to NG9-1-1, although most service =
providers haven=E2=80=99t yet.  The wireless carriers are moving towards =
it; testing is underway. =20
> I will have a companion document in sipcore that handles the signaling =
aspects of this mechanism.  For the older E911 system, none of stir =
really helps because the existing system is built on the older Class 4 =
switches (=E2=80=9CSelective Routers=E2=80=9D).  All of this mechanism =
is for NG9-1-1 and the equivalent services in the rest of the world, =
based on IETF standards (RFC6881, RFC5222, and several others). =20
>=20
>=20
> On Aug 19, 2020, at 7:19 AM, Jack Rickard > wrote:
> =20
> Thanks, that's really useful, however, I'm not convinced.
> =20
> For ESorig, as far as I know this isn't currently always the case, I =
am aware of situations where emergency calls just look like normal calls =
with a number of 911. I'm also still unclear about what affect this has, =
as you can currently already sign emergency calls using the standard =
mechanisms (barring the whole "urn:service:sos" tn which I don't believe =
is standardised for STIR yet?)  by putting "esnet.0" in the auth field =
of an rph passport.
> =20
> For EScallback, if the sph and "rph.auth" claims cover theis entirely =
why is EScallback needed? I'm also still unclear what the verification =
service behaviour is here.
> =20
> I'm still unclear as to how this spec helps with allowing and =
preventing malicious use of emergency calls. You can already put esnet =
resource priority pairs in the "rph.auth" claim and that seems to =
provide as much security as this does. I do agree the sph claim does =
provide value, however.
> =20
> I did just realise that the esnet Resource Priority needs to be in the =
"rph.auth" claim or the logic from that rfc will kick in and remove it, =
as per:
> RFC 8443, section 4.2
>    In such scenarios, the SIP 'Resource-Priority' header field SHOULD =
be
>    stripped from the SIP request, and the network entities should =
treat
>    the call as an ordinary call.
> =20
> I'll note that some of my questions and concerns haven't been =
addressed yet, I'm happy to resolve this first, just making a note so =
that they don't get lost/I don't forget about them.
> Jack
> =20
> From: Brian Rosen >=20
> Sent: 18 August 2020 22:31
> To: Jack Rickard >
> Cc: draft-ietf-stir-rph-emergency-services@ietf.org =
; stir@ietf.org =

> Subject: Re: [stir] Review of draft-ietf-stir-rph-emergency-services
> =20
> Let=E2=80=99s keep the two use cases separate:=20
> ESorig is an emergency call (user to authority).
> EScallback is a call from authority to user.
> =20
> For ESorg, the call is marked with a Request-URI of urn:service:sos.  =
The =E2=80=9CTo=E2=80=9D field is ignored in routing and handling the =
call.  That=E2=80=99s how you know this is an emergency call.   For stir =
purposes, the =46rom is an ordinary identifier, and gets treated in the =
normal way.  However, the rph value can only be used by a valid =
emergency call, and a valid emergency call is a Request URI of =
urn:service:sos, and a valid From.  So you don=E2=80=99t have any =
knowledge of emergency services identifiers, only the Request URI of =
urn:service:sos.  =20
> =20
> For EScallback, the marking is a distinguished value in SIP Priority.  =
If a call has that value, it=E2=80=99s a call back.  The originating =
service provider knows who are the authorities who are allowed to place =
call backs, so the check is what is in SIP Priority, and one of the =
allowed authorities in From.  As a practical matter, in most cases, the =
call will be signed by the emergency authorities themselves, who will be =
able to get appropriate credentials for this purpose.  In most cases =
I=E2=80=99m aware of, the To in an emergency call won=E2=80=99t match =
the =46rom in a Callback, but it=E2=80=99s possible for that to happen, =
and we want to allow it.
> =20
> Esnet is a Resource Priority Header namespace, not a SIP Priority =
value.  We=E2=80=99re allowing emergency calls and call backs to use =
rph, and we=E2=80=99re protecting against malicious use of it.  So =
unless the call has urn:service:sos in Request URI, or the right SIP =
Priority in a call back (and from an authorized authority) they can=E2=80=99=
t use rph with the esnet namespace.  Generally, unless under attack, =
emergency calls go through even if there isn=E2=80=99t a passport.  Many =
networks won=E2=80=99t offer actual priority to emergency calls, but the =
emergency services networks (ESInets) will. =20
> =20
> If a call arrives anywhere with an rph using esnet, and isn=E2=80=99t =
an emergency call, with the appropriate passport,  any intermediary can =
refuse to give it any priority,  The emergency authorities may accept a =
call without a valid passport, but they might treat it with much more =
suspicion than they would any other call.
> =20
> For call backs, the network may have special behavior.  For example, =
it may send the call to the device that placed the emergency call, =
rather than, for example, voice mail.  The network has to be able to =
trust that SIP Priority is set appropriately.  It will also have rph =
using esnet, and the network can grant it appropriate priority if it has =
that capability, and would not allow esnet otherwise.
> =20
> The only value in covering other uses of SIP Priority is to protect =
against middle boxes modifying it.  We don=E2=80=99t really have use =
cases for that.  It probably wouldn=E2=80=99t hurt to allow it though.
> =20
> Does that help?
> =20
> Brian
> =20
>=20
>=20
>=20
> On Aug 14, 2020, at 1:21 PM, Jack Rickard =
> wrote:
> =20
> I have reviewed draft-ietf-stir-rph-emergency-services-02 and have =
some concerns and questions. I don't believe this spec is implementable =
in its current form.
> =20
> Thanks,
> Jack
> =20
> Why are "ESorig" and "EScallback" distinct?
> They seem to serve a very similar purpose with the only difference =
being whether orig or dest should be the emergency services. I don't =
believe there's any check that can be done to validate:
>    When using "ESorig" as the "rph" assertion value, the "orig" claim =
of
>    the PASSporT MUST represent the calling party number that initiates
>    the call to emergency services.
> This (and the equivalent statement for EScallback) don't seem possible =
to me to check (barring the standard orig/dest checking)..
> This would make the check "at least one of the parties should be the =
emergency services" enough to validate that this was a reasonable call.
> =20
> =20
> Why have them at all rather than just using auth?
> This is very possibly an issue with my understanding, but I'm not =
clear on why "ESorig" and "EScallback" even need to exist. "esnet.0" =
etc. are SIP Resource Priority headers, so should be included in the =
"auth" field anyway by the RPH spec. This spec appears to apply extra =
constraints (that a one of the callers must be the emergency services) =
for the "esnet" namespace but it's not clear why entirely separate =
claims are needed.
> =20
> In a similar vein, what should a verifier do if it receives a call =
containing an invalid "ESorig" or "EScallback" value or the passport is =
invalid/untrusted, I'm assuming the behaviour is the same as for auth =
but this isn't clear. Although stripping the fact that this is an =
emergency call is potentially dangerous..
> =20
> =20
> Specify the type of the "ESorig" and "EScallback" claims.
> This specification currently doesn't specify the type of the new =
fields, there are only examples and this isn't enough. It looks like =
they both follow the same scheme as the rph "auth" claim, however =
"esnet,x" doesn't quite fit into that due to the comma and that x isn't =
a valid priority value.
> =20
> =20
> Why is sph limited to psap-callback? What should the verifier do if it =
isn't that? What should it do if it is?
> I'm not entirely clear on the purpose of the sph claim, however, it =
seems odd that it doesn't cover the full range of possible values for =
the SIP Priority Header. Is there a reason that it doesn't cover the =
"non-urgent", "normal", "urgent", or "emergency" values?
> There is also no verifier behaviour defined here, should the verifier =
remove the Priority header if it receives an invite with no passports =
signing for it? That seems dangerous to me but would be consistent with =
rph. Alternatively, what should the verifier do if it receives an invite =
with a valid passport claiming sph but with no Priority header should it =
add it in? I'm not sure the spec needs to be too prescriptive here, =
however some mention of verifier behaviour and the associated security =
considerations would be useful.
>=20
>=20
> Should the spec be stronger about the compact form?
> Section 3 currently states
>    The use of the compact form of PASSporT is not specified in this
>    document.
> However, a compact-form passport following this spec would be hard to =
verify as it introduces multiple possible rph variants, I think this =
spec could go further and say you shouldn't/mustn't.
>=20
>=20
> What is the requirement of these new parameters.
> As I understand it, the passport spec allows you to create a passport =
containing whatever JWT fields you want and verifiers should just ignore =
any fields they don't understand. Unless the "ppt" claim is set, which =
indicates that verifiers should discard it if they don't recognise that =
passport type. As this spec adds additional fields to an existing =
passport type it isn't immediately clear what the behaviour should be. =
Specifically, is an rph passport containing only "rph.ESorig" valid now =
(where it wouldn't be before because auth isn't present), is an rph =
passport containing no rph and only sph valid, and what does a non-rph =
passport with sph or ESorig set mean?
> =20
> _______________________________________________
> stir mailing list
> stir@ietf.org 
> https://www.ietf.org/mailman/listinfo/stir =


--Apple-Mail=_A7F25D06-57D2-41F0-A6ED-AC3487DF6F4F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Jack,

I think we =
still want to keep =E2=80=9Cauth=E2=80=9D and =E2=80=9CESorig/ESCallback=E2=
=80=9D as separate and distinct key/value objects, i see your comments =
as maybe disagreement stylistically but didn=E2=80=99t see anything to =
suggest that it wouldn=E2=80=99t work.  The reasoning though is =
that =E2=80=9Cauth=E2=80=9D is intended to be specific to priority =
services only, not extensible for other applications.  And the fact =
of the matter is key/values are cheap, no reason we can=E2=80=99t have =
new values and be explicit about the intent.  This document is =
specific to 911 and emergency services and to extend the key/values =
defined for =E2=80=98rph=E2=80=99 claim and =E2=80=98rph=E2=80=99 =
PASSporT extension.

I will make this clearer in the document and explicitly say =
that =E2=80=9Cauth=E2=80=9D should not be used for emergency services =
purposes of using resource priority header.

I think it would also make sense to =
make it clear that that this document extends 8443 and linking the =
documents.

For =
compact form, we think it would confuse folks to add provisions for =
compact form or allow it for little gain, and therefore prefer to leave =
it undefined.

Thanks.

-Chris

On Aug =
20, 2020, at 1:30 PM, Jack Rickard <Jack.Rickard@metaswitch.com> wrote:

It's not =
clear that this spec relies on that, and I'm not sure that it should? To =
me it seems like this could be more widely applicable.
 
Would you be able to address, from a verification service's =
point of view, what it should do? I think that will clear up why =
"Esorig" and "EScallback" are useful above plain "auth".
I =
think the spec would benefit from that section as well Section 4 of RFC =
8443 and section 11 of draft-ietf-stir-passport-rcd-06 are both =
incredibly useful.
 
Thanks,
Jack
 
From: Brian Rosen <br@brianrosen.net> 
Sent: 19 =
August 2020 14:40
To: Jack Rickard <Jack.Rickard@metaswitch.com>
Cc: draft-ietf-stir-rph-emergency-services@ietf.org; stir@ietf.org
Subject: Re: [stir] Review of =
draft-ietf-stir-rph-emergency-services
 
NOTE: Message is from an external =
sender
About 20% of the US has now upgraded to NG9-1-1, although =
most service providers haven=E2=80=99t yet.  The wireless carriers =
are moving towards it; testing is underway.  
I will =
have a companion document in sipcore that handles the signaling aspects =
of this mechanism.  For the older E911 system, none of stir really =
helps because the existing system is built on the older Class 4 switches =
(=E2=80=9CSelective Routers=E2=80=9D).  All of this mechanism is =
for NG9-1-1 and the equivalent services in the rest of the world, based =
on IETF standards (RFC6881, RFC5222, and several others).  


On =
Aug 19, 2020, at 7:19 AM, Jack Rickard <Jack.Rickard@metaswitch.com> wrote:
 
Thanks, that's really useful, however, I'm not =
convinced.
 
For ESorig, as far as I know this isn't =
currently always the case, I am aware of situations where emergency =
calls just look like normal calls with a number of 911. I'm also still =
unclear about what affect this has, as you can currently already sign =
emergency calls using the standard mechanisms (barring the whole =
"urn:service:sos" tn which I don't believe is standardised for STIR =
yet?)  by putting "esnet.0" in the auth field of an rph =
passport.
 
For EScallback, if the sph and =
"rph.auth" claims cover theis entirely why is EScallback needed? I'm =
also still unclear what the verification service behaviour is here.
 
I'm still =
unclear as to how this spec helps with allowing and preventing malicious =
use of emergency calls. You can already put esnet resource priority =
pairs in the "rph.auth" claim and that seems to provide as much security =
as this does. I do agree the sph claim does provide value, however.
 
I did =
just realise that the esnet Resource Priority needs to be in the =
"rph.auth" claim or the logic from that rfc will kick in and remove it, =
as per:
RFC 8443, section 4.2
   In such scenarios, the SIP 'Resource-Priority' =
header field SHOULD be
   stripped =
from the SIP request, and the network entities should treat
   the call as an ordinary call.
 
I'll note =
that some of my questions and concerns haven't been addressed yet, I'm =
happy to resolve this first, just making a note so that they don't get =
lost/I don't forget about them.
Jack
 
From: Brian Rosen <br@brianrosen.net> 
Sent: 18 =
August 2020 22:31
To: Jack Rickard <Jack.Rickard@metaswitch.com>
Cc: draft-ietf-stir-rph-emergency-services@ietf.org; stir@ietf.org
Subject: Re: [stir] Review of =
draft-ietf-stir-rph-emergency-services
 
Let=E2=80=99=
s keep the two use cases separate: 
ESorig is an emergency call (user to =
authority).
EScallback is a call from authority to =
user.
 
For ESorg, the call is marked with a Request-URI =
of urn:service:sos.  The =E2=80=9CTo=E2=80=9D field is ignored in =
routing and handling the call.  That=E2=80=99s how you know this is =
an emergency call.   For stir purposes, the =46rom is an ordinary =
identifier, and gets treated in the normal way.  However, the rph =
value can only be used by a valid emergency call, and a valid emergency =
call is a Request URI of urn:service:sos, and a valid From.  So you =
don=E2=80=99t have any knowledge of emergency services identifiers, only =
the Request URI of urn:service:sos.   
 
For EScallback, the =
marking is a distinguished value in SIP Priority.  If a call has =
that value, it=E2=80=99s a call back.  The originating service =
provider knows who are the authorities who are allowed to place call =
backs, so the check is what is in SIP Priority, and one of the allowed =
authorities in From.  As a practical matter, in most cases, the =
call will be signed by the emergency authorities themselves, who will be =
able to get appropriate credentials for this purpose.  In most =
cases I=E2=80=99m aware of, the To in an emergency call won=E2=80=99t =
match the =46rom in a Callback, but it=E2=80=99s possible for that to =
happen, and we want to allow it.
 
Esnet is a Resource =
Priority Header namespace, not a SIP Priority value.  We=E2=80=99re =
allowing emergency calls and call backs to use rph, and we=E2=80=99re =
protecting against malicious use of it.  So unless the call has =
urn:service:sos in Request URI, or the right SIP Priority in a call back =
(and from an authorized authority) they can=E2=80=99t use rph with the =
esnet namespace.  Generally, unless under attack, emergency calls =
go through even if there isn=E2=80=99t a passport.  Many networks =
won=E2=80=99t offer actual priority to emergency calls, but the =
emergency services networks (ESInets) will.  
 
If a call arrives anywhere =
with an rph using esnet, and isn=E2=80=99t an emergency call, with the =
appropriate passport,  any intermediary can refuse to give it any =
priority,  The emergency authorities may accept a call without a =
valid passport, but they might treat it with much more suspicion than =
they would any other call.
 
For call backs, the network may have special =
behavior.  For example, it may send the call to the device that =
placed the emergency call, rather than, for example, voice mail. =
 The network has to be able to trust that SIP Priority is set =
appropriately.  It will also have rph using esnet, and the network =
can grant it appropriate priority if it has that capability, and would =
not allow esnet otherwise.
 
The only value in covering other uses of SIP =
Priority is to protect against middle boxes modifying it.  We =
don=E2=80=99t really have use cases for that.  It probably =
wouldn=E2=80=99t hurt to allow it though.
 
Does that help?
 
Brian
 



On Aug 14, 2020, at 1:21 =
PM, Jack Rickard <Jack.Rickard=3D40metaswitch.com@dmarc.ietf.org> =
wrote:
 
I have =
reviewed draft-ietf-stir-rph-emergency-services-02 and have some =
concerns and questions. I don't believe this spec is implementable in =
its current form.
 
Thanks,
Jack
 
Why are "ESorig" and "EScallback" =
distinct?
They seem to serve a very similar =
purpose with the only difference being whether orig or dest should be =
the emergency services. I don't believe there's any check that can be =
done to validate:
   =
When using "ESorig" as the "rph" assertion value, the "orig" claim =
of
   the =
PASSporT MUST represent the calling party number that =
initiates
   the =
call to emergency services.
This (and the equivalent statement for =
EScallback) don't seem possible to me to check (barring the standard =
orig/dest checking)..
This would make the check =
"at least one of the parties should be the emergency services" enough to =
validate that this was a reasonable call.
 
 
Why have them at all rather than =
just using auth?
This is very possibly an =
issue with my understanding, but I'm not clear on why "ESorig" and =
"EScallback" even need to exist. "esnet.0" etc. are SIP Resource =
Priority headers, so should be included in the "auth" field anyway by =
the RPH spec. This spec appears to apply extra constraints (that a one =
of the callers must be the emergency services) for the "esnet" namespace =
but it's not clear why entirely separate claims are needed.
 
In a similar vein, what =
should a verifier do if it receives a call containing an invalid =
"ESorig" or "EScallback" value or the passport is invalid/untrusted, I'm =
assuming the behaviour is the same as for auth but this isn't clear. =
Although stripping the fact that this is an emergency call is =
potentially dangerous..
 
 
Specify the =
type of the "ESorig" and "EScallback" claims.
This specification currently doesn't specify the =
type of the new fields, there are only examples and this isn't enough. =
It looks like they both follow the same scheme as the rph "auth" claim, =
however "esnet,x" doesn't quite fit into that due to the comma and that =
x isn't a valid priority value.
 
 
Why is sph limited to =
psap-callback? What should the verifier do if it isn't that? What should =
it do if it is?
I'm not entirely clear on =
the purpose of the sph claim, however, it seems odd that it doesn't =
cover the full range of possible values for the SIP Priority Header. Is =
there a reason that it doesn't cover the "non-urgent", "normal", =
"urgent", or "emergency" values?
There is also no verifier behaviour defined =
here, should the verifier remove the Priority header if it receives an =
invite with no passports signing for it? That seems dangerous to me but =
would be consistent with rph. Alternatively, what should the verifier do =
if it receives an invite with a valid passport claiming sph but with no =
Priority header should it add it in? I'm not sure the spec needs to be =
too prescriptive here, however some mention of verifier behaviour and =
the associated security considerations would be useful.


Should the spec be stronger about the compact form?
Section 3 currently states
   The use of the compact form of PASSporT is not =
specified in this
   document.
However, a compact-form =
passport following this spec would be hard to verify as it introduces =
multiple possible rph variants, I think this spec could go further and =
say you shouldn't/mustn't.


What is the requirement of these new =
parameters.
As I understand it, the =
passport spec allows you to create a passport containing whatever JWT =
fields you want and verifiers should just ignore any fields they don't =
understand. Unless the "ppt" claim is set, which indicates that =
verifiers should discard it if they don't recognise that passport type. =
As this spec adds additional fields to an existing passport type it =
isn't immediately clear what the behaviour should be. Specifically, is =
an rph passport containing only "rph.ESorig" valid now (where it =
wouldn't be before because auth isn't present), is an rph passport =
containing no rph and only sph valid, and what does a non-rph passport =
with sph or ESorig set mean?
 
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

=

--Apple-Mail=_A7F25D06-57D2-41F0-A6ED-AC3487DF6F4F--


From nobody Wed Aug 26 14:30:20 2020
Return-Path: 
X-Original-To: stir@ietf.org
Delivered-To: stir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4583A081F; Wed, 26 Aug 2020 14:30:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ines Robles via Datatracker 
To: 
Cc: last-call@ietf.org, stir@ietf.org, draft-ietf-stir-cert-delegation.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159847741398.23291.8299604699001624244@ietfa.amsl.com>
Reply-To: Ines Robles 
Date: Wed, 26 Aug 2020 14:30:14 -0700
Archived-At: 
Subject: [stir] Genart last call review of draft-ietf-stir-cert-delegation-03
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Secure Telephone Identity Revisited 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Aug 2020 21:30:14 -0000

Reviewer: Ines Robles
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-stir-cert-delegation-03
Reviewer: Ines Robles
Review Date: 2020-08-26
IETF LC End Date: 2020-08-26
IESG Telechat date: Not scheduled for a telechat

Summary:

This specification details how that authority can be delegated from a parent
certificate to a subordinate certificate.  This supports a  number of use cases
where callers want to use a particular calling number, but for whatever reason,
their outbound calls will not pass through the authentication service of the
service provider that controls that numbering resource, it includes also those
where service providers grant credentials to enterprises or other customers
capable of signing calls with Secure Telephone Identity Revisited (STIR).

I have some minor suggestions/questions to the authors.

Major issues: None

Minor issues:

1-Introduction Section:

"..., including various forms of robocalling, voicemail hacking, and
swatting..." --> should a reference to RFC7375 be added here?

2- It would be nice to add in Terminology section:

-  delegation: the concept of delegation and its levels are defined in RFC8226.
- definition for "legitimate spoofing". I understand that the draft explain it
with an example.

3- It would be nice to add references to concepts, e.g. cA boolean --> cA
boolean [rfc5280#section-4.2.1.9]

"x5u" link -> "x5u" (X.509 URL) [RFC7515#section-4.1.5] link

4- Section 4: It would be nice to add graphics explaining the process.
E.g. can be used as a model the images displayed in
https://access.atis.org/apps/group_public/download.php/47134/IPNNI-2019-00043R000.pdf
or https://niccstandards.org.uk/wp-content/uploads/2019/03/ND1522V1.1.1.pdf

5- Section 5:"Authentication service behavior for delegate certificates is
little
   changed from [RFC8224] STIR behavior" --> It is not clear to me what are the
   little changes.

Additionally, how you quantify little/big changes?, maybe something like?:
"Authentication service behavior varies from STIR behavior [RFC8224] as
follows:...."

6- Section 8.1: Should the picture displayed in
https://www.ietf.org/proceedings/104/slides/slides-104-stir-certificate-delegation-00--Slide
5 be added here?

7- Security Consideration section: should a reference to RFC7375 be added here?

Nits/editorial comments:

8- Expand the first time: JWS -> JSON Web Signature (JWS)

Thank you for this document,

Ines.




From nobody Mon Aug 31 15:54:38 2020
Return-Path: 
X-Original-To: stir@ietf.org
Delivered-To: stir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 371FF3A03F1; Mon, 31 Aug 2020 15:54:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Martin Duke via Datatracker 
To: "The IESG" 
Cc: draft-ietf-stir-cert-delegation@ietf.org, stir-chairs@ietf.org, stir@ietf.org, Russ Housley , housley@vigilsec.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.15.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke 
Message-ID: <159891447575.13053.17687015779427266002@ietfa.amsl.com>
Date: Mon, 31 Aug 2020 15:54:36 -0700
Archived-At: 
Subject: [stir] Martin Duke's No Record on draft-ietf-stir-cert-delegation-03: (with COMMENT)
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Secure Telephone Identity Revisited 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Aug 2020 22:54:36 -0000

Martin Duke has entered the following ballot position for
draft-ietf-stir-cert-delegation-03: No Record

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-stir-cert-delegation/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S/has a own parent/has their own parent

Sec 7. You may want to specify what happens if the PASSporT contains both x5c
and x5u (presumably, ignore the former).

It also says “ The certificate path [RFC5280] ordering MUST be organized from
the trust anchor towards the signer“, which to me, means the trust anchor would
be first. This is the opposite of what the rest of the paragraph says.




From nobody Mon Aug 31 15:54:54 2020
Return-Path: 
X-Original-To: stir@ietf.org
Delivered-To: stir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3343A05AC; Mon, 31 Aug 2020 15:54:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Martin Duke via Datatracker 
To: "The IESG" 
Cc: draft-ietf-stir-cert-delegation@ietf.org, stir-chairs@ietf.org, stir@ietf.org, Russ Housley , housley@vigilsec.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.15.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke 
Message-ID: <159891449169.27024.5928128702602857499@ietfa.amsl.com>
Date: Mon, 31 Aug 2020 15:54:51 -0700
Archived-At: 
Subject: [stir] Martin Duke's No Objection on draft-ietf-stir-cert-delegation-03: (with COMMENT)
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Secure Telephone Identity Revisited 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Aug 2020 22:54:53 -0000

Martin Duke has entered the following ballot position for
draft-ietf-stir-cert-delegation-03: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-stir-cert-delegation/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S/has a own parent/has their own parent

Sec 7. You may want to specify what happens if the PASSporT contains both x5c
and x5u (presumably, ignore the former).

It also says “ The certificate path [RFC5280] ordering MUST be organized from
the trust anchor towards the signer“, which to me, means the trust anchor would
be first. This is the opposite of what the rest of the paragraph says.