Re: [Anima] Éric Vyncke's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
"Eric Vyncke (evyncke)" <evyncke@cisco.com> Fri, 30 August 2019 07:46 UTC
Return-Path: <evyncke@cisco.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3663A12006A; Fri, 30 Aug 2019 00:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=mMZPlXGp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=U5eGuYfr
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 s1HjhRQArdWs; Fri, 30 Aug 2019 00:46:02 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA8C120130; Fri, 30 Aug 2019 00:46:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17560; q=dns/txt; s=iport; t=1567151161; x=1568360761; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OQ0iAW3u3G3cUaAd3fV09PfVaGFrgy26TxgP78hFv0I=; b=mMZPlXGpK5Etk58zQoxtjB6UCFro5X9E9mNPWiQqV6Th3cBOdX2lkOZn 4c4hdM831hq3KI/dCJYczM/Jb9MGdqQClPqnUMHTDcge18/jZ0xByOHNR /oF1c17571VSlxwMdnaJEpGR1pXk5QN7Jq5/krUYQlBmcs5rVMVIaZSs1 Q=;
IronPort-PHdr: 9a23:gqlJcxPZdDPZY7HzVAUl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETBoZkYMTlg0kDtSCDBj2Mu/sZC83NM9DT1RiuXq8NBsdFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CeBgDa02hd/4wNJK1cChwBAQEEAQEHBAEBgWeBRSQsA21WIAQLKoQhg0cDinKCNyWXa4FCgRADVAkBAQEMAQEjBgQCAQGBS4J0AheCRCM4EwIDCAEBBAEBAQIBBgRthS4MhUoBAQEDARIREQwBATcBDwIBCBgCAh8HAgICMBUFCwIEDgUigwABgWoDDg8BAgwDoSkCgTiIYXOBMoJ8AQEFgTIBg1YYghYDBoEMKIt3GIFAP4ERJwwTgkw+gmECgSUJAQcLAQ8QF4J0MoImjEEKFgoSgimFPoINhl6OPgkCgh+GcIUHhGeDeBuCMoc0hByKXYM2kUFqkEkCBAIEBQIOAQEFgWchZ3FwFTsqAYJBEw6CIQsBFxWDOoUUhT9yGQGBD4tEgkUBAQ
X-IronPort-AV: E=Sophos;i="5.64,446,1559520000"; d="scan'208";a="327861905"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Aug 2019 07:45:59 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x7U7jx5C025652 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Aug 2019 07:45:59 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 02:45:58 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 02:45:58 -0500
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 30 Aug 2019 02:45:58 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aD7jdrzCywS2QNSBRiQvn06xv3Im1rPgS5r1eQ2S78Y3WoHpmyZiIuqgAI76Ua5fEQGnZCcBKTOWymhO+lB4j/erIHG3cMJuTy9lBqgpnBcSFWB8UDjjsAPqXDY5hssfmxSkc08jZY4OBjAM8e8SebZ7txUGVk4R0ZgiBqeg1xyNZVXfYnUm4Py9FWhGcmisomBusUVqY8uwhs85mRM2B37OrTdFG4F87YZr3b+V/7fQmw6X595nUBRFDVorP896r+SQrybv4ppBDUOC1lxv07QFqJjTW1MQddFv+TQCOXCzCfcSYHhycaUStO9kMPvKQi8h4OOvu/HQXRTRJuZtVA==
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=OQ0iAW3u3G3cUaAd3fV09PfVaGFrgy26TxgP78hFv0I=; b=WgMaGCLKUgBPIBeMMhkVJueAfrya1uJCLcpf8UyE180RXGSfIVf+EERGBwZdHgmEZSPvZZXdv0/3FHevPE9uB08mpD+Tu3ef8sJ2rh1amtwp5lPWYOH+jdRCEbybNqX/hhD0AxjFh9lsSwP2YJlla50pGp6ibMh8cyNGMf2/iI6DVXlmnyLFMLZf0pgOHZDLnuXt6t1jIVvIV80rYuH+YTsD8q9oNewKfR6zWn3EQFC1mOYFYOglSWpptKp7zct5MVm8R1A1+105Z6svcxVoyUPs2oCN96wli40zSbs2rsLeOpnBVUzHxdkz5Gg3E/5qMVE9cVjW3muuJJe+0jtLFA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OQ0iAW3u3G3cUaAd3fV09PfVaGFrgy26TxgP78hFv0I=; b=U5eGuYfrfJpanp3MCcz1iPUXGHWi1kE0sa17qbbmS1DZurpIaE3gIjLkQDmWpd41huNHqmdYW35D3hbkINfFYAkvFyNRgqD8iccKewyGZ0xOUtxGuugjQrM68/Ek1cwGkyvsoboTOleNjdN6H3x/GPbUTHnp/Es96jmnF1e8k5o=
Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.19; Fri, 30 Aug 2019 07:45:57 +0000
Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::d5c4:be39:66cb:449b]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::d5c4:be39:66cb:449b%6]) with mapi id 15.20.2199.021; Fri, 30 Aug 2019 07:45:57 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: "draft-ietf-anima-bootstrapping-keyinfra@ietf.org" <draft-ietf-anima-bootstrapping-keyinfra@ietf.org>, "tte+ietf@cs.fau.de" <tte+ietf@cs.fau.de>, "anima-chairs@ietf.org" <anima-chairs@ietf.org>, The IESG <iesg@ietf.org>, "anima@ietf.org" <anima@ietf.org>
Thread-Topic: [Anima] Éric Vyncke's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Thread-Index: AQHVN1Vq7cBMmcmUUkC9prwP00A3z6cTwMUA
Date: Fri, 30 Aug 2019 07:45:57 +0000
Message-ID: <0199051C-4A3E-4850-8DA6-05B97CFA27AD@cisco.com>
References: <156275431789.15280.4126747621934962290.idtracker@ietfa.amsl.com> <16753.1562786791@localhost>
In-Reply-To: <16753.1562786791@localhost>
Accept-Language: fr-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com;
x-originating-ip: [2001:420:c0c1:36:600f:3a1b:883:bc2d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bedac0c5-a349-471e-06ce-08d72d1e1836
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4144;
x-ms-traffictypediagnostic: MN2PR11MB4144:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <MN2PR11MB41446F0E3AE1162AED43F87CA9BD0@MN2PR11MB4144.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:1060;
x-forefront-prvs: 0145758B1D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(376002)(396003)(366004)(39850400004)(189003)(199004)(40224003)(51444003)(2906002)(966005)(5660300002)(46003)(476003)(2616005)(86362001)(11346002)(486006)(446003)(76176011)(99286004)(71200400001)(71190400001)(30864003)(186003)(6506007)(14454004)(76116006)(91956017)(478600001)(64756008)(66574012)(102836004)(66446008)(66476007)(66556008)(66946007)(229853002)(6436002)(6246003)(8936002)(6486002)(81166006)(81156014)(54906003)(316002)(256004)(58126008)(224303003)(36756003)(14444005)(33656002)(305945005)(7736002)(6512007)(25786009)(4326008)(6306002)(6116002)(53936002)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4144; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: e4MTiyg26NXS6EUEFygIKHOb95r6tZLmYu5owHwcTFlRT2QgpisiTqD+Ts3OI0pQncRLobeXmyAD33cusaYHn8rj5PO1WoWGNxj6JM1SlqfnAgHyKWxzRgVHp+i4ImrDja5Mp3XF9mDvFEkNTwyR4BbuldM7gwKy+vgiuvMrVeZQh/YzMvDpRLddrO3orVZF+r874RYaaR9SUj3vP7pdQ3SyMKOh9w30TeTzQRimxxnXMCDD47bj3t8gZ+aLnIM/KC/fEeRfPLsb+j5oF2L+rGhXhXd1WMevh4bX6SFT78tb/8zyCHHNeS8bo/vQHmHFcGHZjJtytywTXdownVEbAuMXsLgDpguksvqV52mt79m+3rh2VqLJCqdqJk6XW8vN8vb0mMG3al3BfiftIpWbcz6ntMa2UheWLKRdIUlcPEo=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <AB6ABD077743574BB933D25079218565@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: bedac0c5-a349-471e-06ce-08d72d1e1836
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 07:45:57.3148 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8FIiG3SKdHgWZlGkAsNc70ZHMTjDsgjhrcufMHjggsMygpa+Fzh94rG4DEKSdCcAr/Nd2ipYlVLUkX7jWOqcLQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4144
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/GYdB2MftLy4EwbcZzWIYnY8yez0>
Subject: Re: [Anima] Éric Vyncke's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Aug 2019 07:46:07 -0000
Michael Sorry for belated reply... My brain switched focus to IETF-105 and then holidays and I am afraid failed to switch back to your document. Please find below some comments on your detailed reply to my DISCUSSes: - lack of TLS version, I understand your comment. You suggestion to add some text (justification, clarification, ...) in Section 5.1 about the TLS version would be a plus (albeit a -27 would be required) but I am removing my DISCUSS - section 2.3.1 and serial number: thank you for the clarified text => DISCUSS is cleared - section 3.3 and examples: thank you for improving the text & example => DISCUSS is cleared - section 4.1 and the 2 back-off mechanisms description: the new text is clear => DISCUSS is cleared - section 4.3 and "IPPROTO_TCP, 80": using a different port number also fix my DISCUSS - section 4.3 and ULA rather than documentation prefix => DISCUSS is clear I have updated the datatracker with my new ballot position. Regards and kudos to all authors for their patience and effort beind this document -éric On 10/07/2019, 21:26, "iesg on behalf of Michael Richardson" <iesg-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote: Eric, thank you for the comments. WG and other authors, please look for XXX as your point where I'd like your input. I will push a -23 on the 22nd when draft submissions open, unless you want it faster. Here is a pointer to get a diff between -22 and what is now in github: https://tinyurl.com/y2ex324x I want to point to a thread that this document needs to Updates: RFC7030, as it is extending the /.well-known/est namespace. It would be great to have the IESG's agreement on this, or suggest an alternative. Éric Vyncke via Datatracker <noreply@ietf.org> wrote: > == DISCUSS == > TLS is assumed to be used but I failed to find WHICH version of TLS > MUST be used. The only reference in the reference section is version > 1.2. Probably worth to refer to this version in the text as well and > use version 1.3 of TLS. First, in developing this protocol we thought a lot about some of the privacy enhancements that TLS 1.3 could provide us, particularly around keeping the identifying parts of the IDevID (present in the Certificate), and we thought about >=1.3, but we did not want to tie things up for vendors. We also considered strongly always having the JRC initiate the TLS, because the ClientCertificate is sent first in TLS, and the JRC has no real privacy needs. We did not do this, even though there were strong requirements from the 6tisch WG to give the JRC more control over enrollment order/bandwidth. We decided to sit on the fence about TLS versions because Getting a TLS version through an evaluation process and into a firmware for a BFR wasn't something we wanted to gate BRSKI upon. As such, we think we are happy with any version of TLS that the TLS WG recommends. We further recognize that Registrar's MAY have to be willing to talk to versions which are older than whatever is considered secure that year. A device that has been in a box in a warehouse won't have the latest patches, and it won't have the latest patches until it goes through an onboarding process. The alternative is a truck roll, a USB stick, and some gum. We reference RFC7030, and it's section 3.3.1 says TLS 1.1 (now considered old), but we didn't like that it even specified what is now an obsolete cipher suite. That's one reason we felt that we shouldn't overspecify: that's the TLS WG's job. It would be nice to be able to point to a STD XX for this. Would you like us the add something in section 5.1? > -- Section 2.3.1 -- > Does the "serial number" need to be unique per vendor ? I guess so then I > strongly suggest to use a different word than "serial number" > (e.g. unique device ID) as a vendor can have multiple products in its > portfolio, each having a different set of unique "serial numbers". We are leverging the serialNumber attribute from 802.1AR (and RFC5280). Since this is an attribute in a certificate's DN, it's uniqueness is defined by the issuer of the certificate. Different issuer public keys would have different serialNumber namespaces. Since the voucher-request is signed by the IDevID, that value is also within the IDevID issuer's namespace. A vendor that operates different signing authorities for different products could decide to keep it's serialNumbers unique across all products. I would certainly recommend that, but from a technical point of view, unnecessary. > -- Section 3.3 -- > The example 1 does not include the mandatory (per YANG module) > serial-number. > It should also state that the cert is not included for saving space in > this document. I have added serial-number to the example. > -- Section 4.1 -- > There are TWO back-off mechanisms: one for the method and one for the > proxy but > no description on how those mechanisms interact together. The first back-off is for the active methods of discovery. (Those methods are optional, GRASP M_FLOOD is the MTI) The second back-off is for attempts to connect to a specific proxy. I don't see an interaction or an issue. The timers are separate. Maybe you can explain your concern? If we see M_FLOOD messages from a new proxy, then we'd start (immediately) trying that new connection, even if there are TCP half-open connections to via proxies. > -- Section 4.3 -- > Probably a naive question about GRASP (that I do not know), but in the > example there is "IPPROTO_TCP, 80" that seems to indicate the use of > plain HTTP and no TLS at all. Is it an issue ? Yes, I agree that is confusing. It can be 443,, or actually any port that the registrar chooses. Are you okay with 8443 to emphasize that it is arbitrary? > Is there a reason why IPv6 ULA are used rather than the documentation > prefix ? yes, we assume that this communication runs over ANIMA's ANI ACP. The ACP is explicitely numbered in ULAs, and we felt that using a GUA (which the documentation prefix is), would confuse people, particularly security people, into thinking that parts of the protocol run over the open internet. If have considered that we ought to have a documentation ULA prefix, and we could allocate that out of the ULA-"C" space (fc00::/8). > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > == COMMENTS == > -- Section 1 -- > Please introduce the MASA acronym used after. Done. > -- Section 1.1 -- >> the pledge requires realtime connectivity to the manufacturer >> service > Why this connection requires "realtime" ? Esp when reading in section > 1.3.1 "The bootstrapping process can take minutes to complete" realtime as opposed store and forward, via, for instance USB key or email over UUCP. > -- Section 1.2 -- > Please use the RFC 8174 boilerplate. <insert old guy gripping about new-fangled things> > "160-bit SHA-1 hash" I will let the security AD to check whether SHA-1 is > deemed sufficient for this purpose. RFC5280 uses it, and we don't have a common replacement for this (or even a good name for it). It is only used in the audit log to identify previous owners. We could easily add a second hash to the audit log. > - Section 1.5 -- > Please explain/refer GRASP acronym. reference added. > -- Section 2 -- > I wonder what will happen when the device vendor stops maintaining the > MASA on-line? please see flamewar^Wsec-dir review thread last fall :-) https://mailarchive.ietf.org/arch/msg/anima/XCS6JpwQSm3naOivwCYaO0AAsVs We added most of section 10 on this. In particular section 10.5 suggests that a manufacturer could permit the MASA anchors to be replaced and/or augmented. This divorces the device entirely From the manufacturer. An operator that goes this way probably should have source code: but that's no longer unreasonable for many platforms that provide virtualized services. > -- Section 2.2 -- > Out of curiosity, why this document uses the word "voucher" as opposed to > "ticket" ? Not sure, but I'd have argued against ticket because BRSKI/RFC8366 vouchers are significantly less functional than Kerberos tickets. > -- Section 3.4 -- > I find a little weird that the included YANG module has a different > authors list than the document itself. A good point. Steinthor changed jobs before we got fully into the YANG modelling. Kent did most of heavy YANG lifting, so we put him first, but I've sorted the rest alphabetically. > Please refer to RFC 8174. > "RFC YYYY: Voucher Profile for Bootstrapping Protocols" does not seem > correct in a YANG module reference. Fixed. > -- Section 5 -- > The MASA URI synthesis explanation is a duplicate of a previous > explanation. > Unsure whether it helps the reader. We included it in both section 5 and section 2.3.2, because in interop testing, we noticed that implementors of Registrar's often do *not* read the part about MASA operations, and VV, the IDevID certificate authority programmer is unlikely to understand section 5. > -- Section 8.4 -- > I am afraid that the DNS service names have a length of maximum 15 > characters. > But, IANA is of course the source of truth. XXX We have heard from IANA, and they did not complain as yet. > -- Appendix A -- > Using IPv6 LLA should be enough, I do not see the reason to describe a > new protocol using legacy IPv4 addresses because IPV6 link-local > addresses should > work on any decent layer-2 network. XXX: I personally have no objection to ripping out that legacy 1980s crap :-) I was happy to relegate it to a non-normative appendix. I'm gonna let the other authors and WG argue this point. > == NITS == > A lot of "ethernet" and "internet" while those words are usually > capitalized as > "Ethernet" or "Internet". okay, fixed. > -- Abstract -- > Shouldn't the plural form used in "using manufacturer installed X.509 > certificate" ? okay > -- Section 1.5 -- > s/Some of the options in this document is the result of > requirements/Some of > the options in this document are the result of requirements/ ? agreed. > -- Section 2.3.2 -- > Please use uppercase in the protocol acronyms in "that MUST be supported, > including ldap, http and ftp" okay. > .... > -- Section 5.1 -- > "A Pledge that can connect to multiple registries concurrently, SHOULD > do so." > lower case for pledge and what is the purpose of the comma in this > sentence? we had a mania at some point that argued that Pledge was a proper noun. We recovered from it. I think that comma belongs; maybe it SHOULD be a semi-colon. I'm happy to let the copy-editor argue it. I think that it seperates out a qualifying noun phrase. > (ok I am not an English native speaker so I can be wrong) ps: here is a video of the protocol from another non-native English speaker: https://vimeo.com/305041755 -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Anima] Éric Vyncke's Discuss on draft-ietf-anima… Éric Vyncke via Datatracker
- Re: [Anima] Éric Vyncke's Discuss on draft-ietf-a… Michael Richardson
- Re: [Anima] Éric Vyncke's Discuss on draft-ietf-a… Eric Vyncke (evyncke)
- Re: [Anima] Éric Vyncke's Discuss on draft-ietf-a… Michael Richardson
- Re: [Anima] Éric Vyncke's Discuss on draft-ietf-a… Eric Vyncke (evyncke)