From nobody Mon May 1 13:16:55 2017 Return-Path: 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 58F9812EAEF; Mon, 1 May 2017 13:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.803 X-Spam-Level: X-Spam-Status: No, score=-11.803 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 cgE76k0n1OMI; Mon, 1 May 2017 13:16:53 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99B212EAF6; Mon, 1 May 2017 13:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=396; q=dns/txt; s=iport; t=1493669631; x=1494879231; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=XdL7BV9ytoFoxXqPUahxsauhQtHJbU4wwBE0yYiLgjw=; b=c+OD3ZiThx5MA+L1HU8M65PANQlbnhMH3Kh2L7khF1RbN3l5+C9QxJZk RnloaXb3pfaCeSwGMZyt1FHpKX7uzF2VcF7R9OlsFoxdPLiPr+8XTqzhU XGIW1LulpKbcd2PVwGBrtYZHGiuUEWTSWsEgheCdlfuwnJ3/6+oTRdxXu E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AwDllQdZ/4wNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1WBdYNhsVOCD4ZAhCFBFgECAQEBAQEBAWsohT8RVwEiAiYCBDAVCgg?= =?us-ascii?q?EAYoxrjCCJosUAQEBAQEBAQMBAQEBAQEBAQEfgQuHXYckEgGDIi6CMQWdUwGTE?= =?us-ascii?q?IFqAY9zlCwBJgMufwtvFUQSAYZdiACBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,401,1488844800"; d="scan'208";a="243610118" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 May 2017 20:13:51 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v41KDplj016617 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 May 2017 20:13:51 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 1 May 2017 15:13:50 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Mon, 1 May 2017 15:13:50 -0500 From: "Max Pritikin (pritikin)" To: "anima-bootstrap@ietf.org" , "anima@ietf.org" Thread-Topic: max is traveling overseas this week Thread-Index: AQHSwrdyWel8vUzo60yX4++RkyLEdg== Date: Mon, 1 May 2017 20:13:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.7.83] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Anima] max is traveling overseas this week X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 20:16:54 -0000 DQpJIG1vc3QgbGlrZWx5IHdpbGwgYmUgbWlzc2luZyB0aGUgYm9vdHN0cmFwcGluZyBkaXNjdXNz aW9uIHRoaXMgd2Vlay4gSeKAmWxsIHRyeSB0byBqb2luIGFzIHBvc3NpYmxlLg0KDQpJIHNob3Vs ZCBiZSBvbiBlbWFpbCBhbmQgaG9wZSB0byBwdXNoIHNvbWUgZ2l0IHVwZGF0ZXMuDQoNCk15IGFw b2xvZ2llcyBpZiBJIGNhbuKAmXQgam9pbi4gSSB3aWxsIGNoZWNrIHRoZSBldGhlcnBhZCBmb3Ig bm90ZXMgb3IgaG9wZSB0byBzZWUgc29tZXRoaW5nIHBvc3RlZCB0byB0aGUgbGlzdCwNCg0KLSBt YXgg From nobody Mon May 1 19:40:00 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F95F12EB1E; Mon, 1 May 2017 19:39:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Thomson To: Cc: draft-ietf-anima-grasp.all@ietf.org, ietf@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149369279041.9906.5712707340786253297@ietfa.amsl.com> Date: Mon, 01 May 2017 19:39:50 -0700 Archived-At: Subject: [Anima] Artart telechat review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 02:39:50 -0000 Reviewer: Martin Thomson Review result: Not Ready This document describes a generic protocol that is for doing just about anything and run over just about any transport protocol. Within that remit, the document is coherent and though I agree with Barry about unnecessary verbiage, it seems to achieve the goals it sets. I don't believe that this document describes a protocol that could be deployed. Caveat here: I didn't review this as thoroughly as I would have liked. It's a large document, though it's clear that it isn't large enough to cover its intended scope in a couple of key areas. There is with lots of content in some areas - some of it quite detailed. But there is surprisingly little detail in areas that I would have imagined to be critical. The two areas that concern me most are transport and security. The draft talks very little about how messages get to their destinations. There's a brief section on UDP/TCP usage in one place and an admonishment to use DTLS/TLS in another, but those sections don't seem to have ever met each other. I'm forced to conclude that this is well ahead of the other pieces that will fill in those gaps. Given that there are no drafts associated with the ANIMA working group that attempt to fill those gaps, I really don't know how this would ever get deployed. The status of the implementations only really confirms this. As an aside, use of UDP needs a few more details. A few that spring to mind: Congestion - Since this appears to be a lock-step protocol, that is probably acceptable (one packet per round trip is generally considered fine). Loss - This doesn't appear to have any provision for loss recovery. For a long-running negotiation that includes wait steps, this seems necessary. Middleboxes - If a peer has to wait a long time for a negotiation, what happens if the NAT binding goes away in the meantime? How does a peer ensure reachability? Can middleboxes verify that endpoints are willing to communicate? The locators concept relates to this. It would appear to be under-specified, largely as a result of not having any concrete transport definitions. For instance, how would you use each of the different locators used in the protocol? Though it might seem obvious, even the IPv6 locator doesn't actually include a definition of what you might do with it. Does the endpoint construct a UDP packet with the CBOR of a GRASP message as its payload and unicast it to the identified IP and port? Seems obvious, needs writing down. The same goes for the FQDN, which I suppose involves an AAAA/A record lookup. It needs to say that, unless it's really SRV or something else. And URIs aren't generically usable, so a lot more work would be needed to make sense of a URI. Security seems to be critical, but the key question of establishing a trust domain is left out of scope. That conveniently removes some hard problems, but I believe that there were a few inconvenient problems that were removed at the same time. For instance, authentication and confidentiality mechanisms for discovery seem to be non-existent. (D)TLS can't secure a multicast signal, but no effort has been put into providing an authentication framework. Nits The document really isn't clear about how multi-round negotiation works. A picture might help here. I ask because the definition of how timers run is a little unclear. I probably missed the text about this, but I assume that an endpoint that responds to M_REQ_NEG with M_NEGOTIATE starts a new timer, and if a multiple rounds are used the timer is reset each time that M_NEGOTIATE is sent. Is there any need for any overall negotiation timer, or do you just multiply out the hop (loop) count? The existence of "dry run" negotiations leads me to ask how a protocol participant is expected to behave when negotiating. Is it expected to enact intermediate values, or does it commit only when the negotiation concludes? From nobody Tue May 2 01:47:42 2017 Return-Path: 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 0AE4D120454; Tue, 2 May 2017 01:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 NFnFbw-_6Q2N; Tue, 2 May 2017 01:47:32 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40F2113012B; Tue, 2 May 2017 01:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19516; q=dns/txt; s=iport; t=1493714543; x=1494924143; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=t+1aP5UjK8dwihsSBc6tFZawXIMb9KW7qE0H24okSjE=; b=SDj8bi9MzpzicFsJJhSB10KigwCjb5n08+28VgIs5xzlnaKYu3Ef46Vh YvqFIFgiCaZPMOPah+nmvm6YqGsklX0KQRK7qpQCs44HTyvELHcoTzsxx wSIMa9/ZWBHwBBEYP2/T5W/zNwDA3tgsMiZWfb3CXS1Bh/vCpus36Y3N0 k=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.37,404,1488844800"; d="asc'?scan'208,217";a="654397594" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2017 08:42:21 +0000 Received: from [10.61.67.64] (ams3-vpn-dhcp832.cisco.com [10.61.67.64]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v428gK3W021775; Tue, 2 May 2017 08:42:20 GMT To: "Max Pritikin (pritikin)" References: <031d87aa-1839-d7af-0723-dd9a2aa7ad0a@cisco.com> <43DF7C00-FC3B-4327-9EE4-13ED6520E580@cisco.com> Cc: "ibagdona@gmail.com" , Zhoutianran , "opsawg@ietf.org" , Anima WG From: Eliot Lear Message-ID: <9298f306-400b-2c38-bed2-637183f35ea1@cisco.com> Date: Tue, 2 May 2017 10:42:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <43DF7C00-FC3B-4327-9EE4-13ED6520E580@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="D9xHssxQfdkMVHo2VU1eVlv6pAQankivD" Archived-At: Subject: Re: [Anima] dealing with multiple manufacturer services with a single certificate extension X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 08:47:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --D9xHssxQfdkMVHo2VU1eVlv6pAQankivD Content-Type: multipart/mixed; boundary="fpRS2doxiGt0jnIifCVBe65tNHuikOKkU"; protected-headers="v1" From: Eliot Lear To: "Max Pritikin (pritikin)" Cc: "ibagdona@gmail.com" , Zhoutianran , "opsawg@ietf.org" , Anima WG Message-ID: <9298f306-400b-2c38-bed2-637183f35ea1@cisco.com> Subject: Re: [Anima] dealing with multiple manufacturer services with a single certificate extension References: <031d87aa-1839-d7af-0723-dd9a2aa7ad0a@cisco.com> <43DF7C00-FC3B-4327-9EE4-13ED6520E580@cisco.com> In-Reply-To: <43DF7C00-FC3B-4327-9EE4-13ED6520E580@cisco.com> --fpRS2doxiGt0jnIifCVBe65tNHuikOKkU Content-Type: multipart/alternative; boundary="------------3325ACEF3C399300E1D0234B" This is a multi-part message in MIME format. --------------3325ACEF3C399300E1D0234B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Max, On 4/24/17 5:52 PM, Max Pritikin (pritikin) wrote: > > I=E2=80=99ve been agitating for a combined form. My thanks to Eliot for= > continuing the conversation. Below I provide some details from the > current BRSKI draft to flesh out the conversation and then present an > argument for my position. > >> On Apr 23, 2017, at 5:23 AM, Eliot Lear > > wrote: >> >> Hi everyone, >> >> Just a quick update on this document. I am preparing for the next >> version of the draft. There is one major change contemplated that is >> not yet addressed. >> >> I received feedback from the IETF Chicago meeting regarding how best >> to structure URLs in manufacturer certificates. There are currently >> two planned, one for MUD and one for ANIMA/BRSKI. The question is >> whether these should be combined.=20 >> >> I had said in Chicago that I would ask various manufacturers about >> whether additional complexity on the backend is worth saving the >> bytes in the certificate. There was, as you might imagine, a mixed >> response. A number of manufacturers answered, =E2=80=9CNo, and in fac= t we >> want to do our own certificate extensions=E2=80=9D. Others simply ans= wered >> =E2=80=9CNo, the code requirements for ANIMA will probably make the ce= rt >> extension a relatively minimal matter=E2=80=9D. And some manufacturer= s, >> said, =E2=80=9Cyes, every byte counts.=E2=80=9D I am proceeding in a = way that >> accommodates the 3rd group for now, but I seek discussion. >> >> If we combine the URLs the way it would work is that there would be a >> service endpoint along the lines of the following: >> >> * https://example.com/.well-known/mfg/modelname >> > Given that the .well-known concept is already well defined the > approach taken in the BRSKI draft (s2.3) is to include only the > =E2=80=9Cmanufacturer=E2=80=9D authority: > https://example.com > > From here the relying party can use the .well-known constructs to > access any variety of manufacturer services which I expect to include=20 > https://example.com/.well-known/brksi > https://example.com/.well-known/mud > etc > > This minimizes the information stored within the certificate itself. A > single extension indicating the =E2=80=9Cmanufacturer services authorit= y=E2=80=9D. > Building a full URL to these services is done using the .well-known > method. One challenge here is that we need model information present, and you may need it as well to route to the correct BRSKI service (presuming there is more than one for manufacturer example.com). And so we would need to add at least the model back, or otherwise reflect the model in the authority section. I'm not a big fan of requiring that because it requires unnecessary interactions with DNS administration. >> At that point, we would need to deference, introducing some >> additional complexity somewhere in the system. We should be mindful >> of the following issue: >> >> 1. Versioning should be supported OUTSIDE of the referenced >> service. The more that is done, the more freedom the referenced >> service has the ability to change. >> 2. Versioning of services should not be done in lock step. That is, >> if we keep the versioning information in the URL, that means that >> when the MUD version is bumped, so too would the ANIMA version.=20 >> It is possible to keep a registry that would indicate URL >> versioning and then map to all the different versions of whatever >> is referenced, but that seems ridiculously complex. >> 3. The resolution mechanism to services should be independent of how >> the URL is gotten by the various {MUD/ANIMA/...} controllers.=20 >> And thus, if a MUD controller receives the URL via LLDP or DHCP, >> the same processing should occur as if it was received via a >> certificate. This simplifies code paths, and will hence reduce >> risk of bugs. It will also follow the principle of least >> astonishment. >> >> It seems to me the simplest way to handle this sort of thing is to >> create a table that MUD/ANIMA controllers simply download when they >> see the URL. It might look something like this: >> >> { >> "mfg-services" : [=20 >> "mud", "v1", "https://mud.example.com/Frobmaster3000.json", >> "anima", "v1", "https://masa.example.com/masa-service" >> ] >> } > Using a .well-known to query a host about which possible interfaces > are available has precedent. For an alternative example also see, > https://tools.ietf.org/html/rfc6415 > "The client obtains the host-meta document for a given host by sending > an HTTP [RFC2616 ] or an HTTPS [= RFC2818 ] GET request to the host fo= r > the "/.well-known/host-meta=E2=80=9D path [=E2=80=A6]=E2=80=9D > > > I see this as an optional redirection that MUD or BRSKI or future > protocols might define but don=E2=80=99t see it as a necessary part of = the > manufacturing certificate extension definition. I=E2=80=99d think we co= uld > stop at an extension to provide the root authority to form .well-known > URLs. Simpler, smaller, and just as flexible. But more complex, requiring a query as opposed to a straight retrieval, thus requiring additional work on the back end. > =20 > > As a side note using this approach imposes a difficulty on MUD: the > model and serial number information need to be carried elsewhere and > normatively defined - MUD can no longer depend on a distinct URL for > each class of device. So while I see this as an improvement for IETF > as a whole it is problematic for MUD itself and I appreciate the > willingness of the MUD authors to discuss it. At the moment, more manufacturers are coming back to me to say that we should just leave these as separate and distinct mechanisms. I think that's the simplest approach. Eliot --------------3325ACEF3C399300E1D0234B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Max,


On 4/24/17 5:52 PM, Max Pritikin (pritikin) wrote:

I=E2=80=99ve been agitating for a combined form. My= thanks to Eliot for continuing the conversation. Below I provide some details from the current BRSKI draft to flesh out the conversation and then present an argument for my position.

On Apr 23, 2017, at 5:23 AM, Eliot Lear <lear@cisco.com> wrote:

Hi every= one,

Just a quick update on this document.=C2=A0 I am preparing = for the next version of the draft.=C2=A0 There is one major cha= nge contemplated that is not yet addressed.

I received feedback from the IETF Chicago meeting regarding how best to structure URLs in manufacturer certificates.=C2=A0 There are currently two planned, one for MUD and one for ANIMA/BRSKI.=C2=A0 The question is whether these should be combined.=C2=A0

I had said in Chicago that I would ask variou= s manufacturers about whether additional complexity on the backend is worth saving the bytes in the certificate.=C2=A0= There was, as you might imagine, a mixed response.=C2=A0 = A number of manufacturers answered, =E2=80=9CNo, and in fac= t we want to do our own certificate extensions=E2=80=9D.=C2=A0= Others simply answered =E2=80=9CNo, the code requirements for AN= IMA will probably make the cert extension a relatively minimal matter=E2=80=9D.=C2=A0 And some manufacturers, sa= id, =E2=80=9Cyes, every byte counts.=E2=80=9D=C2=A0 I am proceeding in a wa= y that accommodates the 3rd group for now, but I seek discussion.

If we combine the URLs the way it would work is that there would be a service endpoint along the lines of the following:

Given that the .well-known concept is already well defined the approach taken in the BRSKI draft (s2.3) is to include only the =E2=80=9Cmanufacturer=E2=80=9D authority:

From here the relying party can use the .well-known constructs to access any variety of manufacturer services which I expect to include=C2=A0
etc

This minimizes the information stored within the certificate itself. A single extension indicating the =E2=80=9Cmanufacturer services authority=E2=80=9D. Building a f= ull URL to these services is done using the .well-known method.

One challenge here is that we need model information present, and you may need it as well to route to the correct BRSKI service (presuming there is more than one for manufacturer example.com).=C2=A0= And so we would need to add at least the model back, or otherwise reflect the model in the authority section.=C2=A0 I'm not a big fan o= f requiring that because it requires unnecessary interactions with DNS administration.

At that point, we would need to deference, introducing some additional complexity somewhere in the system.=C2=A0 W= e should be mindful of the following issue:
  1. Versioning should be supported OUTSIDE of the referenced service.=C2=A0 The more that is done, th= e more freedom the referenced service has the ability to change.
  2. Versioning of services should not be done in lock step.=C2=A0 That is, if we keep the versioning information in the URL, that means that when the MUD version is bumped, so too would the ANIMA version.=C2=A0= It is possible to keep a registry that would indicate URL versioning and then map to all the different versions of whatever is referenced, but that seems ridiculously complex.
  3. The resolution mechanism to services shoul= d be independent of how the URL is gotten by the various {MUD/ANIMA/...} controllers.=C2=A0 And thus, if a MUD controller receives the URL via LLDP or DHCP, the same processing should occur as if it was received via a certificate.=C2=A0 This simplifies code paths, and will= hence reduce risk of bugs.=C2=A0 It will also follow th= e principle of least astonishment.

It seems to me the simplest way to handle thi= s sort of thing is to create a table that MUD/ANIMA controllers simply download when they see the URL.=C2=A0 = It might look something like this:

{
   "mfg-services" : [=20
     "mud", "v1", "https://mud.ex=
ample.com/Frobmaster3000.json",
     "anima", "v1", "https://masa.examp=
le.com/masa-service"
   ]
}
Using a .well-known to query a host about which possible interfaces are available has precedent. For an alternative example also see,
"The client obtains the host-meta document for a given host by sending
  	an HTTP [RFC2616] or an HTTPS [RFC2818] GET request to the host for
   	the "=
/.well-known/host-meta=E2=80=9D path [=E2=80=A6]=E2=80=9D


I see this as an optional redirection that MUD or BRSKI or future protocols might define but don=E2=80=99t see it as a nec= essary part of the manufacturing certificate extension definition. I=E2=80=99d think we could stop at an extension to provide the = root authority to form .well-known URLs. Simpler, smaller, and just as flexible.

But more complex, requiring a query as opposed to a straight retrieval, thus requiring additional work on the back end.

=C2=A0

As a side note using this approach imposes a difficulty on MUD: the model and serial number information need to be carried elsewhere and normatively defined - MUD can no longer depend on a distinct URL for each class of device. So while I see this as an improvement for IETF as a whole it is problematic for MUD itself and I appreciate the willingness of the MUD authors to discuss it.

At the moment, more manufacturers are coming back to me to say that we should just leave these as separate and distinct mechanisms.=C2=A0= I think that's the simplest approach.

Eliot
--------------3325ACEF3C399300E1D0234B-- --fpRS2doxiGt0jnIifCVBe65tNHuikOKkU-- --D9xHssxQfdkMVHo2VU1eVlv6pAQankivD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZCEZsAAoJEIe2a0bZ0nozxSYH/RwyczWZw/ICrtYbjNLUXzYg kbCRBiRNQy2RR1X0YbMCvizmV1AujwIgnPY5tCQdjzkJJ4RFneK/vtL5B7XzudTr EglRR+h0WdtYV/yOwEhkW8mLPr6ikBTyhgGfAEL09rpwqgMy/3rnvbqaD53eBoCO fYhYpZwEbBj3K8oaHGp8EjTbhawVCjfL3ZjQ7/WDVkW82XfEb3AZI5yacldm0/WY ylUNeNaEaMsaHbtvzP36OrAw2iKY4eRCqa7mJGgGrry4jhCfSNuQgjR984wPW6AW M2ABE3xwxYw8fEmGMcyhru7E95wmOCzyhTBC4HxOfmG3ccJPTPZSDIVGiQMajWA= =ztbf -----END PGP SIGNATURE----- --D9xHssxQfdkMVHo2VU1eVlv6pAQankivD-- From nobody Tue May 2 14:08:49 2017 Return-Path: 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 2682C1289B0; Tue, 2 May 2017 14:08:42 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBJ7hCx3pdd2; Tue, 2 May 2017 14:08:39 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 06FD8128959; Tue, 2 May 2017 14:06:11 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id v14so957528pfd.3; Tue, 02 May 2017 14:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:cc:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=BW7kPzJkKzetlFKZMIRRbKCWLdwXQnLfOglxiiLiJUw=; b=k6zC21As9ze/epxI8UAchpKhOhOo4sdi2nB2RAtA3TNsmeMHgs1nSQbsGRZogvpSvp J6zO1V01voKS6xODEZVzWnfZHVl0IrYgiuoYERDR4d4W3DAhkfwU1xsLZXkTgO8xFt0D LDbUJ2otl69CDVT4cxT2OirrVWT3zmXSEnlcLmH7WPUqBBsyw9oVDhxMxE+IM9aALDRZ 1+UPAsRg3qn563DKVySm4wjdSo6QQjD0o6BKp9hfNBX1hwQap/7/cbqBIWW6M2vmHBcx RjeLtnuaYM+XQ5Z/P+PhYeVvKjwk/HDZmoqVXiFTYGb8haV31ioefzolkV5Uy2Ya63KD 8ygA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=BW7kPzJkKzetlFKZMIRRbKCWLdwXQnLfOglxiiLiJUw=; b=cfEG0Q1jwyCQOCksFEeRK89q9IFm7/vRV9tL0a8eDQaMl4OlyqKFqj/4aK4+dFqKVs 8Gbj9qS/x071IXJsIMxJ9PKo+H1i5knF6acwAMACoc4IKqDWily+kcqHbpAlNO7W1GGX qvlYsOy74iHiha7/iGCUduUCj7nnAgMo3pcVy41q0ZpFvhuwd5rQ8EWL1DiEf3orpAiH mXcsXK42czpzMdRJqD41GZm+VLQCbnKY9QGX8iRTtnZD1Dtoa/3hv8547SiKkwR+93F7 en1Cz9zfYUM1H0hn5/CLKJx0pygMsFGywflS07em76tX8nnqwcLJ/qoUwlgDyF5rb//b H4eQ== X-Gm-Message-State: AN3rC/5y2f1pAyEypIzcIbCsGuTfV4LsZdFItXtGgGMypcX0yEJH6yvW 8mqO6kZeGTIhBE8O X-Received: by 10.98.64.69 with SMTP id n66mr1054865pfa.211.1493759170263; Tue, 02 May 2017 14:06:10 -0700 (PDT) Received: from ?IPv6:2406:e001:3a49:1:28cc:dc4c:9703:6781? ([2406:e001:3a49:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g66sm583257pfj.11.2017.05.02.14.06.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 14:06:09 -0700 (PDT) From: Brian E Carpenter To: Martin Thomson , art@ietf.org References: <149369279041.9906.5712707340786253297@ietfa.amsl.com> Cc: draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org Organization: University of Auckland Message-ID: Date: Wed, 3 May 2017 09:06:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149369279041.9906.5712707340786253297@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Artart telechat review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 21:08:42 -0000 (IETF list removed from CCs. Nothing secret here, it just seems unnecessary to fill several thousand inboxes with this...) Thanks for the review, Martin. Responses below: On 02/05/2017 14:39, Martin Thomson wrote: > Reviewer: Martin Thomson > Review result: Not Ready > > This document describes a generic protocol that is for doing just > about anything and run over just about any transport protocol. Within > that remit, the document is coherent and though I agree with Barry > about unnecessary verbiage, it seems to achieve the goals it sets. > > I don't believe that this document describes a protocol that could be > deployed. Obviously, the WG disagrees, so I will try to see below where the discrepancy lies. In a few places I've marked points where IMHO a text change is needed by ***. But generally I hope the issue is just that it's a long, complex document. > Caveat here: I didn't review this as thoroughly as I would have liked. > It's a large document, Yes. If we could have made it shorter, we would have :-( > though it's clear that it isn't large enough > to cover its intended scope in a couple of key areas. There is with > lots of content in some areas - some of it quite detailed. But there > is surprisingly little detail in areas that I would have imagined to > be critical. The two areas that concern me most are transport and > security. Security as such is simply out of scope. This protocol does not secure itself. I thought that was very clearly stated, e.g. https://tools.ietf.org/html/draft-ietf-anima-grasp-11#page-14 The main references for external security are https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane which are indeed normative dependencies. > The draft talks very little about how messages get to their > destinations. There's a brief section on UDP/TCP usage in one place > and an admonishment to use DTLS/TLS in another, but those sections > don't seem to have ever met each other. I'm forced to conclude that > this is well ahead of the other pieces that will fill in those gaps. This puzzles me, because https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.3 says: >> GRASP discovery and flooding messages are designed for use over link- >> local multicast UDP. They MUST NOT be fragmented, and therefore MUST >> NOT exceed the link MTU size. >> >> All other GRASP messages are unicast and could in principle run over >> any transport protocol. An implementation MUST support use of TCP. >> It MAY support use of another transport protocol. However, GRASP >> itself does not provide for error detection or retransmission. Use >> of an unreliable transport protocol is therefore NOT RECOMMENDED. What more do we need to say in general? See below, where we do say more for sepcific message types. > Given that there are no drafts associated with the ANIMA working group > that attempt to fill those gaps, I really don't know how this would > ever get deployed. The status of the implementations only really > confirms this. Actually we sent packets from a more recent version of the BUPT implementation to the Python implementation in Chicago, but it revealed problems with the BUPT code that couldn't be fixed during the week. But it did verify that they could send CBOR and we could receive it; just the wrong CBOR ;-). > As an aside, use of UDP needs a few more details. Why? It's NOT RECOMMENDED except for the link-local multicasts. You're correct that *if* we recommended UDP for the unicast messages, we'd need more details. In fact, I did make a start on changing my prototype to do that, and decided that it was a complex matter and not worth the effort. You give some of the reasons below, and I think there are others. If we wanted to change this to a recommended approach, it would very likely need a separate document. Basically, having to cope with any number of simultaneous overlapping UDP sessions requires a lot of mechanism, all of which comes for free with SOCK_STREAM. > A few that spring to mind: > > Congestion - Since this appears to be a lock-step protocol, that is > probably acceptable (one packet per round trip is generally considered > fine). > > Loss - This doesn't appear to have any provision for loss recovery. > For a long-running negotiation that includes wait steps, this seems > necessary. True, but the GRASP timeout mechanism would kick in - the session would fail. An ASA has to be designed to recover from failure anyway. However, in an overloaded network we want the autonomic solution to work even when everything else is broken, which is IMHO a good argument against UDP. > Middleboxes - If a peer has to wait a long time for a negotiation, > what happens if the NAT binding goes away in the meantime? How does a > peer ensure reachability? Can middleboxes verify that endpoints are > willing to communicate? The ACP is transparent, and we definitely recommend IPv6 anyway, so NATs are out of scope. That's stated as a note at https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.9.5 *** It should be stated more prominently, however, probably in https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.2 > The locators concept relates to this. It would appear to be > under-specified, largely as a result of not having any concrete > transport definitions. For instance, how would you use each of the > different locators used in the protocol? Though it might seem > obvious, even the IPv6 locator doesn't actually include a definition > of what you might do with it. > > Does the endpoint construct a UDP packet with the CBOR of a GRASP > message as its payload and unicast it to the identified IP and port? > Seems obvious, needs writing down. UDP for multicast, TCP for unicast, but yes. We are explicit at several points, for example https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.2 for discovery messages, https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.2 for discovery responses, https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.6 for request messages. https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.6 for flood messages. We aren't explicit for the other unicast messages because they are direct replies within a TCP connection, so it truly seems obvious. > The same goes for the FQDN, which I suppose involves an AAAA/A record > lookup. It needs to say that, unless it's really SRV or something > else. And URIs aren't generically usable, so a lot more work would be > needed to make sense of a URI. We do in fact say something about them in https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.6 but I agree it is a bit wrong. FQDNs are clear enough, but URI usage would definitely depend on the use case. We still want to define them as a locator type, because somebody is certain to define such a use case. *** So that does need a change to the text, leaving the usage of URIs explicitly for future work. > Security seems to be critical, but the key question of establishing a > trust domain is left out of scope. That conveniently removes some > hard problems, but I believe that there were a few inconvenient > problems that were removed at the same time. For instance, > authentication and confidentiality mechanisms for discovery seem to be > non-existent. (D)TLS can't secure a multicast signal, but no effort > has been put into providing an authentication framework. As above, that whole issue is covered in the Anima secure bootstrap work and the autonomic control plane. Since they are normative dependencies, the GRASP RFC cannot appear without them. > Nits > > The document really isn't clear about how multi-round negotiation > works. A picture might help here. I ask because the definition of > how timers run is a little unclear. I probably missed the text about > this, but I assume that an endpoint that responds to M_REQ_NEG with > M_NEGOTIATE starts a new timer, and if a multiple rounds are used the > timer is reset each time that M_NEGOTIATE is sent. Is there any need > for any overall negotiation timer, or do you just multiply out the hop > (loop) count? Firstly, the sample message exchanges in Appendix D, especially https://tools.ietf.org/html/draft-ietf-anima-grasp-11#appendix-D.5 were intended to help on this point. IMHO, ASCII art wouldn't add much. https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.5 explains how timeouts work for initial negotiation requests. But we have cunningly hidden the explanation of timeout for the whole negotiation in https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.6 : When an initiator sends a Request Negotiation message, it MUST initialize a negotiation timer for the new negotiation thread. The default is GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is modified by a Confirm Waiting message (Section 3.8.9), the initiator will consider that the negotiation has failed when the timer expires. *** At the minimum, we need a forward reference to that in section 3.5.5. (Of course the actual timeout values are local, so they don't appear in the protocol, but they do appear in the API, which is not a WG item at present: draft-liu-anima-grasp-api) > The existence of "dry run" negotiations leads me to ask how a protocol > participant is expected to behave when negotiating. Is it expected to > enact intermediate values, or does it commit only when the negotiation > concludes? That depends on the semantics of the individual objective; including the flag in the protocol is a sort of convenience function. We should cover this point somewhere; there's another non-WG draft where that probably belongs (draft-carpenter-anima-asa-guidelines). We do say this in https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.10.4 : An issue requiring particular attention is that GRASP itself is a stateless protocol. Any state associated with a dry run operation, such as temporarily reserving a resource for subsequent use in a live run, is entirely a matter for the designer of the ASA concerned. Personally I imagine that an ASA would mark a resource as 'reserved' during a dry-run negotiation but only commit it when a live negotiation ensues. But we don't want to over-specify before there is some experience with writing full scale ASAs. Hope all this helps, Brian From nobody Tue May 2 17:49:28 2017 Return-Path: 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 0920E12945F; Tue, 2 May 2017 17:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqyhMwzdw6in; Tue, 2 May 2017 17:49:19 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 3A5C6129A9B; Tue, 2 May 2017 17:47:03 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id w64so130144632wma.0; Tue, 02 May 2017 17:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=llwzcNFmyBOYNxJJP8KwFkfAk298i29eZLUaqK1RC5Q=; b=WmBHZS5sh83NBokK9jQK+WlQwTTbAXhuZ7K656FXTVb9HG8YZGlDd4SFnxRdoTzTCv RVdh6LAmfItEkYYY933eM2UpNSg/BntMf7NnA4SOE5CYvY4Vj7gyao1ken4iCoS2JRUq BBnria2fJWhlU2Sxct5VoPeI2QHewsSdRHqLN7s+yW2zoV4Y73eDWjo3s7cNyGK2KVlj rTErMKFcU/+7BaB7I8yXmNOAcmnupmacefJLsC0MWoEohzEslLkJrvQYSdvx5odNGetF 9CMpckem9ENYtqgFp4z3+NqTa64SNEUL7BfHNfpQ1SGdgRC0i7KQdoBva+NMj6l2rmFU gaVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=llwzcNFmyBOYNxJJP8KwFkfAk298i29eZLUaqK1RC5Q=; b=kcRM867IYYcInEb6MLTMQMFJXsW6EoXdgI6bR4k0AHuE3PTmhzSlu+5vwUeEns0EPp 98UfMj2BwZ5dyKMXeCquuCY0EH7c/Rro/q6reTTyMBgPJA2dtg0zFWiAXa/tj8j1YXA7 Ou1imhJN/GXBOsMiWb4U/teBrq3da5CnhTVcNkv1goU6nZPakZIyjNGPhFZYcobIPrzs ukFWpBS2z5DNm+IEMDjihRDYisVbxtQUIe4/8k+cnTtfUh2BA5um8gVj7pyGdGgYThB9 CXO5MaCZQn5Ya16mxRq/XXGqwQSXPKg3n7TGhgG+0fGQqhZJtvFdzwK2rWcv0+QUU0x1 +CkA== X-Gm-Message-State: AN3rC/4xLq4Vb3bGIVVSPzSO3j+/6ea88o9gg4MHBAkShtzRZsBdB+To 1kiQo2nzp9uB76ZNKVSO3Nh/RzgU6Q== X-Received: by 10.25.212.19 with SMTP id l19mr10655956lfg.169.1493772421637; Tue, 02 May 2017 17:47:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Tue, 2 May 2017 17:47:01 -0700 (PDT) In-Reply-To: References: <149369279041.9906.5712707340786253297@ietfa.amsl.com> From: Martin Thomson Date: Wed, 3 May 2017 10:47:01 +1000 Message-ID: To: Brian E Carpenter Cc: ART Area , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Anima] Artart telechat review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 00:49:22 -0000 Thanks for the replies Brian, It seems like I missed the transport stuff entirely. I'd selfishly and sheepishly suggest making that text more precise, but I will respect your editorial discretion. I remain deeply concerned about the security parts. At a minimum, the protocol needs a clear definition of how authentication and confidentiality mechanisms are used, even if the process by which keys and so forth are established is left to other work. In part, that's easy, all the unicast stuff can use TLS and you can wave your hands about how trust anchors get around. However, given that this traverses the Internet, I am going to suggest that not having confidentiality for the general discovery case is unwise and not having authentication for the same seems like a real deal-breaker. On 3 May 2017 at 07:06, Brian E Carpenter wrote: > (IETF list removed from CCs. Nothing secret here, it just seems > unnecessary to fill several thousand inboxes with this...) Yeah, the tool added that. That might have been an unwise choice. (Alexey?) > Security as such is simply out of scope. This protocol does not > secure itself. I thought that was very clearly stated, e.g. > https://tools.ietf.org/html/draft-ietf-anima-grasp-11#page-14 > > The main references for external security are > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra > https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane > which are indeed normative dependencies. Both are informative. >> The draft talks very little about how messages get to their >> destinations. There's a brief section on UDP/TCP usage in one place >> and an admonishment to use DTLS/TLS in another, but those sections >> don't seem to have ever met each other. I'm forced to conclude that >> this is well ahead of the other pieces that will fill in those gaps. > > This puzzles me, because > https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.3 > says: > >>> GRASP discovery and flooding messages are designed for use over link- >>> local multicast UDP. They MUST NOT be fragmented, and therefore MUST >>> NOT exceed the link MTU size. >>> >>> All other GRASP messages are unicast and could in principle run over >>> any transport protocol. An implementation MUST support use of TCP. >>> It MAY support use of another transport protocol. However, GRASP >>> itself does not provide for error detection or retransmission. Use >>> of an unreliable transport protocol is therefore NOT RECOMMENDED. > > What more do we need to say in general? See below, where we do say more > for sepcific message types. OK, that isn't as imperative as I am used to. "designed for" isn't the same as "are sent using". And the leading sentence of the second paragraph does a great job of obfuscating things. There are still a couple of pieces missing. I assume that you create a CBOR serialization of the message and put those end to end on a TCP socket; or you create a CBOR serialization of the message and put that in a UDP datagram. Saying that would genuinely help, even if it seems even absurdly obvious. (Caveat: I would naturally ask where TLS fits in when you do this...) >> Security seems to be critical, but the key question of establishing a >> trust domain is left out of scope. That conveniently removes some >> hard problems, but I believe that there were a few inconvenient >> problems that were removed at the same time. For instance, >> authentication and confidentiality mechanisms for discovery seem to be >> non-existent. (D)TLS can't secure a multicast signal, but no effort >> has been put into providing an authentication framework. > > As above, that whole issue is covered in the Anima secure bootstrap > work and the autonomic control plane. Since they are normative > dependencies, the GRASP RFC cannot appear without them. See above. >> Nits >> >> The document really isn't clear about how multi-round negotiation >> works. A picture might help here. I ask because the definition of >> how timers run is a little unclear. I probably missed the text about >> this, but I assume that an endpoint that responds to M_REQ_NEG with >> M_NEGOTIATE starts a new timer, and if a multiple rounds are used the >> timer is reset each time that M_NEGOTIATE is sent. Is there any need >> for any overall negotiation timer, or do you just multiply out the hop >> (loop) count? > > Firstly, the sample message exchanges in Appendix D, especially > https://tools.ietf.org/html/draft-ietf-anima-grasp-11#appendix-D.5 > were intended to help on this point. IMHO, ASCII art wouldn't > add much. That's up to you, I'm just trying to help. > https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.5 > explains how timeouts work for initial negotiation requests. But we > have cunningly hidden the explanation of timeout for the whole > negotiation in > https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.6 : > > When an initiator sends a Request Negotiation message, it MUST > initialize a negotiation timer for the new negotiation thread. The > default is GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is > modified by a Confirm Waiting message (Section 3.8.9), the initiator > will consider that the negotiation has failed when the timer expires. > > *** At the minimum, we need a forward reference to that in section 3.5.5. So my understanding is that the timeout runs for the entire multi-message exchange? That seems unfortunate because it can't then be based on the observed RTT. From nobody Tue May 2 18:25:49 2017 Return-Path: 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 2418312EAE9; Tue, 2 May 2017 18:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20GpvlPZ4hWT; Tue, 2 May 2017 18:25:39 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0110.outbound.protection.outlook.com [104.47.40.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93261296CD; Tue, 2 May 2017 18:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IeqaVuEOinmfk/GqhoGctzLReSmJUW8jz1yED2kjsSU=; b=fDCbS3mFi0l6Nu7IXT5LnTtT1I4KrCPXzCAbvtGANPzla4zjG2AczbpsoonmPKP0S1Px1S0QK3g+ogUTP+Wgs/t5VTk5lN6VL7Cnj5UrrpvhQO2E68yj1FqxmyQ5SNt3GxSFA/Ve0I0jo34zST+VuFbDXkZF8imBtn5qi1g/Gyk= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Wed, 3 May 2017 01:22:57 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1075.010; Wed, 3 May 2017 01:22:58 +0000 From: Kent Watsen To: "Max Pritikin (pritikin)" , "anima@ietf.org" CC: "anima-bootstrap@ietf.org" Thread-Topic: [Anima-bootstrap] Voucher signing method Thread-Index: AQHSw6vLF2XUnWVoW0q/VYcsqILMZg== Date: Wed, 3 May 2017 01:22:57 +0000 Message-ID: <88FB0F4F-2816-4BCE-A775-EBEE1CFCC0CD@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:SDvTH7DHWAWgWaUteYaVjCysAyjwTXJ4Dc09ae2nSf5F1IF1Gxcs5D+2kD2tMoI+Lpdgshvp9WjGR7tWpcdfbYyGW2chS1bwYdIWzxLiuLWgaYz+5du2VIwmH7rFL9jH6rsz6tmFZFgQUs5BVa/3Ykv98OwvLj0Eyvgfuof5N4iVvZivHjiGT7K/w5N/bt6hf7wCfADaPcuXYJRsEO/q1ucVxkd5CWab9Mq4B5IN8HLmi2SeuWuUh0+JWhMy25GAXXyATvhR3nukUFsMeiz4XeUcDvW5v3hD/awXPqKJvyFRB21BPoLV9GECG39iMsz2BZdLa3SBgVtu0R5vWUu1xg== x-ms-office365-filtering-correlation-id: b4fa0524-0c4c-43a9-8ee1-08d491c2eead x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39860400002)(39840400002)(39450400003)(99286003)(6306002)(6246003)(38730400002)(53946003)(53936002)(54356999)(25786009)(50986999)(6512007)(4326008)(2900100001)(189998001)(86362001)(6486002)(77096006)(305945005)(6506006)(6436002)(4001350100001)(8936002)(122556002)(66066001)(83506001)(36756003)(2906002)(6116002)(8676002)(5660300001)(3846002)(82746002)(102836003)(81166006)(229853002)(575784001)(3660700001)(478600001)(2501003)(3280700002)(33656002)(83716003)(579004)(473944003)(414714003)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <569B29BC7E9EA0489F7CDC93118EFD97@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2017 01:22:57.7929 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Subject: Re: [Anima] [Anima-bootstrap] Voucher signing method X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 01:25:42 -0000 DQpJJ3ZlIGhhZCBzb21lIHRpbWUgbm93IHRvIGludmVzdGlnYXRlIEpXUywgaW4gcGFydGljdWxh ciwgcmVwcm9kdWNpbmcgc29tZSBleGFtcGxlcyBpbiBSRkNzIDc1MTUgYW5kIDc1MjAgdXNpbmcg bm90aGluZyBidXQgc2hlbGwgc2NyaXB0cyBhbmQgdGhlIGBvcGVuc3NsYCBjb21tYW5kIGxpbmUg dXRpbGl0eS4NCg0KSSB3YW50IHRvIGxpa2UgSldTLCBidXQgSSB3aXNoIHRoZSBoZWFkZXIgd2Fz IGluIGEgbW9yZSB0ZWNobm9sb2d5LW5ldXRyYWwgZm9ybWF0LCBpdCBiZWluZyBKU09OIHNlZW1z IHdlaXJkIHRvIG1lLiAgSGFkIHRoaXMgYmVlbiBkb25lLCBpdCB3b3VsZCBiZSBhIG5pY2UgZ2Vu ZXJhbC1wdXJwb3NlIHNpZ25hdHVyZSBmb3JtYXQuICBTaXplIHdpc2UsIEpXUyBncm93cyB0aGUg c2l6ZSBvZiB0aGUgZGF0YSAzMyUgd2hlbiBiNjQgZW5jb2RpbmcgaXQgZm9yIHRoZSAiY29tcGFj dCBzZXJpYWxpemF0aW9uIiBmb3JtLCB3aGljaCBpcyBhY3R1YWxseSBhIDY1LWNoYXJhY3RlciBh bHBoYWJldCBpbmNsdWRpbmcgJy4nLiAgSXQgc2VlbXMgdGhhdCBhIGJpbmFyeSBoZWFkZXIgY291 bGQndmUgYWxzbyBhbGxvd2VkIGZvciBhIGJpbmFyeSBwYXlsb2FkIGFuZCBzaWduYXR1cmUsIHdo aWNoIHdvdWxkJ3ZlIGJlZW4gcGVyZmVjdCwgaW4gbXkgb3Bpbmlvbi4gIFtPZiBjb3Vyc2UsIHRo ZSBlbnRpcmUgYmluYXJ5IGJsb2IgY291bGQgc3RpbGwgYmUgYmFzZTY0dXJsLWVuY29kZWQgZm9y IHRob3NlIHRoYXQgd2FudCBpdCwgd2l0aG91dCBmb3JjaW5nIGl0IG9uIHRob3NlIHRoYXQgZG9u 4oCZdF0NCg0KVGhlIGV4YW1wbGUgdm91Y2hlciB5b3Ugb2J0YWluZWQgZnJvbSBtY3Igd2Fzbid0 IGFzIHRyaW1tZWQgZG93biBhcyBpdCBjb3VsZCd2ZSBiZWVuLCB1c2luZyB0aGUgLW5vYXR0ciBh bmQgLW5vY2VydCBvcHRpb25zLCB3aGljaCBpcyBvbmUgcmVhc29uIHRoZSBhc24xcGFyc2UgZHVt cCBsb29rcyBhcyBidXN5IGFzIGl0IGRvZXMuICBBbm90aGVyIGJlaW5nIHRoYXQgdGhlIG93bmVy L2RvbWFpbi1jZXJ0LXRydXN0ZWQtY2EgZW5jb2RlIHZlcnkgZGlmZmVyZW50IGNlcnRzIChpcyBv bmUgZWMgd2hpbGUgdGhlIG90aGVyIGlzIHJzYT8pDQoNCkluIHRoZSBlbmQsIEpXUyBhcHBlYXJz IHRvIGJlIGp1c3QgYW5vdGhlciBzaWduYXR1cmUgZm9ybWF0IHdpdGggaXRzIG93biBzZXQgb2Yg cGVjdWxpYXJpdGllcy4gIEFuZCBnaXZlbiB0aGF0IHdlIGFscmVhZHkgaGF2ZSB0byBzdXBwb3J0 IEFTTi4xICh0aGUgdm91Y2hlciBlbmNvZGVzIGJvdGggYW4gWC41MDkgY2VydCBhcyB3ZWxsIGFz IGEgWC41MDkgY2VydGlmaWNhdGUgY2hhaW4pLCBub3QgdG8gbWVudGlvbiB0aGUgbmVlZCBmb3Ig dGhlIE1BU0EgdG8gaGF2ZSBhIFBLSVggaW5mcmFzdHJ1Y3R1cmUsIGl0J3Mgbm90IGNsZWFyIHRv IG1lIGlmIHRoaXMgaXMgYSBnb29kIHRyYWRlIGF0IGFsbC4NCg0KTGFzdGx5LCBhcyBtZW50aW9u ZWQgYmVmb3JlLCBteSBuZXRjb25mIHplcm90b3VjaCBkcmFmdCB1c2VzIENNUy9QS0NTNyBlbHNl d2hlcmUuICBXaGlsZSBpdCB3b3VsZCBiZSB0cml2aWFsIHRvIHVwZGF0ZSB0aGUgZHJhZnQgdG8g dXNlIGEgSldTLWJhc2VkIGZvcm1hdCwgaXQgd291bGQgYmUgYXdrd2FyZCBmb3IgY2xpZW50cyB0 byBoYXZlIHRvIGNvbnNpZGVyIGl0IGF0IGFsbC4NCg0KS2VudA0KDQoNCi0tLS0tT1JJR0lOQUwg TUVTU0FHRS0tLS0tDQoNCkZvbGtzLCBpbiBDaGljYWdvIHdlIGRpc2N1c3NlZCB0aGUgc2lnbmlu ZyBtZXRob2QgZm9yIHZvdWNoZXJzLiANCg0KQmVjYXVzZSB0aGUgdm91Y2hlciBpcyBKU09OLCBh bmQgdGhlcmUgaXMgZXhwZWN0YXRpb24gb2YgYSBDQk9SIGVuY29kaW5nIGZvciBmdXR1cmUgd29y aywgdGhlcmUgaXMgYW4gb3BlbiBkaXNjdXNzaW9uIHBvaW50IGFib3V0IHVzaW5nIHRoZSBKV1Mv Q09TRSBzaWduaW5nIG1ldGhvZHM7IGlmIG5vdCBKV1QvQ1dULiBUaGVyZSB3YXMgYnJpZWYgZGlz Y3Vzc2lvbiBvZiB0aGlzIGF0IElFVEY5OCBhbmQgb25lIHBlcnNvbiBpbmRpY2F0ZWQgdGhleSBs aWtlZCBQS0NTNywgb3RoZXJzIGluZGljYXRlcyBKV1QgYW5kIG90aGVycyBkaWQgbm90IHNwZWFr IHVwLiBGdWxseSBtZWV0aW5nIG1pbnV0ZXMgbWlnaHQgcHJvdmlkZSBtb3JlIGluZm9ybWF0aW9u IGJ1dCBteSByZWNvbGxlY3Rpb24gd2FzIHRoYXQgd2XigJlkIG1vdmUgdGhlIGRpc2N1c3Npb24g dG8gdGhlIGxpc3QuIFRoaXMgdGhyZWFkIGlzIGZvciB0aGF0IGRpc2N1c3Npb24uIA0KDQpUaGUg Y3VycmVudCB0ZXh0IG9mIGRyYWZ0LWlldGYtYW5pbWEtdm91Y2hlci0wMiBpczoNCg0KPiBUaGUg dm91Y2hlciBpcyBzaWduZWQgYSBQS0NTIzcgU2lnbmVkRGF0YSBzdHJ1Y3R1cmUsIGFzIHNwZWNp ZmllZCBieSBTZWN0aW9uIDkuMQ0KPiBvZiBbUkZDMjMxNV0sIGVuY29kZWQgdXNpbmcgQVNOLjEg ZGlzdGluZ3Vpc2hlZCBlbmNvZGluZyBydWxlcyAoREVSKSwgYXMgc3BlY2lmaWVkIGluIElUVS1U IFguNjkwLg0KDQoNCkZvciBjb25jcmV0ZSBkaXNjdXNzaW9uLCB0aGUgcHJvcG9zZWQgY2hhbmdl IGlzOg0KDQo+IFRoZSB2b3VjaGVyIGlzIGEgSldUIFtSRkM3NTE5XSBzaWduZWQgdG9rZW4uDQoN Cg0KSeKAmXZlIHVwZGF0ZWQgbXkgdG9vbGluZyB0aGF0IHdhcyB1c2VkIGR1cmluZyB0aGUgSUVU Rjk4IGhhY2thdGhvbiB0byBzdXBwb3J0IGEgSldUIHRva2VuIGZvcm1hdDsgSSBkaWQgdGhpcyBh cyBob21ld29yayB0byBiZSBpbmZvcm1lZCBmb3IgdGhlIGRpc2N1c3Npb24uIA0KDQpNWSBQT1NJ VElPTjogaXMgdGhhdCBJIGFwcHJlY2lhdGUgdGhlIHNpbXBsaWNpdHkgb2YgdGhlIEpXUyBzaWdu aW5nIGFuZCBmZWVsIGl0IGlzIGEgZ29vZCBtYXRjaCBmb3IgdXMuIEl0IHdhcyBlYXN5IGVub3Vn aCB0byBpbXBsZW1lbnQsIHdhcyBhIHJlZnJlc2hpbmcgY2hhbmdlIGZyb20gdGhlIEFTTjEgY29t cGxleGl0eSBvZiBQS0NTNywgYW5kIHNlZW1zIHRvIHByb3ZpZGUgYSBnb29kIHBhdGggdG93YXJk IENCT1IvQ09TRSBpbiBhIGZ1dHVyZSBkb2N1bWVudCB3aXRob3V0IG1haW50YWluaW5nIFBLQ1M3 L0NNUyB0ZWNobmljYWwgZGVidCBvciByZXZpc2l0aW5nL3Jld3JpdGluZyB0b28gbXVjaC4gDQoN ClFVRVNUSU9OIEZPUiBUSEUgV09SS0lORyBHUk9VUDogV2hhdCBpcyB5b3VyIHBvc2l0aW9uPyBX aHk/IA0KDQpXaGF0IGZvbGxvd3MgaXMgYSBkdW1wIG9mIHRoZSByYXcgSldTIGJlZm9yZSBzaWdu aW5nICh0aGUgZXF1aXZhbGVudCBQS0NTNy9DTVMgc3RydWN0dXJlIHdvdWxkIGJlIHRoZSBTaWdu ZWREYXRhIGFzbjEgc3RydWN0dXJlcyB3aGljaCBpcyBoYXJkIHRvIGNhcHR1cmUpLiBBZnRlciB0 aGF0IGlzIGFuIGVuY29kZWQgYW5kIHNpZ25lZCB2b3VjaGVyLiBGdXJ0aGVyIGJlbG93IGlzIGFu IGV4YW1wbGUgb2YgYSBQS0NTNyBzaWduZWQgdm91Y2hlci4gDQoNClBsZWFzZSBub3RlIHRoZXNl IGNoYXJhY3RlcmlzdGljczoNCg0KYSkgRnJvbSBKV1QgUkZDNzUxOSAiSldUcyBhcmUgYWx3YXlz IHJlcHJlc2VudGVkIHVzaW5nIHRoZSBKV1MgQ29tcGFjdCBTZXJpYWxpemF0aW9u4oCdLiBUaGVy ZSBhcmUgc29tZSBKV1QgaGVhZGVycyB0aGF0IG92ZXJsYXAgd2l0aCB2b3VjaGVyIGZpZWxkcy4g SeKAmW0gdXNpbmcgSldUIGhlcmU7IGJ1dCB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBKV1MvSldU IGlzIG5vdCBmdW5kYW1lbnRhbCB0byBvdXIgZGlzY3Vzc2lvbi4gVGhlIGltcG9ydGFudCBwb2lu dCBpcyBKV1MgdnMgUEtDUzcuIA0KDQpiKSBJ4oCZdmUgYWRkZWQgdGhlIHg1YyBoZWFkZXIgdG8g dGhlIEpXUy4gVGhpcyBpcyB1c2VkIHRvIGNhcnJ5IHRoZSBjZXJ0aWZpY2F0ZSBjaGFpbiBvZiB0 aGUgc2lnbmVyLiBPdXIgY3VycmVudCB2b3VjaGVyIGZvcm1hdCBpbmRpY2F0ZXMgUEtDUzcgd2hp Y2ggc3VwcG9ydHMgYW4gZXF1aXZhbGVudCBmaWVsZCBjYWxsZWQg4oCcQ2VydGlmaWNhdGVTZXQg c3RydWN0dXJl4oCdLiBJdHMgaW4gdGhlIEJSU0tJIGRvY3VtZW50IHRoYXQgd2Ugc3BlY2lmeSAi VGhlIGVudGlyZSBjZXJ0aWZpY2F0ZSBjaGFpbiwgdXAgdG8gYW5kIGluY2x1ZGluZyB0aGUgRG9t YWluIENBLCBNVVNUIGJlIGluY2x1ZGVkIGluIHRoZSBDZXJ0aWZpY2F0ZVNldCBzdHJ1Y3R1cmXi gJ0uIFdpdGggdGhlIHRyYW5zaXRpb24gdG8gSldUIHdl4oCZZCBiZSBzcGVjaWZ5aW5nIHRoYXQg dGhlIHg1YyBoZWFkZXIgYmUgZnVsbHkgcG9wdWxhdGVkIHVwIHRvIGFuIGluY2x1ZGluZyB0aGUg RG9tYWluIENBIGV0Yy4gDQoNCmMpIEZyb20gdGhlc2UgZXhhbXBsZXMgd2UgY2Fu4oCZdCBkaXJl Y3RseSBjb21wYXJlIHNpemUgZW5jb2RpbmdzLiBJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBhIHNp Z25pZmljYW50IGFzcGVjdCBvZiB0aGUgY29udmVyc2F0aW9uIGJ1dCBjYW4gY3JlYXRlIGNvbXBh cmFibGUgZXhhbXBsZXMgaWYgZm9sa3MgZmVlbCB0aGF0IGlzIG5lY2Vzc2FyeS4gDQoNClRoZSBk dW1wczoNCg0KQSBkZWJ1ZyBkdW1wIG9mIHRoZSBKV1QgZm9ybSBiZWZvcmUgZW5jb2Rpbmc6DQp7 DQogICAidHlwIjogIkpXVCIsDQogICAiYWxnIjogIkVTMjU2IiwNCiAgICJ4NWMiOiBbIk1JSUJk akNDQVIyZ0F3SUJBZ0lCQVRBS0JnZ3Foa2pPUFFRREFqQXJNUll3RkFZRFZRUUtEQTFEYVhOamJ5 QlRlWE4wWlcxek1SRXdEd1lEVlFRRERBaFdaVzVrYjNKRFFUQWVGdzB4TnpBME1ETXhOVEUxTkRW YUZ3MHhPREEwTURNeE5URTFORFZhTUMweEZqQVVCZ05WQkFvTURVTnBjMk52SUZONWMzUmxiWE14 RXpBUkJnTlZCQU1NQ2xabGJtUnZjazFCVTBFd1dUQVRCZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJC d05DQUFUOUdUckRkMEdXZ3djdVN5OExDbjB3YU1la25wTHpuYWpaenFXbExoclB3c2hnSVBJUHZi eVk2SXlDbzR1QllVL2U0T082VFFEOVVWTGx5VTVSNmNBNm96QXdMakFMQmdOVkhROEVCQU1DQmFB d0h3WURWUjBqQkJnd0ZvQVVSNG9FcGI0WUZ1ZWxrTXJRamxuS3RNMDFvdkV3Q2dZSUtvWkl6ajBF QXdJRFJ3QXdSQUlnQVE4WVIySWRMb2RFRThrK0p4cEJPSUFHdXpDZVQ5Qm1GT1ZoRlViOGVKTUNJ QzIzR29zczZtYW5Sak5TbWg2KzJvQjl0c1Jiam1ubnd1TWxEWFI4Znp1ZyIsICJNSUlCblRDQ0FV T2dBd0lCQWdJSkFLOVBkNUcrL3IwVU1Bb0dDQ3FHU000OUJBTUNNQ3N4RmpBVUJnTlZCQW9NRFVO cGMyTnZJRk41YzNSbGJYTXhFVEFQQmdOVkJBTU1DRlpsYm1SdmNrTkJNQjRYRFRFM01EUXdNekUw TVRBd05Wb1hEVEU0TURRd016RTBNVEF3TlZvd0t6RVdNQlFHQTFVRUNnd05RMmx6WTI4Z1UzbHpk R1Z0Y3pFUk1BOEdBMVVFQXd3SVZtVnVaRzl5UTBFd1dUQVRCZ2NxaGtqT1BRSUJCZ2dxaGtqT1BR TUJCd05DQUFTdW5zUUwyUFZPU0ZXV3Awb0NqbHFGOGlWUFBwRWdKY3Q5MzFDWlE2YXNzcDA3b3Rt ZmdacVhzazFKWVJUbEtDR2pST3hyQWlWUlFzQjU0aW9BMHl1MG8xQXdUakFkQmdOVkhRNEVGZ1FV UjRvRXBiNFlGdWVsa01yUWpsbkt0TTAxb3ZFd0h3WURWUjBqQkJnd0ZvQVVSNG9FcGI0WUZ1ZWxr TXJRamxuS3RNMDFvdkV3REFZRFZSMFRCQVV3QXdFQi96QUtCZ2dxaGtqT1BRUURBZ05JQURCRkFp RUErU1NPaGlOUTIzUldBNzZrWi8ydTcwRkNwVThPc1U3WDlJUmlXR0RnSUFnQ0lGTHU4Rm5KdXFQ eDEwc2dIdkl6cUk1QmdPY3dDYTV2RlFaZENEQkhJeDE4Il0NCn0NCi4NCnsNCiAgICJpZXRmLXZv dWNoZXI6dm91Y2hlciI6IHsNCiAgICAgICAiYXNzZXJ0aW9uIjogImxvZ2dpbmciLA0KICAgICAg ICJkb21haW4tY2VydC10cnVzdGVkLWNhIjogIi0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0tLVxu TUlJQlVqQ0IrcUFEQWdFQ0Fna0F3UDRxS3NHeVFsWXdDZ1lJS29aSXpqMEVBd0l3RnpFVk1CTUdB MVVFQXd3TVxuWlhOMFJYaGhiWEJzWlVOQk1CNFhEVEUzTURNeU5USXlNVGMxTUZvWERURTRNRE15 TlRJeU1UYzFNRm93RnpFVlxuTUJNR0ExVUVBd3dNWlhOMFJYaGhiWEJzWlVOQk1Ga3dFd1lIS29a SXpqMENBUVlJS29aSXpqMERBUWNEUWdBRVxuUlZyTmxFTjJvY1lzY0FJTEJVN05nZ0FCbzBKZ0Ex ckVHZFlkQ1FqMW5IS0w2eEtPTkpJVWZCaWJlNmlNVllkM1xuUlVtUHdhUGlITlpKOThrUndISXdu S012TUMwd0RBWURWUjBUQkFVd0F3RUIvekFkQmdOVkhRNEVGZ1FVK2RWWFxuYVhvdWNVMWdvZE5G MGJ5Y1MxVTVXNTR3Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUlnTnNDR2pwRWp1dno2T0tKL1xuM3JP dk1jMlpmRGhEMDJLKzBQQ1ZGSkdDUUd3Q0lBemYzQlM2eDlrS1NST0pKdnhEU3BnMFFLOStiOUxT RmtiWlxuTTFQVzk4QU5cbi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS1cbiIsDQogICAgICAgIm5v bmNlIjogImVhNzEwMmU4ZTg4ZjExOWUiLA0KICAgICAgICJzZXJpYWwtbnVtYmVyIjogIlBJRDox IFNOOndpZGdldDEiLA0KICAgICAgICJzZXJpYWwtbnVtYmVyLWlzc3VlciI6ICIzNjA5N0UzREVB MzkzMTZFQTRDRTVDNjk1QkU5MDVFNzhBRjJGQjVBIiwNCiAgICAgICAidmVyc2lvbiI6ICIxIg0K ICAgfQ0KfQ0KLg0KW3NpZ25hdHVyZSBnb2VzIGhlcmVdDQoNCkFzIHBlciBKV1QgUkZDNzUxOSB0 aGlzIGlzIHdoYXQgaXQgbG9va3MgbGlrZSBhZnRlciBVUkwtc2FmZSBlbmNvZGluZy4gWW91IGNh biBzZWUgdGhhdCBub3cgdGhlIHNpZ25hdHVyZSBpcyBpbmNsdWRlZCAgKGxvb2sgdG8gdGhlIHNl Y29uZCB0byBsYXN0IGxpbmUgdG8gc2VlIHRoZSBzZWNvbmQg4oCcLuKAnSBmb2xsb3dlZCBieSBh IHZhbGlkIHNpZ25hdHVyZSk6IA0KDQpleUowZVhBaU9pSktWMVFpTENKaGJHY2lPaUpGVXpJMU5p SXNJQ0FnSUNKNE5XTWlPbHNpVFVsSlFtUnFRME5CVWpKblFYZEpRa0ZuU1VKQlZFRkxRbWRuY1do cmFrOVFVVkZFUVdwQmNrMVNXWGRHUVZsRVZsRlJTMFJCTVVSaFdFNXFZbmxDVkdWWVRqQmFWekY2 VFZKRmQwUjNXVVJXVVZGRVJFRm9WMXBYTld0aU0wcEVVVlJCWlVaM01IaE9la0V3VFVSTmVFNVVS VEZPUkZaaFJuY3dlRTlFUVRCTlJFMTRUbFJGTVU1RVZtRk5RekI0Um1wQlZVSm5UbFpDUVc5TlJG Vk9jR015VG5aSlJrNDFZek5TYkdKWVRYaEZla0ZTUW1kT1ZrSkJUVTFEYkZwc1ltMVNkbU5yTVVK Vk1FVjNWMVJCVkVKblkzRm9hMnBQVUZGSlFrSm5aM0ZvYTJwUFVGRk5Ra0ozVGtOQlFWUTVSMVJ5 UkdRd1IxZG5kMk4xVTNrNFRFTnVNSGRoVFdWcmJuQk1lbTVoYWxwNmNWZHNUR2h5VUhkemFHZEpV RWxRZG1KNVdUWkplVU52TkhWQ1dWVXZaVFJQVHpaVVVVUTVWVlpNYkhsVk5WSTJZMEUyYjNwQmQw eHFRVXhDWjA1V1NGRTRSVUpCVFVOQ1lVRjNTSGRaUkZaU01HcENRbWQzUm05QlZWSTBiMFZ3WWpS WlJuVmxiR3ROY2xGcWJHNUxkRTB3TVc5MlJYZERaMWxKUzI5YVNYcHFNRVZCZDBsRVVuZEJkMUpC U1dkQlVUaFpVakpKWkV4dlpFVkZPR3NyU25od1FrOUpRVWQxZWtObFZEbENiVVpQVm1oR1ZXSTRa VXBOUTBsRE1qTkhiM056Tm0xaGJsSnFUbE50YURZck1tOUNPWFJ6VW1KcWJXNXVkM1ZOYkVSWVVq aG1lblZuSWl3aVRVbEpRbTVVUTBOQlZVOW5RWGRKUWtGblNVcEJTemxRWkRWSEt5OXlNRlZOUVc5 SFEwTnhSMU5OTkRsQ1FVMURUVU56ZUVacVFWVkNaMDVXUWtGdlRVUlZUbkJqTWs1MlNVWk9OV016 VW14aVdFMTRSVlJCVUVKblRsWkNRVTFOUTBaYWJHSnRVblpqYTA1Q1RVSTBXRVJVUlROTlJGRjNU WHBGTUUxVVFYZE9WbTlZUkZSRk5FMUVVWGROZWtVd1RWUkJkMDVXYjNkTGVrVlhUVUpSUjBFeFZV VkRaM2RPVVRKc2Vsa3lPR2RWTTJ4NlpFZFdkR042UlZKTlFUaEhRVEZWUlVGM2QwbFdiVloxV2tj NWVWRXdSWGRYVkVGVVFtZGpjV2hyYWs5UVVVbENRbWRuY1docmFrOVFVVTFDUW5kT1EwRkJVM1Z1 YzFGTU1sQldUMU5HVjFkd01HOURhbXh4UmpocFZsQlFjRVZuU21OME9UTXhRMXBSTm1GemMzQXdO MjkwYldablduRlljMnN4U2xsU1ZHeExRMGRxVWs5NGNrRnBWbEpSYzBJMU5HbHZRVEI1ZFRCdk1V RjNWR3BCWkVKblRsWklVVFJGUm1kUlZWSTBiMFZ3WWpSWlJuVmxiR3ROY2xGcWJHNUxkRTB3TVc5 MlJYZElkMWxFVmxJd2FrSkNaM2RHYjBGVlVqUnZSWEJpTkZsR2RXVnNhMDF5VVdwc2JrdDBUVEF4 YjNaRmQwUkJXVVJXVWpCVVFrRlZkMEYzUlVJdmVrRkxRbWRuY1docmFrOVFVVkZFUVdkT1NVRkVR a1pCYVVWQksxTlRUMmhwVGxFeU0xSlhRVGMyYTFvdk1uVTNNRVpEY0ZVNFQzTlZOMWc1U1ZKcFYw ZEVaMGxCWjBOSlJreDFPRVp1U25WeFVIZ3hNSE5uU0haSmVuRkpOVUpuVDJOM1EyRTFka1pSV21S RFJFSklTWGd4T0NKZGZRLmV5SnBaWFJtTFhadmRXTm9aWEk2ZG05MVkyaGxjaUk2ZXlKaGMzTmxj blJwYjI0aU9pSnNiMmRuYVc1bklpd2laRzl0WVdsdUxXTmxjblF0ZEhKMWMzUmxaQzFqWVNJNklp MHRMUzB0UWtWSFNVNGdRMFZTVkVsR1NVTkJWRVV0TFMwdExWeHVUVWxKUWxWcVEwSXJjVUZFUVdk RlEwRm5hMEYzVURSeFMzTkhlVkZzV1hkRFoxbEpTMjlhU1hwcU1FVkJkMGwzUm5wRlZrMUNUVWRC TVZWRlFYZDNUVnh1V2xoT01GSllhR2hpV0VKeldsVk9RazFDTkZoRVZFVXpUVVJOZVU1VVNYbE5W R014VFVadldFUlVSVFJOUkUxNVRsUkplVTFVWXpGTlJtOTNSbnBGVmx4dVRVSk5SMEV4VlVWQmQz ZE5XbGhPTUZKWWFHaGlXRUp6V2xWT1FrMUdhM2RGZDFsSVMyOWFTWHBxTUVOQlVWbEpTMjlhU1hw cU1FUkJVV05FVVdkQlJWeHVVbFp5VG14RlRqSnZZMWx6WTBGSlRFSlZOMDVuWjBGQ2J6QktaMEV4 Y2tWSFpGbGtRMUZxTVc1SVMwdzJlRXRQVGtwSlZXWkNhV0psTm1sTlZsbGtNMXh1VWxWdFVIZGhV R2xJVGxwS09UaHJVbmRJU1hkdVMwMTJUVU13ZDBSQldVUldVakJVUWtGVmQwRjNSVUl2ZWtGa1Ft ZE9Wa2hSTkVWR1oxRlZLMlJXV0Z4dVlWaHZkV05WTVdkdlpFNUdNR0o1WTFNeFZUVlhOVFIzUTJk WlNVdHZXa2w2YWpCRlFYZEpSRkozUVhkU1FVbG5Ubk5EUjJwd1JXcDFkbm8yVDB0S0wxeHVNM0pQ ZGsxak1scG1SR2hFTURKTEt6QlFRMVpHU2tkRFVVZDNRMGxCZW1ZelFsTTJlRGxyUzFOU1QwcEtk bmhFVTNCbk1GRkxPU3RpT1V4VFJtdGlXbHh1VFRGUVZ6azRRVTVjYmkwdExTMHRSVTVFSUVORlVs UkpSa2xEUVZSRkxTMHRMUzFjYmlJc0ltNXZibU5sSWpvaVpXRTNNVEF5WlRobE9EaG1NVEU1WlNJ c0luTmxjbWxoYkMxdWRXMWlaWElpT2lKUVNVUTZNU0JUVGpwM2FXUm5aWFF4SWl3aWMyVnlhV0Zz TFc1MWJXSmxjaTFwYzNOMVpYSWlPaUl6TmpBNU4wVXpSRVZCTXprek1UWkZRVFJEUlRWRE5qazFR a1U1TURWRk56aEJSakpHUWpWQklpd2lkbVZ5YzJsdmJpSTZJakVpZlgwLlFrVFVwY3h2Nk5nNnls eVdZbmxxdW4tNVNGaEQxWHdMSVcxa0Q3WTlkTndpb2hlTk1jVm5vd2tFTGxfRU1DbHlPV3VMdnZX dW9DSEFjV3pfVUEwSUd3DQoNCg0KSGVyZSBpcyBhbiBlcXVpdmFsZW50IFBLQ1M3IHZvdWNoZXIg dmlhIGFzbjEgZHVtcC4gWW914oCZZCBoYXZlIHRvIGxvb2sgYXQgdGhlIGJpbmFyeSBpZiB5b3Ug cmVhbGx5IHdhbnQgdG8gZGVjb2RlIGl0LiBUaGlzIHZvdWNoZXIgd2FzIGdlbmVyYXRlZCBieSBN Q1IgZHVyaW5nIHRoZSBoYWNrYXRob246IA0KDQpwcml0aWtpbkB1YnVudHU6fi9zcmMvYnJza2kt cHJvamVjdC9icnNraV9tc2dzJCBvcGVuc3NsIGFzbjFwYXJzZSAtaW4gbWNyLnZvdWNoZXIudHh0 LnBrY3M3DQogICAgMDpkPTAgIGhsPTQgbD0yNzA2IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0K ICAgIDQ6ZD0xICBobD0yIGw9ICAgOSBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6cGtjczctc2ln bmVkRGF0YQ0KICAgMTU6ZD0xICBobD00IGw9MjY5MSBjb25zOiBjb250IFsgMCBdICAgICAgICAN CiAgIDE5OmQ9MiAgaGw9NCBsPTI2ODcgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogICAyMzpk PTMgIGhsPTIgbD0gICAxIHByaW06IElOVEVHRVIgICAgICAgICAgIDowMQ0KICAgMjY6ZD0zICBo bD0yIGw9ICAxNSBjb25zOiBTRVQgICAgICAgICAgICAgICANCiAgIDI4OmQ9NCAgaGw9MiBsPSAg MTMgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogICAzMDpkPTUgIGhsPTIgbD0gICA5IHByaW06 IE9CSkVDVCAgICAgICAgICAgIDpzaGEyNTYNCiAgIDQxOmQ9NSAgaGw9MiBsPSAgIDAgcHJpbTog TlVMTCAgICAgICAgICAgICAgDQogICA0MzpkPTMgIGhsPTQgbD0xNjQ0IGNvbnM6IFNFUVVFTkNF ICAgICAgICAgIA0KICAgNDc6ZD00ICBobD0yIGw9ICAgOSBwcmltOiBPQkpFQ1QgICAgICAgICAg ICA6cGtjczctZGF0YQ0KICAgNTg6ZD00ICBobD00IGw9MTYyOSBjb25zOiBjb250IFsgMCBdICAg ICAgICANCiAgIDYyOmQ9NSAgaGw9NCBsPTE2MjUgcHJpbTogT0NURVQgU1RSSU5HICAgICAgOnsi aWV0Zi12b3VjaGVyOnZvdWNoZXIiOnsibm9uY2UiOiI2MmEyZTc2OTNkODJmY2RhMjYyNGRlNThm YjY3MjJlNSIsImNyZWF0ZWQtb24iOiIyMDE3LTAxLTAxVDAwOjAwOjAwLjAwMFoiLCJkZXZpY2Ut aWRlbnRpZmllciI6IjAwLWQwLWU1LWYyLTAwLTAxIiwiYXNzZXJ0aW9uIjoibG9nZ2VkIiwib3du ZXIiOiJNSUlFRXpDQ0F2dWdBd0lCQWdJSkFLNnJGb3V2ays3WU1BMEdDU3FHU0liM0RRRUJDd1VB TUlHZk1Rc3dcbkNRWURWUVFHRXdKRFFURVFNQTRHQTFVRUNBd0hUMjUwWVhKcGJ6RVBNQTBHQTFV RUJ3d0dUM1IwWVhkaFxuTVJvd0dBWURWUVFLREJGUGQyNWxjaUJGZUdGdGNHeGxJRTl1WlRFUk1B OEdBMVVFQ3d3SVRtOTBJRlpsXG5jbmt4R3pBWkJnTlZCQU1NRW05M2JtVnlNUzVsZUdGdGNHeGxM bU52YlRFaE1COEdDU3FHU0liM0RRRUpcbkFSWVNiM2R1WlhJeFFHVjRZVzF3YkdVdVkyOXRNQjRY RFRFM01ETXlOVEUyTWprek5Gb1hEVEUzTURReVxuTkRFMk1qa3pORm93Z1o4eEN6QUpCZ05WQkFZ VEFrTkJNUkF3RGdZRFZRUUlEQWRQYm5SaGNtbHZNUTh3XG5EUVlEVlFRSERBWlBkSFJoZDJFeEdq QVlCZ05WQkFvTUVVOTNibVZ5SUVWNFlXMXdiR1VnVDI1bE1SRXdcbkR3WURWUVFMREFoT2IzUWdW bVZ5ZVRFYk1Ca0dBMVVFQXd3U2IzZHVaWEl4TG1WNFlXMXdiR1V1WTI5dFxuTVNFd0h3WUpLb1pJ aHZjTkFRa0JGaEp2ZDI1bGNqRkFaWGhoYlhCc1pTNWpiMjB3Z2dFaU1BMEdDU3FHXG5TSWIzRFFF QkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDNFFZQUVuVHRYZ2lLcXNmU1ZZa2drSGRkRmNQMzRcbk9V M1lQN2licnNneDBpOWN5ajd4T3pXSE9GMlBzb0tCZ1RSSDc1TVNNaFRsNVVpZHJDc3psbHVLK3Fw NFxuZDNaZzMxb1FNL0hEbXlSSnlScFkrUEMxbjVWeC9NajVWYWdSUWJxRzdYVERRQ2ZDcmhxSUty S0JUdVBRXG40dllLZUwwdFFrNFVKbFBJb1pYRW1CazVka24vRnpsOUFmSVpTdlV6UTFRQWhROW9h THo1TmY1TVdIUEtcblVZKzZiMnpBL3lRYVhkdVByVnV4cDd4Q2oxMUMvTGpsaGwxL0h4MTZNSnJW MzNNQ2JkK1JLVzcxMUQvM1xuMFhsV1NxRXByZGJLYnF3OFdNUGp1SjFhb1g4YVFFV29MK3hib21S UVFKSm9GYU1QbHpnZERjZm9BSERVXG5Uc3hkMCtGTjhwRkhBZ01CQUFHalVEQk9NQjBHQTFVZERn UVdCQlNxcDVUd1F0SHNReTlvWUxaYjBENVdcbitsaWNIREFmQmdOVkhTTUVHREFXZ0JTcXA1VHdR dEhzUXk5b1lMWmIwRDVXK2xpY0hEQU1CZ05WSFJNRVxuQlRBREFRSC9NQTBHQ1NxR1NJYjNEUUVC Q3dVQUE0SUJBUUJnU1FHYWNqd3htYlJyckJoVzYzZ1k1S2FXXG5pbTc2ckc0NXAzdWg5QThXVWZN V3J5Q1V1ZnJGT20vUUVKbmxVVUszUVg0S0VWajJleXdiOWdzZmtpQ0VcbnlhSnp4ZTY2NVEyQnJX d2UzckdWa0FoTy9mbjh1cGVjNEUxQVNjMzFBU2FGOG0rcFlxQ0NQU2ZsTDVrVlxuTWVmSEc0bEVz M1hKa0hjZUNsUnp5WHZqYjVLai91MDJDNVlDamNBTFlkOC9rY1NiZjRqb2UxR3VmdktGXG41d3ZQ QlBrUlZmYlcyS2FnTCtqdzYyais4VTZvQjdGYnh0RnlxUVAxWW9aR2lhOU1rUEtuSyt5ZzVvLzBc bmNaNTdoZ2s0bVFtTTFpODJSclVaUVZvQlAzQ0Q1TGRCSlpmSm9Yc3RSbFhlNmRYNytUaXNkU0Fz cHA1ZVxuaE5tMEJjcWRMSyt6OG50dFxuIn19DQogMTY5MTpkPTMgIGhsPTQgbD0gNTU3IGNvbnM6 IGNvbnQgWyAwIF0gICAgICAgIA0KIDE2OTU6ZD00ICBobD00IGw9IDU1MyBjb25zOiBTRVFVRU5D RSAgICAgICAgICANCiAxNjk5OmQ9NSAgaGw9NCBsPSA0MzEgY29uczogU0VRVUVOQ0UgICAgICAg ICAgDQogMTcwMzpkPTYgIGhsPTIgbD0gICAzIGNvbnM6IGNvbnQgWyAwIF0gICAgICAgIA0KIDE3 MDU6ZD03ICBobD0yIGw9ICAgMSBwcmltOiBJTlRFR0VSICAgICAgICAgICA6MDINCiAxNzA4OmQ9 NiAgaGw9MiBsPSAgIDEgcHJpbTogSU5URUdFUiAgICAgICAgICAgOjAxDQogMTcxMTpkPTYgIGhs PTIgbD0gIDEwIGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDE3MTM6ZD03ICBobD0yIGw9ICAg OCBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6ZWNkc2Etd2l0aC1TSEEyNTYNCiAxNzIzOmQ9NiAg aGw9MiBsPSAgNzcgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMTcyNTpkPTcgIGhsPTIgbD0g IDE4IGNvbnM6IFNFVCAgICAgICAgICAgICAgIA0KIDE3Mjc6ZD04ICBobD0yIGw9ICAxNiBjb25z OiBTRVFVRU5DRSAgICAgICAgICANCiAxNzI5OmQ9OSAgaGw9MiBsPSAgMTAgcHJpbTogT0JKRUNU ICAgICAgICAgICAgOmRvbWFpbkNvbXBvbmVudA0KIDE3NDE6ZD05ICBobD0yIGw9ICAgMiBwcmlt OiBJQTVTVFJJTkcgICAgICAgICA6Y2ENCiAxNzQ1OmQ9NyAgaGw9MiBsPSAgMjUgY29uczogU0VU ICAgICAgICAgICAgICAgDQogMTc0NzpkPTggIGhsPTIgbD0gIDIzIGNvbnM6IFNFUVVFTkNFICAg ICAgICAgIA0KIDE3NDk6ZD05ICBobD0yIGw9ICAxMCBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6 ZG9tYWluQ29tcG9uZW50DQogMTc2MTpkPTkgIGhsPTIgbD0gICA5IHByaW06IElBNVNUUklORyAg ICAgICAgIDpzYW5kZWxtYW4NCiAxNzcyOmQ9NyAgaGw9MiBsPSAgMjggY29uczogU0VUICAgICAg ICAgICAgICAgDQogMTc3NDpkPTggIGhsPTIgbD0gIDI2IGNvbnM6IFNFUVVFTkNFICAgICAgICAg IA0KIDE3NzY6ZD05ICBobD0yIGw9ICAgMyBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6Y29tbW9u TmFtZQ0KIDE3ODE6ZD05ICBobD0yIGw9ICAxOSBwcmltOiBVVEY4U1RSSU5HICAgICAgICA6VW5z dHJ1bmcgSGlnaHdheSBDQQ0KIDE4MDI6ZD02ICBobD0yIGw9ICAzMCBjb25zOiBTRVFVRU5DRSAg ICAgICAgICANCiAxODA0OmQ9NyAgaGw9MiBsPSAgMTMgcHJpbTogVVRDVElNRSAgICAgICAgICAg OjE2MDUwNzAyMzY1NVoNCiAxODE5OmQ9NyAgaGw9MiBsPSAgMTMgcHJpbTogVVRDVElNRSAgICAg ICAgICAgOjE4MDUwNzAyMzY1NVoNCiAxODM0OmQ9NiAgaGw9MiBsPSAgNzcgY29uczogU0VRVUVO Q0UgICAgICAgICAgDQogMTgzNjpkPTcgIGhsPTIgbD0gIDE4IGNvbnM6IFNFVCAgICAgICAgICAg ICAgIA0KIDE4Mzg6ZD04ICBobD0yIGw9ICAxNiBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCiAx ODQwOmQ9OSAgaGw9MiBsPSAgMTAgcHJpbTogT0JKRUNUICAgICAgICAgICAgOmRvbWFpbkNvbXBv bmVudA0KIDE4NTI6ZD05ICBobD0yIGw9ICAgMiBwcmltOiBJQTVTVFJJTkcgICAgICAgICA6Y2EN CiAxODU2OmQ9NyAgaGw9MiBsPSAgMjUgY29uczogU0VUICAgICAgICAgICAgICAgDQogMTg1ODpk PTggIGhsPTIgbD0gIDIzIGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDE4NjA6ZD05ICBobD0y IGw9ICAxMCBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6ZG9tYWluQ29tcG9uZW50DQogMTg3Mjpk PTkgIGhsPTIgbD0gICA5IHByaW06IElBNVNUUklORyAgICAgICAgIDpzYW5kZWxtYW4NCiAxODgz OmQ9NyAgaGw9MiBsPSAgMjggY29uczogU0VUICAgICAgICAgICAgICAgDQogMTg4NTpkPTggIGhs PTIgbD0gIDI2IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDE4ODc6ZD05ICBobD0yIGw9ICAg MyBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6Y29tbW9uTmFtZQ0KIDE4OTI6ZD05ICBobD0yIGw9 ICAxOSBwcmltOiBVVEY4U1RSSU5HICAgICAgICA6VW5zdHJ1bmcgSGlnaHdheSBDQQ0KIDE5MTM6 ZD02ICBobD0yIGw9IDExOCBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCiAxOTE1OmQ9NyAgaGw9 MiBsPSAgMTYgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMTkxNzpkPTggIGhsPTIgbD0gICA3 IHByaW06IE9CSkVDVCAgICAgICAgICAgIDppZC1lY1B1YmxpY0tleQ0KIDE5MjY6ZD04ICBobD0y IGw9ICAgNSBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6c2VjcDM4NHIxDQogMTkzMzpkPTcgIGhs PTIgbD0gIDk4IHByaW06IEJJVCBTVFJJTkcgICAgICAgIA0KIDIwMzM6ZD02ICBobD0yIGw9ICA5 OSBjb25zOiBjb250IFsgMyBdICAgICAgICANCiAyMDM1OmQ9NyAgaGw9MiBsPSAgOTcgY29uczog U0VRVUVOQ0UgICAgICAgICAgDQogMjAzNzpkPTggIGhsPTIgbD0gIDE1IGNvbnM6IFNFUVVFTkNF ICAgICAgICAgIA0KIDIwMzk6ZD05ICBobD0yIGw9ICAgMyBwcmltOiBPQkpFQ1QgICAgICAgICAg ICA6WDUwOXYzIEJhc2ljIENvbnN0cmFpbnRzDQogMjA0NDpkPTkgIGhsPTIgbD0gICAxIHByaW06 IEJPT0xFQU4gICAgICAgICAgIDoyNTUNCiAyMDQ3OmQ9OSAgaGw9MiBsPSAgIDUgcHJpbTogT0NU RVQgU1RSSU5HICAgICAgW0hFWCBEVU1QXTozMDAzMDEwMUZGDQogMjA1NDpkPTggIGhsPTIgbD0g IDE0IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDIwNTY6ZD05ICBobD0yIGw9ICAgMyBwcmlt OiBPQkpFQ1QgICAgICAgICAgICA6WDUwOXYzIEtleSBVc2FnZQ0KIDIwNjE6ZD05ICBobD0yIGw9 ICAgMSBwcmltOiBCT09MRUFOICAgICAgICAgICA6MjU1DQogMjA2NDpkPTkgIGhsPTIgbD0gICA0 IHByaW06IE9DVEVUIFNUUklORyAgICAgIFtIRVggRFVNUF06MDMwMjAxMDYNCiAyMDcwOmQ9OCAg aGw9MiBsPSAgMjkgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMjA3MjpkPTkgIGhsPTIgbD0g ICAzIHByaW06IE9CSkVDVCAgICAgICAgICAgIDpYNTA5djMgU3ViamVjdCBLZXkgSWRlbnRpZmll cg0KIDIwNzc6ZD05ICBobD0yIGw9ICAyMiBwcmltOiBPQ1RFVCBTVFJJTkcgICAgICBbSEVYIERV TVBdOjA0MTQyNThFREYyRDUxNzg4RjBDRUM4NzJBMjJGQkQ0RkVCRTA2NzZFQjA3DQogMjEwMTpk PTggIGhsPTIgbD0gIDMxIGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDIxMDM6ZD05ICBobD0y IGw9ICAgMyBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6WDUwOXYzIEF1dGhvcml0eSBLZXkgSWRl bnRpZmllcg0KIDIxMDg6ZD05ICBobD0yIGw9ICAyNCBwcmltOiBPQ1RFVCBTVFJJTkcgICAgICBb SEVYIERVTVBdOjMwMTY4MDE0MjU4RURGMkQ1MTc4OEYwQ0VDODcyQTIyRkJENEZFQkUwNjc2RUIw Nw0KIDIxMzQ6ZD01ICBobD0yIGw9ICAxMCBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCiAyMTM2 OmQ9NiAgaGw9MiBsPSAgIDggcHJpbTogT0JKRUNUICAgICAgICAgICAgOmVjZHNhLXdpdGgtU0hB MjU2DQogMjE0NjpkPTUgIGhsPTIgbD0gMTA0IHByaW06IEJJVCBTVFJJTkcgICAgICAgIA0KIDIy NTI6ZD0zICBobD00IGw9IDQ1NCBjb25zOiBTRVQgICAgICAgICAgICAgICANCiAyMjU2OmQ9NCAg aGw9NCBsPSA0NTAgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMjI2MDpkPTUgIGhsPTIgbD0g ICAxIHByaW06IElOVEVHRVIgICAgICAgICAgIDowMQ0KIDIyNjM6ZD01ICBobD0yIGw9ICA4MiBj b25zOiBTRVFVRU5DRSAgICAgICAgICANCiAyMjY1OmQ9NiAgaGw9MiBsPSAgNzcgY29uczogU0VR VUVOQ0UgICAgICAgICAgDQogMjI2NzpkPTcgIGhsPTIgbD0gIDE4IGNvbnM6IFNFVCAgICAgICAg ICAgICAgIA0KIDIyNjk6ZD04ICBobD0yIGw9ICAxNiBjb25zOiBTRVFVRU5DRSAgICAgICAgICAN CiAyMjcxOmQ9OSAgaGw9MiBsPSAgMTAgcHJpbTogT0JKRUNUICAgICAgICAgICAgOmRvbWFpbkNv bXBvbmVudA0KIDIyODM6ZD05ICBobD0yIGw9ICAgMiBwcmltOiBJQTVTVFJJTkcgICAgICAgICA6 Y2ENCiAyMjg3OmQ9NyAgaGw9MiBsPSAgMjUgY29uczogU0VUICAgICAgICAgICAgICAgDQogMjI4 OTpkPTggIGhsPTIgbD0gIDIzIGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDIyOTE6ZD05ICBo bD0yIGw9ICAxMCBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6ZG9tYWluQ29tcG9uZW50DQogMjMw MzpkPTkgIGhsPTIgbD0gICA5IHByaW06IElBNVNUUklORyAgICAgICAgIDpzYW5kZWxtYW4NCiAy MzE0OmQ9NyAgaGw9MiBsPSAgMjggY29uczogU0VUICAgICAgICAgICAgICAgDQogMjMxNjpkPTgg IGhsPTIgbD0gIDI2IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDIzMTg6ZD05ICBobD0yIGw9 ICAgMyBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6Y29tbW9uTmFtZQ0KIDIzMjM6ZD05ICBobD0y IGw9ICAxOSBwcmltOiBVVEY4U1RSSU5HICAgICAgICA6VW5zdHJ1bmcgSGlnaHdheSBDQQ0KIDIz NDQ6ZD02ICBobD0yIGw9ICAgMSBwcmltOiBJTlRFR0VSICAgICAgICAgICA6MDENCiAyMzQ3OmQ9 NSAgaGw9MiBsPSAgMTMgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMjM0OTpkPTYgIGhsPTIg bD0gICA5IHByaW06IE9CSkVDVCAgICAgICAgICAgIDpzaGEyNTYNCiAyMzYwOmQ9NiAgaGw9MiBs PSAgIDAgcHJpbTogTlVMTCAgICAgICAgICAgICAgDQogMjM2MjpkPTUgIGhsPTMgbD0gMjI4IGNv bnM6IGNvbnQgWyAwIF0gICAgICAgIA0KIDIzNjU6ZD02ICBobD0yIGw9ICAyNCBjb25zOiBTRVFV RU5DRSAgICAgICAgICANCiAyMzY3OmQ9NyAgaGw9MiBsPSAgIDkgcHJpbTogT0JKRUNUICAgICAg ICAgICAgOmNvbnRlbnRUeXBlDQogMjM3ODpkPTcgIGhsPTIgbD0gIDExIGNvbnM6IFNFVCAgICAg ICAgICAgICAgIA0KIDIzODA6ZD04ICBobD0yIGw9ICAgOSBwcmltOiBPQkpFQ1QgICAgICAgICAg ICA6cGtjczctZGF0YQ0KIDIzOTE6ZD02ICBobD0yIGw9ICAyOCBjb25zOiBTRVFVRU5DRSAgICAg ICAgICANCiAyMzkzOmQ9NyAgaGw9MiBsPSAgIDkgcHJpbTogT0JKRUNUICAgICAgICAgICAgOnNp Z25pbmdUaW1lDQogMjQwNDpkPTcgIGhsPTIgbD0gIDE1IGNvbnM6IFNFVCAgICAgICAgICAgICAg IA0KIDI0MDY6ZD04ICBobD0yIGw9ICAxMyBwcmltOiBVVENUSU1FICAgICAgICAgICA6MTcwMzI1 MjIwMzA4Wg0KIDI0MjE6ZD02ICBobD0yIGw9ICA0NyBjb25zOiBTRVFVRU5DRSAgICAgICAgICAN CiAyNDIzOmQ9NyAgaGw9MiBsPSAgIDkgcHJpbTogT0JKRUNUICAgICAgICAgICAgOm1lc3NhZ2VE aWdlc3QNCiAyNDM0OmQ9NyAgaGw9MiBsPSAgMzQgY29uczogU0VUICAgICAgICAgICAgICAgDQog MjQzNjpkPTggIGhsPTIgbD0gIDMyIHByaW06IE9DVEVUIFNUUklORyAgICAgIFtIRVggRFVNUF06 NTUyREQyRUU1Q0JDNEM3QzREMjA3Rjk4QTI1MTlGMDMxRUUxMDA3NEQ2NzQyNjVBN0REMENBNzNF NjhCRTU3RA0KIDI0NzA6ZD02ICBobD0yIGw9IDEyMSBjb25zOiBTRVFVRU5DRSAgICAgICAgICAN CiAyNDcyOmQ9NyAgaGw9MiBsPSAgIDkgcHJpbTogT0JKRUNUICAgICAgICAgICAgOlMvTUlNRSBD YXBhYmlsaXRpZXMNCiAyNDgzOmQ9NyAgaGw9MiBsPSAxMDggY29uczogU0VUICAgICAgICAgICAg ICAgDQogMjQ4NTpkPTggIGhsPTIgbD0gMTA2IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDI0 ODc6ZD05ICBobD0yIGw9ICAxMSBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCiAyNDg5OmQ9MTAg aGw9MiBsPSAgIDkgcHJpbTogT0JKRUNUICAgICAgICAgICAgOmFlcy0yNTYtY2JjDQogMjUwMDpk PTkgIGhsPTIgbD0gIDExIGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDI1MDI6ZD0xMCBobD0y IGw9ICAgOSBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6YWVzLTE5Mi1jYmMNCiAyNTEzOmQ9OSAg aGw9MiBsPSAgMTEgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMjUxNTpkPTEwIGhsPTIgbD0g ICA5IHByaW06IE9CSkVDVCAgICAgICAgICAgIDphZXMtMTI4LWNiYw0KIDI1MjY6ZD05ICBobD0y IGw9ICAxMCBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCiAyNTI4OmQ9MTAgaGw9MiBsPSAgIDgg cHJpbTogT0JKRUNUICAgICAgICAgICAgOmRlcy1lZGUzLWNiYw0KIDI1Mzg6ZD05ICBobD0yIGw9 ICAxNCBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCiAyNTQwOmQ9MTAgaGw9MiBsPSAgIDggcHJp bTogT0JKRUNUICAgICAgICAgICAgOnJjMi1jYmMNCiAyNTUwOmQ9MTAgaGw9MiBsPSAgIDIgcHJp bTogSU5URUdFUiAgICAgICAgICAgOjgwDQogMjU1NDpkPTkgIGhsPTIgbD0gIDEzIGNvbnM6IFNF UVVFTkNFICAgICAgICAgIA0KIDI1NTY6ZD0xMCBobD0yIGw9ICAgOCBwcmltOiBPQkpFQ1QgICAg ICAgICAgICA6cmMyLWNiYw0KIDI1NjY6ZD0xMCBobD0yIGw9ICAgMSBwcmltOiBJTlRFR0VSICAg ICAgICAgICA6NDANCiAyNTY5OmQ9OSAgaGw9MiBsPSAgIDcgY29uczogU0VRVUVOQ0UgICAgICAg ICAgDQogMjU3MTpkPTEwIGhsPTIgbD0gICA1IHByaW06IE9CSkVDVCAgICAgICAgICAgIDpkZXMt Y2JjDQogMjU3ODpkPTkgIGhsPTIgbD0gIDEzIGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDI1 ODA6ZD0xMCBobD0yIGw9ICAgOCBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6cmMyLWNiYw0KIDI1 OTA6ZD0xMCBobD0yIGw9ICAgMSBwcmltOiBJTlRFR0VSICAgICAgICAgICA6MjgNCiAyNTkzOmQ9 NSAgaGw9MiBsPSAgMTAgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMjU5NTpkPTYgIGhsPTIg bD0gICA4IHByaW06IE9CSkVDVCAgICAgICAgICAgIDplY2RzYS13aXRoLVNIQTI1Ng0KIDI2MDU6 ZD01ICBobD0yIGw9IDEwMyBwcmltOiBPQ1RFVCBTVFJJTkcgICAgICBbSEVYIERVTVBdOjMwNjUw MjMxMDBFNjBFQUY3M0E2OTgyNjA3N0NGNkI3NjBBRjlCRDFDOUJGNzIzRDBFODQ4MTJCMDZCNUE4 QjdDMjUyMzYyMzk0RDk4RTFCNUI0QzAyRDhBQ0Q4REE1QkQyMjQ4RDUxRUEwMjMwNkI1QkRCREZG QkIwMjJBMUUwMzlBMTg0NzI1OUQyRTBBQTMzMkUxMkQyNDA1M0IzRTdFQ0E2RDE4RUE4MjFFMjlB NTNEOTNFRTNCQTRERTdEOEM1OTRDNTE3MzY1MTFDDQoNCkFuZCB0aGlzIGlzIHRoZSDigJxlbmNv ZGVk4oCdIGZvcm06DQotLS0tLUJFR0lOIFBLQ1M3LS0tLS0NCk1JSUtrZ1lKS29aSWh2Y05BUWND b0lJS2d6Q0NDbjhDQVFFeER6QU5CZ2xnaGtnQlpRTUVBZ0VGQURDQ0Jtd0cNCkNTcUdTSWIzRFFF SEFhQ0NCbDBFZ2daWmV5SnBaWFJtTFhadmRXTm9aWEk2ZG05MVkyaGxjaUk2ZXlKdWIyNWoNClpT STZJall5WVRKbE56WTVNMlE0TW1aalpHRXlOakkwWkdVMU9HWmlOamN5TW1VMUlpd2lZM0psWVhS bFpDMXYNCmJpSTZJakl3TVRjdE1ERXRNREZVTURBNk1EQTZNREF1TURBd1dpSXNJbVJsZG1salpT MXBaR1Z1ZEdsbWFXVnkNCklqb2lNREF0WkRBdFpUVXRaakl0TURBdE1ERWlMQ0poYzNObGNuUnBi MjRpT2lKc2IyZG5aV1FpTENKdmQyNWwNCmNpSTZJazFKU1VWRmVrTkRRWFoxWjBGM1NVSkJaMGxL UVVzMmNrWnZkWFpyS3pkWlRVRXdSME5UY1VkVFNXSXoNClJGRkZRa04zVlVGTlNVZG1UVkZ6ZDF4 dVExRlpSRlpSVVVkRmQwcEVVVlJGVVUxQk5FZEJNVlZGUTBGM1NGUXkNCk5UQlpXRXB3WW5wRlVF MUJNRWRCTVZWRlFuZDNSMVF6VWpCWldHUm9YRzVOVW05M1IwRlpSRlpSVVV0RVFrWlENClpESTFi R05wUWtabFIwWjBZMGQ0YkVsRk9YVmFWRVZTVFVFNFIwRXhWVVZEZDNkSlZHMDVNRWxHV214Y2Jt TnUNCmEzaEhla0ZhUW1kT1ZrSkJUVTFGYlRrelltMVdlVTFUTld4bFIwWjBZMGQ0YkV4dFRuWmlW RVZvVFVJNFIwTlQNCmNVZFRTV0l6UkZGRlNseHVRVkpaVTJJelpIVmFXRWw0VVVkV05GbFhNWGRp UjFWMVdUSTVkRTFDTkZoRVZFVXoNClRVUk5lVTVVUlRKTmFtdDZUa1p2V0VSVVJUTk5SRkY1WEc1 T1JFVXlUV3ByZWs1R2IzZG5Xamg0UTNwQlNrSm4NClRsWkNRVmxVUVd0T1FrMVNRWGRFWjFsRVZs RlJTVVJCWkZCaWJsSm9ZMjFzZGsxUk9IZGNia1JSV1VSV1VWRkkNClJFRmFVR1JJVW1oa01rVjRS MnBCV1VKblRsWkNRVzlOUlZVNU0ySnRWbmxKUlZZMFdWY3hkMkpIVldkVU1qVnMNClRWSkZkMXh1 UkhkWlJGWlJVVXhFUVdoUFlqTlJaMVp0Vm5sbFZFVmlUVUpyUjBFeFZVVkJkM2RUWWpOa2RWcFkN ClNYaE1iVlkwV1ZjeGQySkhWWFZaTWpsMFhHNU5VMFYzU0hkWlNrdHZXa2xvZG1OT1FWRnJRa1pv U25aa01qVnMNClkycEdRVnBZYUdoaVdFSnpXbE0xYW1JeU1IZG5aMFZwVFVFd1IwTlRjVWRjYmxO SllqTkVVVVZDUVZGVlFVRTANClNVSkVkMEYzWjJkRlMwRnZTVUpCVVVNMFVWbEJSVzVVZEZobmFV dHhjMlpUVmxscloydElaR1JHWTFBek5GeHUNClQxVXpXVkEzYVdKeWMyZDRNR2s1WTNscU4zaFBl bGRJVDBZeVVITnZTMEpuVkZKSU56Vk5VMDFvVkd3MVZXbGsNCmNrTnplbXhzZFVzcmNYQTBYRzVr TTFwbk16RnZVVTB2U0VSdGVWSktlVkp3V1N0UVF6RnVOVlo0TDAxcU5WWmgNCloxSlJZbkZITjFo VVJGRkRaa055YUhGSlMzSkxRbFIxVUZGY2JqUjJXVXRsVERCMFVXczBWVXBzVUVsdldsaEYNCmJV SnJOV1JyYmk5R2VtdzVRV1pKV2xOMlZYcFJNVkZCYUZFNWIyRk1lalZPWmpWTlYwaFFTMXh1VlZr ck5tSXkNCmVrRXZlVkZoV0dSMVVISldkWGh3TjNoRGFqRXhReTlNYW14b2JERXZTSGd4TmsxS2Ns WXpNMDFEWW1RclVrdFgNCk56RXhSQzh6WEc0d1dHeFhVM0ZGY0hKa1lrdGljWGM0VjAxUWFuVktN V0Z2V0RoaFVVVlhiMHdyZUdKdmJWSlINClVVcEtiMFpoVFZCc2VtZGtSR05tYjBGSVJGVmNibFJ6 ZUdRd0swWk9PSEJHU0VGblRVSkJRVWRxVlVSQ1QwMUMNCk1FZEJNVlZrUkdkUlYwSkNVM0Z3TlZS M1VYUkljMUY1T1c5WlRGcGlNRVExVjF4dUsyeHBZMGhFUVdaQ1owNVcNClNGTk5SVWRFUVZkblFs TnhjRFZVZDFGMFNITlJlVGx2V1V4YVlqQkVOVmNyYkdsalNFUkJUVUpuVGxaSVVrMUYNClhHNUNW RUZFUVZGSUwwMUJNRWREVTNGSFUwbGlNMFJSUlVKRGQxVkJRVFJKUWtGUlFtZFRVVWRoWTJwM2VH MWkNClVuSnlRbWhYTmpObldUVkxZVmRjYm1sdE56WnlSelExY0ROMWFEbEJPRmRWWmsxWGNubERW WFZtY2taUGJTOVINClJVcHViRlZWU3pOUldEUkxSVlpxTW1WNWQySTVaM05tYTJsRFJWeHVlV0ZL ZW5obE5qWTFVVEpDY2xkM1pUTnkNClIxWnJRV2hQTDJadU9IVndaV00wUlRGQlUyTXpNVUZUWVVZ NGJTdHdXWEZEUTFCVFpteE1OV3RXWEc1TlpXWkkNClJ6UnNSWE16V0VwclNHTmxRMnhTZW5sWWRt cGlOVXRxTDNVd01rTTFXVU5xWTBGTVdXUTRMMnRqVTJKbU5HcHYNClpURkhkV1oyUzBaY2JqVjNk bEJDVUd0U1ZtWmlWekpMWVdkTUsycDNOakpxS3poVk5tOUNOMFppZUhSR2VYRlINClVERlpiMXBI YVdFNVRXdFFTMjVMSzNsbk5XOHZNRnh1WTFvMU4yaG5helJ0VVcxTk1XazRNbEp5VlZwUlZtOUMN ClVETkRSRFZNWkVKS1dtWktiMWh6ZEZKc1dHVTJaRmczSzFScGMyUlRRWE53Y0RWbFhHNW9UbTB3 UW1OeFpFeEwNCkszbzRiblIwWEc0aWZYMmdnZ0l0TUlJQ0tUQ0NBYStnQXdJQkFnSUJBVEFLQmdn cWhrak9QUVFEQWpCTk1SSXcNCkVBWUtDWkltaVpQeUxHUUJHUllDWTJFeEdUQVhCZ29Ka2lhSmsv SXNaQUVaRmdsellXNWtaV3h0WVc0eEhEQWENCkJnTlZCQU1NRTFWdWMzUnlkVzVuSUVocFoyaDNZ WGtnUTBFd0hoY05NVFl3TlRBM01ESXpOalUxV2hjTk1UZ3cNCk5UQTNNREl6TmpVMVdqQk5NUkl3 RUFZS0NaSW1pWlB5TEdRQkdSWUNZMkV4R1RBWEJnb0praWFKay9Jc1pBRVoNCkZnbHpZVzVrWld4 dFlXNHhIREFhQmdOVkJBTU1FMVZ1YzNSeWRXNW5JRWhwWjJoM1lYa2dRMEV3ZGpBUUJnY3ENCmhr ak9QUUlCQmdVcmdRUUFJZ05pQUFTcVNpeHJwL1pqME9tbnpobzhiTE9OWWdyUHN4ckwzRFRtSmtx aXlaNFQNCndlL0xLMysvaXdCZ1dub2hLck9Wdk8xUE90YURIZEJ1aVVqWDJDQk02NkZnMThOU3l2 d3pFSkV0Rkx1dEZMN1MNCmNqRFlBOEp6UExDbHcwenQvWUJhZCtDall6QmhNQThHQTFVZEV3RUIv d1FGTUFNQkFmOHdEZ1lEVlIwUEFRSC8NCkJBUURBZ0VHTUIwR0ExVWREZ1FXQkJRbGp0OHRVWGlQ RE95SEtpTDcxUDYrQm5ickJ6QWZCZ05WSFNNRUdEQVcNCmdCUWxqdDh0VVhpUERPeUhLaUw3MVA2 K0JuYnJCekFLQmdncWhrak9QUVFEQWdOb0FEQmxBakI2ZGhmdWphZzINCnhRRWdPVXIxOWlXd0F5 T2h1OW5IVWZjcVhoR2I2aTNuRHVLZmVJVTdBbS9XenZBQW1xQVdYeVFDTVFEVExLYU4NCnZmMmsv L0pjVys0K3hhcFZoVzgzdDhVZGxNazArRW9lL1luS1BqL2ExV0lPdXp6aDZ6SnRDWWpsaW1ZeGdn SEcNCk1JSUJ3Z0lCQVRCU01FMHhFakFRQmdvSmtpYUprL0lzWkFFWkZnSmpZVEVaTUJjR0NnbVNK b21UOGl4a0FSa1cNCkNYTmhibVJsYkcxaGJqRWNNQm9HQTFVRUF3d1RWVzV6ZEhKMWJtY2dTR2xu YUhkaGVTQkRRUUlCQVRBTkJnbGcNCmhrZ0JaUU1FQWdFRkFLQ0I1REFZQmdrcWhraUc5dzBCQ1FN eEN3WUpLb1pJaHZjTkFRY0JNQndHQ1NxR1NJYjMNCkRRRUpCVEVQRncweE56QXpNalV5TWpBek1E aGFNQzhHQ1NxR1NJYjNEUUVKQkRFaUJDQlZMZEx1WEx4TWZFMGcNCmY1aWlVWjhESHVFQWROWjBK bHA5ME1wejVvdmxmVEI1QmdrcWhraUc5dzBCQ1E4eGJEQnFNQXNHQ1dDR1NBRmwNCkF3UUJLakFM QmdsZ2hrZ0JaUU1FQVJZd0N3WUpZSVpJQVdVREJBRUNNQW9HQ0NxR1NJYjNEUU1ITUE0R0NDcUcN ClNJYjNEUU1DQWdJQWdEQU5CZ2dxaGtpRzl3MERBZ0lCUURBSEJnVXJEZ01DQnpBTkJnZ3Foa2lH OXcwREFnSUINCktEQUtCZ2dxaGtqT1BRUURBZ1JuTUdVQ01RRG1EcTl6cHBnbUIzejJ0MkN2bTlI SnYzSTlEb1NCS3dhMXFMZkMNClVqWWpsTm1PRzF0TUF0aXMyTnBiMGlTTlVlb0NNR3RiMjkvN3ND S2g0RG1oaEhKWjB1Q3FNeTRTMGtCVHMrZnMNCnB0R09xQ0hpbWxQWlB1TzZUZWZZeFpURkZ6WlJI QT09DQotLS0tLUVORCBQS0NTNy0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkFuaW1hLWJvb3RzdHJhcCBtYWlsaW5nIGxpc3QNCkFuaW1h LWJvb3RzdHJhcEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hbmltYS1ib290c3RyYXANCg0KDQo= From nobody Tue May 2 18:36:10 2017 Return-Path: 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 06FCE12EB3D; Tue, 2 May 2017 18:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se5T1rzTjZ3o; Tue, 2 May 2017 18:35:56 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0125.outbound.protection.outlook.com [104.47.36.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7B4120725; Tue, 2 May 2017 18:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=G6qilLUBSZlIUatGxEmJhzwDOHaofckBd3yQfXA88vI=; b=cz/b8hZ6Cr6GM9SFKCtfK6cqoQfgOlwd/c4ItbwmudAsUl2C3MMDgTrQCsmrnhSYuz1dO/qohG3UMhTwy8Jv06lleo1WLT5hTg0LS8cowRVZ6akZoHXrFEKZnS2zoDM1ZTQt2HYCc7/2L/qfh3cvPIcyV8U3gwwAbFJ/fGKxgGc= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Wed, 3 May 2017 01:33:23 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1075.010; Wed, 3 May 2017 01:33:23 +0000 From: Kent Watsen To: "Max Pritikin (pritikin)" , "anima@ietf.org" CC: "anima-bootstrap@ietf.org" Thread-Topic: [Anima-bootstrap] Voucher signing method Thread-Index: AQHSw6vLF2XUnWVoW0q/VYcsqILMZqHhkBoA Date: Wed, 3 May 2017 01:33:23 +0000 Message-ID: <5DB4ED7C-3427-4AE0-B2C7-4A44D5F8D235@juniper.net> References: <88FB0F4F-2816-4BCE-A775-EBEE1CFCC0CD@juniper.net> In-Reply-To: <88FB0F4F-2816-4BCE-A775-EBEE1CFCC0CD@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:+VagDuUTs28+bIVOK4ccsZlBRoTYez/cdxisOv+7oyMI2QRhTF9k1/+N1bUBCb6np0rFMMSulyds0rUQ9TbOo7ZM+7ljk1qmf22G7UwGj3S4HssLt+z2u9sobmWGqewDfAHD2LHEJ/QkQUrZr56W3zO0S31EkPRHSltyLaHVh6+pc5nYjLQBYPaky47Y+fgZ8mHZnBwvnrNg+v4HW/fA4zCk58L3kis0qpCKEGU2ocm9j4lXKDS4tfxLh3PxDew0768xQXmoS1ljZlFoYh5kqvTYoma6vrqC+N9tX3zPwn+ZyPVtyxEAJjYT8/gm3D7YgNdEkcszxWuuZD85vyAqJg== x-ms-office365-filtering-correlation-id: 84d8104f-8b25-4b33-64c7-08d491c46364 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39860400002)(39840400002)(39450400003)(99286003)(6306002)(6246003)(38730400002)(53946003)(53936002)(54356999)(25786009)(50986999)(6512007)(4326008)(76176999)(2900100001)(189998001)(2950100002)(86362001)(6486002)(77096006)(305945005)(6506006)(6436002)(4001350100001)(8936002)(122556002)(66066001)(83506001)(36756003)(2906002)(6116002)(8676002)(5660300001)(3846002)(82746002)(102836003)(81166006)(229853002)(575784001)(3660700001)(478600001)(2501003)(3280700002)(33656002)(83716003)(579004)(473944003)(414714003)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2017 01:33:23.2286 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Subject: Re: [Anima] [Anima-bootstrap] Voucher signing method X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 01:36:08 -0000 DQpCVFcsIEVTMjU2IHVzZXMgdGhlIFAtMjU2IGN1cnZlIChha2Egc2VjcDI1NnIxKSB3aGljaCBo YXMgc2luY2UgYmVlbiBkZXByZWNhdGVkLiAgSSBnb3QgYSBraWNrIG91dCBvZiBSRkMgNzUxOCBn aXZpbmcgaXQgYSAicmVjb21tZW5kZWQrIiByYXRpbmcgIDspDQoNCksuDQoNCg0KLS0tLS1PUklH SU5BTCBNRVNTQUdFLS0tLS0NCg0KSSd2ZSBoYWQgc29tZSB0aW1lIG5vdyB0byBpbnZlc3RpZ2F0 ZSBKV1MsIGluIHBhcnRpY3VsYXIsIHJlcHJvZHVjaW5nIHNvbWUgZXhhbXBsZXMgaW4gUkZDcyA3 NTE1IGFuZCA3NTIwIHVzaW5nIG5vdGhpbmcgYnV0IHNoZWxsIHNjcmlwdHMgYW5kIHRoZSBgb3Bl bnNzbGAgY29tbWFuZCBsaW5lIHV0aWxpdHkuDQoNCkkgd2FudCB0byBsaWtlIEpXUywgYnV0IEkg d2lzaCB0aGUgaGVhZGVyIHdhcyBpbiBhIG1vcmUgdGVjaG5vbG9neS1uZXV0cmFsIGZvcm1hdCwg aXQgYmVpbmcgSlNPTiBzZWVtcyB3ZWlyZCB0byBtZS4gIEhhZCB0aGlzIGJlZW4gZG9uZSwgaXQg d291bGQgYmUgYSBuaWNlIGdlbmVyYWwtcHVycG9zZSBzaWduYXR1cmUgZm9ybWF0LiAgU2l6ZSB3 aXNlLCBKV1MgZ3Jvd3MgdGhlIHNpemUgb2YgdGhlIGRhdGEgMzMlIHdoZW4gYjY0IGVuY29kaW5n IGl0IGZvciB0aGUgImNvbXBhY3Qgc2VyaWFsaXphdGlvbiIgZm9ybSwgd2hpY2ggaXMgYWN0dWFs bHkgYSA2NS1jaGFyYWN0ZXIgYWxwaGFiZXQgaW5jbHVkaW5nICcuJy4gIEl0IHNlZW1zIHRoYXQg YSBiaW5hcnkgaGVhZGVyIGNvdWxkJ3ZlIGFsc28gYWxsb3dlZCBmb3IgYSBiaW5hcnkgcGF5bG9h ZCBhbmQgc2lnbmF0dXJlLCB3aGljaCB3b3VsZCd2ZSBiZWVuIHBlcmZlY3QsIGluIG15IG9waW5p b24uICBbT2YgY291cnNlLCB0aGUgZW50aXJlIGJpbmFyeSBibG9iIGNvdWxkIHN0aWxsIGJlIGJh c2U2NHVybC1lbmNvZGVkIGZvciB0aG9zZSB0aGF0IHdhbnQgaXQsIHdpdGhvdXQgZm9yY2luZyBp dCBvbiB0aG9zZSB0aGF0IGRvbuKAmXRdDQoNClRoZSBleGFtcGxlIHZvdWNoZXIgeW91IG9idGFp bmVkIGZyb20gbWNyIHdhc24ndCBhcyB0cmltbWVkIGRvd24gYXMgaXQgY291bGQndmUgYmVlbiwg dXNpbmcgdGhlIC1ub2F0dHIgYW5kIC1ub2NlcnQgb3B0aW9ucywgd2hpY2ggaXMgb25lIHJlYXNv biB0aGUgYXNuMXBhcnNlIGR1bXAgbG9va3MgYXMgYnVzeSBhcyBpdCBkb2VzLiAgQW5vdGhlciBi ZWluZyB0aGF0IHRoZSBvd25lci9kb21haW4tY2VydC10cnVzdGVkLWNhIGVuY29kZSB2ZXJ5IGRp ZmZlcmVudCBjZXJ0cyAoaXMgb25lIGVjIHdoaWxlIHRoZSBvdGhlciBpcyByc2E/KQ0KDQpJbiB0 aGUgZW5kLCBKV1MgYXBwZWFycyB0byBiZSBqdXN0IGFub3RoZXIgc2lnbmF0dXJlIGZvcm1hdCB3 aXRoIGl0cyBvd24gc2V0IG9mIHBlY3VsaWFyaXRpZXMuICBBbmQgZ2l2ZW4gdGhhdCB3ZSBhbHJl YWR5IGhhdmUgdG8gc3VwcG9ydCBBU04uMSAodGhlIHZvdWNoZXIgZW5jb2RlcyBib3RoIGFuIFgu NTA5IGNlcnQgYXMgd2VsbCBhcyBhIFguNTA5IGNlcnRpZmljYXRlIGNoYWluKSwgbm90IHRvIG1l bnRpb24gdGhlIG5lZWQgZm9yIHRoZSBNQVNBIHRvIGhhdmUgYSBQS0lYIGluZnJhc3RydWN0dXJl LCBpdCdzIG5vdCBjbGVhciB0byBtZSBpZiB0aGlzIGlzIGEgZ29vZCB0cmFkZSBhdCBhbGwuDQoN Ckxhc3RseSwgYXMgbWVudGlvbmVkIGJlZm9yZSwgbXkgbmV0Y29uZiB6ZXJvdG91Y2ggZHJhZnQg dXNlcyBDTVMvUEtDUzcgZWxzZXdoZXJlLiAgV2hpbGUgaXQgd291bGQgYmUgdHJpdmlhbCB0byB1 cGRhdGUgdGhlIGRyYWZ0IHRvIHVzZSBhIEpXUy1iYXNlZCBmb3JtYXQsIGl0IHdvdWxkIGJlIGF3 a3dhcmQgZm9yIGNsaWVudHMgdG8gaGF2ZSB0byBjb25zaWRlciBpdCBhdCBhbGwuDQoNCktlbnQN Cg0KDQotLS0tLU9SSUdJTkFMIE1FU1NBR0UtLS0tLQ0KDQpGb2xrcywgaW4gQ2hpY2FnbyB3ZSBk aXNjdXNzZWQgdGhlIHNpZ25pbmcgbWV0aG9kIGZvciB2b3VjaGVycy4gDQoNCkJlY2F1c2UgdGhl IHZvdWNoZXIgaXMgSlNPTiwgYW5kIHRoZXJlIGlzIGV4cGVjdGF0aW9uIG9mIGEgQ0JPUiBlbmNv ZGluZyBmb3IgZnV0dXJlIHdvcmssIHRoZXJlIGlzIGFuIG9wZW4gZGlzY3Vzc2lvbiBwb2ludCBh Ym91dCB1c2luZyB0aGUgSldTL0NPU0Ugc2lnbmluZyBtZXRob2RzOyBpZiBub3QgSldUL0NXVC4g VGhlcmUgd2FzIGJyaWVmIGRpc2N1c3Npb24gb2YgdGhpcyBhdCBJRVRGOTggYW5kIG9uZSBwZXJz b24gaW5kaWNhdGVkIHRoZXkgbGlrZWQgUEtDUzcsIG90aGVycyBpbmRpY2F0ZXMgSldUIGFuZCBv dGhlcnMgZGlkIG5vdCBzcGVhayB1cC4gRnVsbHkgbWVldGluZyBtaW51dGVzIG1pZ2h0IHByb3Zp ZGUgbW9yZSBpbmZvcm1hdGlvbiBidXQgbXkgcmVjb2xsZWN0aW9uIHdhcyB0aGF0IHdl4oCZZCBt b3ZlIHRoZSBkaXNjdXNzaW9uIHRvIHRoZSBsaXN0LiBUaGlzIHRocmVhZCBpcyBmb3IgdGhhdCBk aXNjdXNzaW9uLiANCg0KVGhlIGN1cnJlbnQgdGV4dCBvZiBkcmFmdC1pZXRmLWFuaW1hLXZvdWNo ZXItMDIgaXM6DQoNCj4gVGhlIHZvdWNoZXIgaXMgc2lnbmVkIGEgUEtDUyM3IFNpZ25lZERhdGEg c3RydWN0dXJlLCBhcyBzcGVjaWZpZWQgYnkgU2VjdGlvbiA5LjENCj4gb2YgW1JGQzIzMTVdLCBl bmNvZGVkIHVzaW5nIEFTTi4xIGRpc3Rpbmd1aXNoZWQgZW5jb2RpbmcgcnVsZXMgKERFUiksIGFz IHNwZWNpZmllZCBpbiBJVFUtVCBYLjY5MC4NCg0KDQpGb3IgY29uY3JldGUgZGlzY3Vzc2lvbiwg dGhlIHByb3Bvc2VkIGNoYW5nZSBpczoNCg0KPiBUaGUgdm91Y2hlciBpcyBhIEpXVCBbUkZDNzUx OV0gc2lnbmVkIHRva2VuLg0KDQoNCknigJl2ZSB1cGRhdGVkIG15IHRvb2xpbmcgdGhhdCB3YXMg dXNlZCBkdXJpbmcgdGhlIElFVEY5OCBoYWNrYXRob24gdG8gc3VwcG9ydCBhIEpXVCB0b2tlbiBm b3JtYXQ7IEkgZGlkIHRoaXMgYXMgaG9tZXdvcmsgdG8gYmUgaW5mb3JtZWQgZm9yIHRoZSBkaXNj dXNzaW9uLiANCg0KTVkgUE9TSVRJT046IGlzIHRoYXQgSSBhcHByZWNpYXRlIHRoZSBzaW1wbGlj aXR5IG9mIHRoZSBKV1Mgc2lnbmluZyBhbmQgZmVlbCBpdCBpcyBhIGdvb2QgbWF0Y2ggZm9yIHVz LiBJdCB3YXMgZWFzeSBlbm91Z2ggdG8gaW1wbGVtZW50LCB3YXMgYSByZWZyZXNoaW5nIGNoYW5n ZSBmcm9tIHRoZSBBU04xIGNvbXBsZXhpdHkgb2YgUEtDUzcsIGFuZCBzZWVtcyB0byBwcm92aWRl IGEgZ29vZCBwYXRoIHRvd2FyZCBDQk9SL0NPU0UgaW4gYSBmdXR1cmUgZG9jdW1lbnQgd2l0aG91 dCBtYWludGFpbmluZyBQS0NTNy9DTVMgdGVjaG5pY2FsIGRlYnQgb3IgcmV2aXNpdGluZy9yZXdy aXRpbmcgdG9vIG11Y2guIA0KDQpRVUVTVElPTiBGT1IgVEhFIFdPUktJTkcgR1JPVVA6IFdoYXQg aXMgeW91ciBwb3NpdGlvbj8gV2h5PyANCg0KV2hhdCBmb2xsb3dzIGlzIGEgZHVtcCBvZiB0aGUg cmF3IEpXUyBiZWZvcmUgc2lnbmluZyAodGhlIGVxdWl2YWxlbnQgUEtDUzcvQ01TIHN0cnVjdHVy ZSB3b3VsZCBiZSB0aGUgU2lnbmVkRGF0YSBhc24xIHN0cnVjdHVyZXMgd2hpY2ggaXMgaGFyZCB0 byBjYXB0dXJlKS4gQWZ0ZXIgdGhhdCBpcyBhbiBlbmNvZGVkIGFuZCBzaWduZWQgdm91Y2hlci4g RnVydGhlciBiZWxvdyBpcyBhbiBleGFtcGxlIG9mIGEgUEtDUzcgc2lnbmVkIHZvdWNoZXIuIA0K DQpQbGVhc2Ugbm90ZSB0aGVzZSBjaGFyYWN0ZXJpc3RpY3M6DQoNCmEpIEZyb20gSldUIFJGQzc1 MTkgIkpXVHMgYXJlIGFsd2F5cyByZXByZXNlbnRlZCB1c2luZyB0aGUgSldTIENvbXBhY3QgU2Vy aWFsaXphdGlvbuKAnS4gVGhlcmUgYXJlIHNvbWUgSldUIGhlYWRlcnMgdGhhdCBvdmVybGFwIHdp dGggdm91Y2hlciBmaWVsZHMuIEnigJltIHVzaW5nIEpXVCBoZXJlOyBidXQgdGhlIGRpc3RpbmN0 aW9uIGJldHdlZW4gSldTL0pXVCBpcyBub3QgZnVuZGFtZW50YWwgdG8gb3VyIGRpc2N1c3Npb24u IFRoZSBpbXBvcnRhbnQgcG9pbnQgaXMgSldTIHZzIFBLQ1M3LiANCg0KYikgSeKAmXZlIGFkZGVk IHRoZSB4NWMgaGVhZGVyIHRvIHRoZSBKV1MuIFRoaXMgaXMgdXNlZCB0byBjYXJyeSB0aGUgY2Vy dGlmaWNhdGUgY2hhaW4gb2YgdGhlIHNpZ25lci4gT3VyIGN1cnJlbnQgdm91Y2hlciBmb3JtYXQg aW5kaWNhdGVzIFBLQ1M3IHdoaWNoIHN1cHBvcnRzIGFuIGVxdWl2YWxlbnQgZmllbGQgY2FsbGVk IOKAnENlcnRpZmljYXRlU2V0IHN0cnVjdHVyZeKAnS4gSXRzIGluIHRoZSBCUlNLSSBkb2N1bWVu dCB0aGF0IHdlIHNwZWNpZnkgIlRoZSBlbnRpcmUgY2VydGlmaWNhdGUgY2hhaW4sIHVwIHRvIGFu ZCBpbmNsdWRpbmcgdGhlIERvbWFpbiBDQSwgTVVTVCBiZSBpbmNsdWRlZCBpbiB0aGUgQ2VydGlm aWNhdGVTZXQgc3RydWN0dXJl4oCdLiBXaXRoIHRoZSB0cmFuc2l0aW9uIHRvIEpXVCB3ZeKAmWQg YmUgc3BlY2lmeWluZyB0aGF0IHRoZSB4NWMgaGVhZGVyIGJlIGZ1bGx5IHBvcHVsYXRlZCB1cCB0 byBhbiBpbmNsdWRpbmcgdGhlIERvbWFpbiBDQSBldGMuIA0KDQpjKSBGcm9tIHRoZXNlIGV4YW1w bGVzIHdlIGNhbuKAmXQgZGlyZWN0bHkgY29tcGFyZSBzaXplIGVuY29kaW5ncy4gSSBkb27igJl0 IHRoaW5rIHRoaXMgaXMgYSBzaWduaWZpY2FudCBhc3BlY3Qgb2YgdGhlIGNvbnZlcnNhdGlvbiBi dXQgY2FuIGNyZWF0ZSBjb21wYXJhYmxlIGV4YW1wbGVzIGlmIGZvbGtzIGZlZWwgdGhhdCBpcyBu ZWNlc3NhcnkuIA0KDQpUaGUgZHVtcHM6DQoNCkEgZGVidWcgZHVtcCBvZiB0aGUgSldUIGZvcm0g YmVmb3JlIGVuY29kaW5nOg0Kew0KICAgInR5cCI6ICJKV1QiLA0KICAgImFsZyI6ICJFUzI1NiIs DQogICAieDVjIjogWyJNSUlCZGpDQ0FSMmdBd0lCQWdJQkFUQUtCZ2dxaGtqT1BRUURBakFyTVJZ d0ZBWURWUVFLREExRGFYTmpieUJUZVhOMFpXMXpNUkV3RHdZRFZRUUREQWhXWlc1a2IzSkRRVEFl RncweE56QTBNRE14TlRFMU5EVmFGdzB4T0RBME1ETXhOVEUxTkRWYU1DMHhGakFVQmdOVkJBb01E VU5wYzJOdklGTjVjM1JsYlhNeEV6QVJCZ05WQkFNTUNsWmxibVJ2Y2sxQlUwRXdXVEFUQmdjcWhr ak9QUUlCQmdncWhrak9QUU1CQndOQ0FBVDlHVHJEZDBHV2d3Y3VTeThMQ24wd2FNZWtucEx6bmFq WnpxV2xMaHJQd3NoZ0lQSVB2YnlZNkl5Q280dUJZVS9lNE9PNlRRRDlVVkxseVU1UjZjQTZvekF3 TGpBTEJnTlZIUThFQkFNQ0JhQXdId1lEVlIwakJCZ3dGb0FVUjRvRXBiNFlGdWVsa01yUWpsbkt0 TTAxb3ZFd0NnWUlLb1pJemowRUF3SURSd0F3UkFJZ0FROFlSMklkTG9kRUU4aytKeHBCT0lBR3V6 Q2VUOUJtRk9WaEZVYjhlSk1DSUMyM0dvc3M2bWFuUmpOU21oNisyb0I5dHNSYmptbm53dU1sRFhS OGZ6dWciLCAiTUlJQm5UQ0NBVU9nQXdJQkFnSUpBSzlQZDVHKy9yMFVNQW9HQ0NxR1NNNDlCQU1D TUNzeEZqQVVCZ05WQkFvTURVTnBjMk52SUZONWMzUmxiWE14RVRBUEJnTlZCQU1NQ0ZabGJtUnZj a05CTUI0WERURTNNRFF3TXpFME1UQXdOVm9YRFRFNE1EUXdNekUwTVRBd05Wb3dLekVXTUJRR0Ex VUVDZ3dOUTJselkyOGdVM2x6ZEdWdGN6RVJNQThHQTFVRUF3d0lWbVZ1Wkc5eVEwRXdXVEFUQmdj cWhrak9QUUlCQmdncWhrak9QUU1CQndOQ0FBU3Vuc1FMMlBWT1NGV1dwMG9DamxxRjhpVlBQcEVn SmN0OTMxQ1pRNmFzc3AwN290bWZnWnFYc2sxSllSVGxLQ0dqUk94ckFpVlJRc0I1NGlvQTB5dTBv MUF3VGpBZEJnTlZIUTRFRmdRVVI0b0VwYjRZRnVlbGtNclFqbG5LdE0wMW92RXdId1lEVlIwakJC Z3dGb0FVUjRvRXBiNFlGdWVsa01yUWpsbkt0TTAxb3ZFd0RBWURWUjBUQkFVd0F3RUIvekFLQmdn cWhrak9QUVFEQWdOSUFEQkZBaUVBK1NTT2hpTlEyM1JXQTc2a1ovMnU3MEZDcFU4T3NVN1g5SVJp V0dEZ0lBZ0NJRkx1OEZuSnVxUHgxMHNnSHZJenFJNUJnT2N3Q2E1dkZRWmRDREJISXgxOCJdDQp9 DQouDQp7DQogICAiaWV0Zi12b3VjaGVyOnZvdWNoZXIiOiB7DQogICAgICAgImFzc2VydGlvbiI6 ICJsb2dnaW5nIiwNCiAgICAgICAiZG9tYWluLWNlcnQtdHJ1c3RlZC1jYSI6ICItLS0tLUJFR0lO IENFUlRJRklDQVRFLS0tLS1cbk1JSUJVakNCK3FBREFnRUNBZ2tBd1A0cUtzR3lRbFl3Q2dZSUtv Wkl6ajBFQXdJd0Z6RVZNQk1HQTFVRUF3d01cblpYTjBSWGhoYlhCc1pVTkJNQjRYRFRFM01ETXlO VEl5TVRjMU1Gb1hEVEU0TURNeU5USXlNVGMxTUZvd0Z6RVZcbk1CTUdBMVVFQXd3TVpYTjBSWGho YlhCc1pVTkJNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUVcblJWck5sRU4yb2NZ c2NBSUxCVTdOZ2dBQm8wSmdBMXJFR2RZZENRajFuSEtMNnhLT05KSVVmQmliZTZpTVZZZDNcblJV bVB3YVBpSE5aSjk4a1J3SEl3bktNdk1DMHdEQVlEVlIwVEJBVXdBd0VCL3pBZEJnTlZIUTRFRmdR VStkVlhcbmFYb3VjVTFnb2RORjBieWNTMVU1VzU0d0NnWUlLb1pJemowRUF3SURSd0F3UkFJZ05z Q0dqcEVqdXZ6Nk9LSi9cbjNyT3ZNYzJaZkRoRDAySyswUENWRkpHQ1FHd0NJQXpmM0JTNng5a0tT Uk9KSnZ4RFNwZzBRSzkrYjlMU0ZrYlpcbk0xUFc5OEFOXG4tLS0tLUVORCBDRVJUSUZJQ0FURS0t LS0tXG4iLA0KICAgICAgICJub25jZSI6ICJlYTcxMDJlOGU4OGYxMTllIiwNCiAgICAgICAic2Vy aWFsLW51bWJlciI6ICJQSUQ6MSBTTjp3aWRnZXQxIiwNCiAgICAgICAic2VyaWFsLW51bWJlci1p c3N1ZXIiOiAiMzYwOTdFM0RFQTM5MzE2RUE0Q0U1QzY5NUJFOTA1RTc4QUYyRkI1QSIsDQogICAg ICAgInZlcnNpb24iOiAiMSINCiAgIH0NCn0NCi4NCltzaWduYXR1cmUgZ29lcyBoZXJlXQ0KDQpB cyBwZXIgSldUIFJGQzc1MTkgdGhpcyBpcyB3aGF0IGl0IGxvb2tzIGxpa2UgYWZ0ZXIgVVJMLXNh ZmUgZW5jb2RpbmcuIFlvdSBjYW4gc2VlIHRoYXQgbm93IHRoZSBzaWduYXR1cmUgaXMgaW5jbHVk ZWQgIChsb29rIHRvIHRoZSBzZWNvbmQgdG8gbGFzdCBsaW5lIHRvIHNlZSB0aGUgc2Vjb25kIOKA nC7igJ0gZm9sbG93ZWQgYnkgYSB2YWxpZCBzaWduYXR1cmUpOiANCg0KZXlKMGVYQWlPaUpLVjFR aUxDSmhiR2NpT2lKRlV6STFOaUlzSUNBZ0lDSjROV01pT2xzaVRVbEpRbVJxUTBOQlVqSm5RWGRK UWtGblNVSkJWRUZMUW1kbmNXaHJhazlRVVZGRVFXcEJjazFTV1hkR1FWbEVWbEZSUzBSQk1VUmhX RTVxWW5sQ1ZHVllUakJhVnpGNlRWSkZkMFIzV1VSV1VWRkVSRUZvVjFwWE5XdGlNMHBFVVZSQlpV WjNNSGhPZWtFd1RVUk5lRTVVUlRGT1JGWmhSbmN3ZUU5RVFUQk5SRTE0VGxSRk1VNUVWbUZOUXpC NFJtcEJWVUpuVGxaQ1FXOU5SRlZPY0dNeVRuWkpSazQxWXpOU2JHSllUWGhGZWtGU1FtZE9Wa0pC VFUxRGJGcHNZbTFTZG1Ock1VSlZNRVYzVjFSQlZFSm5ZM0ZvYTJwUFVGRkpRa0puWjNGb2EycFBV RkZOUWtKM1RrTkJRVlE1UjFSeVJHUXdSMWRuZDJOMVUzazRURU51TUhkaFRXVnJibkJNZW01aGFs cDZjVmRzVEdoeVVIZHphR2RKVUVsUWRtSjVXVFpKZVVOdk5IVkNXVlV2WlRSUFR6WlVVVVE1VlZa TWJIbFZOVkkyWTBFMmIzcEJkMHhxUVV4Q1owNVdTRkU0UlVKQlRVTkNZVUYzU0hkWlJGWlNNR3BD UW1kM1JtOUJWVkkwYjBWd1lqUlpSblZsYkd0TmNsRnFiRzVMZEUwd01XOTJSWGREWjFsSlMyOWFT WHBxTUVWQmQwbEVVbmRCZDFKQlNXZEJVVGhaVWpKSlpFeHZaRVZGT0dzclNuaHdRazlKUVVkMWVr TmxWRGxDYlVaUFZtaEdWV0k0WlVwTlEwbERNak5IYjNOek5tMWhibEpxVGxOdGFEWXJNbTlDT1hS elVtSnFiVzV1ZDNWTmJFUllVamhtZW5Wbklpd2lUVWxKUW01VVEwTkJWVTluUVhkSlFrRm5TVXBC U3psUVpEVkhLeTl5TUZWTlFXOUhRME54UjFOTk5EbENRVTFEVFVOemVFWnFRVlZDWjA1V1FrRnZU VVJWVG5Cak1rNTJTVVpPTldNelVteGlXRTE0UlZSQlVFSm5UbFpDUVUxTlEwWmFiR0p0VW5aamEw NUNUVUkwV0VSVVJUTk5SRkYzVFhwRk1FMVVRWGRPVm05WVJGUkZORTFFVVhkTmVrVXdUVlJCZDA1 V2IzZExla1ZYVFVKUlIwRXhWVVZEWjNkT1VUSnNlbGt5T0dkVk0yeDZaRWRXZEdONlJWSk5RVGhI UVRGVlJVRjNkMGxXYlZaMVdrYzVlVkV3UlhkWFZFRlVRbWRqY1docmFrOVFVVWxDUW1kbmNXaHJh azlRVVUxQ1FuZE9RMEZCVTNWdWMxRk1NbEJXVDFOR1YxZHdNRzlEYW14eFJqaHBWbEJRY0VWblNt TjBPVE14UTFwUk5tRnpjM0F3TjI5MGJXWm5XbkZZYzJzeFNsbFNWR3hMUTBkcVVrOTRja0ZwVmxK UmMwSTFOR2x2UVRCNWRUQnZNVUYzVkdwQlpFSm5UbFpJVVRSRlJtZFJWVkkwYjBWd1lqUlpSblZs Ykd0TmNsRnFiRzVMZEUwd01XOTJSWGRJZDFsRVZsSXdha0pDWjNkR2IwRlZValJ2UlhCaU5GbEdk V1ZzYTAxeVVXcHNia3QwVFRBeGIzWkZkMFJCV1VSV1VqQlVRa0ZWZDBGM1JVSXZla0ZMUW1kbmNX aHJhazlRVVZGRVFXZE9TVUZFUWtaQmFVVkJLMU5UVDJocFRsRXlNMUpYUVRjMmExb3ZNblUzTUVa RGNGVTRUM05WTjFnNVNWSnBWMGRFWjBsQlowTkpSa3gxT0VadVNuVnhVSGd4TUhOblNIWkplbkZK TlVKblQyTjNRMkUxZGtaUldtUkRSRUpJU1hneE9DSmRmUS5leUpwWlhSbUxYWnZkV05vWlhJNmRt OTFZMmhsY2lJNmV5SmhjM05sY25ScGIyNGlPaUpzYjJkbmFXNW5JaXdpWkc5dFlXbHVMV05sY25R dGRISjFjM1JsWkMxallTSTZJaTB0TFMwdFFrVkhTVTRnUTBWU1ZFbEdTVU5CVkVVdExTMHRMVnh1 VFVsSlFsVnFRMElyY1VGRVFXZEZRMEZuYTBGM1VEUnhTM05IZVZGc1dYZERaMWxKUzI5YVNYcHFN RVZCZDBsM1JucEZWazFDVFVkQk1WVkZRWGQzVFZ4dVdsaE9NRkpZYUdoaVdFSnpXbFZPUWsxQ05G aEVWRVV6VFVSTmVVNVVTWGxOVkdNeFRVWnZXRVJVUlRSTlJFMTVUbFJKZVUxVVl6Rk5SbTkzUm5w RlZseHVUVUpOUjBFeFZVVkJkM2ROV2xoT01GSllhR2hpV0VKeldsVk9RazFHYTNkRmQxbElTMjlh U1hwcU1FTkJVVmxKUzI5YVNYcHFNRVJCVVdORVVXZEJSVnh1VWxaeVRteEZUakp2WTFselkwRkpU RUpWTjA1blowRkNiekJLWjBFeGNrVkhaRmxrUTFGcU1XNUlTMHcyZUV0UFRrcEpWV1pDYVdKbE5t bE5WbGxrTTF4dVVsVnRVSGRoVUdsSVRscEtPVGhyVW5kSVNYZHVTMDEyVFVNd2QwUkJXVVJXVWpC VVFrRlZkMEYzUlVJdmVrRmtRbWRPVmtoUk5FVkdaMUZWSzJSV1dGeHVZVmh2ZFdOVk1XZHZaRTVH TUdKNVkxTXhWVFZYTlRSM1EyZFpTVXR2V2tsNmFqQkZRWGRKUkZKM1FYZFNRVWxuVG5ORFIycHdS V3AxZG5vMlQwdEtMMXh1TTNKUGRrMWpNbHBtUkdoRU1ESkxLekJRUTFaR1NrZERVVWQzUTBsQmVt WXpRbE0yZURsclMxTlNUMHBLZG5oRVUzQm5NRkZMT1N0aU9VeFRSbXRpV2x4dVRURlFWems0UVU1 Y2JpMHRMUzB0UlU1RUlFTkZVbFJKUmtsRFFWUkZMUzB0TFMxY2JpSXNJbTV2Ym1ObElqb2laV0Uz TVRBeVpUaGxPRGhtTVRFNVpTSXNJbk5sY21saGJDMXVkVzFpWlhJaU9pSlFTVVE2TVNCVFRqcDNh V1JuWlhReElpd2ljMlZ5YVdGc0xXNTFiV0psY2kxcGMzTjFaWElpT2lJek5qQTVOMFV6UkVWQk16 a3pNVFpGUVRSRFJUVkROamsxUWtVNU1EVkZOemhCUmpKR1FqVkJJaXdpZG1WeWMybHZiaUk2SWpF aWZYMC5Ra1RVcGN4djZOZzZ5bHlXWW5scXVuLTVTRmhEMVh3TElXMWtEN1k5ZE53aW9oZU5NY1Zu b3drRUxsX0VNQ2x5T1d1THZ2V3VvQ0hBY1d6X1VBMElHdw0KDQoNCkhlcmUgaXMgYW4gZXF1aXZh bGVudCBQS0NTNyB2b3VjaGVyIHZpYSBhc24xIGR1bXAuIFlvdeKAmWQgaGF2ZSB0byBsb29rIGF0 IHRoZSBiaW5hcnkgaWYgeW91IHJlYWxseSB3YW50IHRvIGRlY29kZSBpdC4gVGhpcyB2b3VjaGVy IHdhcyBnZW5lcmF0ZWQgYnkgTUNSIGR1cmluZyB0aGUgaGFja2F0aG9uOiANCg0KcHJpdGlraW5A dWJ1bnR1On4vc3JjL2Jyc2tpLXByb2plY3QvYnJza2lfbXNncyQgb3BlbnNzbCBhc24xcGFyc2Ug LWluIG1jci52b3VjaGVyLnR4dC5wa2NzNw0KICAgIDA6ZD0wICBobD00IGw9MjcwNiBjb25zOiBT RVFVRU5DRSAgICAgICAgICANCiAgICA0OmQ9MSAgaGw9MiBsPSAgIDkgcHJpbTogT0JKRUNUICAg ICAgICAgICAgOnBrY3M3LXNpZ25lZERhdGENCiAgIDE1OmQ9MSAgaGw9NCBsPTI2OTEgY29uczog Y29udCBbIDAgXSAgICAgICAgDQogICAxOTpkPTIgIGhsPTQgbD0yNjg3IGNvbnM6IFNFUVVFTkNF ICAgICAgICAgIA0KICAgMjM6ZD0zICBobD0yIGw9ICAgMSBwcmltOiBJTlRFR0VSICAgICAgICAg ICA6MDENCiAgIDI2OmQ9MyAgaGw9MiBsPSAgMTUgY29uczogU0VUICAgICAgICAgICAgICAgDQog ICAyODpkPTQgIGhsPTIgbD0gIDEzIGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KICAgMzA6ZD01 ICBobD0yIGw9ICAgOSBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6c2hhMjU2DQogICA0MTpkPTUg IGhsPTIgbD0gICAwIHByaW06IE5VTEwgICAgICAgICAgICAgIA0KICAgNDM6ZD0zICBobD00IGw9 MTY0NCBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCiAgIDQ3OmQ9NCAgaGw9MiBsPSAgIDkgcHJp bTogT0JKRUNUICAgICAgICAgICAgOnBrY3M3LWRhdGENCiAgIDU4OmQ9NCAgaGw9NCBsPTE2Mjkg Y29uczogY29udCBbIDAgXSAgICAgICAgDQogICA2MjpkPTUgIGhsPTQgbD0xNjI1IHByaW06IE9D VEVUIFNUUklORyAgICAgIDp7ImlldGYtdm91Y2hlcjp2b3VjaGVyIjp7Im5vbmNlIjoiNjJhMmU3 NjkzZDgyZmNkYTI2MjRkZTU4ZmI2NzIyZTUiLCJjcmVhdGVkLW9uIjoiMjAxNy0wMS0wMVQwMDow MDowMC4wMDBaIiwiZGV2aWNlLWlkZW50aWZpZXIiOiIwMC1kMC1lNS1mMi0wMC0wMSIsImFzc2Vy dGlvbiI6ImxvZ2dlZCIsIm93bmVyIjoiTUlJRUV6Q0NBdnVnQXdJQkFnSUpBSzZyRm91dmsrN1lN QTBHQ1NxR1NJYjNEUUVCQ3dVQU1JR2ZNUXN3XG5DUVlEVlFRR0V3SkRRVEVRTUE0R0ExVUVDQXdI VDI1MFlYSnBiekVQTUEwR0ExVUVCd3dHVDNSMFlYZGhcbk1Sb3dHQVlEVlFRS0RCRlBkMjVsY2lC RmVHRnRjR3hsSUU5dVpURVJNQThHQTFVRUN3d0lUbTkwSUZabFxuY25reEd6QVpCZ05WQkFNTUVt OTNibVZ5TVM1bGVHRnRjR3hsTG1OdmJURWhNQjhHQ1NxR1NJYjNEUUVKXG5BUllTYjNkdVpYSXhR R1Y0WVcxd2JHVXVZMjl0TUI0WERURTNNRE15TlRFMk1qa3pORm9YRFRFM01EUXlcbk5ERTJNamt6 TkZvd2daOHhDekFKQmdOVkJBWVRBa05CTVJBd0RnWURWUVFJREFkUGJuUmhjbWx2TVE4d1xuRFFZ RFZRUUhEQVpQZEhSaGQyRXhHakFZQmdOVkJBb01FVTkzYm1WeUlFVjRZVzF3YkdVZ1QyNWxNUkV3 XG5Ed1lEVlFRTERBaE9iM1FnVm1WeWVURWJNQmtHQTFVRUF3d1NiM2R1WlhJeExtVjRZVzF3YkdV dVkyOXRcbk1TRXdId1lKS29aSWh2Y05BUWtCRmhKdmQyNWxjakZBWlhoaGJYQnNaUzVqYjIwd2dn RWlNQTBHQ1NxR1xuU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLQW9JQkFRQzRRWUFFblR0WGdpS3Fz ZlNWWWtna0hkZEZjUDM0XG5PVTNZUDdpYnJzZ3gwaTljeWo3eE96V0hPRjJQc29LQmdUUkg3NU1T TWhUbDVVaWRyQ3N6bGx1SytxcDRcbmQzWmczMW9RTS9IRG15Ukp5UnBZK1BDMW41VngvTWo1VmFn UlFicUc3WFREUUNmQ3JocUlLcktCVHVQUVxuNHZZS2VMMHRRazRVSmxQSW9aWEVtQms1ZGtuL0Z6 bDlBZklaU3ZVelExUUFoUTlvYUx6NU5mNU1XSFBLXG5VWSs2YjJ6QS95UWFYZHVQclZ1eHA3eENq MTFDL0xqbGhsMS9IeDE2TUpyVjMzTUNiZCtSS1c3MTFELzNcbjBYbFdTcUVwcmRiS2JxdzhXTVBq dUoxYW9YOGFRRVdvTCt4Ym9tUlFRSkpvRmFNUGx6Z2REY2ZvQUhEVVxuVHN4ZDArRk44cEZIQWdN QkFBR2pVREJPTUIwR0ExVWREZ1FXQkJTcXA1VHdRdEhzUXk5b1lMWmIwRDVXXG4rbGljSERBZkJn TlZIU01FR0RBV2dCU3FwNVR3UXRIc1F5OW9ZTFpiMEQ1VytsaWNIREFNQmdOVkhSTUVcbkJUQURB UUgvTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFCZ1NRR2Fjand4bWJScnJCaFc2M2dZNUthV1xu aW03NnJHNDVwM3VoOUE4V1VmTVdyeUNVdWZyRk9tL1FFSm5sVVVLM1FYNEtFVmoyZXl3Yjlnc2Zr aUNFXG55YUp6eGU2NjVRMkJyV3dlM3JHVmtBaE8vZm44dXBlYzRFMUFTYzMxQVNhRjhtK3BZcUND UFNmbEw1a1Zcbk1lZkhHNGxFczNYSmtIY2VDbFJ6eVh2amI1S2ovdTAyQzVZQ2pjQUxZZDgva2NT YmY0am9lMUd1ZnZLRlxuNXd2UEJQa1JWZmJXMkthZ0wranc2MmorOFU2b0I3RmJ4dEZ5cVFQMVlv WkdpYTlNa1BLbksreWc1by8wXG5jWjU3aGdrNG1RbU0xaTgyUnJVWlFWb0JQM0NENUxkQkpaZkpv WHN0UmxYZTZkWDcrVGlzZFNBc3BwNWVcbmhObTBCY3FkTEsrejhudHRcbiJ9fQ0KIDE2OTE6ZD0z ICBobD00IGw9IDU1NyBjb25zOiBjb250IFsgMCBdICAgICAgICANCiAxNjk1OmQ9NCAgaGw9NCBs PSA1NTMgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMTY5OTpkPTUgIGhsPTQgbD0gNDMxIGNv bnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDE3MDM6ZD02ICBobD0yIGw9ICAgMyBjb25zOiBjb250 IFsgMCBdICAgICAgICANCiAxNzA1OmQ9NyAgaGw9MiBsPSAgIDEgcHJpbTogSU5URUdFUiAgICAg ICAgICAgOjAyDQogMTcwODpkPTYgIGhsPTIgbD0gICAxIHByaW06IElOVEVHRVIgICAgICAgICAg IDowMQ0KIDE3MTE6ZD02ICBobD0yIGw9ICAxMCBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCiAx NzEzOmQ9NyAgaGw9MiBsPSAgIDggcHJpbTogT0JKRUNUICAgICAgICAgICAgOmVjZHNhLXdpdGgt U0hBMjU2DQogMTcyMzpkPTYgIGhsPTIgbD0gIDc3IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0K IDE3MjU6ZD03ICBobD0yIGw9ICAxOCBjb25zOiBTRVQgICAgICAgICAgICAgICANCiAxNzI3OmQ9 OCAgaGw9MiBsPSAgMTYgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMTcyOTpkPTkgIGhsPTIg bD0gIDEwIHByaW06IE9CSkVDVCAgICAgICAgICAgIDpkb21haW5Db21wb25lbnQNCiAxNzQxOmQ9 OSAgaGw9MiBsPSAgIDIgcHJpbTogSUE1U1RSSU5HICAgICAgICAgOmNhDQogMTc0NTpkPTcgIGhs PTIgbD0gIDI1IGNvbnM6IFNFVCAgICAgICAgICAgICAgIA0KIDE3NDc6ZD04ICBobD0yIGw9ICAy MyBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCiAxNzQ5OmQ9OSAgaGw9MiBsPSAgMTAgcHJpbTog T0JKRUNUICAgICAgICAgICAgOmRvbWFpbkNvbXBvbmVudA0KIDE3NjE6ZD05ICBobD0yIGw9ICAg OSBwcmltOiBJQTVTVFJJTkcgICAgICAgICA6c2FuZGVsbWFuDQogMTc3MjpkPTcgIGhsPTIgbD0g IDI4IGNvbnM6IFNFVCAgICAgICAgICAgICAgIA0KIDE3NzQ6ZD04ICBobD0yIGw9ICAyNiBjb25z OiBTRVFVRU5DRSAgICAgICAgICANCiAxNzc2OmQ9OSAgaGw9MiBsPSAgIDMgcHJpbTogT0JKRUNU ICAgICAgICAgICAgOmNvbW1vbk5hbWUNCiAxNzgxOmQ9OSAgaGw9MiBsPSAgMTkgcHJpbTogVVRG OFNUUklORyAgICAgICAgOlVuc3RydW5nIEhpZ2h3YXkgQ0ENCiAxODAyOmQ9NiAgaGw9MiBsPSAg MzAgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMTgwNDpkPTcgIGhsPTIgbD0gIDEzIHByaW06 IFVUQ1RJTUUgICAgICAgICAgIDoxNjA1MDcwMjM2NTVaDQogMTgxOTpkPTcgIGhsPTIgbD0gIDEz IHByaW06IFVUQ1RJTUUgICAgICAgICAgIDoxODA1MDcwMjM2NTVaDQogMTgzNDpkPTYgIGhsPTIg bD0gIDc3IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDE4MzY6ZD03ICBobD0yIGw9ICAxOCBj b25zOiBTRVQgICAgICAgICAgICAgICANCiAxODM4OmQ9OCAgaGw9MiBsPSAgMTYgY29uczogU0VR VUVOQ0UgICAgICAgICAgDQogMTg0MDpkPTkgIGhsPTIgbD0gIDEwIHByaW06IE9CSkVDVCAgICAg ICAgICAgIDpkb21haW5Db21wb25lbnQNCiAxODUyOmQ9OSAgaGw9MiBsPSAgIDIgcHJpbTogSUE1 U1RSSU5HICAgICAgICAgOmNhDQogMTg1NjpkPTcgIGhsPTIgbD0gIDI1IGNvbnM6IFNFVCAgICAg ICAgICAgICAgIA0KIDE4NTg6ZD04ICBobD0yIGw9ICAyMyBjb25zOiBTRVFVRU5DRSAgICAgICAg ICANCiAxODYwOmQ9OSAgaGw9MiBsPSAgMTAgcHJpbTogT0JKRUNUICAgICAgICAgICAgOmRvbWFp bkNvbXBvbmVudA0KIDE4NzI6ZD05ICBobD0yIGw9ICAgOSBwcmltOiBJQTVTVFJJTkcgICAgICAg ICA6c2FuZGVsbWFuDQogMTg4MzpkPTcgIGhsPTIgbD0gIDI4IGNvbnM6IFNFVCAgICAgICAgICAg ICAgIA0KIDE4ODU6ZD04ICBobD0yIGw9ICAyNiBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCiAx ODg3OmQ9OSAgaGw9MiBsPSAgIDMgcHJpbTogT0JKRUNUICAgICAgICAgICAgOmNvbW1vbk5hbWUN CiAxODkyOmQ9OSAgaGw9MiBsPSAgMTkgcHJpbTogVVRGOFNUUklORyAgICAgICAgOlVuc3RydW5n IEhpZ2h3YXkgQ0ENCiAxOTEzOmQ9NiAgaGw9MiBsPSAxMTggY29uczogU0VRVUVOQ0UgICAgICAg ICAgDQogMTkxNTpkPTcgIGhsPTIgbD0gIDE2IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDE5 MTc6ZD04ICBobD0yIGw9ICAgNyBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6aWQtZWNQdWJsaWNL ZXkNCiAxOTI2OmQ9OCAgaGw9MiBsPSAgIDUgcHJpbTogT0JKRUNUICAgICAgICAgICAgOnNlY3Az ODRyMQ0KIDE5MzM6ZD03ICBobD0yIGw9ICA5OCBwcmltOiBCSVQgU1RSSU5HICAgICAgICANCiAy MDMzOmQ9NiAgaGw9MiBsPSAgOTkgY29uczogY29udCBbIDMgXSAgICAgICAgDQogMjAzNTpkPTcg IGhsPTIgbD0gIDk3IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDIwMzc6ZD04ICBobD0yIGw9 ICAxNSBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCiAyMDM5OmQ9OSAgaGw9MiBsPSAgIDMgcHJp bTogT0JKRUNUICAgICAgICAgICAgOlg1MDl2MyBCYXNpYyBDb25zdHJhaW50cw0KIDIwNDQ6ZD05 ICBobD0yIGw9ICAgMSBwcmltOiBCT09MRUFOICAgICAgICAgICA6MjU1DQogMjA0NzpkPTkgIGhs PTIgbD0gICA1IHByaW06IE9DVEVUIFNUUklORyAgICAgIFtIRVggRFVNUF06MzAwMzAxMDFGRg0K IDIwNTQ6ZD04ICBobD0yIGw9ICAxNCBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCiAyMDU2OmQ9 OSAgaGw9MiBsPSAgIDMgcHJpbTogT0JKRUNUICAgICAgICAgICAgOlg1MDl2MyBLZXkgVXNhZ2UN CiAyMDYxOmQ9OSAgaGw9MiBsPSAgIDEgcHJpbTogQk9PTEVBTiAgICAgICAgICAgOjI1NQ0KIDIw NjQ6ZD05ICBobD0yIGw9ICAgNCBwcmltOiBPQ1RFVCBTVFJJTkcgICAgICBbSEVYIERVTVBdOjAz MDIwMTA2DQogMjA3MDpkPTggIGhsPTIgbD0gIDI5IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0K IDIwNzI6ZD05ICBobD0yIGw9ICAgMyBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6WDUwOXYzIFN1 YmplY3QgS2V5IElkZW50aWZpZXINCiAyMDc3OmQ9OSAgaGw9MiBsPSAgMjIgcHJpbTogT0NURVQg U1RSSU5HICAgICAgW0hFWCBEVU1QXTowNDE0MjU4RURGMkQ1MTc4OEYwQ0VDODcyQTIyRkJENEZF QkUwNjc2RUIwNw0KIDIxMDE6ZD04ICBobD0yIGw9ICAzMSBjb25zOiBTRVFVRU5DRSAgICAgICAg ICANCiAyMTAzOmQ9OSAgaGw9MiBsPSAgIDMgcHJpbTogT0JKRUNUICAgICAgICAgICAgOlg1MDl2 MyBBdXRob3JpdHkgS2V5IElkZW50aWZpZXINCiAyMTA4OmQ9OSAgaGw9MiBsPSAgMjQgcHJpbTog T0NURVQgU1RSSU5HICAgICAgW0hFWCBEVU1QXTozMDE2ODAxNDI1OEVERjJENTE3ODhGMENFQzg3 MkEyMkZCRDRGRUJFMDY3NkVCMDcNCiAyMTM0OmQ9NSAgaGw9MiBsPSAgMTAgY29uczogU0VRVUVO Q0UgICAgICAgICAgDQogMjEzNjpkPTYgIGhsPTIgbD0gICA4IHByaW06IE9CSkVDVCAgICAgICAg ICAgIDplY2RzYS13aXRoLVNIQTI1Ng0KIDIxNDY6ZD01ICBobD0yIGw9IDEwNCBwcmltOiBCSVQg U1RSSU5HICAgICAgICANCiAyMjUyOmQ9MyAgaGw9NCBsPSA0NTQgY29uczogU0VUICAgICAgICAg ICAgICAgDQogMjI1NjpkPTQgIGhsPTQgbD0gNDUwIGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0K IDIyNjA6ZD01ICBobD0yIGw9ICAgMSBwcmltOiBJTlRFR0VSICAgICAgICAgICA6MDENCiAyMjYz OmQ9NSAgaGw9MiBsPSAgODIgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMjI2NTpkPTYgIGhs PTIgbD0gIDc3IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDIyNjc6ZD03ICBobD0yIGw9ICAx OCBjb25zOiBTRVQgICAgICAgICAgICAgICANCiAyMjY5OmQ9OCAgaGw9MiBsPSAgMTYgY29uczog U0VRVUVOQ0UgICAgICAgICAgDQogMjI3MTpkPTkgIGhsPTIgbD0gIDEwIHByaW06IE9CSkVDVCAg ICAgICAgICAgIDpkb21haW5Db21wb25lbnQNCiAyMjgzOmQ9OSAgaGw9MiBsPSAgIDIgcHJpbTog SUE1U1RSSU5HICAgICAgICAgOmNhDQogMjI4NzpkPTcgIGhsPTIgbD0gIDI1IGNvbnM6IFNFVCAg ICAgICAgICAgICAgIA0KIDIyODk6ZD04ICBobD0yIGw9ICAyMyBjb25zOiBTRVFVRU5DRSAgICAg ICAgICANCiAyMjkxOmQ9OSAgaGw9MiBsPSAgMTAgcHJpbTogT0JKRUNUICAgICAgICAgICAgOmRv bWFpbkNvbXBvbmVudA0KIDIzMDM6ZD05ICBobD0yIGw9ICAgOSBwcmltOiBJQTVTVFJJTkcgICAg ICAgICA6c2FuZGVsbWFuDQogMjMxNDpkPTcgIGhsPTIgbD0gIDI4IGNvbnM6IFNFVCAgICAgICAg ICAgICAgIA0KIDIzMTY6ZD04ICBobD0yIGw9ICAyNiBjb25zOiBTRVFVRU5DRSAgICAgICAgICAN CiAyMzE4OmQ9OSAgaGw9MiBsPSAgIDMgcHJpbTogT0JKRUNUICAgICAgICAgICAgOmNvbW1vbk5h bWUNCiAyMzIzOmQ9OSAgaGw9MiBsPSAgMTkgcHJpbTogVVRGOFNUUklORyAgICAgICAgOlVuc3Ry dW5nIEhpZ2h3YXkgQ0ENCiAyMzQ0OmQ9NiAgaGw9MiBsPSAgIDEgcHJpbTogSU5URUdFUiAgICAg ICAgICAgOjAxDQogMjM0NzpkPTUgIGhsPTIgbD0gIDEzIGNvbnM6IFNFUVVFTkNFICAgICAgICAg IA0KIDIzNDk6ZD02ICBobD0yIGw9ICAgOSBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6c2hhMjU2 DQogMjM2MDpkPTYgIGhsPTIgbD0gICAwIHByaW06IE5VTEwgICAgICAgICAgICAgIA0KIDIzNjI6 ZD01ICBobD0zIGw9IDIyOCBjb25zOiBjb250IFsgMCBdICAgICAgICANCiAyMzY1OmQ9NiAgaGw9 MiBsPSAgMjQgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMjM2NzpkPTcgIGhsPTIgbD0gICA5 IHByaW06IE9CSkVDVCAgICAgICAgICAgIDpjb250ZW50VHlwZQ0KIDIzNzg6ZD03ICBobD0yIGw9 ICAxMSBjb25zOiBTRVQgICAgICAgICAgICAgICANCiAyMzgwOmQ9OCAgaGw9MiBsPSAgIDkgcHJp bTogT0JKRUNUICAgICAgICAgICAgOnBrY3M3LWRhdGENCiAyMzkxOmQ9NiAgaGw9MiBsPSAgMjgg Y29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMjM5MzpkPTcgIGhsPTIgbD0gICA5IHByaW06IE9C SkVDVCAgICAgICAgICAgIDpzaWduaW5nVGltZQ0KIDI0MDQ6ZD03ICBobD0yIGw9ICAxNSBjb25z OiBTRVQgICAgICAgICAgICAgICANCiAyNDA2OmQ9OCAgaGw9MiBsPSAgMTMgcHJpbTogVVRDVElN RSAgICAgICAgICAgOjE3MDMyNTIyMDMwOFoNCiAyNDIxOmQ9NiAgaGw9MiBsPSAgNDcgY29uczog U0VRVUVOQ0UgICAgICAgICAgDQogMjQyMzpkPTcgIGhsPTIgbD0gICA5IHByaW06IE9CSkVDVCAg ICAgICAgICAgIDptZXNzYWdlRGlnZXN0DQogMjQzNDpkPTcgIGhsPTIgbD0gIDM0IGNvbnM6IFNF VCAgICAgICAgICAgICAgIA0KIDI0MzY6ZD04ICBobD0yIGw9ICAzMiBwcmltOiBPQ1RFVCBTVFJJ TkcgICAgICBbSEVYIERVTVBdOjU1MkREMkVFNUNCQzRDN0M0RDIwN0Y5OEEyNTE5RjAzMUVFMTAw NzRENjc0MjY1QTdERDBDQTczRTY4QkU1N0QNCiAyNDcwOmQ9NiAgaGw9MiBsPSAxMjEgY29uczog U0VRVUVOQ0UgICAgICAgICAgDQogMjQ3MjpkPTcgIGhsPTIgbD0gICA5IHByaW06IE9CSkVDVCAg ICAgICAgICAgIDpTL01JTUUgQ2FwYWJpbGl0aWVzDQogMjQ4MzpkPTcgIGhsPTIgbD0gMTA4IGNv bnM6IFNFVCAgICAgICAgICAgICAgIA0KIDI0ODU6ZD04ICBobD0yIGw9IDEwNiBjb25zOiBTRVFV RU5DRSAgICAgICAgICANCiAyNDg3OmQ9OSAgaGw9MiBsPSAgMTEgY29uczogU0VRVUVOQ0UgICAg ICAgICAgDQogMjQ4OTpkPTEwIGhsPTIgbD0gICA5IHByaW06IE9CSkVDVCAgICAgICAgICAgIDph ZXMtMjU2LWNiYw0KIDI1MDA6ZD05ICBobD0yIGw9ICAxMSBjb25zOiBTRVFVRU5DRSAgICAgICAg ICANCiAyNTAyOmQ9MTAgaGw9MiBsPSAgIDkgcHJpbTogT0JKRUNUICAgICAgICAgICAgOmFlcy0x OTItY2JjDQogMjUxMzpkPTkgIGhsPTIgbD0gIDExIGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0K IDI1MTU6ZD0xMCBobD0yIGw9ICAgOSBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6YWVzLTEyOC1j YmMNCiAyNTI2OmQ9OSAgaGw9MiBsPSAgMTAgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMjUy ODpkPTEwIGhsPTIgbD0gICA4IHByaW06IE9CSkVDVCAgICAgICAgICAgIDpkZXMtZWRlMy1jYmMN CiAyNTM4OmQ9OSAgaGw9MiBsPSAgMTQgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQogMjU0MDpk PTEwIGhsPTIgbD0gICA4IHByaW06IE9CSkVDVCAgICAgICAgICAgIDpyYzItY2JjDQogMjU1MDpk PTEwIGhsPTIgbD0gICAyIHByaW06IElOVEVHRVIgICAgICAgICAgIDo4MA0KIDI1NTQ6ZD05ICBo bD0yIGw9ICAxMyBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCiAyNTU2OmQ9MTAgaGw9MiBsPSAg IDggcHJpbTogT0JKRUNUICAgICAgICAgICAgOnJjMi1jYmMNCiAyNTY2OmQ9MTAgaGw9MiBsPSAg IDEgcHJpbTogSU5URUdFUiAgICAgICAgICAgOjQwDQogMjU2OTpkPTkgIGhsPTIgbD0gICA3IGNv bnM6IFNFUVVFTkNFICAgICAgICAgIA0KIDI1NzE6ZD0xMCBobD0yIGw9ICAgNSBwcmltOiBPQkpF Q1QgICAgICAgICAgICA6ZGVzLWNiYw0KIDI1Nzg6ZD05ICBobD0yIGw9ICAxMyBjb25zOiBTRVFV RU5DRSAgICAgICAgICANCiAyNTgwOmQ9MTAgaGw9MiBsPSAgIDggcHJpbTogT0JKRUNUICAgICAg ICAgICAgOnJjMi1jYmMNCiAyNTkwOmQ9MTAgaGw9MiBsPSAgIDEgcHJpbTogSU5URUdFUiAgICAg ICAgICAgOjI4DQogMjU5MzpkPTUgIGhsPTIgbD0gIDEwIGNvbnM6IFNFUVVFTkNFICAgICAgICAg IA0KIDI1OTU6ZD02ICBobD0yIGw9ICAgOCBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6ZWNkc2Et d2l0aC1TSEEyNTYNCiAyNjA1OmQ9NSAgaGw9MiBsPSAxMDMgcHJpbTogT0NURVQgU1RSSU5HICAg ICAgW0hFWCBEVU1QXTozMDY1MDIzMTAwRTYwRUFGNzNBNjk4MjYwNzdDRjZCNzYwQUY5QkQxQzlC RjcyM0QwRTg0ODEyQjA2QjVBOEI3QzI1MjM2MjM5NEQ5OEUxQjVCNEMwMkQ4QUNEOERBNUJEMjI0 OEQ1MUVBMDIzMDZCNUJEQkRGRkJCMDIyQTFFMDM5QTE4NDcyNTlEMkUwQUEzMzJFMTJEMjQwNTNC M0U3RUNBNkQxOEVBODIxRTI5QTUzRDkzRUUzQkE0REU3RDhDNTk0QzUxNzM2NTExQw0KDQpBbmQg dGhpcyBpcyB0aGUg4oCcZW5jb2RlZOKAnSBmb3JtOg0KLS0tLS1CRUdJTiBQS0NTNy0tLS0tDQpN SUlLa2dZSktvWklodmNOQVFjQ29JSUtnekNDQ244Q0FRRXhEekFOQmdsZ2hrZ0JaUU1FQWdFRkFE Q0NCbXdHDQpDU3FHU0liM0RRRUhBYUNDQmwwRWdnWlpleUpwWlhSbUxYWnZkV05vWlhJNmRtOTFZ MmhsY2lJNmV5SnViMjVqDQpaU0k2SWpZeVlUSmxOelk1TTJRNE1tWmpaR0V5TmpJMFpHVTFPR1pp TmpjeU1tVTFJaXdpWTNKbFlYUmxaQzF2DQpiaUk2SWpJd01UY3RNREV0TURGVU1EQTZNREE2TURB dU1EQXdXaUlzSW1SbGRtbGpaUzFwWkdWdWRHbG1hV1Z5DQpJam9pTURBdFpEQXRaVFV0WmpJdE1E QXRNREVpTENKaGMzTmxjblJwYjI0aU9pSnNiMmRuWldRaUxDSnZkMjVsDQpjaUk2SWsxSlNVVkZl a05EUVhaMVowRjNTVUpCWjBsS1FVczJja1p2ZFhackt6ZFpUVUV3UjBOVGNVZFRTV0l6DQpSRkZG UWtOM1ZVRk5TVWRtVFZGemQxeHVRMUZaUkZaUlVVZEZkMHBFVVZSRlVVMUJORWRCTVZWRlEwRjNT RlF5DQpOVEJaV0Vwd1lucEZVRTFCTUVkQk1WVkZRbmQzUjFRelVqQlpXR1JvWEc1TlVtOTNSMEZa UkZaUlVVdEVRa1pRDQpaREkxYkdOcFFrWmxSMFowWTBkNGJFbEZPWFZhVkVWU1RVRTRSMEV4VlVW RGQzZEpWRzA1TUVsR1dteGNibU51DQphM2hIZWtGYVFtZE9Wa0pCVFUxRmJUa3pZbTFXZVUxVE5X eGxSMFowWTBkNGJFeHRUblppVkVWb1RVSTRSME5UDQpjVWRUU1dJelJGRkZTbHh1UVZKWlUySXpa SFZhV0VsNFVVZFdORmxYTVhkaVIxVjFXVEk1ZEUxQ05GaEVWRVV6DQpUVVJOZVU1VVJUSk5hbXQ2 VGtadldFUlVSVE5OUkZGNVhHNU9SRVV5VFdwcmVrNUdiM2RuV2poNFEzcEJTa0puDQpUbFpDUVZs VVFXdE9RazFTUVhkRVoxbEVWbEZSU1VSQlpGQmlibEpvWTIxc2RrMVJPSGRjYmtSUldVUldVVkZJ DQpSRUZhVUdSSVVtaGtNa1Y0UjJwQldVSm5UbFpDUVc5TlJWVTVNMkp0Vm5sSlJWWTBXVmN4ZDJK SFZXZFVNalZzDQpUVkpGZDF4dVJIZFpSRlpSVVV4RVFXaFBZak5SWjFadFZubGxWRVZpVFVKclIw RXhWVVZCZDNkVFlqTmtkVnBZDQpTWGhNYlZZMFdWY3hkMkpIVlhWWk1qbDBYRzVOVTBWM1NIZFpT a3R2V2tsb2RtTk9RVkZyUWtab1NuWmtNalZzDQpZMnBHUVZwWWFHaGlXRUp6V2xNMWFtSXlNSGRu WjBWcFRVRXdSME5UY1VkY2JsTkpZak5FVVVWQ1FWRlZRVUUwDQpTVUpFZDBGM1oyZEZTMEZ2U1VK QlVVTTBVVmxCUlc1VWRGaG5hVXR4YzJaVFZsbHJaMnRJWkdSR1kxQXpORnh1DQpUMVV6V1ZBM2FX SnljMmQ0TUdrNVkzbHFOM2hQZWxkSVQwWXlVSE52UzBKblZGSklOelZOVTAxb1ZHdzFWV2xrDQpj a056ZW14c2RVc3JjWEEwWEc1a00xcG5NekZ2VVUwdlNFUnRlVkpLZVZKd1dTdFFRekZ1TlZaNEww MXFOVlpoDQpaMUpSWW5GSE4xaFVSRkZEWmtOeWFIRkpTM0pMUWxSMVVGRmNialIyV1V0bFREQjBV V3MwVlVwc1VFbHZXbGhGDQpiVUpyTldScmJpOUdlbXc1UVdaSldsTjJWWHBSTVZGQmFGRTViMkZN ZWpWT1pqVk5WMGhRUzF4dVZWa3JObUl5DQpla0V2ZVZGaFdHUjFVSEpXZFhod04zaERhakV4UXk5 TWFteG9iREV2U0hneE5rMUtjbFl6TTAxRFltUXJVa3RYDQpOekV4UkM4elhHNHdXR3hYVTNGRmNI SmtZa3RpY1hjNFYwMVFhblZLTVdGdldEaGhVVVZYYjB3cmVHSnZiVkpSDQpVVXBLYjBaaFRWQnNl bWRrUkdObWIwRklSRlZjYmxSemVHUXdLMFpPT0hCR1NFRm5UVUpCUVVkcVZVUkNUMDFDDQpNRWRC TVZWa1JHZFJWMEpDVTNGd05WUjNVWFJJYzFGNU9XOVpURnBpTUVRMVYxeHVLMnhwWTBoRVFXWkNa MDVXDQpTRk5OUlVkRVFWZG5RbE54Y0RWVWQxRjBTSE5SZVRsdldVeGFZakJFTlZjcmJHbGpTRVJC VFVKblRsWklVazFGDQpYRzVDVkVGRVFWRklMMDFCTUVkRFUzRkhVMGxpTTBSUlJVSkRkMVZCUVRS SlFrRlJRbWRUVVVkaFkycDNlRzFpDQpVbkp5UW1oWE5qTm5XVFZMWVZkY2JtbHROelp5UnpRMWNE TjFhRGxCT0ZkVlprMVhjbmxEVlhWbWNrWlBiUzlSDQpSVXB1YkZWVlN6TlJXRFJMUlZacU1tVjVk Mkk1WjNObWEybERSVnh1ZVdGS2VuaGxOalkxVVRKQ2NsZDNaVE55DQpSMVpyUVdoUEwyWnVPSFZ3 WldNMFJURkJVMk16TVVGVFlVWTRiU3R3V1hGRFExQlRabXhNTld0V1hHNU5aV1pJDQpSelJzUlhN eldFcHJTR05sUTJ4U2VubFlkbXBpTlV0cUwzVXdNa00xV1VOcVkwRk1XV1E0TDJ0alUySm1OR3B2 DQpaVEZIZFdaMlMwWmNialYzZGxCQ1VHdFNWbVppVnpKTFlXZE1LMnAzTmpKcUt6aFZObTlDTjBa aWVIUkdlWEZSDQpVREZaYjFwSGFXRTVUV3RRUzI1TEszbG5OVzh2TUZ4dVkxbzFOMmhuYXpSdFVX MU5NV2s0TWxKeVZWcFJWbTlDDQpVRE5EUkRWTVpFSktXbVpLYjFoemRGSnNXR1UyWkZnM0sxUnBj MlJUUVhOd2NEVmxYRzVvVG0wd1FtTnhaRXhMDQpLM280Ym5SMFhHNGlmWDJnZ2dJdE1JSUNLVEND QWErZ0F3SUJBZ0lCQVRBS0JnZ3Foa2pPUFFRREFqQk5NUkl3DQpFQVlLQ1pJbWlaUHlMR1FCR1JZ Q1kyRXhHVEFYQmdvSmtpYUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhIREFhDQpCZ05WQkFNTUUx VnVjM1J5ZFc1bklFaHBaMmgzWVhrZ1EwRXdIaGNOTVRZd05UQTNNREl6TmpVMVdoY05NVGd3DQpO VEEzTURJek5qVTFXakJOTVJJd0VBWUtDWkltaVpQeUxHUUJHUllDWTJFeEdUQVhCZ29Ka2lhSmsv SXNaQUVaDQpGZ2x6WVc1a1pXeHRZVzR4SERBYUJnTlZCQU1NRTFWdWMzUnlkVzVuSUVocFoyaDNZ WGtnUTBFd2RqQVFCZ2NxDQpoa2pPUFFJQkJnVXJnUVFBSWdOaUFBU3FTaXhycC9aajBPbW56aG84 YkxPTllnclBzeHJMM0RUbUprcWl5WjRUDQp3ZS9MSzMrL2l3QmdXbm9oS3JPVnZPMVBPdGFESGRC dWlValgyQ0JNNjZGZzE4TlN5dnd6RUpFdEZMdXRGTDdTDQpjakRZQThKelBMQ2x3MHp0L1lCYWQr Q2pZekJoTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3RGdZRFZSMFBBUUgvDQpCQVFEQWdFR01CMEdB MVVkRGdRV0JCUWxqdDh0VVhpUERPeUhLaUw3MVA2K0JuYnJCekFmQmdOVkhTTUVHREFXDQpnQlFs anQ4dFVYaVBET3lIS2lMNzFQNitCbmJyQnpBS0JnZ3Foa2pPUFFRREFnTm9BREJsQWpCNmRoZnVq YWcyDQp4UUVnT1VyMTlpV3dBeU9odTluSFVmY3FYaEdiNmkzbkR1S2ZlSVU3QW0vV3p2QUFtcUFX WHlRQ01RRFRMS2FODQp2ZjJrLy9KY1crNCt4YXBWaFc4M3Q4VWRsTWswK0VvZS9ZbktQai9hMVdJ T3V6emg2ekp0Q1lqbGltWXhnZ0hHDQpNSUlCd2dJQkFUQlNNRTB4RWpBUUJnb0praWFKay9Jc1pB RVpGZ0pqWVRFWk1CY0dDZ21TSm9tVDhpeGtBUmtXDQpDWE5oYm1SbGJHMWhiakVjTUJvR0ExVUVB d3dUVlc1emRISjFibWNnU0dsbmFIZGhlU0JEUVFJQkFUQU5CZ2xnDQpoa2dCWlFNRUFnRUZBS0NC NURBWUJna3Foa2lHOXcwQkNRTXhDd1lKS29aSWh2Y05BUWNCTUJ3R0NTcUdTSWIzDQpEUUVKQlRF UEZ3MHhOekF6TWpVeU1qQXpNRGhhTUM4R0NTcUdTSWIzRFFFSkJERWlCQ0JWTGRMdVhMeE1mRTBn DQpmNWlpVVo4REh1RUFkTlowSmxwOTBNcHo1b3ZsZlRCNUJna3Foa2lHOXcwQkNROHhiREJxTUFz R0NXQ0dTQUZsDQpBd1FCS2pBTEJnbGdoa2dCWlFNRUFSWXdDd1lKWUlaSUFXVURCQUVDTUFvR0ND cUdTSWIzRFFNSE1BNEdDQ3FHDQpTSWIzRFFNQ0FnSUFnREFOQmdncWhraUc5dzBEQWdJQlFEQUhC Z1VyRGdNQ0J6QU5CZ2dxaGtpRzl3MERBZ0lCDQpLREFLQmdncWhrak9QUVFEQWdSbk1HVUNNUURt RHE5enBwZ21CM3oydDJDdm05SEp2M0k5RG9TQkt3YTFxTGZDDQpVallqbE5tT0cxdE1BdGlzMk5w YjBpU05VZW9DTUd0YjI5LzdzQ0toNERtaGhISlowdUNxTXk0UzBrQlRzK2ZzDQpwdEdPcUNIaW1s UFpQdU82VGVmWXhaVEZGelpSSEE9PQ0KLS0tLS1FTkQgUEtDUzctLS0tLQ0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBbmltYS1ib290c3RyYXAg bWFpbGluZyBsaXN0DQpBbmltYS1ib290c3RyYXBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEtYm9vdHN0cmFwDQoNCg0KDQoNCg== From nobody Tue May 2 19:00:44 2017 Return-Path: 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 678F3129498; Tue, 2 May 2017 19:00:42 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JloOjEh3ribr; Tue, 2 May 2017 19:00:40 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 4D474129BB2; Tue, 2 May 2017 18:58:13 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id i63so6123235pgd.2; Tue, 02 May 2017 18:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=OhccwrGpCPdlBBNbxQsw9IXhzcHHiywBAmRkLgEJzxg=; b=cCdDNqgCC9BxxIQbgHGcoTJeI8XNzOVW0rLyMlmQpU2jVBtSZqx3t9k14j//SX/l0E 3LNXV3iMX1tdEWYbt2AIXF70RSF1vHzAYIIfswEOmbwNyyTRPWMc6eYysczOvfppt7RF q28/BiHHn3og4ukB7UjX7wbEh7slC0DJS6kyoFrQhEuhgx5x5DeBwdOYWETVx1PhQJC6 TQeBab1Fk6gsOjFY+h41DhgrSpyEC+wABje14D8V7zN9JAPWJTE7BSS1dx0u31DLVi+X kWeDvkpHCkDkcG0U7aUXT6xmvFx2WLpn2M6scw9gLvk/XxIWocaUa4Cfuudlj2p895UQ aiwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=OhccwrGpCPdlBBNbxQsw9IXhzcHHiywBAmRkLgEJzxg=; b=XirI6XW4ISGe2fJpeFKwrSVceRtlIkLzxwv5FrkeO7xXbUR2k9VprNeA3qWQdhUO1s ZClsZs+JLDMdNIThgvMMUNa7J7wdBuj8QD+yr+LrGnyffbQCVh6olvGMoMkqPZWzzi4h bUwhAZ9IFZmGKbiYKe3mHgP7hUAMkyNaVcBkRfw1zMKeDq0yGnC+F1gQXKQ5KF+8J9t9 SJucokRpd6WT5NxEzwB2oObY217Zdv2OxLU2L13acg82E4uJ4K6sjgCxtQazX6puVNbd SyZa1x4Sy3FC0GAhHp4WKEOyTBvQkK+RutRAKjX1hGd2IHSDeHPdkG6akWR9RTnvh1tI NlGQ== X-Gm-Message-State: AN3rC/4H7dXwu6xlr4VHFbMLrvc48476Ce6ClymdefxN4VQ/E3hAnvTr mgmTGPhwk0u42/Ay X-Received: by 10.98.69.213 with SMTP id n82mr2163430pfi.216.1493776692611; Tue, 02 May 2017 18:58:12 -0700 (PDT) Received: from ?IPv6:2406:e001:3a49:1:28cc:dc4c:9703:6781? ([2406:e001:3a49:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e185sm1065861pfa.115.2017.05.02.18.58.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 18:58:11 -0700 (PDT) To: Martin Thomson References: <149369279041.9906.5712707340786253297@ietfa.amsl.com> Cc: ART Area , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 3 May 2017 13:58:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Artart telechat review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 02:00:42 -0000 On 03/05/2017 12:47, Martin Thomson wrote: > Thanks for the replies Brian, > > It seems like I missed the transport stuff entirely. I'd selfishly > and sheepishly suggest making that text more precise, but I will > respect your editorial discretion. > > I remain deeply concerned about the security parts. At a minimum, the > protocol needs a clear definition of how authentication and > confidentiality mechanisms are used, even if the process by which keys > and so forth are established is left to other work. In part, that's > easy, all the unicast stuff can use TLS and you can wave your hands > about how trust anchors get around. However, given that this > traverses the Internet, No. In the recommended scenario, it is confined to the ACP. In the scenario of a limited deployment across an operator boundary, we do recommend TLS: https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.2.1 > I am going to suggest that not having > confidentiality for the general discovery case is unwise and not > having authentication for the same seems like a real deal-breaker. Link-local multicasts don't traverse the Internet, and the relaying process is limited by the loop count even if there is no ACP. Except during bootstrap, everything is supposed to go over the ACP, even the LL multicasts. During the insecure part bootstrap, there is no relaying of multicasts off-link. However, as far as we know that is the only exposure, and nobody knows a way round it. https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.2.2 After that, all the nodes in the ACP are authenticated. > > On 3 May 2017 at 07:06, Brian E Carpenter wrote: >> (IETF list removed from CCs. Nothing secret here, it just seems >> unnecessary to fill several thousand inboxes with this...) > > Yeah, the tool added that. That might have been an unwise choice. (Alexey?) You can delete it manually in the review tool. I often do that when reviewing, unless there does seem to be an IETF-wide issue. > >> Security as such is simply out of scope. This protocol does not >> secure itself. I thought that was very clearly stated, e.g. >> https://tools.ietf.org/html/draft-ietf-anima-grasp-11#page-14 >> >> The main references for external security are >> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra >> https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane >> which are indeed normative dependencies. > > Both are informative. Oh. Well, technically you don't need to know how they work in order to implement GRASP. I'll do whatever the community wants, of course. > >>> The draft talks very little about how messages get to their >>> destinations. There's a brief section on UDP/TCP usage in one place >>> and an admonishment to use DTLS/TLS in another, but those sections >>> don't seem to have ever met each other. I'm forced to conclude that >>> this is well ahead of the other pieces that will fill in those gaps. >> >> This puzzles me, because >> https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.3 >> says: >> >>>> GRASP discovery and flooding messages are designed for use over link- >>>> local multicast UDP. They MUST NOT be fragmented, and therefore MUST >>>> NOT exceed the link MTU size. >>>> >>>> All other GRASP messages are unicast and could in principle run over >>>> any transport protocol. An implementation MUST support use of TCP. >>>> It MAY support use of another transport protocol. However, GRASP >>>> itself does not provide for error detection or retransmission. Use >>>> of an unreliable transport protocol is therefore NOT RECOMMENDED. >> >> What more do we need to say in general? See below, where we do say more >> for sepcific message types. > > OK, that isn't as imperative as I am used to. "designed for" isn't > the same as "are sent using". And the leading sentence of the second > paragraph does a great job of obfuscating things. > > There are still a couple of pieces missing. I assume that you create > a CBOR serialization of the message and put those end to end on a TCP > socket; or you create a CBOR serialization of the message and put that > in a UDP datagram. Saying that would genuinely help, even if it seems > even absurdly obvious. *** We can add that early in https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8 > (Caveat: I would naturally ask where TLS fits > in when you do this...) If there's no ACP, then yes, we need to use TLS but "Further details are out of scope for this document." If the community shows any signs of wanting to do this, as for the UDP case, another document would be needed, I think. >>> Security seems to be critical, but the key question of establishing a >>> trust domain is left out of scope. That conveniently removes some >>> hard problems, but I believe that there were a few inconvenient >>> problems that were removed at the same time. For instance, >>> authentication and confidentiality mechanisms for discovery seem to be >>> non-existent. (D)TLS can't secure a multicast signal, but no effort >>> has been put into providing an authentication framework. Indeed, but the ACP is supposed to provide this. >> As above, that whole issue is covered in the Anima secure bootstrap >> work and the autonomic control plane. Since they are normative >> dependencies, the GRASP RFC cannot appear without them. > > See above. > >>> Nits >>> >>> The document really isn't clear about how multi-round negotiation >>> works. A picture might help here. I ask because the definition of >>> how timers run is a little unclear. I probably missed the text about >>> this, but I assume that an endpoint that responds to M_REQ_NEG with >>> M_NEGOTIATE starts a new timer, and if a multiple rounds are used the >>> timer is reset each time that M_NEGOTIATE is sent. Is there any need >>> for any overall negotiation timer, or do you just multiply out the hop >>> (loop) count? >> >> Firstly, the sample message exchanges in Appendix D, especially >> https://tools.ietf.org/html/draft-ietf-anima-grasp-11#appendix-D.5 >> were intended to help on this point. IMHO, ASCII art wouldn't >> add much. > > That's up to you, I'm just trying to help. > >> https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.5 >> explains how timeouts work for initial negotiation requests. But we >> have cunningly hidden the explanation of timeout for the whole >> negotiation in >> https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.6 : >> >> When an initiator sends a Request Negotiation message, it MUST >> initialize a negotiation timer for the new negotiation thread. The >> default is GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is >> modified by a Confirm Waiting message (Section 3.8.9), the initiator >> will consider that the negotiation has failed when the timer expires. >> >> *** At the minimum, we need a forward reference to that in section 3.5.5. > > So my understanding is that the timeout runs for the entire > multi-message exchange? That seems unfortunate because it can't then > be based on the observed RTT. True. It's more aimed at being based on the nature of the autonomic function concerned, which might involve some time-consuming action, like making a measurement, resetting a slave device, or even physically moving an antenna. And in the far future, maybe even invoking a machine learning algorithm or some other slow process. We do have a mechanism for extending the timeout (the Confirm Waiting message). That was included on the assumption that occasionally an agent might to go off and do some homework before replying to a request. I must say I hadn't thought of RTT as an issue, because we tend to assume that the timescale for an autonomic action will be far greater than an RTT, so timeouts will be milliseconds to seconds, and RTTs within the autonomic domain will be sub-millisecond in many cases. Are you suggesting we should be able to reduce the timeout as well? (That would simply mean the parameter in the Confirm Waiting message would become a signed integer, I guess.) Brian From nobody Tue May 2 19:13:35 2017 Return-Path: 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 F1BAD127ABE for ; Tue, 2 May 2017 19:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00yWYOPZ8Jaf for ; Tue, 2 May 2017 19:13:31 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 31BC5129B72 for ; Tue, 2 May 2017 19:11:00 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id v14so5513392pfd.2 for ; Tue, 02 May 2017 19:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:organization:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=yPz+x/26/umpZw1uM7nhj5RaZmFNZLbOU/46rE5PCPc=; b=N4EyjYQGVJXUcvrCim6nYswdSaKY7L1y/EhIWxyra2uDGE37nj47NEWf0NP3L1Jiy0 zOwzM/EE7kPB2/zK6V/qruIcyCErtOFqujZGRrm7u/FGq2Tz9l1NNTLi/zwuI2wT/8ke 0HjWXsdUFbWD4nYLWW6QSSf9jBnAv0YkiAFiZyfhGAwjx9SwZ1obF96NKI2HxD3Br/l9 m7WvZwhkIpYEYr1yLPre6/l0kck+ng7TMrl0Qw2aB310z24HEQLLl04+bn85oWUkx415 dHwdGYcKdh/tNlEMvT/DFfBwJQ2UqHWLf3g9RJrQv1pmO/38MwijvzMnVtGpBVPDHMi+ 6TGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:organization:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=yPz+x/26/umpZw1uM7nhj5RaZmFNZLbOU/46rE5PCPc=; b=Z92Wreps4szOWzpY0+W83AFChUihJvzixh5lvlbMWFxtjZdToGtXrwVG3mwi5pzw2X QMxnBhiqgAqVa/hI8wSxRxBEaj7O3nowOl0Xj/c1TyTiezjYJAqrCJ576q6InRHWO7Wu Se6OARpfLyMYfArDbx/GimCLiJhvrcnvxQxyfKdpknM4eLcH2TH0PHsy18QzAGTWQ4fP MSNnneHDsU1MGQzGbsNkaYj4LMf7akbu6R0m3WvlvhvyD/AOhkbBbejQrTnnePFP1MLi b8rStH1gVKmsDZtekHAzKy8Bun45WyyoAS8V/4FiqRU9eJKha1vgt33st+rQhBOzmQx4 yC8w== X-Gm-Message-State: AN3rC/41TRZYh6EwVq6AsyJ3kp28sbFJDUznYGLnMrt5BceTrv12KJfl 8PBh/EW2CMF838Io X-Received: by 10.99.45.197 with SMTP id t188mr36590037pgt.209.1493777459677; Tue, 02 May 2017 19:10:59 -0700 (PDT) Received: from ?IPv6:2406:e001:3a49:1:28cc:dc4c:9703:6781? ([2406:e001:3a49:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m89sm1109387pfk.110.2017.05.02.19.10.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 19:10:59 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <21ba87a6-de98-b895-d269-7712f1016032@gmail.com> Date: Wed, 3 May 2017 14:11:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] ACP and LL multicast, again X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 02:13:34 -0000 While responding to Martin Thomson's GRASP review, I had another look at the ACP draft. What it says about multicast during ACP creation is fine. However, I'm still not finding a clear statement that the ACP, viewed as a VRF instance, will correctly forward GRASP link local multicasts to all other nodes on the same physical link. In other words, when the ACP is up and running, and a normal GRASP instance sends a multicast to port 7017 at ALL_GRASP_NEIGHBORS (ff02::xxxx) on its interface to the ACP VRF, how is that propagated? And when the GRASP instance binds to GRASP_LISTEN_PORT and performs IPV6_JOIN_GROUP to ALL_GRASP_NEIGHBORS whose messages will it receive? Brian From nobody Tue May 2 19:23:35 2017 Return-Path: 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 B0D00128DF6 for ; Tue, 2 May 2017 19:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VGuLLZckOwO for ; Tue, 2 May 2017 19:23:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348F012949F for ; Tue, 2 May 2017 19:21:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A0D8DE1DB for ; Tue, 2 May 2017 22:47:17 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E79A6636BB for ; Tue, 2 May 2017 22:21:23 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] some notes about concise version of BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 02:23:34 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Max, I have been through the concise branch, and done a dozen or so small edits which are in the git tree at https://github.com/anima-wg/anima-bootstrap/tree/concise We are defining DomainID in the terminology section. Now that I've been through the entire revised structure, I'll think on where to put that definition. We should define a crypto operation in the terminology part :-) I will do an edit tomorrow for that. I also owe notes from April meetings. section 3.3 reads: automatically authorized. If authorization is successful the MASA responds with a [I-D.ietf-anima-voucher] voucher. The MASA SHOULD check for revocation of the Registrar certificate. The maximum is this going to read right when it is replaced with "RFCXXXX"? It just seems awkward here. 3.7 worries: extensive history. A Registrar MAY request logs at future times [[EDNOTE: we need to ensure MASA server is not slammed with too many requests]]. Thoughts: permit a 301 redirect, even to an HTTP resource. A MASA seeing a lot of requests could redirect to a static content server elsewhere (cloudflare, amazon s3 bucket). That reduces the load of the big response. The object retrieved could even be signed by the MASA. Michael B and I talked during todays call about the MASA URL extension. What's valid? Specifically, would it be valid to have an HTTP URL? It could be to a DDoS aware cloud provider (amazon, cloudflare, etc) which would provide a 30x redirect to an https URL. Also concider if TLS upgrade on an HTTP/2 connection makes sense. Cases:=C2=A0 =C2=A0- pledge contains URL of MASA =C2=A0- step 1: registrar follows URL (default) =C2=A0- option 1: redirect: should it be allowed? (if not, cannot d= eploy anti-DDOS re-direct) =C2=A0- option 2: manual override of URL: should it be allowed?=C2= =A0 Tentatively: Neither option 1 or 2 have an impact on security ("stealing" a device).=C2=A0 Next: Is there a relationship between the TLS Server Certificate of the MASA, and the Issuer Certificate from the IDevID? Is the MASA's ServerCertificate validated with WebPKI? How does the Registrar obtain the Vendor's cert chain that permits it to validate the IDevID. Can it obtain it via the MASA connection? Registar: IDevID provides URL, use URL with WebPKI validation, obtain priva= te cert chain (not anchored to WebPKI) from MASA, validate IDevID. Is there any attack here if the pledge can control the MASA URL? MB suggests that IDevID and MASA Server Certificate would be verifiable via the WebPKI, and there would not necessarily be any common root of trust between the two. MB: There are two security associations:=C2=A0 =2D between pledge and MASA =2D between Registrar and MASA Observations:=C2=A0 =2D those two SAs are independent =2D the first (BRSKI/EST) is anchored on a trust anchor that may be private= (ie not part of the public PKI) =2D the second (MASA<->Registrar) is normally anchored on the public WebPKI= for the ServerCertificate. =2D the URL in the certificate of the IDevID of the pledge may be used to p= oint the registrar to the MASA. (or, redirect, or override, see line 1477-1= 478) =C2=A0 --> In that URL, the vendor defines the type of security association= to be used between registrar and MASA.=C2=A0 =C2=A0 --> The vendor choooses the type of SA. MUST define a minimum protoc= ol set that MUST be supported on the registrar, including a minimum level o= f security. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkJPqMACgkQgItw+93Q 3WUXTAgAsN/oHUxIu/3hZF7gg8zRdbTJjreww9Hin88vBR+USJbEwEhPLavZfcaf pTEMmshfLI9aaHstpgV3LvlHCRuN2ePhHeUJBjaYd7t9bztF8ziUReXZVdxb9oHF QforxwJ//Oy5Xnv0ld1CPu9kDeXgH/3AbBsxuGStWazRPlXBKNZq5DVXwso8SN98 C1kCcsNofeTycdJSpwpbxF5pd9VDYd4p4vq+NZzbQt+WM7B3H/7qXer1TG3PlzPq E0ImqgqLQmmQUe02gaCwEbc10T+FZ/g39X4VX2WeDa5hCt0qmrpN7HiluGXaywWd DkFD2iJQ/oiQEIhL9aYs6qWjIAc1NQ== =6or/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 2 19:34:33 2017 Return-Path: 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 124B9127ABE; Tue, 2 May 2017 19:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ld0yUwSG7-F; Tue, 2 May 2017 19:34:28 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 C1EE212EAAC; Tue, 2 May 2017 19:32:19 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id w64so131597339wma.0; Tue, 02 May 2017 19:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sDVcI06mOHrYICbcMLriS1qnl2dEFwfITEkI4bJmbBU=; b=sBt0LvmzErKELR6Bvo1yYDsKtMGFXSfmXjnVXBQtDF4wAqBUfS5Ng5x0qJCPVd8la3 SsJL7ZxLplQavwPiAxxw8mTvHkOXZB7nLfSlP+Zpco31PXWj+eA+NHdFmHnzGL2ywzxw ZRwExlJPn1EzPEPMiKSP3A8/dV6pjJhTQqJQ+Nbsf0Nq9k/0GJcIbxXtu02FVElNeSYs ZMFZosHTXIQ92KFtB9zqWhX/FDHGnU0CULI2Agu5H4+HGxWIrPNlTRbHM+iMonkuZGDj RTe9+UwbiKT8ep3TgVDTz7EP+Wc8N/huSusNKaoUZtDVMioyQb2KI8jJkTzp9eTZVazc PK8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sDVcI06mOHrYICbcMLriS1qnl2dEFwfITEkI4bJmbBU=; b=CqSd65sALE/eL/vZMXGWyO/8gZtXSCyebbGSOknO7Kx4w7zC6oyyjkr8HSH2FfY2hg YPu1Bkbw70te9v5V0yUk9grKdJLSg9+OKOutowQZ9FT2/M3IT+LeLSe7dreO2sC45ILL muet4rLJ/GtF8MA2o5QtWQp4XRAFbtd5vVvBKJ9TqU6EWte37rvnP32MWcoVmzO4UJgv RNIhYzYE/6F/UQFgBN/Dc/jFXBv/5COVCGvp2YiMjdMygRr9T99w5eQU5GITjJMEz0PH Qw4f2mMTK2XHs5yFImGeHbxZDfNBHx/4wjB8phQROs4p2YqU4z8pzaA6BeBVuM8WXCWS 0/fA== X-Gm-Message-State: AN3rC/46O46OUkA7B3mkl6XDk/ySfLRsNkOEhJQf8mXe9NE++3koi+8e MB1N2OFDYAtep4iKPFGCMD3a9J1k3pNI8Do= X-Received: by 10.25.212.19 with SMTP id l19mr10759495lfg.169.1493778738248; Tue, 02 May 2017 19:32:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Tue, 2 May 2017 19:32:17 -0700 (PDT) In-Reply-To: References: <149369279041.9906.5712707340786253297@ietfa.amsl.com> From: Martin Thomson Date: Wed, 3 May 2017 12:32:17 +1000 Message-ID: To: Brian E Carpenter Cc: ART Area , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Anima] Artart telechat review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 02:34:31 -0000 You seem to have covered the other points well enough. I won't say that I'm happy with the security story; I would strongly prefer that you at least say that unicast messages are added to TLS. In fact, here's an idea: use TLS for unicast always and leave the rules about what authentication is offered and accepted to the other documents. Then you only have the link-local multicast stuff in the clear. On the topic of link-local multicast, you definitely want text in "3.5.4.5. Rapid Mode (Discovery/Negotiation binding)" on the implications for security. I would prefer that you forbid triggering a negotiation during a multicast discovery because it lacks any form of protection. On 3 May 2017 at 11:58, Brian E Carpenter wrote: > I must say I hadn't thought of RTT as an issue, because we tend to assume > that the timescale for an autonomic action will be far greater than > an RTT, so timeouts will be milliseconds to seconds, and RTTs within > the autonomic domain will be sub-millisecond in many cases. Ahh, I always assume that machines work faster than the network, so the opposite really.. > Are you suggesting we should be able to reduce the timeout as well? Can't it already do that? I mean, it can't account for any time already spent waiting, but it could include the value 0, which means don't wait any more when you receive this (a nonsensical thing here, but it demonstrates that a reduction is possible). From nobody Tue May 2 19:48:26 2017 Return-Path: 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 D890012EB02; Tue, 2 May 2017 19:48:17 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdkhcQhX1kaM; Tue, 2 May 2017 19:48:16 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 E020A12EB09; Tue, 2 May 2017 19:45:53 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id i63so6311694pgd.2; Tue, 02 May 2017 19:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=v0SOmH+Jlo+taWZrHB9v/80WqHMe/TNLiNIJ8IPfCuw=; b=dy8k+YowNPo7wekshAJIyiHw+e3x+FcYftOEgx1RjbABpqyBwugnE/CBbnSSU6nYwT Tqbmzj3mRu/asfzsUQawdFu81JTQMHQbV5FFLrM33ZiFR6fEXQMyLbhO4BPTdo/VGEGP 0yhtSTSSgspmpm2Fs5y09TpW1aOY3fBtDxuPQnUUzrfIXjeUlTgmVl0y1/nIMUH75wqg 01lxRHb6I7IAHbYRrDWhBkjyaQPjMuYdPzu1umAq989D+CI7ZDRzs0dVh6WqU3jCBgEW bfWKsv38GoJYifQ8+wyObahjnvtlUQ3z6THNeSeQIBrkxC+S6lV3tqGYTlKb0JpolZdf ow3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=v0SOmH+Jlo+taWZrHB9v/80WqHMe/TNLiNIJ8IPfCuw=; b=UaoGYioO2nzTgph+okilLk0oB8FIzqDn3DE++8ibQAhzFri9M7Bwtiil3AvX1eSJ5W 4508hwu4nyjchHg2dzFCe2DusVmkQi1oCvZqealLv29hkH5XGEJuQP2CaEwnOIvX/m2O TKKBntiGNnM/ltwM5zYZmiVqxq9C5G+DVNA5e0Ja/aXMuG+JWwkaAAVN5E4lf2y89uxb coqCNlsmTWmJ/Neqt9dSZpsoz3J0XJA81u6HEF7VeGII5kV9ZXdgkAxooom3RhMhmnzM 55zp6R8XrwQqnJ1qSI5PkhHI6XZu6UY5TOgaNVojEE/H+xL9XWL4lsJHKiD4m0HetFnW FwQQ== X-Gm-Message-State: AN3rC/5iE7qMjNZM0srFDtWJipVx+Alh6hcZFukObdjY0/8/JeK60NAd uqlfK8upNuiqKA== X-Received: by 10.84.238.134 with SMTP id v6mr5674984plk.137.1493779553537; Tue, 02 May 2017 19:45:53 -0700 (PDT) Received: from ?IPv6:2406:e001:3a49:1:28cc:dc4c:9703:6781? ([2406:e001:3a49:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p3sm27809711pgd.36.2017.05.02.19.45.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 19:45:52 -0700 (PDT) To: Martin Thomson References: <149369279041.9906.5712707340786253297@ietfa.amsl.com> Cc: ART Area , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 3 May 2017 14:45:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Artart telechat review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 02:48:18 -0000 Duly noted. At this point I think we'll wait for direction from the AD. I expect other points will come up from the IESG. Regards Brian On 03/05/2017 14:32, Martin Thomson wrote: > You seem to have covered the other points well enough. I won't say > that I'm happy with the security story; I would strongly prefer that > you at least say that unicast messages are added to TLS. > > In fact, here's an idea: use TLS for unicast always and leave the > rules about what authentication is offered and accepted to the other > documents. Then you only have the link-local multicast stuff in the > clear. > > On the topic of link-local multicast, you definitely want text in > "3.5.4.5. Rapid Mode (Discovery/Negotiation binding)" on the > implications for security. I would prefer that you forbid triggering > a negotiation during a multicast discovery because it lacks any form > of protection. > > On 3 May 2017 at 11:58, Brian E Carpenter wrote: >> I must say I hadn't thought of RTT as an issue, because we tend to assume >> that the timescale for an autonomic action will be far greater than >> an RTT, so timeouts will be milliseconds to seconds, and RTTs within >> the autonomic domain will be sub-millisecond in many cases. > > Ahh, I always assume that machines work faster than the network, so > the opposite really.. > >> Are you suggesting we should be able to reduce the timeout as well? > > Can't it already do that? I mean, it can't account for any time > already spent waiting, but it could include the value 0, which means > don't wait any more when you receive this (a nonsensical thing here, > but it demonstrates that a reduction is possible). > From nobody Wed May 3 05:53:46 2017 Return-Path: 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 F1F2E12948A for ; Wed, 3 May 2017 05:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2orXeeeEIN4 for ; Wed, 3 May 2017 05:53:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26955129488 for ; Wed, 3 May 2017 05:51:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F67A2009E; Wed, 3 May 2017 09:17:04 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E0330636BB; Wed, 3 May 2017 08:51:08 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-Reply-To: <1347ae5f-4e68-c4d7-4cfd-3df0295993ce@gmail.com> References: <1347ae5f-4e68-c4d7-4cfd-3df0295993ce@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] GRASP multicast frequency X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 12:53:45 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > One more thing from our tests this week. > We noticed when testing at busy times that link-local multicasts > were often dropped. We would see quite long gaps when discovery > and flooding simply did not occur. Suspecting that the wireless > network was limiting the rate of multicasts, I cheated for a > few minutes by sending multicasts 10 times more frequently, > and the gaps in performance vanished. > According to the NOC: >> > Do the access points throttle the rate of IPv6 link-local multicasts? >> Yes, we do MLD snooping on our wireless LAN controllers to prevent >> multicast storms over the air. The MLD timeout and MLD query interval are >> set to 60 seconds and 20 seconds, respectively. > So, on a busy network the effect of that is apparently to incent > a protocol like GRASP to increase its rate of LL multicasts to grab a > sufficient share of capacity. It seems like a bad way to go open-loop. > Since we need the autonomic mechanisms to work well in times of > overload, this effect needs to be understood by implementors. Given an ACP, the L2 devices should only see unicast ESP packets. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkJ0jwACgkQgItw+93Q 3WWu4QgAnRjhnISi12jm78Z5x3bqR9BKjI9n9wNzssSGYqDuXzfpC/YjLgh+pfJX Qb8TAsiz15Lh10Nm0LnRhQSa/ZyypGbHjhlWzMloJWuZyVwEWSo2YvIBr6RpmQ4z L1wrp9E9KKqDVHH+beDdlCaIaNzW2mhbtMQJiZgq6YL2ThMfkO5chKtbAhrbDfBY x0Dpdd4Nokq1Eup3z21ApUE/JZXQdB4He4ivkS4PatcgCoN49aMXIh7HegcZt4vm W/3b+ywIwhmAwR4G330NEDjEuIhh6DWcYjR2Oqycm6UPVxS8B/BTAX+Iqi9SbjYU dLt/+qptQAfwuE61J5NYE7VdvDNyPA== =5flF -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 3 13:03:38 2017 Return-Path: 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 7977C129423 for ; Wed, 3 May 2017 13:03:37 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdoYwHs5ap2s for ; Wed, 3 May 2017 13:03:36 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 D2E1A127A91 for ; Wed, 3 May 2017 13:01:54 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id y4so98613pge.0 for ; Wed, 03 May 2017 13:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NSvK8aqdFKw1dQsBHGIMNL9H8gOCZ1tIQF6X0BhGvjE=; b=KT97DGgOpVS9Rs8l/k4+Bg9/atpjVcYLNpVjf5nzIzXKd1IPvJ40jBzCzEq6qZcfDT y3dsMEN+qBJqRA9q600IMIki3ndTNLQYIDJGR0q5MnWNs0wmJKmjkrkR9qJlSDG1s4JA xFO5OIVrl0jildaXKvlhoEF6oa14lYLWwHjPludnuTHdFFPcqZkoLG3Us+pFOdzAbubX z+UGbHHGXtVtbPrvvipW+QXMFQLwlm5C+jvdYC7OY85+Oi4JyRMENLeRqJhlMZmfi9E0 DDQg7k31Otenq6PdPkUoDtX9L8lqUq5f0c5lB2ljauylqHlS0icNArA8/iLEeQdslRkk fk+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=NSvK8aqdFKw1dQsBHGIMNL9H8gOCZ1tIQF6X0BhGvjE=; b=VDGzUR+aidv+WyLN5QPeUcQxEhpf/xJSmsDFxdAgYDgXADk4K6xm2+8loqpeEsuAC3 apB3jB/D46HRWRfW99x0OSpp2hJPPEK4+MdaF98w8MlbaG3DVW9ejT8H7U18wncbhIEf WAdZS0X9rb0mF8NjNSI+BHjJe8z3YKrjiediX4z+9ASWHCcgKEGIXly+v+VpzF7zByIL ToiLTIHQaHyrUrIHzsrB6IGm6bcoXmM55fojM76AnAJrGCWXsycUDST5UXGHVxPDljGM OPAj5CfiIC7spiGo6VgcBmSvEBAjO++WkWIZYBW2Fz+rKalcAHzytvM9NBJeklRVziu0 gLhQ== X-Gm-Message-State: AN3rC/6uBYgOHTG4uV8JwGzmEfSnBPd7wBweR+hoircAA2fHX5GlaQxT SF4ghHXfaEv63rQubO4= X-Received: by 10.98.36.154 with SMTP id k26mr6669478pfk.174.1493841714167; Wed, 03 May 2017 13:01:54 -0700 (PDT) Received: from ?IPv6:2406:e007:69d0:1:28cc:dc4c:9703:6781? ([2406:e007:69d0:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v187sm5655pgv.18.2017.05.03.13.01.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 13:01:53 -0700 (PDT) To: Michael Richardson References: <1347ae5f-4e68-c4d7-4cfd-3df0295993ce@gmail.com> <28520.1493815868@obiwan.sandelman.ca> Cc: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <3caf4ba8-1e3e-9388-09fc-3d29a10f2a69@gmail.com> Date: Thu, 4 May 2017 08:01:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <28520.1493815868@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP multicast frequency X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 20:03:37 -0000 On 04/05/2017 00:51, Michael Richardson wrote: > > Brian E Carpenter wrote: > > One more thing from our tests this week. > > > We noticed when testing at busy times that link-local multicasts > > were often dropped. We would see quite long gaps when discovery > > and flooding simply did not occur. Suspecting that the wireless > > network was limiting the rate of multicasts, I cheated for a > > few minutes by sending multicasts 10 times more frequently, > > and the gaps in performance vanished. > > > According to the NOC: > >> > Do the access points throttle the rate of IPv6 link-local multicasts? > >> Yes, we do MLD snooping on our wireless LAN controllers to prevent > >> multicast storms over the air. The MLD timeout and MLD query interval are > >> set to 60 seconds and 20 seconds, respectively. > > > So, on a busy network the effect of that is apparently to incent > > a protocol like GRASP to increase its rate of LL multicasts to grab a > > sufficient share of capacity. > > It seems like a bad way to go open-loop. > > > Since we need the autonomic mechanisms to work well in times of > > overload, this effect needs to be understood by implementors. > > Given an ACP, the L2 devices should only see unicast ESP packets. I believe so (another reason for good ACP support for LL multicast). It also occurred to me that if we want autonomic traffic to flow whatever else happens, we should consider setting diffserv CS6 or CS7 in all ACP traffic (cf section 4.2.2.3 of RFC2474). Brian From nobody Wed May 3 18:57:57 2017 Return-Path: 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 868E01294EE for ; Wed, 3 May 2017 18:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfUhVFyQjpsP for ; Wed, 3 May 2017 18:57:54 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 C532C12951C for ; Wed, 3 May 2017 18:57:52 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id t7so262308pgt.3 for ; Wed, 03 May 2017 18:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=O3m6dMBRyqaHVLPpxK3T4dSP6N79Zgt/52DFmPuloyQ=; b=e0lECVSpwNTnxTpvj0oeqeIyy54ewm9YVIMQESaxMlyxteqIzjjv65cDaX1wT/uanR fkL+KFZPrj4y7NjOzLuHrJMkvs/bidEfh68RCgS1RPUI/1m6me/kSHTFwA3ylE5qPezu dtwOJwqXuJwukJu38WDdmCkclvEapBBNYkhNsRWKGOoteVcc4jqiVRjyaK52dGS7jMWY N+JxuDO9tw3qtHNzTfGrPwftdUl8FsaFbQIGYbRG6DH5bUiIG0ZtB9jHcVyfOtE1mxka cdwnKLE/X2rtYV/AehgQ25sVdsTubVzG+mMRa81BDfK1Bi5Awvdj+ImehAxK9mkETKSG 27mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=O3m6dMBRyqaHVLPpxK3T4dSP6N79Zgt/52DFmPuloyQ=; b=ceU/UT2tnqlhVfhb8ErJh5FiVs6bxgvAv11LM8k8I0090clcpUG/2yI8ORG/gU/OVr 31MnFKTU4XoyIdkdxpgFKVRL4E1QTuhIrx+JEFVY1B5H3xC9I1SWf2mWfKS2rJWNxxQd mohzouikvYOPrNkEy5/QECrVmUEFrNQp0QnO+448bf7TZ5O/wH86y66N4Fm0RLk4f9PK NRR8iYJAEIKUmdfbtyLqD3P9kCLAm0p7m7v47+vDWAA1AMqOoTf4SyIxmBCUlt28fefF LCcBS1oCJg2Di8EGXygzH0Ypd6RrG9bjLqeQg4if93aNGIoaXHuHXXGexme5+qCRtcVi 2V6g== X-Gm-Message-State: AN3rC/6tbY3bgjxQt6QqtgSvrN+HoYn4bS29VPWTy83/e9JHqbgap3mE 12Bg8hrkbP0g11Ip X-Received: by 10.98.57.203 with SMTP id u72mr8371993pfj.9.1493863072182; Wed, 03 May 2017 18:57:52 -0700 (PDT) Received: from ?IPv6:2406:e007:69d0:1:28cc:dc4c:9703:6781? ([2406:e007:69d0:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o62sm632926pfj.87.2017.05.03.18.57.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 18:57:51 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 4 May 2017 13:57:55 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Question to the WG about draft-ietf-anima-prefix-management X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:57:55 -0000 Hi, Before we move the prefix management draft forward, I've been enhancing the corresponding demonstration ASA to be more realistic. The new version isn't quite ready for public release yet, but I have made it capable of dynamically assigning prefixes of any reasonable length on demand (the previous version was limited to a few pre-defined prefix lengths). Doing this, I realised that it's a very simple enhancement to include IPv4 prefixes (represented as IPv4-mapped IPv6 addresses). For fun, you can look at the output from the ASA below, which shows how it can split a /104 prefix into multiple longer prefixes when asked to assign a /120 (known in IPv4 as a /24). So to my question: should we add an "IP version" flag to the PrefixManager objective? It would be easy to do, and would allow one to write an ASA that manages prefixes for both protocols. Regards Brian [output edited only by deleting noise] _MainThread 3268 GRASP startup function exiting _MainThread 3268 ========================== _MainThread 3268 ASA Pfxm2 is starting up. _MainThread 3268 ========================== _MainThread 3268 Pfxm2 is a demonstration Autonomic Service Agent. _MainThread 3268 It supports the IPv6 Edge Prefix Management _MainThread 3268 objective 'PrefixManager' and its companion _MainThread 3268 'PrefixManager.Params'. Act as master? Y/N:y _MainThread 3268 This ASA will provide an initial prefix pool. _MainThread 3268 Also, it will supply default parameters for other ASAs. Default prefix for pool? Y/N:n Prefix length for pool (3..127):104 Manual prefix entry? Y/N:y Enter IPv6 prefix:::ffff:10.0.0.0 _MainThread 3268 Prefix pool contents: _MainThread 3268 ::ffff:a00:0 / 104 >>> p = get_from_pool(120) >>> ipaddress.IPv6Address(p) IPv6Address('::ffff:aff:ff00') >>> dump_pool() _MainThread 3268 Prefix pool contents: _MainThread 3268 ::ffff:a00:0 / 105 _MainThread 3268 ::ffff:a80:0 / 106 _MainThread 3268 ::ffff:ac0:0 / 107 _MainThread 3268 ::ffff:ae0:0 / 108 _MainThread 3268 ::ffff:af0:0 / 109 _MainThread 3268 ::ffff:af8:0 / 110 _MainThread 3268 ::ffff:afc:0 / 111 _MainThread 3268 ::ffff:afe:0 / 112 _MainThread 3268 ::ffff:aff:0 / 113 _MainThread 3268 ::ffff:aff:8000 / 114 _MainThread 3268 ::ffff:aff:c000 / 115 _MainThread 3268 ::ffff:aff:e000 / 116 _MainThread 3268 ::ffff:aff:f000 / 117 _MainThread 3268 ::ffff:aff:f800 / 118 _MainThread 3268 ::ffff:aff:fc00 / 119 _MainThread 3268 ::ffff:aff:fe00 / 120 >>> From nobody Thu May 4 04:17:34 2017 Return-Path: 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 77C491294F4 for ; Thu, 4 May 2017 04:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 VluXyUUA5uGf for ; Thu, 4 May 2017 04:17:31 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8755F127241 for ; Thu, 4 May 2017 04:17:30 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id v44BHTKe021608 for ; Thu, 4 May 2017 07:17:29 -0400 To: anima@ietf.org References: From: William Atwood Organization: Concordia University, Montreal Message-ID: Date: Thu, 4 May 2017 07:17:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2017-05-04 07:17:29 EDT Archived-At: Subject: Re: [Anima] Question to the WG about draft-ietf-anima-prefix-management X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 11:17:33 -0000 My vote is yes. There are a lot of IPv4 systems out there, and if we can retrofit into them (even if it requires a bit of smoke and mirrors to fake the existence of an IDevID), then that would be a big win. Bill On 03/05/2017 9:57 PM, Brian E Carpenter wrote: > Hi, > > Before we move the prefix management draft forward, I've been enhancing > the corresponding demonstration ASA to be more realistic. The new version > isn't quite ready for public release yet, but I have made it capable > of dynamically assigning prefixes of any reasonable length on demand > (the previous version was limited to a few pre-defined prefix lengths). > > Doing this, I realised that it's a very simple enhancement to include > IPv4 prefixes (represented as IPv4-mapped IPv6 addresses). For fun, you > can look at the output from the ASA below, which shows how it can > split a /104 prefix into multiple longer prefixes when asked to > assign a /120 (known in IPv4 as a /24). > > So to my question: should we add an "IP version" flag to the > PrefixManager objective? It would be easy to do, and would allow one > to write an ASA that manages prefixes for both protocols. > > Regards > Brian > > [output edited only by deleting noise] > > _MainThread 3268 GRASP startup function exiting > _MainThread 3268 ========================== > _MainThread 3268 ASA Pfxm2 is starting up. > _MainThread 3268 ========================== > _MainThread 3268 Pfxm2 is a demonstration Autonomic Service Agent. > _MainThread 3268 It supports the IPv6 Edge Prefix Management > _MainThread 3268 objective 'PrefixManager' and its companion > _MainThread 3268 'PrefixManager.Params'. > > Act as master? Y/N:y > _MainThread 3268 This ASA will provide an initial prefix pool. > _MainThread 3268 Also, it will supply default parameters for other ASAs. > Default prefix for pool? Y/N:n > Prefix length for pool (3..127):104 > Manual prefix entry? Y/N:y > Enter IPv6 prefix:::ffff:10.0.0.0 > _MainThread 3268 Prefix pool contents: > _MainThread 3268 ::ffff:a00:0 / 104 > >>>> p = get_from_pool(120) >>>> ipaddress.IPv6Address(p) > IPv6Address('::ffff:aff:ff00') >>>> dump_pool() > _MainThread 3268 Prefix pool contents: > _MainThread 3268 ::ffff:a00:0 / 105 > _MainThread 3268 ::ffff:a80:0 / 106 > _MainThread 3268 ::ffff:ac0:0 / 107 > _MainThread 3268 ::ffff:ae0:0 / 108 > _MainThread 3268 ::ffff:af0:0 / 109 > _MainThread 3268 ::ffff:af8:0 / 110 > _MainThread 3268 ::ffff:afc:0 / 111 > _MainThread 3268 ::ffff:afe:0 / 112 > _MainThread 3268 ::ffff:aff:0 / 113 > _MainThread 3268 ::ffff:aff:8000 / 114 > _MainThread 3268 ::ffff:aff:c000 / 115 > _MainThread 3268 ::ffff:aff:e000 / 116 > _MainThread 3268 ::ffff:aff:f000 / 117 > _MainThread 3268 ::ffff:aff:f800 / 118 > _MainThread 3268 ::ffff:aff:fc00 / 119 > _MainThread 3268 ::ffff:aff:fe00 / 120 >>>> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Thu May 4 18:56:59 2017 Return-Path: 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 1AE04128BA2 for ; Thu, 4 May 2017 18:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4sEfKKqoyu8 for ; Thu, 4 May 2017 18:56:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8C4128D6F for ; Thu, 4 May 2017 18:56:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMH45906; Fri, 05 May 2017 01:56:52 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 5 May 2017 02:56:50 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.200]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 5 May 2017 09:56:45 +0800 From: Sheng Jiang To: William Atwood , "anima@ietf.org" Thread-Topic: [Anima] Question to the WG about draft-ietf-anima-prefix-management Thread-Index: AQHSxHnoxggzcdkLjUqCRw7KN9zF/aHjgPsAgAF7CmA= Date: Fri, 5 May 2017 01:56:44 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CD78462@NKGEML515-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.590BDBE4.00DB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.200, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8a71cdad30be97edd2bd8190ec77905c Archived-At: Subject: Re: [Anima] Question to the WG about draft-ietf-anima-prefix-management X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 01:56:57 -0000 My vote is also yes for the flag. Although GRASP and ACP is mainly IPv6 bas= ed, the operator might like to manage IPv4 plane through it. The dual stack= /network would be existing for a long while. Sheng > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of William Atwood > Sent: Thursday, May 04, 2017 7:18 PM > To: anima@ietf.org > Subject: Re: [Anima] Question to the WG about > draft-ietf-anima-prefix-management >=20 > My vote is yes. >=20 > There are a lot of IPv4 systems out there, and if we can retrofit into th= em (even > if it requires a bit of smoke and mirrors to fake the existence of an IDe= vID), > then that would be a big win. >=20 > Bill >=20 > On 03/05/2017 9:57 PM, Brian E Carpenter wrote: > > Hi, > > > > Before we move the prefix management draft forward, I've been > > enhancing the corresponding demonstration ASA to be more realistic. > > The new version isn't quite ready for public release yet, but I have > > made it capable of dynamically assigning prefixes of any reasonable > > length on demand (the previous version was limited to a few pre-defined > prefix lengths). > > > > Doing this, I realised that it's a very simple enhancement to include > > IPv4 prefixes (represented as IPv4-mapped IPv6 addresses). For fun, > > you can look at the output from the ASA below, which shows how it can > > split a /104 prefix into multiple longer prefixes when asked to assign > > a /120 (known in IPv4 as a /24). > > > > So to my question: should we add an "IP version" flag to the > > PrefixManager objective? It would be easy to do, and would allow one > > to write an ASA that manages prefixes for both protocols. > > > > Regards > > Brian > > > > [output edited only by deleting noise] > > > > _MainThread 3268 GRASP startup function exiting _MainThread 3268 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D _MainThread 3268 ASA Pfxm2 is starting up. > > _MainThread 3268 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D _MainThread 3268 > Pfxm2 is > > a demonstration Autonomic Service Agent. > > _MainThread 3268 It supports the IPv6 Edge Prefix Management > > _MainThread 3268 objective 'PrefixManager' and its companion > > _MainThread 3268 'PrefixManager.Params'. > > > > Act as master? Y/N:y > > _MainThread 3268 This ASA will provide an initial prefix pool. > > _MainThread 3268 Also, it will supply default parameters for other ASAs= . > > Default prefix for pool? Y/N:n > > Prefix length for pool (3..127):104 > > Manual prefix entry? Y/N:y > > Enter IPv6 prefix:::ffff:10.0.0.0 > > _MainThread 3268 Prefix pool contents: > > _MainThread 3268 ::ffff:a00:0 / 104 > > > >>>> p =3D get_from_pool(120) > >>>> ipaddress.IPv6Address(p) > > IPv6Address('::ffff:aff:ff00') > >>>> dump_pool() > > _MainThread 3268 Prefix pool contents: > > _MainThread 3268 ::ffff:a00:0 / 105 > > _MainThread 3268 ::ffff:a80:0 / 106 > > _MainThread 3268 ::ffff:ac0:0 / 107 > > _MainThread 3268 ::ffff:ae0:0 / 108 > > _MainThread 3268 ::ffff:af0:0 / 109 > > _MainThread 3268 ::ffff:af8:0 / 110 > > _MainThread 3268 ::ffff:afc:0 / 111 > > _MainThread 3268 ::ffff:afe:0 / 112 > > _MainThread 3268 ::ffff:aff:0 / 113 > > _MainThread 3268 ::ffff:aff:8000 / 114 _MainThread 3268 > > ::ffff:aff:c000 / 115 _MainThread 3268 ::ffff:aff:e000 / 116 > > _MainThread 3268 ::ffff:aff:f000 / 117 _MainThread 3268 > > ::ffff:aff:f800 / 118 _MainThread 3268 ::ffff:aff:fc00 / 119 > > _MainThread 3268 ::ffff:aff:fe00 / 120 > >>>> > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > >=20 > -- >=20 > Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 > Distinguished Professor Emeritus fax: +1 (514) 848-2830 > Department of Computer Science > and Software Engineering > Concordia University EV 3.185 email:william.atwood@concordia.ca > 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill > Montreal, Quebec Canada H3G 1M8 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Fri May 5 08:08:19 2017 Return-Path: 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 9CB21128AFE for ; Fri, 5 May 2017 08:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38aztg-9c-Hh for ; Fri, 5 May 2017 08:08:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB393126E01 for ; Fri, 5 May 2017 08:08:15 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 62037203CA; Fri, 5 May 2017 11:34:17 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EA464636E0; Fri, 5 May 2017 11:08:14 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-Reply-To: <3caf4ba8-1e3e-9388-09fc-3d29a10f2a69@gmail.com> References: <1347ae5f-4e68-c4d7-4cfd-3df0295993ce@gmail.com> <28520.1493815868@obiwan.sandelman.ca> <3caf4ba8-1e3e-9388-09fc-3d29a10f2a69@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Content-Transfer-Encoding: quoted-printable Date: Fri, 05 May 2017 11:08:14 -0400 Message-ID: <23803.1493996894@obiwan.sandelman.ca> Archived-At: Subject: Re: [Anima] GRASP multicast frequency X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 15:08:18 -0000 Brian E Carpenter wrote: >> Given an ACP, the L2 devices should only see unicast ESP packets. > I believe so (another reason for good ACP support for LL multicast). > It also occurred to me that if we want autonomic traffic to flow wha= tever > else happens, we should consider setting diffserv CS6 or CS7 in all = ACP > traffic (cf section 4.2.2.3 of RFC2474). It can't hurt! We need to set it on the outside of the tunnel, of course. -- ] Never tell me the odds! | ipv6 mesh networ= ks [ ] Michael Richardson, Sandelman Software Works | network architec= t [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Sat May 6 20:04:25 2017 Return-Path: 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 42DCD1270A7 for ; Sat, 6 May 2017 20:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnuJHuZmUQb8 for ; Sat, 6 May 2017 20:04:22 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 97F541205D3 for ; Sat, 6 May 2017 20:04:22 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id q20so18528631pfg.0 for ; Sat, 06 May 2017 20:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=Wz/B1kp/Cuyawu0vwknmFQxCioeoa/vLdoIF4tRNoDs=; b=cInsmAKJUajrUjBmyTucmNnoIv4hx/lE33n/gHPOlKljyYNZA3Ha40ZSLfANSsegjB uHqZAik7LwXavDE3/fp4CHK+0g4q/UkzgUpbd6rap2tGAxMrw5cPOyrAFKzPgIH9R5DG gu+FJmC2RSiOHvzjxmr7XsaHRyHdZR/jOU+TcQmfG3vz5vHmX3i8HtTp6dVt/5G+IEBR 0lFiawZH80kQWSB6P254S7djhL4DUduE7b6glMepNoWerqEloKqmwI2Ls2wrLmX1ZuUf PHsRf5NvwxH+PfpMEIzefUGMdt5YPra6HQhrrHM1U+++t05Iym0T2oznKvi0wxmCIkaE Bq2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=Wz/B1kp/Cuyawu0vwknmFQxCioeoa/vLdoIF4tRNoDs=; b=nWE5HWZ+o9Ye0aD/SDChA6eHK4QJtDofOqLjgLvIs0s4L9XMnlQgud2gNxDM+gyicp 55ZMtUUKB+aApab9zSW1a48uLlYDAh16RwMSkwvephHxDVjzdU3nGQcBok6p2PUwkZNv beywkNxq3tozCyBETDUc3AHfdDa9VPGS6+l9+8nAnMr0zHILUgRj6AoeR2BvowdnKfBa THjHjxDyJCjKlo5SQeKUs/jwEeeM++h8fcwjj2y0UQ/YSN/AnrCh8ATvwXKf3Qh12maU POSD20a1J2dXQ/75ZQlGftn43ik+Qe1sQQKxPTRT4helBzaHHAf+/k+y4au9WVXmfD2t VjEg== X-Gm-Message-State: AN3rC/7yEJOB/NkSca+tlCJM9/A9sMyNJk2NioD/F/FA6equ094E5IFo qswoMztJdH45lF2Z X-Received: by 10.99.125.13 with SMTP id y13mr11874784pgc.234.1494126262042; Sat, 06 May 2017 20:04:22 -0700 (PDT) Received: from [192.168.178.21] (181.228.69.111.dynamic.snap.net.nz. [111.69.228.181]) by smtp.gmail.com with ESMTPSA id w23sm14871529pfl.133.2017.05.06.20.04.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 May 2017 20:04:21 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <8d965972-312c-aff0-a011-b6198baa660e@gmail.com> Date: Sun, 7 May 2017 15:04:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Prefix manager code updated X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 03:04:24 -0000 Hi, I've uploaded a new improved version of my demo code for draft-ietf-anima-prefix-management. It can be found at https://www.cs.auckland.ac.nz/~brian/graspy/pfxm2.py, but I advise reading the implementation notes first: https://www.cs.auckland.ac.nz/~brian/graspy/pfxm2.pdf . There's also a screen shot at https://www.cs.auckland.ac.nz/~brian/graspy/prefixen.png . This shows a 'master' prefix manager (bottom left) and four prefix delegators in action, all running on the same machine (but independent GRASP instances). It works between machines too, but that's hard to capture in a screen shot. TL;DR: "Apart from figuring out the bit manipulations and eliminating a few fencepost errors, this was quite easy work. I think it shows that the whole mechanism is viable. With stable storage added, and a secure ACP, it should be safe for real world use. Expansion to cover IPv4 as well would be straightforward, if the objective format allowed it." Regards Brian Carpenter From nobody Sun May 7 19:41:49 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 486021243F3; Sun, 7 May 2017 19:41:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149421130029.23119.9372718991371280967.idtracker@ietfa.amsl.com> Date: Sun, 07 May 2017 19:41:40 -0700 Archived-At: Subject: [Anima] Spencer Dawkins' No Objection on draft-ietf-anima-grasp-11: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 02:41:40 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-anima-grasp-11: 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-anima-grasp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In this text, T6. The protocol must be capable of supporting multiple simultaneous operations with one or more peers, especially when wait states occur. I understand every word, but I'm not sure what this requires the protocol to do. Are you asking that the protocol be non-blocking? But that's a guess. In this text, A GRASP implementation will be part of the Autonomic Networking Infrastructure in an autonomic node, which must also provide an appropriate security environment. In accordance with [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. I wonder what happens if the security environment isn't the ACP. Is that obvious? In this text, An implementation MUST support use of TCP. It MAY support use of another transport protocol. However, GRASP itself does not provide for error detection or retransmission. Use of an unreliable transport protocol is therefore NOT RECOMMENDED. just to educate me, is the strategy here, that (for instance) if synchronization fails over an unreliable transport protocol, that eventually it will be attempted again, just because the two ACAs know they aren't synchronized? I'm really confused by this text. Nevertheless, when running within a secure ACP on reliable infrastructure, UDP MAY be used for unicast messages not exceeding the minimum IPv6 path MTU; however, TCP MUST be used for longer messages. In other words, IPv6 fragmentation is avoided. If a node receives a UDP message but the reply is too long, it MUST open a TCP connection to the peer for the reply. Note that when the network is under heavy load or in a fault condition, UDP might become unreliable. Since this is when autonomic functions are most necessary, automatic fallback to TCP MUST be implemented. The simplest implementation is therefore to use only TCP. We've been having quite the discussion about how well Path MTU Discovery works, even in IPv6. Because GRASP could be running over virtual interfaces, I suspect there's a chance that you'll be running in a tunnel that will give you a Path MTU that's smaller than the IPv6 minimum. But ignoring that for now ... IIRC, we've had poor experiences with protocols that are expected to switch from UDP transport to TCP transport in the middle of a request/response pair. But, setting THAT aside for now ... This text correctly points out that UDP transport is most likely to fail under heavy network load or in a fault condition, when autonomic functions are most necessary. If TCP is mandatory to implement, and implementations will need to switch from UDP to TCP at the most awkward times, and that's been a problem area for other protocols in the past, why not just require TCP in the first place? I see that the UDP/TCP question was listed as an open issue before it was closed, so I'm not balloting Discuss, because I assume I'm missing something that people will help me understand, but I thought about it for a while ... Thanks for this text, If no discovery response is received within a reasonable timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the Discovery message MAY be repeated, with a newly generated Session ID (Section 3.7). An exponential backoff SHOULD be used for subsequent repetitions, to limit the load during busy periods. Frequent repetition might be symptomatic of a denial of service attack. and especially for the warning about DoS attacks. I found Appendix D and E useful. Thanks for including both of them. From nobody Mon May 8 14:48:31 2017 Return-Path: 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 C5B07127333; Mon, 8 May 2017 14:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 g151btJh0Pzk; Mon, 8 May 2017 14:48:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E181A126BFD; Mon, 8 May 2017 14:48:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 48C6A203B0; Mon, 8 May 2017 18:14:36 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9A96E636E0; Mon, 8 May 2017 17:48:22 -0400 (EDT) From: Michael Richardson To: anima@ietf.org Reply-To: anima@ietf.org cc: anima-bootstrap@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] upcoming bootstrap design team meetings X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 21:48:26 -0000 --=-=-= Content-Type: text/plain To be clear, we continue to meet on Tuesdays at 10am EDT (1400UTC). The meeting are at: https://appear.in/anima-boostrap using webrtc. We continue to use the etherpad, which is now on HTTPS at: https://etherpad.tools.ietf.org/p/anima-boostrapping?useMonospaceFont=true The dates are: 2017-05-08 2017-05-15 2017-05-22 2017-05-29 2017-06-06 2017-06-13 2017-06-20 2017-06-27 2017-07-04 CANCELLED 2017-07-11 IETF99 PRAGUE I'm writing minutes which I'll get done later tonight, but I wanted to get this off in time for people to read for whom the start time is earlier in their Tuesday. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkQ56YACgkQgItw+93Q 3WXXyQf/U3F/pKNHGCLtqyfk3dQE3YxHEc16DRJAIp33JDJTAzwEY8fjinL0zBu2 0tp3bs6/HU2B+mIy/vO0cl7BxmqxvIlTXoTvaRvj5rcx3d+YsbCzGZFsDzGOzXAs tI7LXP/gettP7wRFERzEB/NuxxJ6xCNz049Y0N7UiFjJkfUtN8XZ+hqHaHPXF1bl fsb5V9VDTZVLLDCRuRfRWogHZeq3j0K9bsEMdOqriiTe5OoQqG62B7L2iLZf6Jo3 C78R16Z/qKZE6qigyczJXU/91yub2sLvWu4unJfi/LhKQxViyy2njLa+LS8UGh4l 4zsfglsrGTRGmxSYbWspcTgm1Hi1Uw== =ZEWF -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 8 20:38:38 2017 Return-Path: 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 8851B129A97; Mon, 8 May 2017 20:38:37 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T94Jh5pk91Fd; Mon, 8 May 2017 20:38:35 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 96E5B126C2F; Mon, 8 May 2017 20:38:35 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id b23so12127958pfc.0; Mon, 08 May 2017 20:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:cc:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hKb7a6bVFdOyIPbS27WDljAvS8J5SwrBx5qNzpDtzi8=; b=TIpLeMJ95msiL0it4xgsNCBfou+fOZzCIQa7abIX/t00mzPhZ4sF0+ti9k0LSoGk7r EzVWFmb8QC7KT9XFDzC/Ci+VHLamZr2+HYH/pE/sCvhG5dYSflMjT8yxTrNnTvi3LIc6 tmBIYj8/tGrffZZecDEtu9bqT8PlQs0RcZv2Nm0QWn+Ps8NWY3rruSuiGQ5NvQQveROP +OOqpVDWumJl1q4t/iJqY9xa36HPX+m/B8JN11EGtQe4HiExmSSlGMb0patKRtRLch3r ndxFBHYwWpVE8Ettb+Rx0nZb2e3dV4ObxYbhFF9v0nWGe+WhLgw2o5mg5bPp5/WkUuYb 6b/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=hKb7a6bVFdOyIPbS27WDljAvS8J5SwrBx5qNzpDtzi8=; b=H7Cj/WslPZGRb1N37dfhStqymkMrSLHQEkdGi+Yews3/k6R4aO3tav34TWsNSUQo54 SOayTVb6D4dAhbgcTSwWbxb7R3uYjyyVjsraNTvfWwPKuaOPytsGD0nqeJ48e9AzkjxC s9/Zc/U3kq6ABFkj/1cbtvBl9/NqSlk9sUHxSpMBtTKHHWnTUCSo4Ckv2uUKmpoW/6jd Div6uSCJlEu+y0A+NLzPPVwekbwXqk0PgOKKEs02s0GsuMNfs4ErVwxyGEk0NlZlGSL7 ZA/fB5w35WpAAlpzCgye9ee2+hS1/QPnGVZZNqFRq4b4KeA2JqWURTPQEJQk++8smZ3D LgzA== X-Gm-Message-State: AN3rC/7usuHQOSneN40daepY98pafscD8ZyU2bzeUwgNBPlxUTrw/xmc CLRNgZ8IBNvAJfFK X-Received: by 10.99.178.90 with SMTP id t26mr21826635pgo.136.1494301114884; Mon, 08 May 2017 20:38:34 -0700 (PDT) Received: from [192.168.178.21] (101.23.255.123.dynamic.snap.net.nz. [123.255.23.101]) by smtp.gmail.com with ESMTPSA id n71sm11778273pfg.46.2017.05.08.20.38.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 May 2017 20:38:34 -0700 (PDT) From: Brian E Carpenter To: Spencer Dawkins References: <149421130029.23119.9372718991371280967.idtracker@ietfa.amsl.com> Cc: draft-ietf-anima-grasp@ietf.org, anima-chairs@ietf.org, Anima WG , IESG Organization: University of Auckland Message-ID: Date: Tue, 9 May 2017 15:38:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149421130029.23119.9372718991371280967.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Spencer Dawkins' No Objection on draft-ietf-anima-grasp-11: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 03:38:37 -0000 On 08/05/2017 14:41, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-anima-grasp-11: No Objection ... > In this text, > > T6. The protocol must be capable of supporting multiple > simultaneous > operations with one or more peers, especially when wait states > occur. > > I understand every word, but I'm not sure what this requires the protocol > to do. Are you asking that the protocol be non-blocking? But that's a > guess. The practical implication is that we need session IDs, so that overlapping operations can be distinguished. It's a bit over-simplified to call it non-blocking - for example discover/discovery response looks like a blocking call with timeout in the API, but the underlying messages are atomic. > > In this text, > > A GRASP implementation will be part of the Autonomic Networking > Infrastructure in an autonomic node, which must also provide an > appropriate security environment. In accordance with > [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic > Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. > > I wonder what happens if the security environment isn't the ACP. Is that > obvious? Hopefully https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.1 explains this. > > In this text, > > An implementation MUST support use of TCP. > It MAY support use of another transport protocol. However, GRASP > itself does not provide for error detection or retransmission. Use > of an unreliable transport protocol is therefore NOT RECOMMENDED. > > just to educate me, is the strategy here, that (for instance) if > synchronization fails over an unreliable transport protocol, that > eventually it will be attempted again, just because the two ACAs know > they aren't synchronized? Actually even 'reliable' transports can fail on occasion, so I'd say that an implementation should *always* wait and retry. UDP just makes it all harder. > > I'm really confused by this text. > > Nevertheless, when running within a secure ACP on reliable > infrastructure, UDP MAY be used for unicast messages not exceeding > the minimum IPv6 path MTU; however, TCP MUST be used for longer > messages. In other words, IPv6 fragmentation is avoided. If a node > receives a UDP message but the reply is too long, it MUST open a TCP > connection to the peer for the reply. Note that when the network is > under heavy load or in a fault condition, UDP might become > unreliable. Since this is when autonomic functions are most > necessary, automatic fallback to TCP MUST be implemented. The > simplest implementation is therefore to use only TCP. > > We've been having quite the discussion about how well Path MTU Discovery > works, even in IPv6. Because GRASP could be running over virtual > interfaces, I suspect there's a chance that you'll be running in a tunnel > that will give you a Path MTU that's smaller than the IPv6 minimum. But > ignoring that for now ... > > IIRC, we've had poor experiences with protocols that are expected to > switch from UDP transport to TCP transport in the middle of a > request/response pair. But, setting THAT aside for now ... > > This text correctly points out that UDP transport is most likely to fail > under heavy network load or in a fault condition, when autonomic > functions are most necessary. If TCP is mandatory to implement, and > implementations will need to switch from UDP to TCP at the most awkward > times, and that's been a problem area for other protocols in the past, > why not just require TCP in the first place? Personally (editor hat off) I would eliminate UDP completely except for the multicasts, but there are others who believe that UDP has its place. So I guess this is compromise text. I'll be interested to see if anybody can make a UDP variant work robustly. > > I see that the UDP/TCP question was listed as an open issue before it was > closed, so I'm not balloting Discuss, because I assume I'm missing > something that people will help me understand, but I thought about it for > a while ... > > Thanks for this text, > > If no discovery response is received within a reasonable timeout > (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the Discovery > message MAY be repeated, with a newly generated Session ID > (Section 3.7). An exponential backoff SHOULD be used for subsequent > repetitions, to limit the load during busy periods. Frequent > repetition might be symptomatic of a denial of service attack. > > and especially for the warning about DoS attacks. > > I found Appendix D and E useful. Thanks for including both of them. Thanks for the comments. Brian From nobody Tue May 9 10:14:08 2017 Return-Path: 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 409831294F5; Tue, 9 May 2017 10:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIibc9QBbnR6; Tue, 9 May 2017 10:13:56 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 9AD45129494; Tue, 9 May 2017 10:13:56 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id l14so3801027ywk.1; Tue, 09 May 2017 10:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Igtv8OlPTFNuu3J6SJ7hwV72kxJuU7SxX5+V5sU753g=; b=uBMw/pmoIFFD9yYLp+N9itB8FWtjiwktskZ8aRSEiiltCgS1T1Lw6lBoTKGXcbA0ZI 2ijN09pQhnG6u2O47bSqXJO5iN/hBI4aghURUzKAqqcCd5TxApAshgch1IHiiTLvRTG7 3BTeUK0mZSckp64jMDKA0vh3brrrb0eZKAtEBLcxSyb6WcjIjRIX3CCWwqJWSxLt2iO6 T5WsfUdgylMhoN54vt/yUC3uJO7j3spfkL8TTmsok2vg+Q2tPFctlhe0ZKS+4WCKPOg8 RwgYP7tT4VIbdW8k11ulBx3CSs3OeGPaL/uINnBUgcYWJP9bipPCA0iAcn9ZeqvwWBft tkoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Igtv8OlPTFNuu3J6SJ7hwV72kxJuU7SxX5+V5sU753g=; b=IJGf6ktu3JDDjc52MogSLpQmvCKw9NT4o2XxmWYKIutrs1jgewYUuhxZQCOiyLNfqz bv8UXu7w3dOoYmIgpqku5aLAWTmoRJdNPfVFHBgUdmjo6T+CzCjq2du4kbYVmpKmyuf+ Xuqep+yiQxGJx4Pui09m+OQFJ2Vk47arm2/o9PGmJ9tf0Mu+1Ktv/ZXSMg0Cjr5Q3gYC 9MQswPNHgkbg1fneLsL/CfE/sx9eNufIuhegoY+W5gcoH4ECcj4ruIp0LXoPWtA4I4HQ klYzdU6h1QChO94MbLeiKiGl5wH2brPzxwhJBASCt7IL1GNF47qVE8Ee4MQLSC4KVhQh 67NA== X-Gm-Message-State: AODbwcBxYoYynAoUjJRpX2YVuAC99SABHZ8JB6mHTi9+jSVmznKv8v2N beGVDuvfvdzVQPEXB9IVySvNpgdr7irO X-Received: by 10.129.87.209 with SMTP id l200mr884190ywb.289.1494350035655; Tue, 09 May 2017 10:13:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.161.198 with HTTP; Tue, 9 May 2017 10:13:54 -0700 (PDT) In-Reply-To: References: <149421130029.23119.9372718991371280967.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Tue, 9 May 2017 12:13:54 -0500 Message-ID: To: Brian E Carpenter Cc: draft-ietf-anima-grasp@ietf.org, anima-chairs@ietf.org, Anima WG , IESG Content-Type: multipart/alternative; boundary=001a114564120ba816054f1a7bc2 Archived-At: Subject: Re: [Anima] Spencer Dawkins' No Objection on draft-ietf-anima-grasp-11: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 17:14:00 -0000 --001a114564120ba816054f1a7bc2 Content-Type: text/plain; charset=UTF-8 Hi, Brian, On Mon, May 8, 2017 at 10:38 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 08/05/2017 14:41, Spencer Dawkins wrote: > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-anima-grasp-11: No Objection > ... > > In this text, > > > > T6. The protocol must be capable of supporting multiple > > simultaneous > > operations with one or more peers, especially when wait states > > occur. > > > > I understand every word, but I'm not sure what this requires the protocol > > to do. Are you asking that the protocol be non-blocking? But that's a > > guess. > > The practical implication is that we need session IDs, so that overlapping > operations can be distinguished. It's a bit over-simplified to call it > non-blocking - for example discover/discovery response looks like a > blocking call with timeout in the API, but the underlying messages are > atomic. > Your explanation helped me understand a lot. Could I suggest something like OLD T6. The protocol must be capable of supporting multiple simultaneous operations with one or more peers, especially when wait states occur. New T6. The protocol must be capable of distinguishing multiple simultaneous operations with one or more peers, especially when wait states occur. (using the word "distinguishing" from your explanation that lifted my fog) > > > > In this text, > > > > A GRASP implementation will be part of the Autonomic Networking > > Infrastructure in an autonomic node, which must also provide an > > appropriate security environment. In accordance with > > [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic > > Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. > > > > I wonder what happens if the security environment isn't the ACP. Is that > > obvious? > > Hopefully https://tools.ietf.org/html/draft-ietf-anima-grasp-11# > section-3.5.1 > explains this. > It does, but that nudges me to ask another question. I'm looking at 3.2. High Level Deployment Model A GRASP implementation will be part of the Autonomic Networking Infrastructure in an autonomic node, which must also provide an appropriate security environment. In accordance with [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. and 3.5.1. Required External Security Mechanism The protocol SHOULD always run within a secure Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The ACP is assumed to carry all messages securely, including link-local multicast when it is virtualized over the ACP. A GRASP instance MUST verify whether the ACP is operational. If there is no ACP, one of the following alternatives applies: Are those SHOULDs saying the same thing using different words? Assuming so ... probably the easiest change that would have clued me in, would be to say (in 3.2) something like 3.2. High Level Deployment Model A GRASP implementation will be part of the Autonomic Networking Infrastructure in an autonomic node, which must also provide an appropriate security environment. In accordance with [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. If there is no ACP, the considerations described in Section 3.5.1 apply. as a forward pointer. You could likely link these two thoughts together in a better way, but I hope you see what I'm suggesting. > > > In this text, > > > > An implementation MUST support use of TCP. > > It MAY support use of another transport protocol. However, GRASP > > itself does not provide for error detection or retransmission. Use > > of an unreliable transport protocol is therefore NOT RECOMMENDED. > > > > just to educate me, is the strategy here, that (for instance) if > > synchronization fails over an unreliable transport protocol, that > > eventually it will be attempted again, just because the two ACAs know > > they aren't synchronized? > > Actually even 'reliable' transports can fail on occasion, so I'd say > that an implementation should *always* wait and retry. UDP just makes > it all harder. > Grrr, but please see below. > > > > > I'm really confused by this text. > > > > Nevertheless, when running within a secure ACP on reliable > > infrastructure, UDP MAY be used for unicast messages not exceeding > > the minimum IPv6 path MTU; however, TCP MUST be used for longer > > messages. In other words, IPv6 fragmentation is avoided. If a node > > receives a UDP message but the reply is too long, it MUST open a TCP > > connection to the peer for the reply. Note that when the network is > > under heavy load or in a fault condition, UDP might become > > unreliable. Since this is when autonomic functions are most > > necessary, automatic fallback to TCP MUST be implemented. The > > simplest implementation is therefore to use only TCP. > > > > We've been having quite the discussion about how well Path MTU Discovery > > works, even in IPv6. Because GRASP could be running over virtual > > interfaces, I suspect there's a chance that you'll be running in a tunnel > > that will give you a Path MTU that's smaller than the IPv6 minimum. But > > ignoring that for now ... > > > > IIRC, we've had poor experiences with protocols that are expected to > > switch from UDP transport to TCP transport in the middle of a > > request/response pair. But, setting THAT aside for now ... > > > > This text correctly points out that UDP transport is most likely to fail > > under heavy network load or in a fault condition, when autonomic > > functions are most necessary. If TCP is mandatory to implement, and > > implementations will need to switch from UDP to TCP at the most awkward > > times, and that's been a problem area for other protocols in the past, > > why not just require TCP in the first place? > > Personally (editor hat off) I would eliminate UDP completely except for > the multicasts, but there are others who believe that UDP has its place. > So I guess this is compromise text. I'll be interested to see if anybody > can make a UDP variant work robustly. > > > > > I see that the UDP/TCP question was listed as an open issue before it was > > closed, so I'm not balloting Discuss, because I assume I'm missing > > something that people will help me understand, but I thought about it for > > a while ... > Continued from "grrr" above ... I'm muttering to myself, "This looks like the working group is choosing to drag the same kind of weird corner cases SIP applications have when they're written to run over both TCP and UDP into 21st century applications, except that these applications can be misconfiguring networks at scale when they get something wrong, rather than just keeping us from completing a VoIP call." Having muttered that to myself, I re-read https://www.ietf.org/iesg/statement/discuss-criteria.html, and can't decide whether I'm muttering about something that's closer to the Discuss criteria "The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity" or the Discuss NON-criteria "Disagreement with informed WG decisions that do not exhibit problems outlined in Section 3.1 (DISCUSS Criteria). In other words, disagreement in preferences among technically sound approaches." Unfortunately, "this is likely to blow up badly" doesn't obviously fall into either bucket. So, I'll leave this as a Comment, and let the many folks who see IESG ballot positions these days think about this, and either tell me that this isn't a problem, or that it is. Several of them have more relevant experience with application protocols that use multiple transports than I do. Alternatively, perhaps providing a DNS-style "TrunCation" indicator (as in https://www.ietf.org/rfc/rfc1035.txt) and letting applications retry using TCP would be useful. But, do the right thing, whether I think it's the right thing or not, of course. > Thanks for this text, > > > > If no discovery response is received within a reasonable timeout > > (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the Discovery > > message MAY be repeated, with a newly generated Session ID > > (Section 3.7). An exponential backoff SHOULD be used for subsequent > > repetitions, to limit the load during busy periods. Frequent > > repetition might be symptomatic of a denial of service attack. > > > > and especially for the warning about DoS attacks. > > > > I found Appendix D and E useful. Thanks for including both of them. > > Thanks for the comments. > > Brian > It's always a pleasure :-) Spencer --001a114564120ba816054f1a7bc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Brian,

On Mon, May 8, 2017 at 10:38 PM, Brian E Carpenter <br= ian.e.carpenter@gmail.com> wrote:
On 08/05/2017 14:41, Spenc= er Dawkins wrote:
> Spencer Dawkins has entered the followin= g ballot position for
> draft-ietf-anima-grasp-11: No Objection
...
> In this text,
>
>=C2=A0 =C2=A0 T6.=C2=A0 The protocol must be capable of supporting mult= iple
> simultaneous
>=C2=A0 =C2=A0 operations with one or more peers, especially when wait s= tates
> occur.
>
> I understand every word, but I'm not sure what this requires the p= rotocol
> to do. Are you asking that the protocol be non-blocking? But that'= s a
> guess.

The practical implication is t= hat we need session IDs, so that overlapping
operations can be distinguished. It's a bit over-simplified to call it<= br> non-blocking - for example discover/discovery response looks like a
blocking call with timeout in the API, but the underlying messages are
atomic.

Your explanation helped = me understand a lot.=C2=A0

Could I suggest somethi= ng like

OLD

T6.=C2=A0 The prot= ocol must be capable of supporting multiple simultaneous operations with on= e or more peers, especially when wait states occur.

New

T6.=C2=A0 The protocol must be = capable of distinguishing multiple simultaneous operations with one or more= peers, especially when wait states occur.
=
(using the word "distinguishing&q= uot; from your explanation that lifted my fog)
=C2=A0
>
> In this text,
>
>=C2=A0 =C2=A0 A GRASP implementation will be part of the Autonomic Netw= orking
>=C2=A0 =C2=A0 Infrastructure in an autonomic node, which must also prov= ide an
>=C2=A0 =C2=A0 appropriate security environment.=C2=A0 In accordance wit= h
>=C2=A0 =C2=A0 [I-D.ietf-anima-reference-model], this SHOULD be the= Autonomic
>=C2=A0 =C2=A0 Control Plane (ACP) [I-D.ietf-anima-autonomic-contro= l-plane].
>
> I wonder what happens if the security environment isn't the ACP. I= s that
> obvious?

Hopefully https://tools.ietf.org/html/draft-ietf-anima-gra= sp-11#section-3.5.1
explains this.

It does, but that= nudges me to ask another question.

I'm lookin= g at

3.2.=C2=A0 High Level Deployment Model
<= div>
=C2=A0 =C2=A0A GRASP implementation will be part of the = Autonomic Networking
=C2=A0 =C2=A0Infrastructure in an autonomic = node, which must also provide an
=C2=A0 =C2=A0appropriate securit= y environment.=C2=A0 In accordance with
=C2=A0 =C2=A0[I-D.ietf-an= ima-reference-model], this SHOULD be the Autonomic
=C2=A0 =C2=A0C= ontrol Plane (ACP) [I-D.ietf-anima-autonomic-control-plane].=C2=A0

and=C2=A0

3.5.1.=C2=A0 Required E= xternal Security Mechanism

=C2=A0 =C2=A0The protoc= ol SHOULD always run within a secure Autonomic Control
=C2=A0 =C2= =A0Plane (ACP) [I-D.ietf-anima-autonomic-control-plane].=C2=A0 The ACP is
=C2=A0 =C2=A0assumed to carry all messages securely, including lin= k-local
=C2=A0 =C2=A0multicast when it is virtualized over the AC= P.=C2=A0 A GRASP instance MUST
=C2=A0 =C2=A0verify whether the AC= P is operational.

=C2=A0 =C2=A0If there is no ACP,= one of the following alternatives applies:

Are th= ose SHOULDs saying the same thing using different words?

Assuming so ... probably the easiest change that would have clued me= in, would be to say (in 3.2) something like=C2=A0

3.2.=C2=A0 High Level Deployment Model

=C2=A0 =C2= =A0A GRASP implementation will be part of the Autonomic Networking
=C2=A0 =C2=A0Infrastructure in an autonomic node, which must also provide= an
=C2=A0 =C2=A0appropriate security environment.=C2=A0 In accor= dance with
=C2=A0 =C2=A0[I-D.ietf-anima-reference-model], this SH= OULD be the Autonomic
=C2=A0 =C2=A0Control Plane (ACP) [I-D.ietf-= anima-autonomic-control-plane].=C2=A0
=C2=A0 =C2=A0If there is no= ACP, the considerations described in Section 3.5.1=C2=A0
=C2=A0 = =C2=A0apply.

as a forward pointer.=C2=A0

You could likely link these two thoughts together in a bett= er way, but I hope you see what I'm suggesting.=C2=A0

>
> In this text,
>
>=C2=A0 =C2=A0 An implementation MUST support use of TCP.
>=C2=A0 =C2=A0 It MAY support use of another transport protocol.=C2=A0 H= owever, GRASP
>=C2=A0 =C2=A0 itself does not provide for error detection or retransmis= sion.=C2=A0 Use
>=C2=A0 =C2=A0 of an unreliable transport protocol is therefore NOT RECO= MMENDED.
>
> just to educate me, is the strategy here, that (for instance) if
> synchronization fails over an unreliable transport protocol, that
> eventually it will be attempted again, just because the two ACAs know<= br> > they aren't synchronized?

Actually even 'reliable= 9; transports can fail on occasion, so I'd say
that an implementation should *always* wait and retry. UDP just makes
it all harder.

Grrr, but please = see below.=C2=A0

>
> I'm rea= lly confused by this text.
>
>=C2=A0 =C2=A0 Nevertheless, when running within a secure ACP on reliabl= e
>=C2=A0 =C2=A0 infrastructure, UDP MAY be used for unicast messages not = exceeding
>=C2=A0 =C2=A0 the minimum IPv6 path MTU; however, TCP MUST be used for = longer
>=C2=A0 =C2=A0 messages.=C2=A0 In other words, IPv6 fragmentation is avo= ided.=C2=A0 If a node
>=C2=A0 =C2=A0 receives a UDP message but the reply is too long, it MUST= open a TCP
>=C2=A0 =C2=A0 connection to the peer for the reply.=C2=A0 Note that whe= n the network is
>=C2=A0 =C2=A0 under heavy load or in a fault condition, UDP might becom= e
>=C2=A0 =C2=A0 unreliable.=C2=A0 Since this is when autonomic functions = are most
>=C2=A0 =C2=A0 necessary, automatic fallback to TCP MUST be implemented.= =C2=A0 The
>=C2=A0 =C2=A0 simplest implementation is therefore to use only TCP.
>
> We've been having quite the discussion about how well Path MTU Dis= covery
> works, even in IPv6. Because GRASP could be running over virtual
> interfaces, I suspect there's a chance that you'll be running = in a tunnel
> that will give you a Path MTU that's smaller than the IPv6 minimum= . But
> ignoring that for now ...
>
> IIRC, we've had poor experiences with protocols that are expected = to
> switch from UDP transport to TCP transport in the middle of a
> request/response pair. But, setting THAT aside for now ...
>
> This text correctly points out that UDP transport is most likely to fa= il
> under heavy network load or in a fault condition, when autonomic
> functions are most necessary. If TCP is mandatory to implement, and > implementations will need to switch from UDP to TCP at the most awkwar= d
> times, and that's been a problem area for other protocols in the p= ast,
> why not just require TCP in the first place?

Personally (editor hat of= f) I would eliminate UDP completely except for
the multicasts, but there are others who believe that UDP has its place. So I guess this is compromise text. I'll be interested to see if anybod= y
can make a UDP variant work robustly.

>
> I see that the UDP/TCP qu= estion was listed as an open issue before it was
> closed, so I'm not balloting Discuss, because I assume I'm mis= sing
> something that people will help me understand, but I thought about it = for
> a while ...

Continued from = "grrr" above ...

I'm muttering to my= self, "This looks like the working group is choosing to drag the same = kind of weird corner cases SIP applications have when they're written t= o run over both TCP and UDP into 21st century applications, except that the= se applications can be misconfiguring networks at scale when they get somet= hing wrong, rather than just keeping us from completing a VoIP call."<= /div>

Having muttered that to myself, I re-read=C2=A0https://= www.ietf.org/iesg/statement/discuss-criteria.html, and can't decide= whether I'm muttering about something that's closer to the Discuss= criteria

"The protocol has technical flaws that will prevent it = from working properly, or the description is unclear in such a way that the= reader cannot understand it without ambiguity"
=C2=A0
or the Discuss NON-criteria=C2=A0

"Disagreement with= informed WG decisions that do not exhibit problems outlined in Section 3.1= (DISCUSS Criteria). In other words, disagreement in preferences among tech= nically sound approaches."

Unfortunately,= "this is likely to blow up badly" doesn't obviously fall int= o either bucket.

So, I'll leave this as a Comm= ent, and let the many folks who see IESG ballot positions these days think = about this, and either tell me that this isn't a problem, or that it is= . Several of them have more relevant experience with application protocols = that use multiple transports than I do.

Alternativ= ely, perhaps providing a DNS-style "TrunCation" indicator (as in= =C2=A0https://www.ietf.org= /rfc/rfc1035.txt) and letting applications retry using TCP would be use= ful.=C2=A0

But, do the right thing, whether I thin= k it's the right thing or not, of course.

> Thanks for this text,
>
>=C2=A0 =C2=A0 If no discovery response is received within a reasonable = timeout
>=C2=A0 =C2=A0 (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), th= e Discovery
>=C2=A0 =C2=A0 message MAY be repeated, with a newly generated Session I= D
>=C2=A0 =C2=A0 (Section 3.7).=C2=A0 An exponential backoff SHOULD be use= d for subsequent
>=C2=A0 =C2=A0 repetitions, to limit the load during busy periods.=C2=A0= Frequent
>=C2=A0 =C2=A0 repetition might be symptomatic of a denial of service at= tack.
>
> and especially for the warning about DoS attacks.
>
> I found Appendix D and E useful. Thanks for including both of them.
Thanks for the c= omments.

=C2=A0 =C2=A0 =C2=A0Brian

It= 9;s always a pleasure :-)

Spencer=C2=A0
--001a114564120ba816054f1a7bc2-- From nobody Tue May 9 11:05:09 2017 Return-Path: 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 619D512EAC1; Tue, 9 May 2017 11:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 P8x-vLjRTf34; Tue, 9 May 2017 11:04:58 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F45E12EABD; Tue, 9 May 2017 11:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33368; q=dns/txt; s=iport; t=1494353098; x=1495562698; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hWMXLOvVhwLE2WLfoOJkLXZe4tyZNk9eQ3J7yiR8lOQ=; b=Sis57y2KEcBRmgnWUKGawaleVnLzTdQIuukfa56A76Xj7GDmM3Gn1rcl +6vfQ89JiT3XzKneWyAg46KpFDFz3s2GixU2XggLoXxf3UMznbAOY6KlN dWBJYMtrRtyM2uW9h9kQWMmavJquSuUkuq+tfy5AZOYb4LFLnoYiwOAbU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRBQBrBBJZ/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1ViMloHg2J3iSGQfTghcpUAggwDIQuFeAIahFM/GAECAQEBAQE?= =?us-ascii?q?BAWsoQg4BhEQBAQEBAgEBARgJEToLBQsCAQYCDgoCAiYCAgIlCxUQAgQOBYgdA?= =?us-ascii?q?4F5CA6VIJ1hgiaKcAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuHMQErC4IxNIR?= =?us-ascii?q?jF4JzLoIxBZ4FAZMYggSFO4NmhkaIfYtCAR84gQpwFUYSAYRhHIFjdoERhlaBD?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,315,1491264000"; d="scan'208";a="424047434" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2017 18:04:57 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v49I4umU030079 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2017 18:04:56 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 May 2017 13:04:56 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Tue, 9 May 2017 13:04:56 -0500 From: "Max Pritikin (pritikin)" To: Kent Watsen CC: "anima@ietf.org" , "anima-bootstrap@ietf.org" Thread-Topic: [Anima-bootstrap] Voucher signing method Thread-Index: AQHSw6vLF2XUnWVoW0q/VYcsqILMZqHsqfMA Date: Tue, 9 May 2017 18:04:55 +0000 Message-ID: <3A44A1B8-57B3-4178-970B-97BBB594B888@cisco.com> References: <88FB0F4F-2816-4BCE-A775-EBEE1CFCC0CD@juniper.net> In-Reply-To: <88FB0F4F-2816-4BCE-A775-EBEE1CFCC0CD@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.4] Content-Type: text/plain; charset="utf-8" Content-ID: <7087CAAC5073DE4A8840ABC0609F6DDF@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] [Anima-bootstrap] Voucher signing method X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 18:05:01 -0000 DQo+IE9uIE1heSAyLCAyMDE3LCBhdCA3OjIyIFBNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5p cGVyLm5ldD4gd3JvdGU6DQo+IA0KPiANCj4gSSd2ZSBoYWQgc29tZSB0aW1lIG5vdyB0byBpbnZl c3RpZ2F0ZSBKV1MsIGluIHBhcnRpY3VsYXIsIHJlcHJvZHVjaW5nIHNvbWUgZXhhbXBsZXMgaW4g UkZDcyA3NTE1IGFuZCA3NTIwIHVzaW5nIG5vdGhpbmcgYnV0IHNoZWxsIHNjcmlwdHMgYW5kIHRo ZSBgb3BlbnNzbGAgY29tbWFuZCBsaW5lIHV0aWxpdHkuDQoNCkV4Y2VsbGVudC4gSSBsb29rIGZv cndhcmQgdG8gaGVhcmluZyB3aGF0IHRvb2wgeW91IHVzZWQgdG8gY29udmVydCB0aGUgb3BlbnNz bCBkZ3N0IHNpZ25hdHVyZSB0byB0aGUgSldTIGZvcm0uIA0KDQo+IEkgd2FudCB0byBsaWtlIEpX UywgYnV0IEkgd2lzaCB0aGUgaGVhZGVyIHdhcyBpbiBhIG1vcmUgdGVjaG5vbG9neS1uZXV0cmFs IGZvcm1hdCwgaXQgYmVpbmcgSlNPTiBzZWVtcyB3ZWlyZCB0byBtZS4NCg0KR2l2ZW4gdGhhdCB3 ZeKAmXJlIGFscmVhZHkgdXNpbmcgSlNPTiAod2l0aCBkaXNjdXNzaW9uIG9mIENCT1IpIHRoaXMg ZG9lc27igJl0IHNlZW0gcmVsZXZhbnQgc2luY2Ugd2UgYXJlbuKAmXQgdGVjaG5vbG9neS1uZXV0 cmFsIGVpdGhlci4gSSBkb27igJl0IGtub3cgdGhhdCB0aGVyZSBpcyBzdWNoIGEgdGhpbmcgYXMg YSB0ZWNobm9sb2d5IG5ldXRyYWwgaGVhZGVyLiANCg0KPiAgSGFkIHRoaXMgYmVlbiBkb25lLCBp dCB3b3VsZCBiZSBhIG5pY2UgZ2VuZXJhbC1wdXJwb3NlIHNpZ25hdHVyZSBmb3JtYXQuICBTaXpl IHdpc2UsIEpXUyBncm93cyB0aGUgc2l6ZSBvZiB0aGUgZGF0YSAzMyUgd2hlbiBiNjQgZW5jb2Rp bmcgaXQgZm9yIHRoZSAiY29tcGFjdCBzZXJpYWxpemF0aW9uIiBmb3JtLCB3aGljaCBpcyBhY3R1 YWxseSBhIDY1LWNoYXJhY3RlciBhbHBoYWJldCBpbmNsdWRpbmcgJy4nLiAgSXQgc2VlbXMgdGhh dCBhIGJpbmFyeSBoZWFkZXIgY291bGQndmUgYWxzbyBhbGxvd2VkIGZvciBhIGJpbmFyeSBwYXls b2FkIGFuZCBzaWduYXR1cmUsIHdoaWNoIHdvdWxkJ3ZlIGJlZW4gcGVyZmVjdCwgaW4gbXkgb3Bp bmlvbi4gIFtPZiBjb3Vyc2UsIHRoZSBlbnRpcmUgYmluYXJ5IGJsb2IgY291bGQgc3RpbGwgYmUg YmFzZTY0dXJsLWVuY29kZWQgZm9yIHRob3NlIHRoYXQgd2FudCBpdCwgd2l0aG91dCBmb3JjaW5n IGl0IG9uIHRob3NlIHRoYXQgZG9u4oCZdF0NCg0KSW4gZWl0aGVyIFBLQ1M3IG9yIEpXVCB3ZeKA mXJlIHVzaW5nIGEgYmFzZTY0IGVuY29kaW5nIHRvIHRyYW5zbWl0IHRoZSBmaW5hbCByZXN1bHQg b3ZlciB0aGUgSFRUUFMvUkVTVCBpbnRlcmZhY2UuIFdpdGggQUNFIGRpc2N1c3Npb25zIG1vdmlu ZyB0b3dhcmQgQ29BUCB3LyBDQk9SIHRoZXnigJlsbCBoYXZlIHRoZSBvcHRpb24gb2Yg4oCcQ1dU 4oCdIG9yIOKAnFBLQ1M3IGJpbmFyeSBpbiBhIENCT1LigJ0uDQoNCj4gVGhlIGV4YW1wbGUgdm91 Y2hlciB5b3Ugb2J0YWluZWQgZnJvbSBtY3Igd2Fzbid0IGFzIHRyaW1tZWQgZG93biBhcyBpdCBj b3VsZCd2ZSBiZWVuLCB1c2luZyB0aGUgLW5vYXR0ciBhbmQgLW5vY2VydCBvcHRpb25zLCB3aGlj aCBpcyBvbmUgcmVhc29uIHRoZSBhc24xcGFyc2UgZHVtcCBsb29rcyBhcyBidXN5IGFzIGl0IGRv ZXMuICBBbm90aGVyIGJlaW5nIHRoYXQgdGhlIG93bmVyL2RvbWFpbi1jZXJ0LXRydXN0ZWQtY2Eg ZW5jb2RlIHZlcnkgZGlmZmVyZW50IGNlcnRzIChpcyBvbmUgZWMgd2hpbGUgdGhlIG90aGVyIGlz IHJzYT8pDQoNCkkgcmVhZCB0aGlzIGFzIGFuIGFyZ3VtZW50IGluIGZhdm9yIG9mIGEgc3RyaWN0 IHByb2ZpbGUgb2YgUEtDUzcgaWYgd2XigJlyZSBnb2luZyB0byBzdGljayB3aXRoIHRoYXQgZm9y bWF0LiBPZiBjb3Vyc2UgUG9zdGVs4oCZcyBsYXcgKOKAnGJlIGNvbnNlcnZhdGl2ZSBpbiB3aGF0 IHlvdSBkbywgYmUgbGliZXJhbCBpbiB3aGF0IHlvdSBhY2NlcHTigJ0pIGltcGxpZXMgdGhhdCBy ZWx5aW5nIHBhcnRpZXMgd291bGQgaGF2ZSB0byBkZWFsIHdpdGggdGhlIG1vcmUgY29tcGxleCBB U04xIGVuY29kaW5ncyDigJQgd2hpY2ggcmVzdWx0cyBpbiB0aGUgYmFzaWMgaXNzdWUgb2YgY29t cGxleCBBU04xIHBhcnNlcnMgb24gdGhlIGVuZHBvaW50cy4gIA0KDQo+IEluIHRoZSBlbmQsIEpX UyBhcHBlYXJzIHRvIGJlIGp1c3QgYW5vdGhlciBzaWduYXR1cmUgZm9ybWF0IHdpdGggaXRzIG93 biBzZXQgb2YgcGVjdWxpYXJpdGllcy4gIEFuZCBnaXZlbiB0aGF0IHdlIGFscmVhZHkgaGF2ZSB0 byBzdXBwb3J0IEFTTi4xICh0aGUgdm91Y2hlciBlbmNvZGVzIGJvdGggYW4gWC41MDkgY2VydCBh cyB3ZWxsIGFzIGEgWC41MDkgY2VydGlmaWNhdGUgY2hhaW4pLCBub3QgdG8gbWVudGlvbiB0aGUg bmVlZCBmb3IgdGhlIE1BU0EgdG8gaGF2ZSBhIFBLSVggaW5mcmFzdHJ1Y3R1cmUsIGl0J3Mgbm90 IGNsZWFyIHRvIG1lIGlmIHRoaXMgaXMgYSBnb29kIHRyYWRlIGF0IGFsbC4NCj4gDQo+IExhc3Rs eSwgYXMgbWVudGlvbmVkIGJlZm9yZSwgbXkgbmV0Y29uZiB6ZXJvdG91Y2ggZHJhZnQgdXNlcyBD TVMvUEtDUzcgZWxzZXdoZXJlLiAgV2hpbGUgaXQgd291bGQgYmUgdHJpdmlhbCB0byB1cGRhdGUg dGhlIGRyYWZ0IHRvIHVzZSBhIEpXUy1iYXNlZCBmb3JtYXQsIGl0IHdvdWxkIGJlIGF3a3dhcmQg Zm9yIGNsaWVudHMgdG8gaGF2ZSB0byBjb25zaWRlciBpdCBhdCBhbGwuDQoNCkJ1dCB3aXRoIHRo YXQgYXBwcm9hY2ggd2XigJlsbCBuZXZlciBraWxsIG9mZiBhc24xLiA6KA0KDQotIG1heA0KDQo+ IA0KPiBLZW50DQo+IA0KPiANCj4gLS0tLS1PUklHSU5BTCBNRVNTQUdFLS0tLS0NCj4gDQo+IEZv bGtzLCBpbiBDaGljYWdvIHdlIGRpc2N1c3NlZCB0aGUgc2lnbmluZyBtZXRob2QgZm9yIHZvdWNo ZXJzLiANCj4gDQo+IEJlY2F1c2UgdGhlIHZvdWNoZXIgaXMgSlNPTiwgYW5kIHRoZXJlIGlzIGV4 cGVjdGF0aW9uIG9mIGEgQ0JPUiBlbmNvZGluZyBmb3IgZnV0dXJlIHdvcmssIHRoZXJlIGlzIGFu IG9wZW4gZGlzY3Vzc2lvbiBwb2ludCBhYm91dCB1c2luZyB0aGUgSldTL0NPU0Ugc2lnbmluZyBt ZXRob2RzOyBpZiBub3QgSldUL0NXVC4gVGhlcmUgd2FzIGJyaWVmIGRpc2N1c3Npb24gb2YgdGhp cyBhdCBJRVRGOTggYW5kIG9uZSBwZXJzb24gaW5kaWNhdGVkIHRoZXkgbGlrZWQgUEtDUzcsIG90 aGVycyBpbmRpY2F0ZXMgSldUIGFuZCBvdGhlcnMgZGlkIG5vdCBzcGVhayB1cC4gRnVsbHkgbWVl dGluZyBtaW51dGVzIG1pZ2h0IHByb3ZpZGUgbW9yZSBpbmZvcm1hdGlvbiBidXQgbXkgcmVjb2xs ZWN0aW9uIHdhcyB0aGF0IHdl4oCZZCBtb3ZlIHRoZSBkaXNjdXNzaW9uIHRvIHRoZSBsaXN0LiBU aGlzIHRocmVhZCBpcyBmb3IgdGhhdCBkaXNjdXNzaW9uLiANCj4gDQo+IFRoZSBjdXJyZW50IHRl eHQgb2YgZHJhZnQtaWV0Zi1hbmltYS12b3VjaGVyLTAyIGlzOg0KPiANCj4+IFRoZSB2b3VjaGVy IGlzIHNpZ25lZCBhIFBLQ1MjNyBTaWduZWREYXRhIHN0cnVjdHVyZSwgYXMgc3BlY2lmaWVkIGJ5 IFNlY3Rpb24gOS4xDQo+PiBvZiBbUkZDMjMxNV0sIGVuY29kZWQgdXNpbmcgQVNOLjEgZGlzdGlu Z3Vpc2hlZCBlbmNvZGluZyBydWxlcyAoREVSKSwgYXMgc3BlY2lmaWVkIGluIElUVS1UIFguNjkw Lg0KPiANCj4gDQo+IEZvciBjb25jcmV0ZSBkaXNjdXNzaW9uLCB0aGUgcHJvcG9zZWQgY2hhbmdl IGlzOg0KPiANCj4+IFRoZSB2b3VjaGVyIGlzIGEgSldUIFtSRkM3NTE5XSBzaWduZWQgdG9rZW4u DQo+IA0KPiANCj4gSeKAmXZlIHVwZGF0ZWQgbXkgdG9vbGluZyB0aGF0IHdhcyB1c2VkIGR1cmlu ZyB0aGUgSUVURjk4IGhhY2thdGhvbiB0byBzdXBwb3J0IGEgSldUIHRva2VuIGZvcm1hdDsgSSBk aWQgdGhpcyBhcyBob21ld29yayB0byBiZSBpbmZvcm1lZCBmb3IgdGhlIGRpc2N1c3Npb24uIA0K PiANCj4gTVkgUE9TSVRJT046IGlzIHRoYXQgSSBhcHByZWNpYXRlIHRoZSBzaW1wbGljaXR5IG9m IHRoZSBKV1Mgc2lnbmluZyBhbmQgZmVlbCBpdCBpcyBhIGdvb2QgbWF0Y2ggZm9yIHVzLiBJdCB3 YXMgZWFzeSBlbm91Z2ggdG8gaW1wbGVtZW50LCB3YXMgYSByZWZyZXNoaW5nIGNoYW5nZSBmcm9t IHRoZSBBU04xIGNvbXBsZXhpdHkgb2YgUEtDUzcsIGFuZCBzZWVtcyB0byBwcm92aWRlIGEgZ29v ZCBwYXRoIHRvd2FyZCBDQk9SL0NPU0UgaW4gYSBmdXR1cmUgZG9jdW1lbnQgd2l0aG91dCBtYWlu dGFpbmluZyBQS0NTNy9DTVMgdGVjaG5pY2FsIGRlYnQgb3IgcmV2aXNpdGluZy9yZXdyaXRpbmcg dG9vIG11Y2guIA0KPiANCj4gUVVFU1RJT04gRk9SIFRIRSBXT1JLSU5HIEdST1VQOiBXaGF0IGlz IHlvdXIgcG9zaXRpb24/IFdoeT8gDQo+IA0KPiBXaGF0IGZvbGxvd3MgaXMgYSBkdW1wIG9mIHRo ZSByYXcgSldTIGJlZm9yZSBzaWduaW5nICh0aGUgZXF1aXZhbGVudCBQS0NTNy9DTVMgc3RydWN0 dXJlIHdvdWxkIGJlIHRoZSBTaWduZWREYXRhIGFzbjEgc3RydWN0dXJlcyB3aGljaCBpcyBoYXJk IHRvIGNhcHR1cmUpLiBBZnRlciB0aGF0IGlzIGFuIGVuY29kZWQgYW5kIHNpZ25lZCB2b3VjaGVy LiBGdXJ0aGVyIGJlbG93IGlzIGFuIGV4YW1wbGUgb2YgYSBQS0NTNyBzaWduZWQgdm91Y2hlci4g DQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGVzZSBjaGFyYWN0ZXJpc3RpY3M6DQo+IA0KPiBhKSBGcm9t IEpXVCBSRkM3NTE5ICJKV1RzIGFyZSBhbHdheXMgcmVwcmVzZW50ZWQgdXNpbmcgdGhlIEpXUyBD b21wYWN0IFNlcmlhbGl6YXRpb27igJ0uIFRoZXJlIGFyZSBzb21lIEpXVCBoZWFkZXJzIHRoYXQg b3ZlcmxhcCB3aXRoIHZvdWNoZXIgZmllbGRzLiBJ4oCZbSB1c2luZyBKV1QgaGVyZTsgYnV0IHRo ZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIEpXUy9KV1QgaXMgbm90IGZ1bmRhbWVudGFsIHRvIG91ciBk aXNjdXNzaW9uLiBUaGUgaW1wb3J0YW50IHBvaW50IGlzIEpXUyB2cyBQS0NTNy4gDQo+IA0KPiBi KSBJ4oCZdmUgYWRkZWQgdGhlIHg1YyBoZWFkZXIgdG8gdGhlIEpXUy4gVGhpcyBpcyB1c2VkIHRv IGNhcnJ5IHRoZSBjZXJ0aWZpY2F0ZSBjaGFpbiBvZiB0aGUgc2lnbmVyLiBPdXIgY3VycmVudCB2 b3VjaGVyIGZvcm1hdCBpbmRpY2F0ZXMgUEtDUzcgd2hpY2ggc3VwcG9ydHMgYW4gZXF1aXZhbGVu dCBmaWVsZCBjYWxsZWQg4oCcQ2VydGlmaWNhdGVTZXQgc3RydWN0dXJl4oCdLiBJdHMgaW4gdGhl IEJSU0tJIGRvY3VtZW50IHRoYXQgd2Ugc3BlY2lmeSAiVGhlIGVudGlyZSBjZXJ0aWZpY2F0ZSBj aGFpbiwgdXAgdG8gYW5kIGluY2x1ZGluZyB0aGUgRG9tYWluIENBLCBNVVNUIGJlIGluY2x1ZGVk IGluIHRoZSBDZXJ0aWZpY2F0ZVNldCBzdHJ1Y3R1cmXigJ0uIFdpdGggdGhlIHRyYW5zaXRpb24g dG8gSldUIHdl4oCZZCBiZSBzcGVjaWZ5aW5nIHRoYXQgdGhlIHg1YyBoZWFkZXIgYmUgZnVsbHkg cG9wdWxhdGVkIHVwIHRvIGFuIGluY2x1ZGluZyB0aGUgRG9tYWluIENBIGV0Yy4gDQo+IA0KPiBj KSBGcm9tIHRoZXNlIGV4YW1wbGVzIHdlIGNhbuKAmXQgZGlyZWN0bHkgY29tcGFyZSBzaXplIGVu Y29kaW5ncy4gSSBkb27igJl0IHRoaW5rIHRoaXMgaXMgYSBzaWduaWZpY2FudCBhc3BlY3Qgb2Yg dGhlIGNvbnZlcnNhdGlvbiBidXQgY2FuIGNyZWF0ZSBjb21wYXJhYmxlIGV4YW1wbGVzIGlmIGZv bGtzIGZlZWwgdGhhdCBpcyBuZWNlc3NhcnkuIA0KPiANCj4gVGhlIGR1bXBzOg0KPiANCj4gQSBk ZWJ1ZyBkdW1wIG9mIHRoZSBKV1QgZm9ybSBiZWZvcmUgZW5jb2Rpbmc6DQo+IHsNCj4gICAidHlw IjogIkpXVCIsDQo+ICAgImFsZyI6ICJFUzI1NiIsDQo+ICAgIng1YyI6IFsiTUlJQmRqQ0NBUjJn QXdJQkFnSUJBVEFLQmdncWhrak9QUVFEQWpBck1SWXdGQVlEVlFRS0RBMURhWE5qYnlCVGVYTjBa VzF6TVJFd0R3WURWUVFEREFoV1pXNWtiM0pEUVRBZUZ3MHhOekEwTURNeE5URTFORFZhRncweE9E QTBNRE14TlRFMU5EVmFNQzB4RmpBVUJnTlZCQW9NRFVOcGMyTnZJRk41YzNSbGJYTXhFekFSQmdO VkJBTU1DbFpsYm1SdmNrMUJVMEV3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVQ5 R1RyRGQwR1dnd2N1U3k4TENuMHdhTWVrbnBMem5halp6cVdsTGhyUHdzaGdJUElQdmJ5WTZJeUNv NHVCWVUvZTRPTzZUUUQ5VVZMbHlVNVI2Y0E2b3pBd0xqQUxCZ05WSFE4RUJBTUNCYUF3SHdZRFZS MGpCQmd3Rm9BVVI0b0VwYjRZRnVlbGtNclFqbG5LdE0wMW92RXdDZ1lJS29aSXpqMEVBd0lEUndB d1JBSWdBUThZUjJJZExvZEVFOGsrSnhwQk9JQUd1ekNlVDlCbUZPVmhGVWI4ZUpNQ0lDMjNHb3Nz Nm1hblJqTlNtaDYrMm9COXRzUmJqbW5ud3VNbERYUjhmenVnIiwgIk1JSUJuVENDQVVPZ0F3SUJB Z0lKQUs5UGQ1RysvcjBVTUFvR0NDcUdTTTQ5QkFNQ01Dc3hGakFVQmdOVkJBb01EVU5wYzJOdklG TjVjM1JsYlhNeEVUQVBCZ05WQkFNTUNGWmxibVJ2Y2tOQk1CNFhEVEUzTURRd016RTBNVEF3TlZv WERURTRNRFF3TXpFME1UQXdOVm93S3pFV01CUUdBMVVFQ2d3TlEybHpZMjhnVTNsemRHVnRjekVS TUE4R0ExVUVBd3dJVm1WdVpHOXlRMEV3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNB QVN1bnNRTDJQVk9TRldXcDBvQ2pscUY4aVZQUHBFZ0pjdDkzMUNaUTZhc3NwMDdvdG1mZ1pxWHNr MUpZUlRsS0NHalJPeHJBaVZSUXNCNTRpb0EweXUwbzFBd1RqQWRCZ05WSFE0RUZnUVVSNG9FcGI0 WUZ1ZWxrTXJRamxuS3RNMDFvdkV3SHdZRFZSMGpCQmd3Rm9BVVI0b0VwYjRZRnVlbGtNclFqbG5L dE0wMW92RXdEQVlEVlIwVEJBVXdBd0VCL3pBS0JnZ3Foa2pPUFFRREFnTklBREJGQWlFQStTU09o aU5RMjNSV0E3NmtaLzJ1NzBGQ3BVOE9zVTdYOUlSaVdHRGdJQWdDSUZMdThGbkp1cVB4MTBzZ0h2 SXpxSTVCZ09jd0NhNXZGUVpkQ0RCSEl4MTgiXQ0KPiB9DQo+IC4NCj4gew0KPiAgICJpZXRmLXZv dWNoZXI6dm91Y2hlciI6IHsNCj4gICAgICAgImFzc2VydGlvbiI6ICJsb2dnaW5nIiwNCj4gICAg ICAgImRvbWFpbi1jZXJ0LXRydXN0ZWQtY2EiOiAiLS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t XG5NSUlCVWpDQitxQURBZ0VDQWdrQXdQNHFLc0d5UWxZd0NnWUlLb1pJemowRUF3SXdGekVWTUJN R0ExVUVBd3dNXG5aWE4wUlhoaGJYQnNaVU5CTUI0WERURTNNRE15TlRJeU1UYzFNRm9YRFRFNE1E TXlOVEl5TVRjMU1Gb3dGekVWXG5NQk1HQTFVRUF3d01aWE4wUlhoaGJYQnNaVU5CTUZrd0V3WUhL b1pJemowQ0FRWUlLb1pJemowREFRY0RRZ0FFXG5SVnJObEVOMm9jWXNjQUlMQlU3TmdnQUJvMEpn QTFyRUdkWWRDUWoxbkhLTDZ4S09OSklVZkJpYmU2aU1WWWQzXG5SVW1Qd2FQaUhOWko5OGtSd0hJ d25LTXZNQzB3REFZRFZSMFRCQVV3QXdFQi96QWRCZ05WSFE0RUZnUVUrZFZYXG5hWG91Y1UxZ29k TkYwYnljUzFVNVc1NHdDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdOc0NHanBFanV2ejZPS0ovXG4z ck92TWMyWmZEaEQwMksrMFBDVkZKR0NRR3dDSUF6ZjNCUzZ4OWtLU1JPSkp2eERTcGcwUUs5K2I5 TFNGa2JaXG5NMVBXOThBTlxuLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLVxuIiwNCj4gICAgICAg Im5vbmNlIjogImVhNzEwMmU4ZTg4ZjExOWUiLA0KPiAgICAgICAic2VyaWFsLW51bWJlciI6ICJQ SUQ6MSBTTjp3aWRnZXQxIiwNCj4gICAgICAgInNlcmlhbC1udW1iZXItaXNzdWVyIjogIjM2MDk3 RTNERUEzOTMxNkVBNENFNUM2OTVCRTkwNUU3OEFGMkZCNUEiLA0KPiAgICAgICAidmVyc2lvbiI6 ICIxIg0KPiAgIH0NCj4gfQ0KPiAuDQo+IFtzaWduYXR1cmUgZ29lcyBoZXJlXQ0KPiANCj4gQXMg cGVyIEpXVCBSRkM3NTE5IHRoaXMgaXMgd2hhdCBpdCBsb29rcyBsaWtlIGFmdGVyIFVSTC1zYWZl IGVuY29kaW5nLiBZb3UgY2FuIHNlZSB0aGF0IG5vdyB0aGUgc2lnbmF0dXJlIGlzIGluY2x1ZGVk ICAobG9vayB0byB0aGUgc2Vjb25kIHRvIGxhc3QgbGluZSB0byBzZWUgdGhlIHNlY29uZCDigJwu 4oCdIGZvbGxvd2VkIGJ5IGEgdmFsaWQgc2lnbmF0dXJlKTogDQo+IA0KPiBleUowZVhBaU9pSktW MVFpTENKaGJHY2lPaUpGVXpJMU5pSXNJQ0FnSUNKNE5XTWlPbHNpVFVsSlFtUnFRME5CVWpKblFY ZEpRa0ZuU1VKQlZFRkxRbWRuY1docmFrOVFVVkZFUVdwQmNrMVNXWGRHUVZsRVZsRlJTMFJCTVVS aFdFNXFZbmxDVkdWWVRqQmFWekY2VFZKRmQwUjNXVVJXVVZGRVJFRm9WMXBYTld0aU0wcEVVVlJC WlVaM01IaE9la0V3VFVSTmVFNVVSVEZPUkZaaFJuY3dlRTlFUVRCTlJFMTRUbFJGTVU1RVZtRk5R ekI0Um1wQlZVSm5UbFpDUVc5TlJGVk9jR015VG5aSlJrNDFZek5TYkdKWVRYaEZla0ZTUW1kT1Zr SkJUVTFEYkZwc1ltMVNkbU5yTVVKVk1FVjNWMVJCVkVKblkzRm9hMnBQVUZGSlFrSm5aM0ZvYTJw UFVGRk5Ra0ozVGtOQlFWUTVSMVJ5UkdRd1IxZG5kMk4xVTNrNFRFTnVNSGRoVFdWcmJuQk1lbTVo YWxwNmNWZHNUR2h5VUhkemFHZEpVRWxRZG1KNVdUWkplVU52TkhWQ1dWVXZaVFJQVHpaVVVVUTVW VlpNYkhsVk5WSTJZMEUyYjNwQmQweHFRVXhDWjA1V1NGRTRSVUpCVFVOQ1lVRjNTSGRaUkZaU01H cENRbWQzUm05QlZWSTBiMFZ3WWpSWlJuVmxiR3ROY2xGcWJHNUxkRTB3TVc5MlJYZERaMWxKUzI5 YVNYcHFNRVZCZDBsRVVuZEJkMUpCU1dkQlVUaFpVakpKWkV4dlpFVkZPR3NyU25od1FrOUpRVWQx ZWtObFZEbENiVVpQVm1oR1ZXSTRaVXBOUTBsRE1qTkhiM056Tm0xaGJsSnFUbE50YURZck1tOUNP WFJ6VW1KcWJXNXVkM1ZOYkVSWVVqaG1lblZuSWl3aVRVbEpRbTVVUTBOQlZVOW5RWGRKUWtGblNV cEJTemxRWkRWSEt5OXlNRlZOUVc5SFEwTnhSMU5OTkRsQ1FVMURUVU56ZUVacVFWVkNaMDVXUWtG dlRVUlZUbkJqTWs1MlNVWk9OV016VW14aVdFMTRSVlJCVUVKblRsWkNRVTFOUTBaYWJHSnRVblpq YTA1Q1RVSTBXRVJVUlROTlJGRjNUWHBGTUUxVVFYZE9WbTlZUkZSRk5FMUVVWGROZWtVd1RWUkJk MDVXYjNkTGVrVlhUVUpSUjBFeFZVVkRaM2RPVVRKc2Vsa3lPR2RWTTJ4NlpFZFdkR042UlZKTlFU aEhRVEZWUlVGM2QwbFdiVloxV2tjNWVWRXdSWGRYVkVGVVFtZGpjV2hyYWs5UVVVbENRbWRuY1do cmFrOVFVVTFDUW5kT1EwRkJVM1Z1YzFGTU1sQldUMU5HVjFkd01HOURhbXh4UmpocFZsQlFjRVZu U21OME9UTXhRMXBSTm1GemMzQXdOMjkwYldablduRlljMnN4U2xsU1ZHeExRMGRxVWs5NGNrRnBW bEpSYzBJMU5HbHZRVEI1ZFRCdk1VRjNWR3BCWkVKblRsWklVVFJGUm1kUlZWSTBiMFZ3WWpSWlJu VmxiR3ROY2xGcWJHNUxkRTB3TVc5MlJYZElkMWxFVmxJd2FrSkNaM2RHYjBGVlVqUnZSWEJpTkZs R2RXVnNhMDF5VVdwc2JrdDBUVEF4YjNaRmQwUkJXVVJXVWpCVVFrRlZkMEYzUlVJdmVrRkxRbWRu Y1docmFrOVFVVkZFUVdkT1NVRkVRa1pCYVVWQksxTlRUMmhwVGxFeU0xSlhRVGMyYTFvdk1uVTNN RVpEY0ZVNFQzTlZOMWc1U1ZKcFYwZEVaMGxCWjBOSlJreDFPRVp1U25WeFVIZ3hNSE5uU0haSmVu RkpOVUpuVDJOM1EyRTFka1pSV21SRFJFSklTWGd4T0NKZGZRLmV5SnBaWFJtTFhadmRXTm9aWEk2 ZG05MVkyaGxjaUk2ZXlKaGMzTmxjblJwYjI0aU9pSnNiMmRuYVc1bklpd2laRzl0WVdsdUxXTmxj blF0ZEhKMWMzUmxaQzFqWVNJNklpMHRMUzB0UWtWSFNVNGdRMFZTVkVsR1NVTkJWRVV0TFMwdExW eHVUVWxKUWxWcVEwSXJjVUZFUVdkRlEwRm5hMEYzVURSeFMzTkhlVkZzV1hkRFoxbEpTMjlhU1hw cU1FVkJkMGwzUm5wRlZrMUNUVWRCTVZWRlFYZDNUVnh1V2xoT01GSllhR2hpV0VKeldsVk9RazFD TkZoRVZFVXpUVVJOZVU1VVNYbE5WR014VFVadldFUlVSVFJOUkUxNVRsUkplVTFVWXpGTlJtOTNS bnBGVmx4dVRVSk5SMEV4VlVWQmQzZE5XbGhPTUZKWWFHaGlXRUp6V2xWT1FrMUdhM2RGZDFsSVMy OWFTWHBxTUVOQlVWbEpTMjlhU1hwcU1FUkJVV05FVVdkQlJWeHVVbFp5VG14RlRqSnZZMWx6WTBG SlRFSlZOMDVuWjBGQ2J6QktaMEV4Y2tWSFpGbGtRMUZxTVc1SVMwdzJlRXRQVGtwSlZXWkNhV0ps Tm1sTlZsbGtNMXh1VWxWdFVIZGhVR2xJVGxwS09UaHJVbmRJU1hkdVMwMTJUVU13ZDBSQldVUldV akJVUWtGVmQwRjNSVUl2ZWtGa1FtZE9Wa2hSTkVWR1oxRlZLMlJXV0Z4dVlWaHZkV05WTVdkdlpF NUdNR0o1WTFNeFZUVlhOVFIzUTJkWlNVdHZXa2w2YWpCRlFYZEpSRkozUVhkU1FVbG5Ubk5EUjJw d1JXcDFkbm8yVDB0S0wxeHVNM0pQZGsxak1scG1SR2hFTURKTEt6QlFRMVpHU2tkRFVVZDNRMGxC ZW1ZelFsTTJlRGxyUzFOU1QwcEtkbmhFVTNCbk1GRkxPU3RpT1V4VFJtdGlXbHh1VFRGUVZ6azRR VTVjYmkwdExTMHRSVTVFSUVORlVsUkpSa2xEUVZSRkxTMHRMUzFjYmlJc0ltNXZibU5sSWpvaVpX RTNNVEF5WlRobE9EaG1NVEU1WlNJc0luTmxjbWxoYkMxdWRXMWlaWElpT2lKUVNVUTZNU0JUVGpw M2FXUm5aWFF4SWl3aWMyVnlhV0ZzTFc1MWJXSmxjaTFwYzNOMVpYSWlPaUl6TmpBNU4wVXpSRVZC TXprek1UWkZRVFJEUlRWRE5qazFRa1U1TURWRk56aEJSakpHUWpWQklpd2lkbVZ5YzJsdmJpSTZJ akVpZlgwLlFrVFVwY3h2Nk5nNnlseVdZbmxxdW4tNVNGaEQxWHdMSVcxa0Q3WTlkTndpb2hlTk1j Vm5vd2tFTGxfRU1DbHlPV3VMdnZXdW9DSEFjV3pfVUEwSUd3DQo+IA0KPiANCj4gSGVyZSBpcyBh biBlcXVpdmFsZW50IFBLQ1M3IHZvdWNoZXIgdmlhIGFzbjEgZHVtcC4gWW914oCZZCBoYXZlIHRv IGxvb2sgYXQgdGhlIGJpbmFyeSBpZiB5b3UgcmVhbGx5IHdhbnQgdG8gZGVjb2RlIGl0LiBUaGlz IHZvdWNoZXIgd2FzIGdlbmVyYXRlZCBieSBNQ1IgZHVyaW5nIHRoZSBoYWNrYXRob246IA0KPiAN Cj4gcHJpdGlraW5AdWJ1bnR1On4vc3JjL2Jyc2tpLXByb2plY3QvYnJza2lfbXNncyQgb3BlbnNz bCBhc24xcGFyc2UgLWluIG1jci52b3VjaGVyLnR4dC5wa2NzNw0KPiAgICAwOmQ9MCAgaGw9NCBs PTI3MDYgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQo+ICAgIDQ6ZD0xICBobD0yIGw9ICAgOSBw cmltOiBPQkpFQ1QgICAgICAgICAgICA6cGtjczctc2lnbmVkRGF0YQ0KPiAgIDE1OmQ9MSAgaGw9 NCBsPTI2OTEgY29uczogY29udCBbIDAgXSAgICAgICAgDQo+ICAgMTk6ZD0yICBobD00IGw9MjY4 NyBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCj4gICAyMzpkPTMgIGhsPTIgbD0gICAxIHByaW06 IElOVEVHRVIgICAgICAgICAgIDowMQ0KPiAgIDI2OmQ9MyAgaGw9MiBsPSAgMTUgY29uczogU0VU ICAgICAgICAgICAgICAgDQo+ICAgMjg6ZD00ICBobD0yIGw9ICAxMyBjb25zOiBTRVFVRU5DRSAg ICAgICAgICANCj4gICAzMDpkPTUgIGhsPTIgbD0gICA5IHByaW06IE9CSkVDVCAgICAgICAgICAg IDpzaGEyNTYNCj4gICA0MTpkPTUgIGhsPTIgbD0gICAwIHByaW06IE5VTEwgICAgICAgICAgICAg IA0KPiAgIDQzOmQ9MyAgaGw9NCBsPTE2NDQgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQo+ICAg NDc6ZD00ICBobD0yIGw9ICAgOSBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6cGtjczctZGF0YQ0K PiAgIDU4OmQ9NCAgaGw9NCBsPTE2MjkgY29uczogY29udCBbIDAgXSAgICAgICAgDQo+ICAgNjI6 ZD01ICBobD00IGw9MTYyNSBwcmltOiBPQ1RFVCBTVFJJTkcgICAgICA6eyJpZXRmLXZvdWNoZXI6 dm91Y2hlciI6eyJub25jZSI6IjYyYTJlNzY5M2Q4MmZjZGEyNjI0ZGU1OGZiNjcyMmU1IiwiY3Jl YXRlZC1vbiI6IjIwMTctMDEtMDFUMDA6MDA6MDAuMDAwWiIsImRldmljZS1pZGVudGlmaWVyIjoi MDAtZDAtZTUtZjItMDAtMDEiLCJhc3NlcnRpb24iOiJsb2dnZWQiLCJvd25lciI6Ik1JSUVFekND QXZ1Z0F3SUJBZ0lKQUs2ckZvdXZrKzdZTUEwR0NTcUdTSWIzRFFFQkN3VUFNSUdmTVFzd1xuQ1FZ RFZRUUdFd0pEUVRFUU1BNEdBMVVFQ0F3SFQyNTBZWEpwYnpFUE1BMEdBMVVFQnd3R1QzUjBZWGRo XG5NUm93R0FZRFZRUUtEQkZQZDI1bGNpQkZlR0Z0Y0d4bElFOXVaVEVSTUE4R0ExVUVDd3dJVG05 MElGWmxcbmNua3hHekFaQmdOVkJBTU1FbTkzYm1WeU1TNWxlR0Z0Y0d4bExtTnZiVEVoTUI4R0NT cUdTSWIzRFFFSlxuQVJZU2IzZHVaWEl4UUdWNFlXMXdiR1V1WTI5dE1CNFhEVEUzTURNeU5URTJN amt6TkZvWERURTNNRFF5XG5OREUyTWprek5Gb3dnWjh4Q3pBSkJnTlZCQVlUQWtOQk1SQXdEZ1lE VlFRSURBZFBiblJoY21sdk1ROHdcbkRRWURWUVFIREFaUGRIUmhkMkV4R2pBWUJnTlZCQW9NRVU5 M2JtVnlJRVY0WVcxd2JHVWdUMjVsTVJFd1xuRHdZRFZRUUxEQWhPYjNRZ1ZtVnllVEViTUJrR0Ex VUVBd3dTYjNkdVpYSXhMbVY0WVcxd2JHVXVZMjl0XG5NU0V3SHdZSktvWklodmNOQVFrQkZoSnZk MjVsY2pGQVpYaGhiWEJzWlM1amIyMHdnZ0VpTUEwR0NTcUdcblNJYjNEUUVCQVFVQUE0SUJEd0F3 Z2dFS0FvSUJBUUM0UVlBRW5UdFhnaUtxc2ZTVllrZ2tIZGRGY1AzNFxuT1UzWVA3aWJyc2d4MGk5 Y3lqN3hPeldIT0YyUHNvS0JnVFJINzVNU01oVGw1VWlkckNzemxsdUsrcXA0XG5kM1pnMzFvUU0v SERteVJKeVJwWStQQzFuNVZ4L01qNVZhZ1JRYnFHN1hURFFDZkNyaHFJS3JLQlR1UFFcbjR2WUtl TDB0UWs0VUpsUElvWlhFbUJrNWRrbi9Gemw5QWZJWlN2VXpRMVFBaFE5b2FMejVOZjVNV0hQS1xu VVkrNmIyekEveVFhWGR1UHJWdXhwN3hDajExQy9MamxobDEvSHgxNk1KclYzM01DYmQrUktXNzEx RC8zXG4wWGxXU3FFcHJkYkticXc4V01QanVKMWFvWDhhUUVXb0wreGJvbVJRUUpKb0ZhTVBsemdk RGNmb0FIRFVcblRzeGQwK0ZOOHBGSEFnTUJBQUdqVURCT01CMEdBMVVkRGdRV0JCU3FwNVR3UXRI c1F5OW9ZTFpiMEQ1V1xuK2xpY0hEQWZCZ05WSFNNRUdEQVdnQlNxcDVUd1F0SHNReTlvWUxaYjBE NVcrbGljSERBTUJnTlZIUk1FXG5CVEFEQVFIL01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQkFRQmdT UUdhY2p3eG1iUnJyQmhXNjNnWTVLYVdcbmltNzZyRzQ1cDN1aDlBOFdVZk1XcnlDVXVmckZPbS9R RUpubFVVSzNRWDRLRVZqMmV5d2I5Z3Nma2lDRVxueWFKenhlNjY1UTJCcld3ZTNyR1ZrQWhPL2Zu OHVwZWM0RTFBU2MzMUFTYUY4bStwWXFDQ1BTZmxMNWtWXG5NZWZIRzRsRXMzWEprSGNlQ2xSenlY dmpiNUtqL3UwMkM1WUNqY0FMWWQ4L2tjU2JmNGpvZTFHdWZ2S0ZcbjV3dlBCUGtSVmZiVzJLYWdM K2p3NjJqKzhVNm9CN0ZieHRGeXFRUDFZb1pHaWE5TWtQS25LK3lnNW8vMFxuY1o1N2hnazRtUW1N MWk4MlJyVVpRVm9CUDNDRDVMZEJKWmZKb1hzdFJsWGU2ZFg3K1Rpc2RTQXNwcDVlXG5oTm0wQmNx ZExLK3o4bnR0XG4ifX0NCj4gMTY5MTpkPTMgIGhsPTQgbD0gNTU3IGNvbnM6IGNvbnQgWyAwIF0g ICAgICAgIA0KPiAxNjk1OmQ9NCAgaGw9NCBsPSA1NTMgY29uczogU0VRVUVOQ0UgICAgICAgICAg DQo+IDE2OTk6ZD01ICBobD00IGw9IDQzMSBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCj4gMTcw MzpkPTYgIGhsPTIgbD0gICAzIGNvbnM6IGNvbnQgWyAwIF0gICAgICAgIA0KPiAxNzA1OmQ9NyAg aGw9MiBsPSAgIDEgcHJpbTogSU5URUdFUiAgICAgICAgICAgOjAyDQo+IDE3MDg6ZD02ICBobD0y IGw9ICAgMSBwcmltOiBJTlRFR0VSICAgICAgICAgICA6MDENCj4gMTcxMTpkPTYgIGhsPTIgbD0g IDEwIGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KPiAxNzEzOmQ9NyAgaGw9MiBsPSAgIDggcHJp bTogT0JKRUNUICAgICAgICAgICAgOmVjZHNhLXdpdGgtU0hBMjU2DQo+IDE3MjM6ZD02ICBobD0y IGw9ICA3NyBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCj4gMTcyNTpkPTcgIGhsPTIgbD0gIDE4 IGNvbnM6IFNFVCAgICAgICAgICAgICAgIA0KPiAxNzI3OmQ9OCAgaGw9MiBsPSAgMTYgY29uczog U0VRVUVOQ0UgICAgICAgICAgDQo+IDE3Mjk6ZD05ICBobD0yIGw9ICAxMCBwcmltOiBPQkpFQ1Qg ICAgICAgICAgICA6ZG9tYWluQ29tcG9uZW50DQo+IDE3NDE6ZD05ICBobD0yIGw9ICAgMiBwcmlt OiBJQTVTVFJJTkcgICAgICAgICA6Y2ENCj4gMTc0NTpkPTcgIGhsPTIgbD0gIDI1IGNvbnM6IFNF VCAgICAgICAgICAgICAgIA0KPiAxNzQ3OmQ9OCAgaGw9MiBsPSAgMjMgY29uczogU0VRVUVOQ0Ug ICAgICAgICAgDQo+IDE3NDk6ZD05ICBobD0yIGw9ICAxMCBwcmltOiBPQkpFQ1QgICAgICAgICAg ICA6ZG9tYWluQ29tcG9uZW50DQo+IDE3NjE6ZD05ICBobD0yIGw9ICAgOSBwcmltOiBJQTVTVFJJ TkcgICAgICAgICA6c2FuZGVsbWFuDQo+IDE3NzI6ZD03ICBobD0yIGw9ICAyOCBjb25zOiBTRVQg ICAgICAgICAgICAgICANCj4gMTc3NDpkPTggIGhsPTIgbD0gIDI2IGNvbnM6IFNFUVVFTkNFICAg ICAgICAgIA0KPiAxNzc2OmQ9OSAgaGw9MiBsPSAgIDMgcHJpbTogT0JKRUNUICAgICAgICAgICAg OmNvbW1vbk5hbWUNCj4gMTc4MTpkPTkgIGhsPTIgbD0gIDE5IHByaW06IFVURjhTVFJJTkcgICAg ICAgIDpVbnN0cnVuZyBIaWdod2F5IENBDQo+IDE4MDI6ZD02ICBobD0yIGw9ICAzMCBjb25zOiBT RVFVRU5DRSAgICAgICAgICANCj4gMTgwNDpkPTcgIGhsPTIgbD0gIDEzIHByaW06IFVUQ1RJTUUg ICAgICAgICAgIDoxNjA1MDcwMjM2NTVaDQo+IDE4MTk6ZD03ICBobD0yIGw9ICAxMyBwcmltOiBV VENUSU1FICAgICAgICAgICA6MTgwNTA3MDIzNjU1Wg0KPiAxODM0OmQ9NiAgaGw9MiBsPSAgNzcg Y29uczogU0VRVUVOQ0UgICAgICAgICAgDQo+IDE4MzY6ZD03ICBobD0yIGw9ICAxOCBjb25zOiBT RVQgICAgICAgICAgICAgICANCj4gMTgzODpkPTggIGhsPTIgbD0gIDE2IGNvbnM6IFNFUVVFTkNF ICAgICAgICAgIA0KPiAxODQwOmQ9OSAgaGw9MiBsPSAgMTAgcHJpbTogT0JKRUNUICAgICAgICAg ICAgOmRvbWFpbkNvbXBvbmVudA0KPiAxODUyOmQ9OSAgaGw9MiBsPSAgIDIgcHJpbTogSUE1U1RS SU5HICAgICAgICAgOmNhDQo+IDE4NTY6ZD03ICBobD0yIGw9ICAyNSBjb25zOiBTRVQgICAgICAg ICAgICAgICANCj4gMTg1ODpkPTggIGhsPTIgbD0gIDIzIGNvbnM6IFNFUVVFTkNFICAgICAgICAg IA0KPiAxODYwOmQ9OSAgaGw9MiBsPSAgMTAgcHJpbTogT0JKRUNUICAgICAgICAgICAgOmRvbWFp bkNvbXBvbmVudA0KPiAxODcyOmQ9OSAgaGw9MiBsPSAgIDkgcHJpbTogSUE1U1RSSU5HICAgICAg ICAgOnNhbmRlbG1hbg0KPiAxODgzOmQ9NyAgaGw9MiBsPSAgMjggY29uczogU0VUICAgICAgICAg ICAgICAgDQo+IDE4ODU6ZD04ICBobD0yIGw9ICAyNiBjb25zOiBTRVFVRU5DRSAgICAgICAgICAN Cj4gMTg4NzpkPTkgIGhsPTIgbD0gICAzIHByaW06IE9CSkVDVCAgICAgICAgICAgIDpjb21tb25O YW1lDQo+IDE4OTI6ZD05ICBobD0yIGw9ICAxOSBwcmltOiBVVEY4U1RSSU5HICAgICAgICA6VW5z dHJ1bmcgSGlnaHdheSBDQQ0KPiAxOTEzOmQ9NiAgaGw9MiBsPSAxMTggY29uczogU0VRVUVOQ0Ug ICAgICAgICAgDQo+IDE5MTU6ZD03ICBobD0yIGw9ICAxNiBjb25zOiBTRVFVRU5DRSAgICAgICAg ICANCj4gMTkxNzpkPTggIGhsPTIgbD0gICA3IHByaW06IE9CSkVDVCAgICAgICAgICAgIDppZC1l Y1B1YmxpY0tleQ0KPiAxOTI2OmQ9OCAgaGw9MiBsPSAgIDUgcHJpbTogT0JKRUNUICAgICAgICAg ICAgOnNlY3AzODRyMQ0KPiAxOTMzOmQ9NyAgaGw9MiBsPSAgOTggcHJpbTogQklUIFNUUklORyAg ICAgICAgDQo+IDIwMzM6ZD02ICBobD0yIGw9ICA5OSBjb25zOiBjb250IFsgMyBdICAgICAgICAN Cj4gMjAzNTpkPTcgIGhsPTIgbD0gIDk3IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KPiAyMDM3 OmQ9OCAgaGw9MiBsPSAgMTUgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQo+IDIwMzk6ZD05ICBo bD0yIGw9ICAgMyBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6WDUwOXYzIEJhc2ljIENvbnN0cmFp bnRzDQo+IDIwNDQ6ZD05ICBobD0yIGw9ICAgMSBwcmltOiBCT09MRUFOICAgICAgICAgICA6MjU1 DQo+IDIwNDc6ZD05ICBobD0yIGw9ICAgNSBwcmltOiBPQ1RFVCBTVFJJTkcgICAgICBbSEVYIERV TVBdOjMwMDMwMTAxRkYNCj4gMjA1NDpkPTggIGhsPTIgbD0gIDE0IGNvbnM6IFNFUVVFTkNFICAg ICAgICAgIA0KPiAyMDU2OmQ9OSAgaGw9MiBsPSAgIDMgcHJpbTogT0JKRUNUICAgICAgICAgICAg Olg1MDl2MyBLZXkgVXNhZ2UNCj4gMjA2MTpkPTkgIGhsPTIgbD0gICAxIHByaW06IEJPT0xFQU4g ICAgICAgICAgIDoyNTUNCj4gMjA2NDpkPTkgIGhsPTIgbD0gICA0IHByaW06IE9DVEVUIFNUUklO RyAgICAgIFtIRVggRFVNUF06MDMwMjAxMDYNCj4gMjA3MDpkPTggIGhsPTIgbD0gIDI5IGNvbnM6 IFNFUVVFTkNFICAgICAgICAgIA0KPiAyMDcyOmQ9OSAgaGw9MiBsPSAgIDMgcHJpbTogT0JKRUNU ICAgICAgICAgICAgOlg1MDl2MyBTdWJqZWN0IEtleSBJZGVudGlmaWVyDQo+IDIwNzc6ZD05ICBo bD0yIGw9ICAyMiBwcmltOiBPQ1RFVCBTVFJJTkcgICAgICBbSEVYIERVTVBdOjA0MTQyNThFREYy RDUxNzg4RjBDRUM4NzJBMjJGQkQ0RkVCRTA2NzZFQjA3DQo+IDIxMDE6ZD04ICBobD0yIGw9ICAz MSBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCj4gMjEwMzpkPTkgIGhsPTIgbD0gICAzIHByaW06 IE9CSkVDVCAgICAgICAgICAgIDpYNTA5djMgQXV0aG9yaXR5IEtleSBJZGVudGlmaWVyDQo+IDIx MDg6ZD05ICBobD0yIGw9ICAyNCBwcmltOiBPQ1RFVCBTVFJJTkcgICAgICBbSEVYIERVTVBdOjMw MTY4MDE0MjU4RURGMkQ1MTc4OEYwQ0VDODcyQTIyRkJENEZFQkUwNjc2RUIwNw0KPiAyMTM0OmQ9 NSAgaGw9MiBsPSAgMTAgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQo+IDIxMzY6ZD02ICBobD0y IGw9ICAgOCBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6ZWNkc2Etd2l0aC1TSEEyNTYNCj4gMjE0 NjpkPTUgIGhsPTIgbD0gMTA0IHByaW06IEJJVCBTVFJJTkcgICAgICAgIA0KPiAyMjUyOmQ9MyAg aGw9NCBsPSA0NTQgY29uczogU0VUICAgICAgICAgICAgICAgDQo+IDIyNTY6ZD00ICBobD00IGw9 IDQ1MCBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCj4gMjI2MDpkPTUgIGhsPTIgbD0gICAxIHBy aW06IElOVEVHRVIgICAgICAgICAgIDowMQ0KPiAyMjYzOmQ9NSAgaGw9MiBsPSAgODIgY29uczog U0VRVUVOQ0UgICAgICAgICAgDQo+IDIyNjU6ZD02ICBobD0yIGw9ICA3NyBjb25zOiBTRVFVRU5D RSAgICAgICAgICANCj4gMjI2NzpkPTcgIGhsPTIgbD0gIDE4IGNvbnM6IFNFVCAgICAgICAgICAg ICAgIA0KPiAyMjY5OmQ9OCAgaGw9MiBsPSAgMTYgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQo+ IDIyNzE6ZD05ICBobD0yIGw9ICAxMCBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6ZG9tYWluQ29t cG9uZW50DQo+IDIyODM6ZD05ICBobD0yIGw9ICAgMiBwcmltOiBJQTVTVFJJTkcgICAgICAgICA6 Y2ENCj4gMjI4NzpkPTcgIGhsPTIgbD0gIDI1IGNvbnM6IFNFVCAgICAgICAgICAgICAgIA0KPiAy Mjg5OmQ9OCAgaGw9MiBsPSAgMjMgY29uczogU0VRVUVOQ0UgICAgICAgICAgDQo+IDIyOTE6ZD05 ICBobD0yIGw9ICAxMCBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6ZG9tYWluQ29tcG9uZW50DQo+ IDIzMDM6ZD05ICBobD0yIGw9ICAgOSBwcmltOiBJQTVTVFJJTkcgICAgICAgICA6c2FuZGVsbWFu DQo+IDIzMTQ6ZD03ICBobD0yIGw9ICAyOCBjb25zOiBTRVQgICAgICAgICAgICAgICANCj4gMjMx NjpkPTggIGhsPTIgbD0gIDI2IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KPiAyMzE4OmQ9OSAg aGw9MiBsPSAgIDMgcHJpbTogT0JKRUNUICAgICAgICAgICAgOmNvbW1vbk5hbWUNCj4gMjMyMzpk PTkgIGhsPTIgbD0gIDE5IHByaW06IFVURjhTVFJJTkcgICAgICAgIDpVbnN0cnVuZyBIaWdod2F5 IENBDQo+IDIzNDQ6ZD02ICBobD0yIGw9ICAgMSBwcmltOiBJTlRFR0VSICAgICAgICAgICA6MDEN Cj4gMjM0NzpkPTUgIGhsPTIgbD0gIDEzIGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KPiAyMzQ5 OmQ9NiAgaGw9MiBsPSAgIDkgcHJpbTogT0JKRUNUICAgICAgICAgICAgOnNoYTI1Ng0KPiAyMzYw OmQ9NiAgaGw9MiBsPSAgIDAgcHJpbTogTlVMTCAgICAgICAgICAgICAgDQo+IDIzNjI6ZD01ICBo bD0zIGw9IDIyOCBjb25zOiBjb250IFsgMCBdICAgICAgICANCj4gMjM2NTpkPTYgIGhsPTIgbD0g IDI0IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KPiAyMzY3OmQ9NyAgaGw9MiBsPSAgIDkgcHJp bTogT0JKRUNUICAgICAgICAgICAgOmNvbnRlbnRUeXBlDQo+IDIzNzg6ZD03ICBobD0yIGw9ICAx MSBjb25zOiBTRVQgICAgICAgICAgICAgICANCj4gMjM4MDpkPTggIGhsPTIgbD0gICA5IHByaW06 IE9CSkVDVCAgICAgICAgICAgIDpwa2NzNy1kYXRhDQo+IDIzOTE6ZD02ICBobD0yIGw9ICAyOCBj b25zOiBTRVFVRU5DRSAgICAgICAgICANCj4gMjM5MzpkPTcgIGhsPTIgbD0gICA5IHByaW06IE9C SkVDVCAgICAgICAgICAgIDpzaWduaW5nVGltZQ0KPiAyNDA0OmQ9NyAgaGw9MiBsPSAgMTUgY29u czogU0VUICAgICAgICAgICAgICAgDQo+IDI0MDY6ZD04ICBobD0yIGw9ICAxMyBwcmltOiBVVENU SU1FICAgICAgICAgICA6MTcwMzI1MjIwMzA4Wg0KPiAyNDIxOmQ9NiAgaGw9MiBsPSAgNDcgY29u czogU0VRVUVOQ0UgICAgICAgICAgDQo+IDI0MjM6ZD03ICBobD0yIGw9ICAgOSBwcmltOiBPQkpF Q1QgICAgICAgICAgICA6bWVzc2FnZURpZ2VzdA0KPiAyNDM0OmQ9NyAgaGw9MiBsPSAgMzQgY29u czogU0VUICAgICAgICAgICAgICAgDQo+IDI0MzY6ZD04ICBobD0yIGw9ICAzMiBwcmltOiBPQ1RF VCBTVFJJTkcgICAgICBbSEVYIERVTVBdOjU1MkREMkVFNUNCQzRDN0M0RDIwN0Y5OEEyNTE5RjAz MUVFMTAwNzRENjc0MjY1QTdERDBDQTczRTY4QkU1N0QNCj4gMjQ3MDpkPTYgIGhsPTIgbD0gMTIx IGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KPiAyNDcyOmQ9NyAgaGw9MiBsPSAgIDkgcHJpbTog T0JKRUNUICAgICAgICAgICAgOlMvTUlNRSBDYXBhYmlsaXRpZXMNCj4gMjQ4MzpkPTcgIGhsPTIg bD0gMTA4IGNvbnM6IFNFVCAgICAgICAgICAgICAgIA0KPiAyNDg1OmQ9OCAgaGw9MiBsPSAxMDYg Y29uczogU0VRVUVOQ0UgICAgICAgICAgDQo+IDI0ODc6ZD05ICBobD0yIGw9ICAxMSBjb25zOiBT RVFVRU5DRSAgICAgICAgICANCj4gMjQ4OTpkPTEwIGhsPTIgbD0gICA5IHByaW06IE9CSkVDVCAg ICAgICAgICAgIDphZXMtMjU2LWNiYw0KPiAyNTAwOmQ9OSAgaGw9MiBsPSAgMTEgY29uczogU0VR VUVOQ0UgICAgICAgICAgDQo+IDI1MDI6ZD0xMCBobD0yIGw9ICAgOSBwcmltOiBPQkpFQ1QgICAg ICAgICAgICA6YWVzLTE5Mi1jYmMNCj4gMjUxMzpkPTkgIGhsPTIgbD0gIDExIGNvbnM6IFNFUVVF TkNFICAgICAgICAgIA0KPiAyNTE1OmQ9MTAgaGw9MiBsPSAgIDkgcHJpbTogT0JKRUNUICAgICAg ICAgICAgOmFlcy0xMjgtY2JjDQo+IDI1MjY6ZD05ICBobD0yIGw9ICAxMCBjb25zOiBTRVFVRU5D RSAgICAgICAgICANCj4gMjUyODpkPTEwIGhsPTIgbD0gICA4IHByaW06IE9CSkVDVCAgICAgICAg ICAgIDpkZXMtZWRlMy1jYmMNCj4gMjUzODpkPTkgIGhsPTIgbD0gIDE0IGNvbnM6IFNFUVVFTkNF ICAgICAgICAgIA0KPiAyNTQwOmQ9MTAgaGw9MiBsPSAgIDggcHJpbTogT0JKRUNUICAgICAgICAg ICAgOnJjMi1jYmMNCj4gMjU1MDpkPTEwIGhsPTIgbD0gICAyIHByaW06IElOVEVHRVIgICAgICAg ICAgIDo4MA0KPiAyNTU0OmQ9OSAgaGw9MiBsPSAgMTMgY29uczogU0VRVUVOQ0UgICAgICAgICAg DQo+IDI1NTY6ZD0xMCBobD0yIGw9ICAgOCBwcmltOiBPQkpFQ1QgICAgICAgICAgICA6cmMyLWNi Yw0KPiAyNTY2OmQ9MTAgaGw9MiBsPSAgIDEgcHJpbTogSU5URUdFUiAgICAgICAgICAgOjQwDQo+ IDI1Njk6ZD05ICBobD0yIGw9ICAgNyBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCj4gMjU3MTpk PTEwIGhsPTIgbD0gICA1IHByaW06IE9CSkVDVCAgICAgICAgICAgIDpkZXMtY2JjDQo+IDI1Nzg6 ZD05ICBobD0yIGw9ICAxMyBjb25zOiBTRVFVRU5DRSAgICAgICAgICANCj4gMjU4MDpkPTEwIGhs PTIgbD0gICA4IHByaW06IE9CSkVDVCAgICAgICAgICAgIDpyYzItY2JjDQo+IDI1OTA6ZD0xMCBo bD0yIGw9ICAgMSBwcmltOiBJTlRFR0VSICAgICAgICAgICA6MjgNCj4gMjU5MzpkPTUgIGhsPTIg bD0gIDEwIGNvbnM6IFNFUVVFTkNFICAgICAgICAgIA0KPiAyNTk1OmQ9NiAgaGw9MiBsPSAgIDgg cHJpbTogT0JKRUNUICAgICAgICAgICAgOmVjZHNhLXdpdGgtU0hBMjU2DQo+IDI2MDU6ZD01ICBo bD0yIGw9IDEwMyBwcmltOiBPQ1RFVCBTVFJJTkcgICAgICBbSEVYIERVTVBdOjMwNjUwMjMxMDBF NjBFQUY3M0E2OTgyNjA3N0NGNkI3NjBBRjlCRDFDOUJGNzIzRDBFODQ4MTJCMDZCNUE4QjdDMjUy MzYyMzk0RDk4RTFCNUI0QzAyRDhBQ0Q4REE1QkQyMjQ4RDUxRUEwMjMwNkI1QkRCREZGQkIwMjJB MUUwMzlBMTg0NzI1OUQyRTBBQTMzMkUxMkQyNDA1M0IzRTdFQ0E2RDE4RUE4MjFFMjlBNTNEOTNF RTNCQTRERTdEOEM1OTRDNTE3MzY1MTFDDQo+IA0KPiBBbmQgdGhpcyBpcyB0aGUg4oCcZW5jb2Rl ZOKAnSBmb3JtOg0KPiAtLS0tLUJFR0lOIFBLQ1M3LS0tLS0NCj4gTUlJS2tnWUpLb1pJaHZjTkFR Y0NvSUlLZ3pDQ0NuOENBUUV4RHpBTkJnbGdoa2dCWlFNRUFnRUZBRENDQm13Rw0KPiBDU3FHU0li M0RRRUhBYUNDQmwwRWdnWlpleUpwWlhSbUxYWnZkV05vWlhJNmRtOTFZMmhsY2lJNmV5SnViMjVq DQo+IFpTSTZJall5WVRKbE56WTVNMlE0TW1aalpHRXlOakkwWkdVMU9HWmlOamN5TW1VMUlpd2lZ M0psWVhSbFpDMXYNCj4gYmlJNklqSXdNVGN0TURFdE1ERlVNREE2TURBNk1EQXVNREF3V2lJc0lt UmxkbWxqWlMxcFpHVnVkR2xtYVdWeQ0KPiBJam9pTURBdFpEQXRaVFV0WmpJdE1EQXRNREVpTENK aGMzTmxjblJwYjI0aU9pSnNiMmRuWldRaUxDSnZkMjVsDQo+IGNpSTZJazFKU1VWRmVrTkRRWFox WjBGM1NVSkJaMGxLUVVzMmNrWnZkWFpyS3pkWlRVRXdSME5UY1VkVFNXSXoNCj4gUkZGRlFrTjNW VUZOU1VkbVRWRnpkMXh1UTFGWlJGWlJVVWRGZDBwRVVWUkZVVTFCTkVkQk1WVkZRMEYzU0ZReQ0K PiBOVEJaV0Vwd1lucEZVRTFCTUVkQk1WVkZRbmQzUjFRelVqQlpXR1JvWEc1TlVtOTNSMEZaUkZa UlVVdEVRa1pRDQo+IFpESTFiR05wUWtabFIwWjBZMGQ0YkVsRk9YVmFWRVZTVFVFNFIwRXhWVVZE ZDNkSlZHMDVNRWxHV214Y2JtTnUNCj4gYTNoSGVrRmFRbWRPVmtKQlRVMUZiVGt6WW0xV2VVMVRO V3hsUjBaMFkwZDRiRXh0VG5aaVZFVm9UVUk0UjBOVA0KPiBjVWRUU1dJelJGRkZTbHh1UVZKWlUy SXpaSFZhV0VsNFVVZFdORmxYTVhkaVIxVjFXVEk1ZEUxQ05GaEVWRVV6DQo+IFRVUk5lVTVVUlRK TmFtdDZUa1p2V0VSVVJUTk5SRkY1WEc1T1JFVXlUV3ByZWs1R2IzZG5Xamg0UTNwQlNrSm4NCj4g VGxaQ1FWbFVRV3RPUWsxU1FYZEVaMWxFVmxGUlNVUkJaRkJpYmxKb1kyMXNkazFST0hkY2JrUlJX VVJXVVZGSQ0KPiBSRUZhVUdSSVVtaGtNa1Y0UjJwQldVSm5UbFpDUVc5TlJWVTVNMkp0Vm5sSlJW WTBXVmN4ZDJKSFZXZFVNalZzDQo+IFRWSkZkMXh1UkhkWlJGWlJVVXhFUVdoUFlqTlJaMVp0Vm5s bFZFVmlUVUpyUjBFeFZVVkJkM2RUWWpOa2RWcFkNCj4gU1hoTWJWWTBXVmN4ZDJKSFZYVlpNamww WEc1TlUwVjNTSGRaU2t0dldrbG9kbU5PUVZGclFrWm9TblprTWpWcw0KPiBZMnBHUVZwWWFHaGlX RUp6V2xNMWFtSXlNSGRuWjBWcFRVRXdSME5UY1VkY2JsTkpZak5FVVVWQ1FWRlZRVUUwDQo+IFNV SkVkMEYzWjJkRlMwRnZTVUpCVVVNMFVWbEJSVzVVZEZobmFVdHhjMlpUVmxscloydElaR1JHWTFB ek5GeHUNCj4gVDFVeldWQTNhV0p5YzJkNE1HazVZM2xxTjNoUGVsZElUMFl5VUhOdlMwSm5WRkpJ TnpWTlUwMW9WR3cxVldsaw0KPiBja056ZW14c2RVc3JjWEEwWEc1a00xcG5NekZ2VVUwdlNFUnRl VkpLZVZKd1dTdFFRekZ1TlZaNEwwMXFOVlpoDQo+IFoxSlJZbkZITjFoVVJGRkRaa055YUhGSlMz SkxRbFIxVUZGY2JqUjJXVXRsVERCMFVXczBWVXBzVUVsdldsaEYNCj4gYlVKck5XUnJiaTlHZW13 NVFXWkpXbE4yVlhwUk1WRkJhRkU1YjJGTWVqVk9aalZOVjBoUVMxeHVWVmtyTm1JeQ0KPiBla0V2 ZVZGaFdHUjFVSEpXZFhod04zaERhakV4UXk5TWFteG9iREV2U0hneE5rMUtjbFl6TTAxRFltUXJV a3RYDQo+IE56RXhSQzh6WEc0d1dHeFhVM0ZGY0hKa1lrdGljWGM0VjAxUWFuVktNV0Z2V0RoaFVV VlhiMHdyZUdKdmJWSlINCj4gVVVwS2IwWmhUVkJzZW1ka1JHTm1iMEZJUkZWY2JsUnplR1F3SzBa T09IQkdTRUZuVFVKQlFVZHFWVVJDVDAxQw0KPiBNRWRCTVZWa1JHZFJWMEpDVTNGd05WUjNVWFJJ YzFGNU9XOVpURnBpTUVRMVYxeHVLMnhwWTBoRVFXWkNaMDVXDQo+IFNGTk5SVWRFUVZkblFsTnhj RFZVZDFGMFNITlJlVGx2V1V4YVlqQkVOVmNyYkdsalNFUkJUVUpuVGxaSVVrMUYNCj4gWEc1Q1ZF RkVRVkZJTDAxQk1FZERVM0ZIVTBsaU0wUlJSVUpEZDFWQlFUUkpRa0ZSUW1kVFVVZGhZMnAzZUcx aQ0KPiBVbkp5UW1oWE5qTm5XVFZMWVZkY2JtbHROelp5UnpRMWNETjFhRGxCT0ZkVlprMVhjbmxE VlhWbWNrWlBiUzlSDQo+IFJVcHViRlZWU3pOUldEUkxSVlpxTW1WNWQySTVaM05tYTJsRFJWeHVl V0ZLZW5obE5qWTFVVEpDY2xkM1pUTnkNCj4gUjFaclFXaFBMMlp1T0hWd1pXTTBSVEZCVTJNek1V RlRZVVk0YlN0d1dYRkRRMUJUWm14TU5XdFdYRzVOWldaSQ0KPiBSelJzUlhNeldFcHJTR05sUTJ4 U2VubFlkbXBpTlV0cUwzVXdNa00xV1VOcVkwRk1XV1E0TDJ0alUySm1OR3B2DQo+IFpURkhkV1oy UzBaY2JqVjNkbEJDVUd0U1ZtWmlWekpMWVdkTUsycDNOakpxS3poVk5tOUNOMFppZUhSR2VYRlIN Cj4gVURGWmIxcEhhV0U1VFd0UVMyNUxLM2xuTlc4dk1GeHVZMW8xTjJobmF6UnRVVzFOTVdrNE1s SnlWVnBSVm05Qw0KPiBVRE5EUkRWTVpFSktXbVpLYjFoemRGSnNXR1UyWkZnM0sxUnBjMlJUUVhO d2NEVmxYRzVvVG0wd1FtTnhaRXhMDQo+IEszbzRiblIwWEc0aWZYMmdnZ0l0TUlJQ0tUQ0NBYStn QXdJQkFnSUJBVEFLQmdncWhrak9QUVFEQWpCTk1SSXcNCj4gRUFZS0NaSW1pWlB5TEdRQkdSWUNZ MkV4R1RBWEJnb0praWFKay9Jc1pBRVpGZ2x6WVc1a1pXeHRZVzR4SERBYQ0KPiBCZ05WQkFNTUUx VnVjM1J5ZFc1bklFaHBaMmgzWVhrZ1EwRXdIaGNOTVRZd05UQTNNREl6TmpVMVdoY05NVGd3DQo+ IE5UQTNNREl6TmpVMVdqQk5NUkl3RUFZS0NaSW1pWlB5TEdRQkdSWUNZMkV4R1RBWEJnb0praWFK ay9Jc1pBRVoNCj4gRmdsellXNWtaV3h0WVc0eEhEQWFCZ05WQkFNTUUxVnVjM1J5ZFc1bklFaHBa MmgzWVhrZ1EwRXdkakFRQmdjcQ0KPiBoa2pPUFFJQkJnVXJnUVFBSWdOaUFBU3FTaXhycC9aajBP bW56aG84YkxPTllnclBzeHJMM0RUbUprcWl5WjRUDQo+IHdlL0xLMysvaXdCZ1dub2hLck9Wdk8x UE90YURIZEJ1aVVqWDJDQk02NkZnMThOU3l2d3pFSkV0Rkx1dEZMN1MNCj4gY2pEWUE4SnpQTENs dzB6dC9ZQmFkK0NqWXpCaE1BOEdBMVVkRXdFQi93UUZNQU1CQWY4d0RnWURWUjBQQVFILw0KPiBC QVFEQWdFR01CMEdBMVVkRGdRV0JCUWxqdDh0VVhpUERPeUhLaUw3MVA2K0JuYnJCekFmQmdOVkhT TUVHREFXDQo+IGdCUWxqdDh0VVhpUERPeUhLaUw3MVA2K0JuYnJCekFLQmdncWhrak9QUVFEQWdO b0FEQmxBakI2ZGhmdWphZzINCj4geFFFZ09VcjE5aVd3QXlPaHU5bkhVZmNxWGhHYjZpM25EdUtm ZUlVN0FtL1d6dkFBbXFBV1h5UUNNUURUTEthTg0KPiB2ZjJrLy9KY1crNCt4YXBWaFc4M3Q4VWRs TWswK0VvZS9ZbktQai9hMVdJT3V6emg2ekp0Q1lqbGltWXhnZ0hHDQo+IE1JSUJ3Z0lCQVRCU01F MHhFakFRQmdvSmtpYUprL0lzWkFFWkZnSmpZVEVaTUJjR0NnbVNKb21UOGl4a0FSa1cNCj4gQ1hO aGJtUmxiRzFoYmpFY01Cb0dBMVVFQXd3VFZXNXpkSEoxYm1jZ1NHbG5hSGRoZVNCRFFRSUJBVEFO QmdsZw0KPiBoa2dCWlFNRUFnRUZBS0NCNURBWUJna3Foa2lHOXcwQkNRTXhDd1lKS29aSWh2Y05B UWNCTUJ3R0NTcUdTSWIzDQo+IERRRUpCVEVQRncweE56QXpNalV5TWpBek1EaGFNQzhHQ1NxR1NJ YjNEUUVKQkRFaUJDQlZMZEx1WEx4TWZFMGcNCj4gZjVpaVVaOERIdUVBZE5aMEpscDkwTXB6NW92 bGZUQjVCZ2txaGtpRzl3MEJDUTh4YkRCcU1Bc0dDV0NHU0FGbA0KPiBBd1FCS2pBTEJnbGdoa2dC WlFNRUFSWXdDd1lKWUlaSUFXVURCQUVDTUFvR0NDcUdTSWIzRFFNSE1BNEdDQ3FHDQo+IFNJYjNE UU1DQWdJQWdEQU5CZ2dxaGtpRzl3MERBZ0lCUURBSEJnVXJEZ01DQnpBTkJnZ3Foa2lHOXcwREFn SUINCj4gS0RBS0JnZ3Foa2pPUFFRREFnUm5NR1VDTVFEbURxOXpwcGdtQjN6MnQyQ3ZtOUhKdjNJ OURvU0JLd2ExcUxmQw0KPiBVallqbE5tT0cxdE1BdGlzMk5wYjBpU05VZW9DTUd0YjI5LzdzQ0to NERtaGhISlowdUNxTXk0UzBrQlRzK2ZzDQo+IHB0R09xQ0hpbWxQWlB1TzZUZWZZeFpURkZ6WlJI QT09DQo+IC0tLS0tRU5EIFBLQ1M3LS0tLS0NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBbmltYS1ib290c3RyYXAgbWFpbGluZyBs aXN0DQo+IEFuaW1hLWJvb3RzdHJhcEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2FuaW1hLWJvb3RzdHJhcA0KPiANCj4gDQoNCg== From nobody Tue May 9 18:51:12 2017 Return-Path: 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 85E7B12EBAF; Tue, 9 May 2017 18:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4U5XsqrYA9Tx; Tue, 9 May 2017 18:51:09 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 128B312EB98; Tue, 9 May 2017 18:51:09 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id 64so2071682pgb.3; Tue, 09 May 2017 18:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=FF7VNJU3EfEvyoub1uiexvCVWWrtdbSLOxe6qzWOiWY=; b=p+udcK76/nODeBhXkb5amKZaaMfdO+2W8oMZsQG55BmPKZQoAceZBjSkElpxc+DGVw K/bnONAzQ/Caej3ElUiiOhzMoBxN4S9PX5XRipYuLpgkJTbqbvWfArZPyBl0EFpHLwvo brpKdNLV++E3i9u9esTbw+wDax1AxnuhKqzwNQkUPQE9mphxFi4u3qdZd/ShqvWEpmip RBxkI+Uv2xZx1KokL3MV4WhD4eQhaki3eqwsjWIERUBTRD3N6EuSC9fJA4TC6+ArjpE1 5sl0UQL1OSpxNlmw7CNVdbeA1F2qePeTguIZwD+mjRgV5wMYIbnRtHFXYu7XVStVeqiq Baaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=FF7VNJU3EfEvyoub1uiexvCVWWrtdbSLOxe6qzWOiWY=; b=oVIu9yTYrlbk5ZQ4YriKxIlMMSh4vClW6kXKcYdt2eG3YurEsCn1UZUsgXtLI1sUDJ C4And5QSJfogPr3zC+OBDbJgaV3XZGyx+5NHGQYAAuMQ0f2oEnOfplDwGGdXHWTPxDqi VtNrTe7u/TidP883bQEDCNsgfOFVZyeULCmC1+2hokOGB2YMW3i5YezclsAElLeg0kfr VSUpQN7wWji9DngNjc7LvlEkDXsEfo07LbFwcCO5lWgDTnELicEJz8Fo5Z8T2M+sg2nj Tx+4I0X6AHL7ZzCBxH0BzoMjhngzUqevUXlteohtWbHv5rvWgq3jgzjeZKpGOvnXOp8Q Dk7A== X-Gm-Message-State: AODbwcCmKboehUgf/25i7DIrmTEUoms7lY4ycQrWjmWswndkgMfqAkBh 2RlSfGzpPnIwSQWG X-Received: by 10.98.98.66 with SMTP id w63mr3459029pfb.44.1494381068517; Tue, 09 May 2017 18:51:08 -0700 (PDT) Received: from [130.216.38.30] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.30]) by smtp.gmail.com with ESMTPSA id a21sm2029827pfc.60.2017.05.09.18.51.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 18:51:07 -0700 (PDT) To: Martin Thomson References: <149369279041.9906.5712707340786253297@ietfa.amsl.com> Cc: ART Area , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 10 May 2017 13:51:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Artart telechat review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 01:51:10 -0000 Just one point while working on the text: On 03/05/2017 14:32, Martin Thomson wrote: ... > On 3 May 2017 at 11:58, Brian E Carpenter wrote: >> I must say I hadn't thought of RTT as an issue, because we tend to assume >> that the timescale for an autonomic action will be far greater than >> an RTT, so timeouts will be milliseconds to seconds, and RTTs within >> the autonomic domain will be sub-millisecond in many cases. > > Ahh, I always assume that machines work faster than the network, so > the opposite really.. > >> Are you suggesting we should be able to reduce the timeout as well? > > Can't it already do that? I mean, it can't account for any time > already spent waiting, but it could include the value 0, which means > don't wait any more when you receive this (a nonsensical thing here, > but it demonstrates that a reduction is possible). Actually it's redundant. If the peer replies with another Negotiation message we keep going; if it replies with a Negotiation End message we're done anyway. So there's never anything to gain by shortening the timeout that I can see. Brian From nobody Tue May 9 19:29:22 2017 Return-Path: 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 6409512EBC2; Tue, 9 May 2017 19:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1iCLdSb4j9Y; Tue, 9 May 2017 19:29:19 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 DB07512EBB6; Tue, 9 May 2017 19:29:18 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id 99so12047710lfu.1; Tue, 09 May 2017 19:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A2OwnAYpiTZtXY9GTlJVIQOx/hRrkMVPHJt2jVdb2o0=; b=NbAXNjHr0+4CyYKWd4mxq0zSrrqqJHvi7vnCf+xrjk8+tNqLDYST1HT2urxXKvwZZZ 7MB63Sd7RfmHgW/g1U4rSN+EBTZmS9Kglbpi1+PURpOWl5kuhlMS1ymiunSjDsBQyV5N DW2KN1cR37Nf6ER4L609TIp7rllobBpkQtCBXbmq2eOep6VCd8LdY9WNazXgMohXrtc/ C+PiqKLW1dWjtuMmdRnHZSTzyS/pXyWUdqjBjdtTfi8CCWhwizb6qk7wmDA9CDmW6bcb 94CCe53aRB2t1822LrzUT8tU7jnw9XRVbJ671wPUf0B846/bkmQ8VkR6JSMBNrk61b1T dxjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A2OwnAYpiTZtXY9GTlJVIQOx/hRrkMVPHJt2jVdb2o0=; b=LmhEloEbUQXOYq67Q5lcTsBz6THpl0QVF2jtaEjp56bjcfz2RTf0vU2sURstwAr//A wCFD46A+FBTLt0qwyTCosilVMCHrxNwp582HxD4mX3qHmZKPS7rhX30COD4xfqvC0EdZ 4LUGWvX08J/dXgQkSUuVoFyau/iPqulGtkryyXDIYnBjDcY45396YVsfqHvsHrpMvAVj Ic2iR7SLgT2Lt4JUcQsl7xAkQNMQsfyZ2GOBbkLeFZ1HQgGVuwtbFLwRTkfX/ugfXKOk vhvnR33HfBe51sav9NG2tje2KCrGv0niDf0DpXBP7k3N40rKTHsJJ7tm/tnRnAg1vDNT kW2Q== X-Gm-Message-State: AODbwcChUWgLNTj0m7qoERN3YMaPnIes9a/CX4gfdVbho/czjJbdHkV1 cm8ET0zGh+/RISB4GA/mr0QfBPHsqQ== X-Received: by 10.25.33.138 with SMTP id h132mr1716101lfh.43.1494383356983; Tue, 09 May 2017 19:29:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Tue, 9 May 2017 19:29:16 -0700 (PDT) In-Reply-To: References: <149369279041.9906.5712707340786253297@ietfa.amsl.com> From: Martin Thomson Date: Wed, 10 May 2017 12:29:16 +1000 Message-ID: To: Brian E Carpenter Cc: ART Area , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Anima] Artart telechat review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 02:29:20 -0000 On 10 May 2017 at 11:51, Brian E Carpenter wrote: > Actually it's redundant. If the peer replies with another Negotiation > message we keep going; if it replies with a Negotiation End message > we're done anyway. So there's never anything to gain by shortening > the timeout that I can see. WFM From nobody Tue May 9 19:47:25 2017 Return-Path: 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 5F3B812EBCC; Tue, 9 May 2017 19:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id delpb06y3jxC; Tue, 9 May 2017 19:47:21 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 CE2BD128B8D; Tue, 9 May 2017 19:47:21 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id u187so2230800pgb.1; Tue, 09 May 2017 19:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=uZnL7gXVz/zUMyUNVWxYgFtmTg9EJutaLo28WSBsTZ8=; b=LC3tL9I6HIdQ0F9peoligrE9vBI1XLBMYOZg89vMkbQv2jLFDyvW6IFRJU+j0kBjIJ UKsoZNMiysuMrIQU/gdyJ8rSJJTfnsu879fGi3wmd188EEl8eLp2XLTHz3+QqMm5DN1p 2wk6xVxx0zmUcbCvQSsl/G4boT4pMgstx6PZ+kUrJGRrYttRflUCqwnaIsvNfzocdPPO NA3LnkkXpdV1zWCF6u5DSnfBBDmwqTy3k2n6kbEdETo5KjlX9wtByBSgS6YXSlJA/q+t smg3xlg7gpirXlzq9icfDEo3p84dNy+PSt4pUtT7oUMf9o0FF8iJbhOkqq+6vlTowVBs NC/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=uZnL7gXVz/zUMyUNVWxYgFtmTg9EJutaLo28WSBsTZ8=; b=nrKPIOLTumoysK2zCj4/beTiWEEE/Hw3ykrRQaO+L8wECONmps3T+MfcR49ZFobc6h vgYQlKg/T9ccLVw2zOEIPM3dTVlInB0XdB+DKp5HBPL/2qv/hrWX7xKVW+KuZldYiXnC ISfgY2xU46DOYCYro8YNVXegMdJuAuioCqNZYEXDQ/an85SOj5KdAkE9DaMBFO+eN3X2 tkL4seaynYHgNOPB8uLS6bcyJ5HRKguO5TJa9H3pqNVP8UWruvUTwxOAzZJOEi9KUhEw 0ux4PDElLT9CEAnxB8tfR02/s2YDsTNMCaFdVuZPQmEmDNiEd5oc0CEcxNcPYnAm1Kdw 2ILw== X-Gm-Message-State: AODbwcBXuRAC3tYpzsSfTyQShiRTJlKhIrSoz0clW/Nsh1WlJ8sC3Asj Xe/H808PwhYfTg== X-Received: by 10.84.174.67 with SMTP id q61mr4809983plb.97.1494384441416; Tue, 09 May 2017 19:47:21 -0700 (PDT) Received: from [130.216.38.30] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.30]) by smtp.gmail.com with ESMTPSA id m125sm2233268pfc.3.2017.05.09.19.47.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 19:47:20 -0700 (PDT) To: Martin Thomson References: <149369279041.9906.5712707340786253297@ietfa.amsl.com> Cc: ART Area , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 10 May 2017 14:47:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Security references [Re: Artart telechat review of draft-ietf-anima-grasp-11] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 02:47:23 -0000 On 03/05/2017 13:58, Brian E Carpenter wrote: > On 03/05/2017 12:47, Martin Thomson wrote: ... >>> The main references for external security are >>> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra >>> https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane >>> which are indeed normative dependencies. >> >> Both are informative. > > Oh. Well, technically you don't need to know how they work in order > to implement GRASP. I'll do whatever the community wants, of course. The reason that these two references are currently Informative in GRASP is that a person coding the protocol has no need to understand their details. (She will need to understand the ACP's API, but that is not described in the ACP draft.) Therefore, technically, although using the ACP is a SHOULD requirement in GRASP, my understanding of the rules is that it is not a normative reference. The downside is that if we get into the RFC Editor queue, GRASP could in theory be published before the ACP becomes an RFC. That seems wrong. Opinions, please! Brian From nobody Tue May 9 19:49:37 2017 Return-Path: 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 8DDE1128B8D; Tue, 9 May 2017 19:49:35 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHU1aWqeKiMi; Tue, 9 May 2017 19:49:34 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 5921712EBCE; Tue, 9 May 2017 19:49:28 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id s62so2250120pgc.0; Tue, 09 May 2017 19:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=LFhKDfR1ARSfR3KogoYLVB2AdOweGb35EMSoGTUCznQ=; b=QUap34vz4fAkDlY5h3RHeCaYGW31qTmKNawq9BxGvSSpevSWwZ9I5dot8IEybqvZsv 06P6lctk544ZQm20n3rltOt8KlnZT+BUgCWKZX8dbfx8LehRVRHMpNe6gsfRL0v7ya4x ba9ZvX56FadQLnWJcs8hz1gQsZO+97Q2Z/YakFaOu9jfLqt+wbwCo/gfmdGpFZrMHyy/ LZZXIWDn7420vml/gPLcO5FsCOZayNXcQJ7toZvNm+Wqu3KrFp7e2SU/fJGCoe+co+H9 piZvJ1v+WdqHZY/EuIlBcLbMIt7wEptyJ32fago5RZh2xn91Gl37GbtXhHE/9bNk0jrp 3mJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=LFhKDfR1ARSfR3KogoYLVB2AdOweGb35EMSoGTUCznQ=; b=K6JbvSzTBGQ0W4vVotDJsN3HwfWdknL0L37nSXF+R23Bgw5oQ3eQn1bn8SR5lKw2rV daDFjYdokZORbIqBkhUwFgB9LIkuSg3nNfjin3cx+qkH7LCPYnYVHDNH1JYJyJLn5JEG oR3PoS2oxupxtYvtg8EUUCrk4qSqhKQ0iMPWuMAd3D/drduibsBwQLYmNPF6EYfCpxDc E/yARR4FBXxHJd31GD+loBd4rlABKenGBB1HQW983xjH6GwCf6pbR/0bp8f3RS9JqueJ dMUHnEQ6djofm4ethb2G7XGxEvZKb+Z03zTy1peOFiObORsGqjZwq5MTVeBj15WM+FEr 2Qbg== X-Gm-Message-State: AODbwcBlANzwztBOd/cEq6xxQaRhSxwEOCdl+hResY4V6cbeZmIQKpae T5DrKHoxP51btgRj X-Received: by 10.99.119.137 with SMTP id s131mr3798127pgc.116.1494384567779; Tue, 09 May 2017 19:49:27 -0700 (PDT) Received: from [130.216.38.30] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.30]) by smtp.gmail.com with ESMTPSA id q82sm2348476pfl.28.2017.05.09.19.49.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 19:49:27 -0700 (PDT) To: Spencer Dawkins at IETF References: <149421130029.23119.9372718991371280967.idtracker@ietfa.amsl.com> Cc: draft-ietf-anima-grasp@ietf.org, anima-chairs@ietf.org, Anima WG , IESG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 10 May 2017 14:49:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Spencer Dawkins' No Objection on draft-ietf-anima-grasp-11: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 02:49:35 -0000 Spencer, On 10/05/2017 05:13, Spencer Dawkins at IETF wrote: The bits where we can simply do what you suggest > Grrr, but please see below. > >> >>> >>> I'm really confused by this text. >>> >>> Nevertheless, when running within a secure ACP on reliable >>> infrastructure, UDP MAY be used for unicast messages not exceeding >>> the minimum IPv6 path MTU; however, TCP MUST be used for longer >>> messages. In other words, IPv6 fragmentation is avoided. If a node >>> receives a UDP message but the reply is too long, it MUST open a TCP >>> connection to the peer for the reply. Note that when the network is >>> under heavy load or in a fault condition, UDP might become >>> unreliable. Since this is when autonomic functions are most >>> necessary, automatic fallback to TCP MUST be implemented. The >>> simplest implementation is therefore to use only TCP. Editor hat off. I agree. I think it's very naive to think that for this application, intended to be used internally within an enterprise network, in a NAT-free and proxy-free addressing realm, UDP has any value. In fact, it's just a nuisance, since the programmer has to do a lot of the work that TCP does. The performance gain, even if it's real, is unimportant - autonomic traffic will be a tiny fraction of total traffic. There will be no gain in footprint, since autonomic nodes will carry full TCP stacks anyway. [If we wanted to put GRASP in constrained nodes, we'd probably be talking about GRASP-over-COAP anyway.] So here's what I would do: OLD All other GRASP messages are unicast and could in principle run over any transport protocol. An implementation MUST support use of TCP. It MAY support use of another transport protocol. However, GRASP itself does not provide for error detection or retransmission. Use of an unreliable transport protocol is therefore NOT RECOMMENDED. Nevertheless, when running within a secure ACP on reliable infrastructure, UDP MAY be used for unicast messages not exceeding the minimum IPv6 path MTU; however, TCP MUST be used for longer messages. In other words, IPv6 fragmentation is avoided. If a node receives a UDP message but the reply is too long, it MUST open a TCP connection to the peer for the reply. Note that when the network is under heavy load or in a fault condition, UDP might become unreliable. Since this is when autonomic functions are most necessary, automatic fallback to TCP MUST be implemented. The simplest implementation is therefore to use only TCP. NEW All other GRASP messages are unicast and could in principle run over any transport protocol. An implementation MUST support use of TCP. It MAY support use of another transport protocol, but the details are out of scope for this specification. However, GRASP itself does not provide for error detection or retransmission. Use of an unreliable transport protocol is therefore NOT RECOMMENDED. END NEW That doesn't slam the door, but it removes what I now feel is a very misleading paragraph. Of course, anybody is at liberty to draft a full description of GRASP-over-UDP as a separate document. Again, that was personal opinion. I won't edit that part of the draft without community input. Brian From nobody Tue May 9 20:02:35 2017 Return-Path: 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 D86AF129494; Tue, 9 May 2017 20:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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=joelhalpern.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 nSzYFhGVDGd3; Tue, 9 May 2017 20:02:32 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 6CD71124D37; Tue, 9 May 2017 20:02:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4E780240F6D; Tue, 9 May 2017 20:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1494385352; bh=PE8vz5ygBT29+hRiVB4+roO5rvz+TDj17GxtbmtlqCU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=COmktpxfkTTfAkBIOha8KJOSaByEQMywV94yza1WciFHFu3knmzJ/EUXqXv044Pah OcYCqiixFE4oDsYqA87VY2AIjmAhYs1xVZqxJpma6zjROVSPYuGCU9rHm4KP7LDEp/ 5KK7uANxzGJBqOlpjo47xvARhErpv+KNKaPZ+bBA= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4D0FC240138; Tue, 9 May 2017 20:02:30 -0700 (PDT) To: Brian E Carpenter , Martin Thomson References: <149369279041.9906.5712707340786253297@ietfa.amsl.com> Cc: draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org From: "Joel M. Halpern" Message-ID: <2a9faaa6-7430-5a3e-dae4-272f13db0ba6@joelhalpern.com> Date: Tue, 9 May 2017 23:02:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Security references [Re: Artart telechat review of draft-ietf-anima-grasp-11] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 03:02:34 -0000 Claiming that ACP is not a normative reference for GRASP, since GRASP is to run on ACP, seems a stretch. Yes, if there is a library or API to call, that masks the knowledge. But that could be said of a lot of normative references. Put differently, it has seemed to me that I need to understand at least the general shape of ACP operation in order to understand GRASP operation. Which is the definition I am familair with for a normative reference. And making it normative couples the publication in the right order. Which seems a good indiciation fo teh relationship. Yours, Joel On 5/9/17 10:47 PM, Brian E Carpenter wrote: > On 03/05/2017 13:58, Brian E Carpenter wrote: >> On 03/05/2017 12:47, Martin Thomson wrote: > ... >>>> The main references for external security are >>>> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra >>>> https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane >>>> which are indeed normative dependencies. >>> >>> Both are informative. >> >> Oh. Well, technically you don't need to know how they work in order >> to implement GRASP. I'll do whatever the community wants, of course. > > The reason that these two references are currently Informative > in GRASP is that a person coding the protocol has no need to > understand their details. (She will need to understand the ACP's > API, but that is not described in the ACP draft.) Therefore, > technically, although using the ACP is a SHOULD requirement in > GRASP, my understanding of the rules is that it is not a > normative reference. > > The downside is that if we get into the RFC Editor queue, GRASP > could in theory be published before the ACP becomes an RFC. > That seems wrong. > > Opinions, please! > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue May 9 20:53:48 2017 Return-Path: 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 AC819128C83 for ; Tue, 9 May 2017 20:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.5 X-Spam-Level: ** X-Spam-Status: No, score=2.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=163.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 bSWiZRTPu8jC for ; Tue, 9 May 2017 20:53:45 -0700 (PDT) Received: from m13-51.163.com (m13-51.163.com [220.181.13.51]) by ietfa.amsl.com (Postfix) with ESMTP id D169D126BF6 for ; Tue, 9 May 2017 20:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=zMnfh d2hYFWdCIA0Q6Ed4ezJi5e9ploAvYoqoLjaXOI=; b=Ghl3BMH9F0eKdYwV5PkoP KMMsfA8QFdX40US//GmgyocGp4caIVTL57Koh4gcNFCvMMsGIFvJtcNRntn8z/Q+ 7KNRVAN5CPm45eYmmX6Qx37sJkT7m02I9MnX3QcKoDr+UFEuOxTMNIYt/EyetpnG pvZK569FJG2jF2ZBvU2fkA= Received: from yanboyuan$bupt.edu.cn ( [47.88.24.237] ) by ajax-webmail-wmsvr51 (Coremail) ; Wed, 10 May 2017 11:53:00 +0800 (CST) X-Originating-IP: [47.88.24.237] Date: Wed, 10 May 2017 11:53:00 +0800 (CST) From: "Boyuan Yan" To: anima@ietf.org X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20160729(86883.8884) Copyright (c) 2002-2017 www.mailtech.cn 163com Sender: yanliuzhangyan@163.com Content-Type: multipart/alternative; boundary="----=_Part_97710_158191087.1494388380030" MIME-Version: 1.0 Message-ID: <26f487c2.62aa.15bf07d117f.Coremail.yanboyuan@bupt.edu.cn> X-Coremail-Locale: zh_CN X-CM-TRANSID: M8GowADX36+cjhJZ9qMWAA--.20269W X-CM-SenderInfo: x1dqzxpx2kt0hj1d0qqrwthudrp/1tbiVwjTiVetTcbtlAAHsK X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Archived-At: Subject: [Anima] Process about Intent related draft X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 03:53:47 -0000 ------=_Part_97710_158191087.1494388380030 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 SGkgYWxsLAogICAgSSByZWFsaXplZCB0aGF0IHRoZXJlIGRvZXNuJ3QgZXhpc3QgYSBpbnRlbnQg cmVsYXRlZCBkcmFmdCBub3csIGFuZCBpdCBzaG91bGQgYmUgdmVyeSBpbXBvcnRhbnQgcGFydCBv ZiBBTklNQSwgc28gSSB3b25kZXIgdGhlIHByb2Nlc3MgdW50aWwgbm93LCBjb3VsZCBhbnkgYm9k eSBzdW1tYXJ5IHRhbGtzIGJlZm9yZT8KClJlZ2FyZHMsCkJveXVhbgoKCgoKCgoKCg== ------=_Part_97710_158191087.1494388380030 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+SGkgYWxsLDxicj4mbmJzcDsmbmJzcDsmbmJzcDsgSSBy ZWFsaXplZCB0aGF0IHRoZXJlIGRvZXNuJ3QgZXhpc3QgYSBpbnRlbnQgcmVsYXRlZCBkcmFmdCBu b3csIGFuZCBpdCBzaG91bGQgYmUgdmVyeSBpbXBvcnRhbnQgcGFydCBvZiBBTklNQSwgc28gSSB3 b25kZXIgdGhlIHByb2Nlc3MgdW50aWwgbm93LCBjb3VsZCBhbnkgYm9keSBzdW1tYXJ5IHRhbGtz IGJlZm9yZT88YnI+PGJyPlJlZ2FyZHMsPGJyPkJveXVhbjxicj48L2Rpdj48YnI+PGJyPjxicj48 YnI+PGJyPjxkaXYgc3R5bGU9InBvc2l0aW9uOnJlbGF0aXZlO3pvb206MSI+PHNwYW4gc3R5bGU9 ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAx M3B4OyBsaW5lLWhlaWdodDogMjAuMDJweDsiPjxicj48L3NwYW4+PGRpdiBzdHlsZT0iY2xlYXI6 Ym90aCI+PC9kaXY+PC9kaXY+PC9kaXY+ ------=_Part_97710_158191087.1494388380030-- From nobody Tue May 9 21:34:33 2017 Return-Path: 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 B977B12EACB for ; Tue, 9 May 2017 21:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rM5GPH5fxye for ; Tue, 9 May 2017 21:34:29 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00137.outbound.protection.outlook.com [40.107.0.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A03712EAB3 for ; Tue, 9 May 2017 21:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zd3BmEFaKzyaW8JJ0jAUdNiAUGEVXa/ki2DC58qQLSA=; b=e1L82I9/pJU0gv5wg64fj5MCnNYIenxg6iOw4t/3IsXuAYt+sd+viI/0ss4hq272LnIa6C31quKug8TDGvmNKyZYtPtWJ2bG2p/rg2MlcbN3iX2IQ+lFyAsIrxKPcPT17vMc7iYArSCnfhtB9Z3pYqPotaHbyzP5EnGOcFPek4w= Received: from HE1PR0701MB2203.eurprd07.prod.outlook.com (10.168.36.134) by HE1PR0701MB2202.eurprd07.prod.outlook.com (10.168.36.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Wed, 10 May 2017 04:34:25 +0000 Received: from HE1PR0701MB2203.eurprd07.prod.outlook.com ([10.168.36.134]) by HE1PR0701MB2203.eurprd07.prod.outlook.com ([10.168.36.134]) with mapi id 15.01.1084.015; Wed, 10 May 2017 04:34:25 +0000 From: "Ciavaglia, Laurent (Nokia - FR/Nozay)" To: Boyuan Yan , "anima@ietf.org" Thread-Topic: [Anima] Process about Intent related draft Thread-Index: AQHSyUEKL418fKqbvkaeB2rR9byNwKHs+grQ Date: Wed, 10 May 2017 04:34:25 +0000 Message-ID: References: <26f487c2.62aa.15bf07d117f.Coremail.yanboyuan@bupt.edu.cn> In-Reply-To: <26f487c2.62aa.15bf07d117f.Coremail.yanboyuan@bupt.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bupt.edu.cn; dkim=none (message not signed) header.d=none;bupt.edu.cn; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [176.78.44.112] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2202; 7:xWJAAa7BmhRLq2uQnel4AhkbEIC0QSh0gos3V/Dl3V1TCtOYSHQ0Yf0wZtpRfWByDpb7jp678lTwwggSNtKjd15/kNG9GcJMurAa2wiyfMezf5HfiTyajZfu3WBk/7AuENNBrETEfrqB6kHQ4sg9kOsVfKLnY25LDEq/ToQEcO6f3a++k1H81HbeBJYLrXiZ3WFSlJ8drQ+zFqgM4c0HgCxa2dElyRyl6bEOyK6y89f7Bh84WS6YbLyQWQoOtS1SruRIPNBwACTQ+K/m4vz20iwEN3pdBTM0Bk40TQVNiDYly8ZWHXzh7/i0vCiAOtJ7DDJKQi61o7Xna5QpGlnGug== x-ms-office365-filtering-correlation-id: 9f9345f4-70ab-4b2a-c970-08d4975dd6d4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:HE1PR0701MB2202; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155)(81160342030619); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:HE1PR0701MB2202; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2202; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39450400003)(39860400002)(39410400002)(39840400002)(377454003)(53754006)(122556002)(86362001)(54896002)(7696004)(38730400002)(189998001)(66066001)(2171002)(3280700002)(25786009)(53546009)(99286003)(6246003)(2950100002)(6436002)(606005)(55016002)(54356999)(2906002)(3660700001)(50986999)(76176999)(53936002)(77096006)(2501003)(478600001)(9686003)(6506006)(7906003)(6306002)(236005)(81166006)(6116002)(790700001)(102836003)(8676002)(33656002)(5660300001)(3846002)(74316002)(19609705001)(7736002)(8936002)(45080400002)(2900100001)(90052001)(15669805003); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2202; H:HE1PR0701MB2203.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2203F27E48BB6E9A96FBC1FDE8EC0HE1PR0701MB2203_" MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2017 04:34:25.6463 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2202 Archived-At: Subject: Re: [Anima] Process about Intent related draft X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 04:34:32 -0000 --_000_HE1PR0701MB2203F27E48BB6E9A96FBC1FDE8EC0HE1PR0701MB2203_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Boyuan, There is no WG document on intent because it is not a chartered work item. However, several drafts have been proposed / progressed. Try a search on the IETF data tracker with the keyword 'intent' and the exp= ired ID box selected and you will see several documents. https://datatracker.ietf.org/doc/search/?name=3Dintent&sort=3D&rfcs=3Don&ac= tivedrafts=3Don&olddrafts=3Don&by=3Dgroup&group=3D Summarizing the discussion might be a bit complex, but we can for sure have= discussion on the way forward and new contributions. Best regards, --- Laurent Ciavaglia Nokia, Bell Labs +33 160 402 636 route de Villejust - Nozay, France linkedin.com/in/laurent.ciavaglia From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Boyuan Yan Sent: Wednesday, May 10, 2017 5:53 AM To: anima@ietf.org Subject: [Anima] Process about Intent related draft Hi all, I realized that there doesn't exist a intent related draft now, and it = should be very important part of ANIMA, so I wonder the process until now, = could any body summary talks before? Regards, Boyuan --_000_HE1PR0701MB2203F27E48BB6E9A96FBC1FDE8EC0HE1PR0701MB2203_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Boyuan,

 

There is no WG document on= intent because it is not a chartered work item.

However, several drafts ha= ve been proposed / progressed.

Try a search on the IETF d= ata tracker with the keyword ‘intent’ and the expired ID box se= lected and you will see several documents.

https://datatracker.ietf.org/doc/search/?name=3Dintent&sort= =3D&rfcs=3Don&activedrafts=3Don&olddrafts=3Don&by=3Dgroup&a= mp;group=3D

 

Summarizing the discussion= might be a bit complex, but we can for sure have discussion on the way for= ward and new contributions.

 

Best regards,

---

= Laurent Ciavaglia

= Nokia, Bell Labs

=  

= +33 160 402 636

= route de Villejust - Nozay, France

= linkedin.com/in/laurent.ciavaglia

&nbs= p;

From: Anima [mailto:anima-bounces@ie= tf.org] On Behalf Of Boyuan Yan
Sent: Wednesday, May 10, 2017 5:53 AM
To: anima@ietf.org
Subject: [Anima] Process about Intent related draft

 

Hi all,
    I realized that there doesn't exist a intent related dra= ft now, and it should be very important part of ANIMA, so I wonder the proc= ess until now, could any body summary talks before?

Regards,
Boyuan





 

--_000_HE1PR0701MB2203F27E48BB6E9A96FBC1FDE8EC0HE1PR0701MB2203_-- From nobody Wed May 10 05:34:40 2017 Return-Path: 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 630C9129B2D; Wed, 10 May 2017 05:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssz7ACpTCI79; Wed, 10 May 2017 05:34:27 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 0A819126DFB; Wed, 10 May 2017 05:34:27 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id l135so14541809ywb.2; Wed, 10 May 2017 05:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Bcln3lT98t4IxsXbNbAIX7ButJl93S2jBBccIqdMaVQ=; b=Iaf0Fz8tghN072tRq4aWZ41HfKz8Hgu6mT08X/BB4KUmoE0dS9H00aIBlxZkvQHhp+ L4KHmboLuL9Ixj6jHQQYB/B+79R5jv9LN29dhXU1HkHHQ0483n9fjl8Rdbt+T+CnVEaG fOFO8r3rBP1RW8qQUK4Gsk1ClAi0SLCUWmX9oNxWMkc+PdBpS/dYeuL8xg/bAnNGIdmw jmU1sNfNosVYgRnbb+KNsHNG+5USp9YQpTrHKz0IXWsbJGVg7BpcPKCeWZWMKtVbbMFa uOl08H8jklG9MZgyv+igxaR5x1toRUrV2XV8prQsSA5j3xGph2e+sDPm4cIsk86awbF3 alNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Bcln3lT98t4IxsXbNbAIX7ButJl93S2jBBccIqdMaVQ=; b=YVrgO9TofVJk7hxtoK2TxhMsf3kWQrqnxN4DVAc+8FfW20QOk9T5G0RcokJL6xWpuN 5POl9RjlgdRnRlwGf9dR9yF/QmfTbjorPYJUomJ1lG164eUH8rxKS/3IIZPlfu6Nx3kW ghbPO9saoHj9o6s7y+AuFiAutkAYuF6FHoINFFLzTRpTadUIu/1WiypqgsmI3p1P2l2n Ph58/1MITmHAg6tZ5m9vBygM8yGXf8MpfCcv7aUDSUt0Iuuh9sblnqjBOILpSuJAWutL lar5Td2/oTmLvMf8j7EI6auQq/Mefn9phlez42eTyf8o0WO4V+KKS9Spnh0b9XwTuk/e YXkA== X-Gm-Message-State: AODbwcChmSGyxWcv+inaDC5ExCj/e+vhzT146x0OYEZeFOasxCrdiYOE dbp/n8E85ltgC6nwmgrK/j5rzcNkeA== X-Received: by 10.13.196.129 with SMTP id g123mr4435491ywd.21.1494419666170; Wed, 10 May 2017 05:34:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.161.198 with HTTP; Wed, 10 May 2017 05:34:25 -0700 (PDT) In-Reply-To: References: <149421130029.23119.9372718991371280967.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Wed, 10 May 2017 07:34:25 -0500 Message-ID: To: Brian E Carpenter Cc: draft-ietf-anima-grasp@ietf.org, anima-chairs@ietf.org, Anima WG , IESG Content-Type: multipart/alternative; boundary=001a114d80fc58fd6c054f2ab178 Archived-At: Subject: Re: [Anima] Spencer Dawkins' No Objection on draft-ietf-anima-grasp-11: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 12:34:30 -0000 --001a114d80fc58fd6c054f2ab178 Content-Type: text/plain; charset=UTF-8 Hi, Brian, On Tue, May 9, 2017 at 9:49 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Spencer, > On 10/05/2017 05:13, Spencer Dawkins at IETF wrote: > > The bits where we can simply do what you suggest > > > Grrr, but please see below. > > > >> > >>> > >>> I'm really confused by this text. > >>> > >>> Nevertheless, when running within a secure ACP on reliable > >>> infrastructure, UDP MAY be used for unicast messages not exceeding > >>> the minimum IPv6 path MTU; however, TCP MUST be used for longer > >>> messages. In other words, IPv6 fragmentation is avoided. If a node > >>> receives a UDP message but the reply is too long, it MUST open a TCP > >>> connection to the peer for the reply. Note that when the network is > >>> under heavy load or in a fault condition, UDP might become > >>> unreliable. Since this is when autonomic functions are most > >>> necessary, automatic fallback to TCP MUST be implemented. The > >>> simplest implementation is therefore to use only TCP. > > Editor hat off. > > I agree. I think it's very naive to think that for this application, > intended to be used internally within an enterprise network, in > a NAT-free and proxy-free addressing realm, UDP has any value. > In fact, it's just a nuisance, since the programmer has to do a lot > of the work that TCP does. The performance gain, even if it's real, > is unimportant - autonomic traffic will be a tiny fraction of total > traffic. There will be no gain in footprint, since autonomic nodes > will carry full TCP stacks anyway. [If we wanted to put GRASP in > constrained nodes, we'd probably be talking about GRASP-over-COAP > anyway.] So here's what I would do: > > OLD > All other GRASP messages are unicast and could in principle run over > any transport protocol. An implementation MUST support use of TCP. > It MAY support use of another transport protocol. However, GRASP > itself does not provide for error detection or retransmission. Use > of an unreliable transport protocol is therefore NOT RECOMMENDED. > > Nevertheless, when running within a secure ACP on reliable > infrastructure, UDP MAY be used for unicast messages not exceeding > the minimum IPv6 path MTU; however, TCP MUST be used for longer > messages. In other words, IPv6 fragmentation is avoided. If a node > receives a UDP message but the reply is too long, it MUST open a TCP > connection to the peer for the reply. Note that when the network is > under heavy load or in a fault condition, UDP might become > unreliable. Since this is when autonomic functions are most > necessary, automatic fallback to TCP MUST be implemented. The > simplest implementation is therefore to use only TCP. > > NEW > All other GRASP messages are unicast and could in principle run over > any transport protocol. An implementation MUST support use of TCP. > It MAY support use of another transport protocol, but the details > are out of scope for this specification. However, GRASP itself does > not provide for error detection or retransmission. Use of an > unreliable transport protocol is therefore NOT RECOMMENDED. > END NEW > > That doesn't slam the door, but it removes what I now feel is > a very misleading paragraph. Of course, anybody is at liberty to > draft a full description of GRASP-over-UDP as a separate > document. > > Again, that was personal opinion. I won't edit that part of > the draft without community input. > Thanks, and I agree with not making changes unless there's community agreement. I do suspect that if UDP is not at least NOT RECOMMENDED, some developers may not use TCP at all. A quick Google search turned up e-mail from 2015 asking "if we REALLY have to support TCP in our (micro-)DNS server", and TCP to accommodate response TrunCation has been a requirement for DNS since at least RFC 1035 in 1987. But I don't know the future, of course. :D Spencer > Brian > --001a114d80fc58fd6c054f2ab178 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Brian,

On Tue, May 9, 2017 at 9:49 PM, Brian E Carpenter <bri= an.e.carpenter@gmail.com> wrote:
Spencer,
On 10/05/2017 05:13, Spencer Dawkins at IETF wrote:

<snip> The bits where we can simply do what you suggest </snip>=

> Grrr, but please see below.
>
>>
>>>
>>> I'm really confused by this text.
>>>
>>>=C2=A0 =C2=A0 Nevertheless, when running within a secure ACP on= reliable
>>>=C2=A0 =C2=A0 infrastructure, UDP MAY be used for unicast messa= ges not exceeding
>>>=C2=A0 =C2=A0 the minimum IPv6 path MTU; however, TCP MUST be u= sed for longer
>>>=C2=A0 =C2=A0 messages.=C2=A0 In other words, IPv6 fragmentatio= n is avoided.=C2=A0 If a node
>>>=C2=A0 =C2=A0 receives a UDP message but the reply is too long,= it MUST open a TCP
>>>=C2=A0 =C2=A0 connection to the peer for the reply.=C2=A0 Note = that when the network is
>>>=C2=A0 =C2=A0 under heavy load or in a fault condition, UDP mig= ht become
>>>=C2=A0 =C2=A0 unreliable.=C2=A0 Since this is when autonomic fu= nctions are most
>>>=C2=A0 =C2=A0 necessary, automatic fallback to TCP MUST be impl= emented.=C2=A0 The
>>>=C2=A0 =C2=A0 simplest implementation is therefore to use only = TCP.

Editor hat off.

I agree. I think it's very naive to think that for this application, intended to be used internally within an enterprise network, in
a NAT-free and proxy-free addressing realm, UDP has any value.
In fact, it's just a nuisance, since the programmer has to do a lot
of the work that TCP does. The performance gain, even if it's real,
is unimportant - autonomic traffic will be a tiny fraction of total
traffic. There will be no gain in footprint, since autonomic nodes
will carry full TCP stacks anyway. [If we wanted to put GRASP in
constrained nodes, we'd probably be talking about GRASP-over-COAP
anyway.] So here's what I would do:

OLD
=C2=A0 =C2=A0All other GRASP messages are unicast and could in principle ru= n over
=C2=A0 =C2=A0any transport protocol.=C2=A0 An implementation MUST support u= se of TCP.
=C2=A0 =C2=A0It MAY support use of another transport proto= col.=C2=A0 However, GRASP
=C2=A0 =C2=A0itself does not provide for error detection or retransmission.= =C2=A0 Use
=C2=A0 =C2=A0of an unreliable transport protocol is therefore NOT RECOMMEND= ED.

=C2=A0 =C2=A0Nevertheless, when running within a se= cure ACP on reliable
=C2=A0 =C2=A0infrastructure, UDP MAY be used for unicast messages not excee= ding
=C2=A0 =C2=A0the minimum IPv6 path MTU; however, TCP MUST be used for longe= r
=C2=A0 =C2=A0messages.=C2=A0 In other words, IPv6 fragmentation is avoided.= =C2=A0 If a node
=C2=A0 =C2=A0receives a UDP message but the reply is too long, it MUST open= a TCP
=C2=A0 =C2=A0connection to the peer for the reply.=C2=A0 Note that when the= network is
=C2=A0 =C2=A0under heavy load or in a fault condition, UDP might become
=C2=A0 =C2=A0unreliable.=C2=A0 Since this is when autonomic functions are m= ost
=C2=A0 =C2=A0necessary, automatic fallback to TCP MUST be implemented.=C2= =A0 The
=C2=A0 =C2=A0simplest implementation is therefore to use only TCP.

NEW
=C2=A0 =C2=A0All other GRASP messages are unicast and could in principle ru= n over
=C2=A0 =C2=A0any transport protocol.=C2=A0 An implementation MUST support u= se of TCP.
=C2=A0 =C2=A0It MAY support use of another transport protocol, but the deta= ils
=C2=A0 =C2=A0are out of scope for this specification. However, GRASP itself= does
=C2=A0 =C2=A0not provide for error detection or retransmis= sion.=C2=A0 Use of an
=C2=A0 =C2=A0unreliable transport protocol is therefore NOT RECOMMENDED. END NEW

That doesn't slam the door, but it removes what I now feel is
a very misleading paragraph. Of course, anybody is at liberty to
draft a full description of GRASP-over-UDP as a separate
document.

Again, that was personal opinion. I won't edit that part of
the draft without community input.

Than= ks, and I agree with not making changes unless there's community agreem= ent.

I do suspect that if UDP is not at least NOT = RECOMMENDED, some developers may not use TCP at all. A quick Google search = turned up e-mail from 2015 asking "if we REALLY have to support TCP in= our (micro-)DNS server", and TCP to accommodate response TrunCation h= as been a requirement for DNS since at least RFC 1035 in 1987.
But I don't know the future, of course. :D

<= /div>
Spencer


=C2=A0 =C2=A0 Brian

--001a114d80fc58fd6c054f2ab178-- From nobody Wed May 10 12:26:02 2017 Return-Path: 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 50E8312EA94; Wed, 10 May 2017 12:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 pXrFP9Es7qJE; Wed, 10 May 2017 12:25:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C49512EAB2; Wed, 10 May 2017 12:25:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2A5CBE19D; Wed, 10 May 2017 15:51:41 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E90DF636E0; Wed, 10 May 2017 15:25:20 -0400 (EDT) From: Michael Richardson To: Martin Thomson cc: Brian E Carpenter , ART Area , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org In-Reply-To: References: <149369279041.9906.5712707340786253297@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Artart telechat review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 19:25:30 -0000 --=-=-= Content-Type: text/plain Martin Thomson wrote: > I remain deeply concerned about the security parts. At a minimum, the > protocol needs a clear definition of how authentication and > confidentiality mechanisms are used, even if the process by which keys > and so forth are established is left to other work. In part, that's > easy, all the unicast stuff can use TLS and you can wave your hands > about how trust anchors get around. However, given that this I've argued strongly against doing this. "Use TLS" with hand-waving is akin to rfc5406 "Use IPsec": it gets us nowhere. We are doing quite a lot of work to get trust anchors in the right place (BRSKI), to describe how to bring up IP (or maybe GRE) over IPsec in the ACP document. GRASP does not stand alone. > traverses the Internet, I am going to suggest that not having > confidentiality for the general discovery case is unwise and not > having authentication for the same seems like a real deal-breaker. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkTaSAACgkQgItw+93Q 3WV2EQgAtL362CzHrm5sCS45bdMWW7C9yBRf9NAvj+Nnclc0ypBaL7mar22q0yWV qt4G+0J2pCnvmyId34YbB6sCONitHlFi1lUHOzE9M15vYWcQIiJ9tuJg0NfYvFhZ Kn2vUL9VutD/kKlOphnhY5uxzc+ZBPvXGhFRPwWNXxJjwhGBOa058JA2PPz//YOr dQYC/1SiBIvRtmN52jRcWxh6fjp+9V9TkEm0UGY7On0kjcFEe/EHBPW1sC0HzIgK dZJeg9OhntSdvUOKC+KjUkLVAS3cozG8PBgdi/iIsLJxve0rcxi4jZS9qMbf8sxZ N+HZUgzJOgxoxdQy0lMybZTcrLpX0g== =5AsS -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 10 12:28:25 2017 Return-Path: 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 C5A61128656; Wed, 10 May 2017 12:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 dRSFrm9_MfKB; Wed, 10 May 2017 12:28:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8A71274D0; Wed, 10 May 2017 12:28:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7DC96E19D; Wed, 10 May 2017 15:54:41 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4A707636E0; Wed, 10 May 2017 15:28:21 -0400 (EDT) From: Michael Richardson To: "Joel M. Halpern" cc: Brian E Carpenter , Martin Thomson , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org In-Reply-To: <2a9faaa6-7430-5a3e-dae4-272f13db0ba6@joelhalpern.com> References: <149369279041.9906.5712707340786253297@ietfa.amsl.com> <2a9faaa6-7430-5a3e-dae4-272f13db0ba6@joelhalpern.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Security references [Re: Artart telechat review of draft-ietf-anima-grasp-11] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 19:28:24 -0000 --=-=-= Content-Type: text/plain Agreed: GRASP should normatively reference the ACP. Joel M. Halpern wrote: > Claiming that ACP is not a normative reference for GRASP, since GRASP is to > run on ACP, seems a stretch. > Yes, if there is a library or API to call, that masks the knowledge. But that > could be said of a lot of normative references. > Put differently, it has seemed to me that I need to understand at least the > general shape of ACP operation in order to understand GRASP operation. Which > is the definition I am familair with for a normative reference. > And making it normative couples the publication in the right order. Which > seems a good indiciation fo teh relationship. > Yours, > Joel > On 5/9/17 10:47 PM, Brian E Carpenter wrote: >> On 03/05/2017 13:58, Brian E Carpenter wrote: >>> On 03/05/2017 12:47, Martin Thomson wrote: >> ... >>>>> The main references for external security are >>>>> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra >>>>> https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane >>>>> which are indeed normative dependencies. >>>> >>>> Both are informative. >>> >>> Oh. Well, technically you don't need to know how they work in order >>> to implement GRASP. I'll do whatever the community wants, of course. >> >> The reason that these two references are currently Informative >> in GRASP is that a person coding the protocol has no need to >> understand their details. (She will need to understand the ACP's >> API, but that is not described in the ACP draft.) Therefore, >> technically, although using the ACP is a SHOULD requirement in >> GRASP, my understanding of the rules is that it is not a >> normative reference. >> >> The downside is that if we get into the RFC Editor queue, GRASP >> could in theory be published before the ACP becomes an RFC. >> That seems wrong. >> >> Opinions, please! >> >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkTadQACgkQgItw+93Q 3WW4UAf/W75qnZ+ObCwS5yqgwQ3y5MBO6ALs9q3zI4QY4lFRXUuhz4ynRE4s/xaC V9+yrEMhovRFPSRsfMQ9ErCpf8wlvArWyWd7G1gG4Omf+c0DLdjFGeDXCKgYDRUQ q8ARubwVo4GTgtJRgy4VAeHA2doaoXSXtslDbPXeQI67EFsrNbWPCihf02EEcukl eZxid3pomyM+A91sUy08VaXHbzbCUkgt8Me6N1/JPNDA7Y0NKN/2q0QoOqP/6JC2 mlZaQdGOiPIPCHYKqVFgwywXBqJ2a0lV3IOzz/K+1l68dI1GStKVZdJ7fV0Gn7zX O6l3hrZS7GWefWnSTRVoGuqr5W4xJQ== =xiH7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 10 13:11:39 2017 Return-Path: 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 60B28129C5A; Wed, 10 May 2017 13:11: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqvKEVUeqMgm; Wed, 10 May 2017 13:11:36 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 CDDCB129649; Wed, 10 May 2017 13:11:36 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id i63so711206pgd.2; Wed, 10 May 2017 13:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0Ga9oFjdx2aGX6iN8IaK1gtHzBsNGDntbJrq9ZRhzp0=; b=kaglLsgpDRay31rLZHNGXfKHUaZJdC8lvrviI5w7svIb7BH66yFHcSYLB/O19bze9h yrjFJNZy+gGSxwF2Kxu/XT4m8LWpJLMoQEz6fiPIlchw4SrnQ4aPIg19EJEPCy8sOTSl aOGFY29fiaIEl8M9mplZYiMOW6zj/WlzpHS98nMNJ3dNMd5M+NP+h7JBuam5ppZw5/Kr wsALwciaSRlOT6PxyTJNLMyrxst4YmkcFTYgCy6sBhmRjPwlLFcyH8eSuZK5tpc4drtq PNUsdr+i6QWwO/nsAu1b+q4xC39CarQ2NyYuWF8Q1naBVqtf0Uxl2tqxt+zEqvFrYcTX 7n3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=0Ga9oFjdx2aGX6iN8IaK1gtHzBsNGDntbJrq9ZRhzp0=; b=TVZ5vVeBxNelKgm5AtcOgDLU5z1H35+GQbui5a8XtnbLNOsgdD4af14vvsKfrEFys5 mW68ACA3QNWOIFFtGIt9UPJkDkbN4tTpcbt5gwgAyx7LXN4eOelHNgVgBnMoTYA24FyW eUlq9V8bmfWUeWn86sTfyS6kie3OTklfrpty0+M2LP1GUArb2dFP6JhjyNpA5Dh4WggA 2+iFF02XLuZwlGrPCiJffHQH+N09BrKxwi1dBmD/lFOfJTOeM3mjLv7v4XL7Zg24grkz tLqQUW3tTT1fuXFMFTIBNapK6USDLVBbanoPAi8jd8+w3TKSXe8+Yt+deKTCbqDosCBv ktvA== X-Gm-Message-State: AODbwcDENphPD21R/OcQISSZcldcyPgUuK68tmLyzfhRSTTvSXJ/YC5F 70zo1pFTnjnWkg== X-Received: by 10.98.194.215 with SMTP id w84mr8298254pfk.192.1494447096358; Wed, 10 May 2017 13:11:36 -0700 (PDT) Received: from [192.168.178.21] (173.230.69.111.dynamic.snap.net.nz. [111.69.230.173]) by smtp.gmail.com with ESMTPSA id l185sm6649860pfl.106.2017.05.10.13.11.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 13:11:35 -0700 (PDT) To: Michael Richardson , "Joel M. Halpern" References: <149369279041.9906.5712707340786253297@ietfa.amsl.com> <2a9faaa6-7430-5a3e-dae4-272f13db0ba6@joelhalpern.com> <16117.1494444501@obiwan.sandelman.ca> Cc: Martin Thomson , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <058c0e26-405b-4be4-62cd-f0d642792ab9@gmail.com> Date: Thu, 11 May 2017 08:11:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <16117.1494444501@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Security references [Re: Artart telechat review of draft-ietf-anima-grasp-11] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 20:11:38 -0000 On 11/05/2017 07:28, Michael Richardson wrote: > > Agreed: GRASP should normatively reference the ACP. OK, I will make that change in my working copy. Apparently there is a tsv-art review coming soon, so we will not publish an update before that arrives. I will put the ongoing xml file in https://github.com/becarpenter/animaproto sometime today. Brian > Joel M. Halpern wrote: > > Claiming that ACP is not a normative reference for GRASP, since GRASP is to > > run on ACP, seems a stretch. > > Yes, if there is a library or API to call, that masks the knowledge. But that > > could be said of a lot of normative references. > > > Put differently, it has seemed to me that I need to understand at least the > > general shape of ACP operation in order to understand GRASP operation. Which > > is the definition I am familair with for a normative reference. > > > And making it normative couples the publication in the right order. Which > > seems a good indiciation fo teh relationship. > > > Yours, > > Joel > > > On 5/9/17 10:47 PM, Brian E Carpenter wrote: > >> On 03/05/2017 13:58, Brian E Carpenter wrote: > >>> On 03/05/2017 12:47, Martin Thomson wrote: > >> ... > >>>>> The main references for external security are > >>>>> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra > >>>>> https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane > >>>>> which are indeed normative dependencies. > >>>> > >>>> Both are informative. > >>> > >>> Oh. Well, technically you don't need to know how they work in order > >>> to implement GRASP. I'll do whatever the community wants, of course. > >> > >> The reason that these two references are currently Informative > >> in GRASP is that a person coding the protocol has no need to > >> understand their details. (She will need to understand the ACP's > >> API, but that is not described in the ACP draft.) Therefore, > >> technically, although using the ACP is a SHOULD requirement in > >> GRASP, my understanding of the rules is that it is not a > >> normative reference. > >> > >> The downside is that if we get into the RFC Editor queue, GRASP > >> could in theory be published before the ACP becomes an RFC. > >> That seems wrong. > >> > >> Opinions, please! > >> > >> Brian > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > >> > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Wed May 10 14:18:31 2017 Return-Path: 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 AD18A128959; Wed, 10 May 2017 14:18:30 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvDDXy-tB8F4; Wed, 10 May 2017 14:18:29 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 7DD52128616; Wed, 10 May 2017 14:18:29 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id l50so6120412wrc.3; Wed, 10 May 2017 14:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P1jhZQrSkMsNcfFNPlxPCUf7QL8eRmWIlAUTCdVWfec=; b=Y2gYhAcqahwGJAne5e+jH3awZ64/Atehk7qGOGCCFPEGswAWD5Rtet9uuhhrZ9Na0K tmp9Rhb+hGqnNm7hpHyDxYDxZmbYDiH6Ov1Hwj4Xq8ZRClXvxjPwjwHme3kRTsJPukH9 X7Vde9nW9joirwnIERIHhOHArCahOYMWr4noWZKEIbhaci05yYw915LBPWnBFz9kzsUm laq7/ds3lteEU6N4iLMvzFTIU9CptJVrL0pe55nFW0dxZ6te8potN/NB0jvl5ourUitj JxAYaf7lr/PGoBBqeZzEur/2yDyRyvOImBvMncjR4X26n22cywIvzli7px1f/ZRmItxB FoUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P1jhZQrSkMsNcfFNPlxPCUf7QL8eRmWIlAUTCdVWfec=; b=JiCIgTPUdWFZSFJS+YNDNPuI4r7f+M30Bg9DioxKzW+DVjLQKT44k57RyH9nDt8XW7 9nepMYt4UH6UfneK+d9+Aw4dK1hhC/q1HP74aYFY94jTDKEeCbGIK9x61y/YFIej35ln eRtrgc+ft5xgDWSap1HyzNm+zwmHbS7zHah4e0lJsE/TvY7cEDnDSg3539G8JfPnT8mS KjPSzOyd69wczOuyP1N48ZZbl0aB3Fywjw7h8vgp0w0597WUeAEK5giTtmT0yDO5rnGz tIsdQ3EDEh3Plt1TGHEZXA07XCJZYmUnV7qDldRXS6fEAkCRUp+X4VNcBxGc2SxWunFA 8UwQ== X-Gm-Message-State: AODbwcC/AmEiFGB7u8LF9Od1ePvzJiXQxOuue7BQWHGK7WD10eukBu+l kRmzonb4P7MWV6gapidRqZv/rtHbOQ== X-Received: by 10.46.0.23 with SMTP id 23mr3572783lja.33.1494451107941; Wed, 10 May 2017 14:18:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 10 May 2017 14:18:27 -0700 (PDT) In-Reply-To: <15394.1494444320@obiwan.sandelman.ca> References: <149369279041.9906.5712707340786253297@ietfa.amsl.com> <15394.1494444320@obiwan.sandelman.ca> From: Martin Thomson Date: Thu, 11 May 2017 07:18:27 +1000 Message-ID: To: Michael Richardson Cc: Brian E Carpenter , ART Area , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Anima] Artart telechat review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 21:18:30 -0000 On 11 May 2017 at 05:25, Michael Richardson wrote: > GRASP does not stand alone. I have to assess the document on its own merits. As already established, there are no normative dependencies on any sort of key management. That this work has been done suggests that perhaps a small change to the structure of this and other documents could be made to rectify the problem. From nobody Wed May 10 17:47:06 2017 Return-Path: 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 3699C12EAB6; Wed, 10 May 2017 17:47:03 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEJqPAMxbJCK; Wed, 10 May 2017 17:47:01 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 91FC912EAB0; Wed, 10 May 2017 17:47:01 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id s62so1409224pgc.0; Wed, 10 May 2017 17:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4Rsh+f4WzQY0r4g+C66q5we73/FPu86GmHvqL7NKowk=; b=GKSp8KE7PFHQH8QcPnrZCnbbVuPyUV9fZe+LMKNmbWFOMPvLJo1ZzFjqO2PJYXj4AV lrTigdphBGbU+B0gfNb1+6uvBEVGwO0kznQlJmJcOu5nu2UQMBw/eYcwFlSPBcwM9CAr GzpQk1J5V9+tUfsIzXHUIul6ReN19xBI0UjdXpttflp2/6ZRGradWm9DMi4Gj5HbuygO M+UW/+bWMAQd1OlqJtuuGArWL+7mqX5SEYF8rMXkNW0NLXx5UprNxZVEVKM5zHEv/PSF W/Dmn/+i0xb76ygaesovpCqsAL4uASWxcFh2DKVHtz/VW260UFy94GAR6di/1VVW/+ax Wj5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=4Rsh+f4WzQY0r4g+C66q5we73/FPu86GmHvqL7NKowk=; b=ivpgGt5YpkknxWDQt/JzKCHUc03LGqc1xkptgNt2WhTdV0Y1dOw/Xk23ss68YGmXpb LkV2u7XroFUpGCv2J/PNdQudj/4rcHHP/L5d9pFCLX94LLBWIhvcBupZgNw+4gaFNbHG fqQPyNcAqKOeSZkNWZKLD+dOuzIWbUQA5r1nDvDfQCN9ztEph+R2znrmBK6eYYKGBX4K biCEFIaRGbn+skETFVmIqTYbHNu7oZpB8Qzo1+BCfytXjwKYF5KeWfDxwMi8iOACkHti TT0vaWz/Bf1/sP6nPZaR2mjkP1a9kQfYNw9rQbGkCLMuGaXVaZ2kCC7NZ0+SzyjQBSfN IUZA== X-Gm-Message-State: AODbwcA5ronxyvxM4z6Vx3m60lOiB5+3iJvbVDTcdz0kSCtmFydftveG 1oRpxvailcqOVg== X-Received: by 10.99.61.134 with SMTP id k128mr9241870pga.201.1494463621114; Wed, 10 May 2017 17:47:01 -0700 (PDT) Received: from [192.168.178.21] (173.230.69.111.dynamic.snap.net.nz. [111.69.230.173]) by smtp.gmail.com with ESMTPSA id s187sm140000pfs.54.2017.05.10.17.46.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 17:47:00 -0700 (PDT) To: Martin Thomson , Michael Richardson References: <149369279041.9906.5712707340786253297@ietfa.amsl.com> <15394.1494444320@obiwan.sandelman.ca> Cc: ART Area , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <862226cd-2092-e3bd-2329-48f0ae3e4071@gmail.com> Date: Thu, 11 May 2017 12:47:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Artart telechat review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 00:47:03 -0000 On 11/05/2017 09:18, Martin Thomson wrote: > On 11 May 2017 at 05:25, Michael Richardson wrote: >> GRASP does not stand alone. > > > I have to assess the document on its own merits. As already > established, there are no normative dependencies on any sort of key > management. > > That this work has been done suggests that perhaps a small change to > the structure of this and other documents could be made to rectify the > problem. The ACP will now be a normative reference for GRASP. It's the ACP whose trust model depends on the security bootstrap, which will therefore need to be a normative reference for the ACP. How trust is established when there is no ACP is explicitly out of scope, see section 3.5.2.1. Brian From nobody Wed May 10 18:05:14 2017 Return-Path: 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 92291129C5F for ; Wed, 10 May 2017 18:05:12 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGC6xgg7BwoJ for ; Wed, 10 May 2017 18:05:11 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 105A512949A for ; Wed, 10 May 2017 18:05:11 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id n23so711949pfb.2 for ; Wed, 10 May 2017 18:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=znJaMtemIXLyfyaE2rKPt3n8texz9NMo1qaX5UKr20c=; b=vaGFDE3tsyHpiGX8xTtnbOQ1GVTN6RcvNshig/ExbcO+VSUHWX/zarYfvfYOg42FfG gXIWXM+Y57y0oo4YxHzuafbQ/9nG/b+XMGdd7kF2SvKjV74A7S8IpP+feP/+nhZio9Bz ZOGo4b9JOVoZ9hhs8cIATjCB+9mg/pFcmRatjEftPjE9dophVEDHwDhw9EluRU28MkPs 4TA+0bFm6/U8ag3Dq6PEd7pRvUoAb438nddbeeSAyNXVv0nKqHdSlhhEUiE9Z/RS2c68 YDy+SIoEQQmHzGbta0yHX77JrSlwZeqhALn2VLILiafywH54bSZLPGhRRbX3vPzpdpl0 KAGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=znJaMtemIXLyfyaE2rKPt3n8texz9NMo1qaX5UKr20c=; b=nnNE4vs5frnK5YjpWS+vXrhM2ym6wZFqOixPDO90gj2D/sqbaHN8S/59Om7E2+KGzx L64sF0MBRaVel9u4OrMrIVJ4zXpvZ3HePCoTuHCo70YQh7m2qugfYfOVGjpxG/xgR2Mf xryXobOHgULM4UhAFm5A+2eY+TW2Xqyn31BoOZxiCq7x0Jtclo2uU3JjWNNzAa3UnPgX 82ZsULTwfVvGs3z3V4+77DS7IzUyX6GmIu4b9PHLWVCYii2/Ajb0O6SD1bc7sJSHTOjO 9kdAbIZGyOQnAkAJtKm7AamyvFqZgSPf2WzG4XF/e+4yX6tgOJIRRR1o9R+fpzjbwkSC yldQ== X-Gm-Message-State: AODbwcBZNYkB0cpmVk4wzfKm5rGqU48Ouhm1xjt46VdKFwcO0/QXF2Wa Y0mYB+XvftLvK+By X-Received: by 10.99.113.74 with SMTP id b10mr2318120pgn.139.1494464710457; Wed, 10 May 2017 18:05:10 -0700 (PDT) Received: from [192.168.178.21] (173.230.69.111.dynamic.snap.net.nz. [111.69.230.173]) by smtp.gmail.com with ESMTPSA id e187sm180848pfc.17.2017.05.10.18.05.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 18:05:09 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <61dc4146-7882-cf18-cc4b-8be155f49986@gmail.com> Date: Thu, 11 May 2017 13:05:15 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Reference errors in draft-ietf-anima-autonomic-control-plane X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 01:05:13 -0000 I noticed that the references in the ACP draft are not separated into Normative and Informative as required. I think that at least the following should be normative: [I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-grasp] [RFC4193] [RFC5280] [RFC5952] [RFC6347] [RFC6550] [RFC6552] [RFC7676] Also, idnits finds several unused references that should be deleted: == Unused Reference: 'RFC4122' is defined on line 1574, but no explicit reference was found in the text == Unused Reference: 'RFC5082' is defined on line 1588, but no explicit reference was found in the text == Unused Reference: 'RFC6762' is defined on line 1620, but no explicit reference was found in the text == Unused Reference: 'RFC6763' is defined on line 1624, but no explicit reference was found in the text And while I'm here: ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. Regards, Brian From nobody Thu May 11 20:21:55 2017 Return-Path: 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 2CE5E131556 for ; Thu, 11 May 2017 20:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ROxrwiZxWPa for ; Thu, 11 May 2017 20:21:52 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::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 C0B10131567 for ; Thu, 11 May 2017 20:15:01 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id q125so4230134pgq.2 for ; Thu, 11 May 2017 20:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=0qdVN6e0Lo4qyxmR4arZkPStIZq84sirXfs1U/TbaFI=; b=BxmZm+KFBCfxBVGiQ6f4L8RhCmOjpq+6X4RoxyhGIjgyZArCbIdZ8/MPdIlwPaG41X RFPCwIbjBMkSXFFTklAirmu6831J8rUeZj3DlJH0udBXRjL2lNlhopIxYEuV8q6mour3 TDTVS1mV897K2V886psVlpGZByg6pVzQ2s+5r74WYbADWqd2r4eF3Rhjc3a5AeGNiJ4P z/f3YfzMJE7J+7R4fJxtOONbcoMhb0NtX/Q42RovSbYwLntBcjes2FCQX0/hr7kotW6C L4qzTVRGnYZKFNWCuSH4S2LcRK3x07/vE7ck/GeQHJqymyvHseq1T4BjSF0uF1Srczu4 tldA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=0qdVN6e0Lo4qyxmR4arZkPStIZq84sirXfs1U/TbaFI=; b=k4LnpZdoYSlc8+E2WSZR/HcrUdWknyY1An+otzP569/ZCsxBs5mzLe8m4JOO7xeRQ5 Q0Xy9mtiV0nFuhDLcAC8EidbcqahvurVjtlmrDeNL7qkgbS27xS1P2O7koUzPW04OK2R o85WoCpHds4pIdSPrt94+OrLmIMzmzgzszDHpaTdCoPv3JjRdaigLvaN2yrfXKaHQ7EM XrHExYLKiYs1n7Yx6S4hD35GGfrVgr7ElWojsnKvMdhr/oIO8cM/F8tZVlY6JNy9IdSU aRmmvcU4EP6jKJGAGWDYFvy5BGIDv9jeHJcu6owQsLY0Dcxuk4PuwoWpbgzGjq59FTDX Tfmw== X-Gm-Message-State: AODbwcAE7oaaCzCQRDcg2mN5ppQdd5pbQzw4YIwmY3S5st6qdNSUkOYU vWMSUuYWGzdhPrY2 X-Received: by 10.84.136.135 with SMTP id 7mr2662470pll.33.1494558901133; Thu, 11 May 2017 20:15:01 -0700 (PDT) Received: from [192.168.178.21] ([118.149.111.242]) by smtp.gmail.com with ESMTPSA id f80sm2405912pfe.26.2017.05.11.20.14.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 May 2017 20:15:00 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 12 May 2017 15:15:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] 2 questions about the prefix management draft X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 03:21:54 -0000 I have two questions about draft-ietf-anima-prefix-management-03 before we move it forward. As a reminder, the main GRASP objective is defined like this: objective = ["PrefixManager", objective-flags, loop-count, [PD-support, length, ?prefix]] loop-count = 0..255 ; as in the GRASP specification objective-flags /= ; as in the GRASP specification PD-support = true / false ; indicates whether sender supports PD length = 0..128 ; requested or offered prefix length prefix = bytes .size 16 ; offered prefix in binary format Question 1: Should we add an IP version indicator? In this case the value of the objective would be something like: [IP-version, PD-support, length, ?prefix] (and the prefix would be 4 or 16 bytes according to the IP-version). This seems quite simple to define (and to implement: I have figured out how to do it for my demonstration code). It makes the objective more versatile at low cost. Question 2: What is the value of the PD-support parameter? I have been thinking about use cases, and I can't find one. Lets's assume that an ASA supports "PrefixManager" in order to obtain address space from a pool, and then hands out prefixes to non-autonomic devices such as CE routers. It may use DHCPv6/PD for that, or RADIUS, or some other method. However, that is quite irrelevant for the autonomic operations where this ASA communicates with other ASAs to obtain address space. We introduced this parameter a long time ago and the text says: 4.3. Behavior after Successful Negotiation Upon receiving a GRASP Negotiation-ending message that indicates that an acceptable prefix length is available, the requesting device may request the prefix using DHCPv6 PD, if both ASAs have indicated that they are within a device that supports PD. Otherwise, it is permissible for the initiating ASA to use the negotiated prefix without further messages. What's the point? Why would we need to use PD when we've already negotiated a prefix? Regards, Brian From nobody Mon May 15 02:49:20 2017 Return-Path: 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 7122F129BD7; Mon, 15 May 2017 02:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Yz9CdMt4ja4; Mon, 15 May 2017 02:49:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A33B129566; Mon, 15 May 2017 02:45:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGQ31145; Mon, 15 May 2017 09:45:15 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 15 May 2017 10:45:14 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 15 May 2017 17:45:09 +0800 From: Sheng Jiang To: Anima WG CC: "anima-chairs@ietf.org" Thread-Topic: Review of draft-ietf-anima-voucher-02 Thread-Index: AdLNX+f8nW2hbPYgQsahYgXj0ecekQ== Date: Mon, 15 May 2017 09:45:08 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CD9CE1C@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CD9CE1CNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.591978AC.001C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6a09d196242fc6fa9810e732d4504d90 Archived-At: Subject: [Anima] Review of draft-ietf-anima-voucher-02 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 09:49:17 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CD9CE1CNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, authors of draft-ietf-anima-voucher, I am doing a thorough review as the document shepherd with my ANIMA chair h= at on. Please address the below comments so that we could process this docu= ment further. I cannot claim myself a security expert, so extra security ex= pert review is needed, either in WGLC or IESG review stage. Firstly, there is report that this document has warnings or errors returned= by YANG validation. Please Secondly, please check the references and normative words. This document ha= s a "MUST not", which is not an accepted usage according to RFC 2119. RFC60= 66 & RFC5652 has been quota in the document, but not defined; and normative= reference to an Informational RFC 2315. Thirdly, there are 19 question marks in the document. Most of these are dis= cussed and reach conclusions, I believe. Please remove these question marks= and relevant text. If there are still open questions, please discuss in ma= iling list and address them, before we could process WGLC. In section 2, The quota from Konrad Lorenz should be put into quotation mar= ks. "This document describes vouchers in detail."It is better to give a referen= ce to the specific section 4. In definition of Domain CA, "Optionally, it certifies all elements." What d= oes the term "element" mean? This term does not appear anywhere else in the= document. In definition of MASA, "It does not track ownership." It is not clear for m= e, whether the MASA is technically not be able to track ownership or in the= commercial deployment model, it MUST NOT/SHOULD NOT track ownership. There= is no enough description or discussion on the relationship between the MAS= A and device ownership. A few inconsistent for capital abbreviation, such as cn-id, dns-id, etc. A few DISCUSS & EDNOTE from editor notes should be removed. The normative words in design consideration seems odd for me. The design co= nsideration means not protocol definition neither behavior specification al= though security consideration may be specification in my eyes. It should no= t have normative words. Typo: "informative", "informative"; "Circustance", "Circumstances"; "mainta= nence", "maintenance"; hardware security modules (HSMs), Hardware Security = Modules (HSMs). Regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B927CD9CE1CNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, authors of draft-ietf-anima-voucher,

 

I am doing a thorough review as the documen= t shepherd with my ANIMA chair hat on. Please address the below comments so= that we could process this document further. I cannot claim myself a security expert, so extra security expert review is needed, eithe= r in WGLC or IESG review stage.

 

Firstly, there is report that this document= has warnings or errors returned by YANG validation. Please

 

Secondly, please check the references and n= ormative words. This document has a “MUST not”, which is not an= accepted usage according to RFC 2119. RFC6066 & RFC5652 has been quota in the document, but not defined; and normative reference to an Informatio= nal RFC 2315.

 

Thirdly, there are 19 question marks in the= document. Most of these are discussed and reach conclusions, I believe. Pl= ease remove these question marks and relevant text. If there are still open questions, please discuss in mailing list and address them,= before we could process WGLC.

 

In section 2, The quota from Konrad Lorenz = should be put into quotation marks.

 

“This document descri= bes vouchers in detail.”It is better to give a reference to the speci= fic section 4.

 

In definition of Domain CA, “Optional= ly, it certifies all elements.” What does the term “elementR= 21; mean? This term does not appear anywhere else in the document.

 

In definition of MASA, “It does not t= rack ownership.” It is not clear for me, whether the MASA is technica= lly not be able to track ownership or in the commercial deployment model, it MUST NOT/SHOULD NOT track ownership. There is no enough description or = discussion on the relationship between the MASA and device ownership.<= /o:p>

 

A few inconsistent for capital abbreviation= , such as cn-id, dns-id, etc.

 

A few DISCUSS & EDNOTE from editor note= s should be removed.

 

The normative words in design consideration= seems odd for me. The design consideration means not protocol definition n= either behavior specification although security consideration may be specification in my eyes. It should not have normative words.<= /o:p>

 

Typo: “informative”, “inf= ormative”; “Circustance”, “Circumstances”; &#= 8220;maintanence”, “maintenance”; hardware security modul= es (HSMs), Hardware Security Modules (HSMs).

 

Regards,

 

Sheng

--_000_5D36713D8A4E7348A7E10DF7437A4B927CD9CE1CNKGEML515MBXchi_-- From nobody Mon May 15 07:18:13 2017 Return-Path: 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 D828C12952E; Mon, 15 May 2017 07:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJMyWw0Igx-6; Mon, 15 May 2017 07:18:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950B212EB11; Mon, 15 May 2017 07:12:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8BF7C20566; Mon, 15 May 2017 10:38:52 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DF87B636BB; Mon, 15 May 2017 10:12:15 -0400 (EDT) From: Michael Richardson To: Sheng Jiang cc: Anima WG , "anima-chairs\@ietf.org" In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CD9CE1C@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927CD9CE1C@NKGEML515-MBX.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Review of draft-ietf-anima-voucher-02 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 14:18:13 -0000 --=-=-= Content-Type: text/plain Sheng Jiang wrote: > Hi, authors of draft-ietf-anima-voucher, > I am doing a thorough review as the document shepherd with my ANIMA okay. We'll work through these on Tuesday (tomorrow). > A few DISCUSS & EDNOTE from editor notes should be removed. Well, they are there to keep us from advancing the document with issues unresolved :-) > The normative words in design consideration seems odd for me. The > design consideration means not protocol definition neither behavior > specification although security consideration may be specification in > my eyes. It should not have normative words. Perhaps naming it Design Considerations is the error. I don't see the normative words there as wrong; they need to be there. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkZtz8ACgkQgItw+93Q 3WXc3QgAr3lBajS2TR0qIg2ecWVyRPd/DPo271LBThAE1lHrufGpMzRop2ZI69e9 IZOFe8/gQtwTuENy2iYtaCc6Nkr2fSwDoamEI077kDXqKTWvMLkHD8CmrzG1eZi3 XYrTEcSfA+G8/Vu1XJoDjiaUnPfdJmmMYWiZZ2nNTm9a1U1MhNFRmFSzzMUKMbwL 3pUQc0ierNhcAkrMIB7mIEWC5+Xx4dm6hKybCFzY7pOdWWeGNlw8cZuXDOA6GnD7 0kXzKz+5AvftWVwK3Mt4xFDgERRA5DY9MeTHJbmEGIyCGtjBALeH3Ybjixv/52PI 9ppy/5UArWr0lwNDcfcdmcBJL85MDg== =krW6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 15 13:33:01 2017 Return-Path: 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 D6E5A129B74 for ; Mon, 15 May 2017 13:33:00 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiQryWv1wP8k for ; Mon, 15 May 2017 13:32:59 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 6EE6A129AFE for ; Mon, 15 May 2017 13:30:14 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id m17so68577401pfg.3 for ; Mon, 15 May 2017 13:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XLCoMKk8fA//uF3h6vKmg61VynYzM9tFYMTtrCwt2+s=; b=K/BuHtqcvHABhKQjEWjanmHga0BqW/Ya9Qceb0XhbeRW9MakTFQ740CL74/wJrMDBJ jzNVofVdj9EsymhmznQkXCWmGH87u4os71fj4dnhsyed/cMBVx2ziABPcXB9Khup5VL2 ccIDnc21NLT5jaHnG5E4+IkTz5+bWqgQvfo2Mn2kGr83ugs6zFOqxF/G1dZCFIXKJ3Fr tvTVH3T69P9rlX8MVTXZaTbdwF+U2z3mvPQis3OAv5KONIredzweKC5logITC+LTWGSV jF5ZIfavPqUKgJfI/jSqJ8vRYK4BXeu0A8E2DNvyJ2rhdxARARplvzySL2i+Mcrk2y9h Koqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=XLCoMKk8fA//uF3h6vKmg61VynYzM9tFYMTtrCwt2+s=; b=V/Gtj2Ma7YBUQlMVzMy6RN/uJl3dtMetFeskRdxV9H0nfkAY7E3OknvmixWx7Z3l0z AotfFKQKXE9WM+GeQAB1Mz9pfylTJSh0pWtHdndB+h/+gPP+XsThQZpMUP7f9XPk+eMY nWb1u1FXrwGNqPiEI2UHEK+rgGHaCbkwOcGqKhxDHgkI9cd+994DiSx94ksmW6OrlW6k 0FQOIDoYiDcc17AyoJIK06/D/mnbkZCW6rT7HHR8raj9J0R9e7mAkzSpkWb/ibwjo+lb Fa5UEQTw1SqrfHRxPDjQWXeIQXhY7hipU7mLQaCnx/qJHGQd54ng/NWrEYoWz2cfS+YH +GuQ== X-Gm-Message-State: AODbwcCroFn8EcauPQ8tw3QKrCuz1gY5XXjxpCPZXzgHR7CkwLWEmCUs qS3Rvqc/39+CFwiV X-Received: by 10.98.207.132 with SMTP id b126mr8183348pfg.167.1494880213746; Mon, 15 May 2017 13:30:13 -0700 (PDT) Received: from [192.168.178.21] ([118.149.96.184]) by smtp.gmail.com with ESMTPSA id i68sm21143845pfi.72.2017.05.15.13.30.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 May 2017 13:30:12 -0700 (PDT) To: Anima WG References: <149421130029.23119.9372718991371280967.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <801850a1-bd98-e84a-f001-fb309d0d0288@gmail.com> Date: Tue, 16 May 2017 08:30:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Remove UDP text [ Spencer Dawkins' No Objection on draft-ietf-anima-grasp-11: (with COMMENT)] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 20:33:01 -0000 Hi Anima WG (only), We need to resolve this issue quickly, to get a new draft out in the next few days, before the IESG meeting next week. So, since I haven't seen any opinions on the issue below, I propose to delete the UDP paragraph as suggested below. Note that this does not prevent us adding a UDP mode later, but it removes the confusion that we have in the text today. If you don't agree please send alternative text in the next 24 hours. (Also see: https://www.ietf.org/mail-archive/web/ops-dir/current/msg02653.html ) Regards Brian On 11/05/2017 00:34, Spencer Dawkins at IETF wrote: > Hi, Brian, > > On Tue, May 9, 2017 at 9:49 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Spencer, >> On 10/05/2017 05:13, Spencer Dawkins at IETF wrote: >> >> The bits where we can simply do what you suggest >> >>> Grrr, but please see below. >>> >>>> >>>>> >>>>> I'm really confused by this text. >>>>> >>>>> Nevertheless, when running within a secure ACP on reliable >>>>> infrastructure, UDP MAY be used for unicast messages not exceeding >>>>> the minimum IPv6 path MTU; however, TCP MUST be used for longer >>>>> messages. In other words, IPv6 fragmentation is avoided. If a node >>>>> receives a UDP message but the reply is too long, it MUST open a TCP >>>>> connection to the peer for the reply. Note that when the network is >>>>> under heavy load or in a fault condition, UDP might become >>>>> unreliable. Since this is when autonomic functions are most >>>>> necessary, automatic fallback to TCP MUST be implemented. The >>>>> simplest implementation is therefore to use only TCP. >> >> Editor hat off. >> >> I agree. I think it's very naive to think that for this application, >> intended to be used internally within an enterprise network, in >> a NAT-free and proxy-free addressing realm, UDP has any value. >> In fact, it's just a nuisance, since the programmer has to do a lot >> of the work that TCP does. The performance gain, even if it's real, >> is unimportant - autonomic traffic will be a tiny fraction of total >> traffic. There will be no gain in footprint, since autonomic nodes >> will carry full TCP stacks anyway. [If we wanted to put GRASP in >> constrained nodes, we'd probably be talking about GRASP-over-COAP >> anyway.] So here's what I would do: >> >> OLD >> All other GRASP messages are unicast and could in principle run over >> any transport protocol. An implementation MUST support use of TCP. >> It MAY support use of another transport protocol. However, GRASP >> itself does not provide for error detection or retransmission. Use >> of an unreliable transport protocol is therefore NOT RECOMMENDED. >> >> Nevertheless, when running within a secure ACP on reliable >> infrastructure, UDP MAY be used for unicast messages not exceeding >> the minimum IPv6 path MTU; however, TCP MUST be used for longer >> messages. In other words, IPv6 fragmentation is avoided. If a node >> receives a UDP message but the reply is too long, it MUST open a TCP >> connection to the peer for the reply. Note that when the network is >> under heavy load or in a fault condition, UDP might become >> unreliable. Since this is when autonomic functions are most >> necessary, automatic fallback to TCP MUST be implemented. The >> simplest implementation is therefore to use only TCP. >> >> NEW >> All other GRASP messages are unicast and could in principle run over >> any transport protocol. An implementation MUST support use of TCP. >> It MAY support use of another transport protocol, but the details >> are out of scope for this specification. However, GRASP itself does >> not provide for error detection or retransmission. Use of an >> unreliable transport protocol is therefore NOT RECOMMENDED. >> END NEW >> >> That doesn't slam the door, but it removes what I now feel is >> a very misleading paragraph. Of course, anybody is at liberty to >> draft a full description of GRASP-over-UDP as a separate >> document. >> >> Again, that was personal opinion. I won't edit that part of >> the draft without community input. >> > > Thanks, and I agree with not making changes unless there's community > agreement. > > I do suspect that if UDP is not at least NOT RECOMMENDED, some developers > may not use TCP at all. A quick Google search turned up e-mail from 2015 > asking "if we REALLY have to support TCP in our (micro-)DNS server", and > TCP to accommodate response TrunCation has been a requirement for DNS since > at least RFC 1035 in 1987. > > But I don't know the future, of course. :D > > Spencer > > >> Brian >> > From nobody Mon May 15 14:08:30 2017 Return-Path: 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 CD9C1129467 for ; Mon, 15 May 2017 14:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 ov_yPny3n841 for ; Mon, 15 May 2017 14:08:26 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1B51D128896 for ; Mon, 15 May 2017 14:05:36 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id v4FL5YqF017005 for ; Mon, 15 May 2017 17:05:35 -0400 To: anima@ietf.org References: <149421130029.23119.9372718991371280967.idtracker@ietfa.amsl.com> <801850a1-bd98-e84a-f001-fb309d0d0288@gmail.com> From: William Atwood Organization: Concordia University, Montreal Message-ID: <259cfad3-31bb-b7da-1777-0954de9cad32@concordia.ca> Date: Mon, 15 May 2017 17:05:40 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <801850a1-bd98-e84a-f001-fb309d0d0288@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2017-05-15 17:05:35 EDT Archived-At: Subject: Re: [Anima] Remove UDP text [ Spencer Dawkins' No Objection on draft-ietf-anima-grasp-11: (with COMMENT)] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 21:08:29 -0000 I strongly agree with the proposed change. Bill Atwood On 15/05/2017 4:30 PM, Brian E Carpenter wrote: > Hi Anima WG (only), > > We need to resolve this issue quickly, to get a new draft out in the next > few days, before the IESG meeting next week. > > So, since I haven't seen any opinions on the issue below, I propose to > delete the UDP paragraph as suggested below. Note that this does not > prevent us adding a UDP mode later, but it removes the confusion that we > have in the text today. > > If you don't agree please send alternative text in the next 24 hours. > > (Also see: https://www.ietf.org/mail-archive/web/ops-dir/current/msg02653.html ) > > Regards > Brian > > On 11/05/2017 00:34, Spencer Dawkins at IETF wrote: >> Hi, Brian, >> >> On Tue, May 9, 2017 at 9:49 PM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >>> Spencer, >>> On 10/05/2017 05:13, Spencer Dawkins at IETF wrote: >>> >>> The bits where we can simply do what you suggest >>> >>>> Grrr, but please see below. >>>> >>>>> >>>>>> >>>>>> I'm really confused by this text. >>>>>> >>>>>> Nevertheless, when running within a secure ACP on reliable >>>>>> infrastructure, UDP MAY be used for unicast messages not exceeding >>>>>> the minimum IPv6 path MTU; however, TCP MUST be used for longer >>>>>> messages. In other words, IPv6 fragmentation is avoided. If a node >>>>>> receives a UDP message but the reply is too long, it MUST open a TCP >>>>>> connection to the peer for the reply. Note that when the network is >>>>>> under heavy load or in a fault condition, UDP might become >>>>>> unreliable. Since this is when autonomic functions are most >>>>>> necessary, automatic fallback to TCP MUST be implemented. The >>>>>> simplest implementation is therefore to use only TCP. >>> >>> Editor hat off. >>> >>> I agree. I think it's very naive to think that for this application, >>> intended to be used internally within an enterprise network, in >>> a NAT-free and proxy-free addressing realm, UDP has any value. >>> In fact, it's just a nuisance, since the programmer has to do a lot >>> of the work that TCP does. The performance gain, even if it's real, >>> is unimportant - autonomic traffic will be a tiny fraction of total >>> traffic. There will be no gain in footprint, since autonomic nodes >>> will carry full TCP stacks anyway. [If we wanted to put GRASP in >>> constrained nodes, we'd probably be talking about GRASP-over-COAP >>> anyway.] So here's what I would do: >>> >>> OLD >>> All other GRASP messages are unicast and could in principle run over >>> any transport protocol. An implementation MUST support use of TCP. >>> It MAY support use of another transport protocol. However, GRASP >>> itself does not provide for error detection or retransmission. Use >>> of an unreliable transport protocol is therefore NOT RECOMMENDED. >>> >>> Nevertheless, when running within a secure ACP on reliable >>> infrastructure, UDP MAY be used for unicast messages not exceeding >>> the minimum IPv6 path MTU; however, TCP MUST be used for longer >>> messages. In other words, IPv6 fragmentation is avoided. If a node >>> receives a UDP message but the reply is too long, it MUST open a TCP >>> connection to the peer for the reply. Note that when the network is >>> under heavy load or in a fault condition, UDP might become >>> unreliable. Since this is when autonomic functions are most >>> necessary, automatic fallback to TCP MUST be implemented. The >>> simplest implementation is therefore to use only TCP. >>> >>> NEW >>> All other GRASP messages are unicast and could in principle run over >>> any transport protocol. An implementation MUST support use of TCP. >>> It MAY support use of another transport protocol, but the details >>> are out of scope for this specification. However, GRASP itself does >>> not provide for error detection or retransmission. Use of an >>> unreliable transport protocol is therefore NOT RECOMMENDED. >>> END NEW >>> >>> That doesn't slam the door, but it removes what I now feel is >>> a very misleading paragraph. Of course, anybody is at liberty to >>> draft a full description of GRASP-over-UDP as a separate >>> document. >>> >>> Again, that was personal opinion. I won't edit that part of >>> the draft without community input. >>> >> >> Thanks, and I agree with not making changes unless there's community >> agreement. >> >> I do suspect that if UDP is not at least NOT RECOMMENDED, some developers >> may not use TCP at all. A quick Google search turned up e-mail from 2015 >> asking "if we REALLY have to support TCP in our (micro-)DNS server", and >> TCP to accommodate response TrunCation has been a requirement for DNS since >> at least RFC 1035 in 1987. >> >> But I don't know the future, of course. :D >> >> Spencer >> >> >>> Brian >>> >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Wed May 17 11:09:44 2017 Return-Path: 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 3889B12940E for ; Wed, 17 May 2017 11:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfbHXdbRyif1 for ; Wed, 17 May 2017 11:09:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68710129AAA for ; Wed, 17 May 2017 11:04:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 61D8A20183; Wed, 17 May 2017 14:31:37 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 51798636BB; Wed, 17 May 2017 14:04:53 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-Reply-To: <801850a1-bd98-e84a-f001-fb309d0d0288@gmail.com> References: <149421130029.23119.9372718991371280967.idtracker@ietfa.amsl.com> <801850a1-bd98-e84a-f001-fb309d0d0288@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Remove UDP text [ Spencer Dawkins' No Objection on draft-ietf-anima-grasp-11: (with COMMENT)] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 18:09:42 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > We need to resolve this issue quickly, to get a new draft out in the next > few days, before the IESG meeting next week. > So, since I haven't seen any opinions on the issue below, I propose to > delete the UDP paragraph as suggested below. Note that this does not > prevent us adding a UDP mode later, but it removes the confusion that we > have in the text today. So, we will (initially) support UDP for multicasted Link-Layer M_FLOOD and M_DISCOVER, but that's all. Everything else will be TCP. (In my opinion, inside the point to point mesh ACP, one might as well keep a single TCP connection up for every M_DISCOVER and M_FLOOD, as UDP has no advantage there) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkckMUACgkQgItw+93Q 3WUTdAf8DC/pgHuv/B/ozfaDrYJvSqYLP2xTIqCqL8raKgSoSMuZ7GFFgWTgNKaL 4lIdiFwHq2DzLKokJ+bhJ0qOBZ3fytClVuZSVy/KOx0GmgZroVtloDY1onr8vBDO 1Tp8e6QhyiOb7DseepaUvTn9hLL7700NvR7LA8usErSM0KKDo97f5azFQNO6CuM+ s+ZczcEhHexmfyQ40MOLBxYLC6B33Ja4Scj6Y/bHUJWs34PGj0Hs0wHBHCHOoEyO k8ccC5AsPEzdh+wyR7Mko1DiZ9FgGH+iPHou133mLbGlE32TY+ejq7uMtnQ49ImR RGC5HU6KNw8eQPAqA992a7CiFNFSww== =l8n1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 17 13:58:28 2017 Return-Path: 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 E594E124B0A for ; Wed, 17 May 2017 13:58:26 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Scb5YT3Fda2i for ; Wed, 17 May 2017 13:58:25 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 D304012441E for ; Wed, 17 May 2017 13:58:25 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id x64so12422755pgd.3 for ; Wed, 17 May 2017 13:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=P2Aiu0CEZ2HlF0Xz+NjFYM1WVmmCugKCG6DEnYKfSu4=; b=rAX4aAihDw0PLTicuY47OU2DRHPW4sp2hXXR3uCrhD8YqV4T+WjjdRlaH8FuYc41Qz OGe3Yz+DVr1E49Qg6OOzAAYK+CC1SuS7/UUKgX/CJkI7mxmQTnmC4AbOD/OcJDpuMSg4 WSqF9x/HDMyI1mdoD1gK02QuqSE9wTS3o7zAv0YWV02tcskF1/KIwjkU71apmOpiawGb SSeUJWiKwSBh0r3Dn4pLaCbhJGzPMhs/0ljfCfJZ4QFFv80f8D+IAgw6S2U3xP9vJbym uimi504uhQEe7xJhvhgVgQvBN2cqKFkB6GxjQMWQ9Dy7EmJQg4TTM7FeyfcpdkDKWrJk L78w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=P2Aiu0CEZ2HlF0Xz+NjFYM1WVmmCugKCG6DEnYKfSu4=; b=WKbTpUmPL6kb0EBo5Hos92rEAKyJYMzmakA/7SLtMLHc3/8slvWqMHhTSE5/D0v1i+ ezMelEuaH09/ppDdAI67T6GFcTaAt359TISD3FoYSNIKezOx55RC6awqXb9VtDt1z8Jh j+KP8pkRZn3fLtBNz6h8hkZuZ2NDfUt9OSOuTWvPOTnjfiEFtv2TQbjJoscpBstQRPTL 9DQS/HtsPK2YT4HZksLwVIsMzwQ+frniatk/Y7yf3GW+Zo/cKAPY33rhtmqPtMDIrgWz 8mAxo9JBXQ8IF5Q4AGV6KxyizdlKrzjKby0gEiCMsYsPtBWyFEu9tzCVaY2CMjV/VD8v 8rEw== X-Gm-Message-State: AODbwcBtyDLKARLeV81Vb1N+p2PkhY8KX0CvbTr9IOQvHUdmzXChyRHv J/k6NxkXjXDOhMrQ X-Received: by 10.99.56.66 with SMTP id h2mr801374pgn.40.1495054705285; Wed, 17 May 2017 13:58:25 -0700 (PDT) Received: from ?IPv6:2406:e007:765f:1:28cc:dc4c:9703:6781? ([2406:e007:765f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g20sm5712035pfk.21.2017.05.17.13.58.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 May 2017 13:58:24 -0700 (PDT) To: Michael Richardson References: <149421130029.23119.9372718991371280967.idtracker@ietfa.amsl.com> <801850a1-bd98-e84a-f001-fb309d0d0288@gmail.com> <16993.1495044293@obiwan.sandelman.ca> Cc: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 18 May 2017 08:58:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <16993.1495044293@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Remove UDP text [ Spencer Dawkins' No Objection on draft-ietf-anima-grasp-11: (with COMMENT)] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 20:58:27 -0000 On 18/05/2017 06:04, Michael Richardson wrote: > > Brian E Carpenter wrote: > > We need to resolve this issue quickly, to get a new draft out in the next > > few days, before the IESG meeting next week. > > > So, since I haven't seen any opinions on the issue below, I propose to > > delete the UDP paragraph as suggested below. Note that this does not > > prevent us adding a UDP mode later, but it removes the confusion that we > > have in the text today. > > So, we will (initially) support UDP for multicasted Link-Layer M_FLOOD and > M_DISCOVER, but that's all. Everything else will be TCP. Until we write a profile for GRASP-over-UDP or GRASP-over-DECnet or whatever we want. The GRASP protocol model doesn't really care. > (In my opinion, inside the point to point mesh ACP, one might as well keep a > single TCP connection up for every M_DISCOVER and M_FLOOD, as UDP has no > advantage there) As long as it behaves like a multicast, it really doesn't matter how the ACP chooses to implement it. For a stand-alone specification of GRASP, I don't see how else to specify it, though. Brian From nobody Thu May 18 11:32:33 2017 Return-Path: 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 A6F2A1270AC for ; Thu, 18 May 2017 11:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 sqf97PGz0KSe for ; Thu, 18 May 2017 11:32:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02C6129AAD for ; Thu, 18 May 2017 11:27:26 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id EAE19203B5 for ; Thu, 18 May 2017 14:54:12 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 61D6B636E0 for ; Thu, 18 May 2017 14:27:25 -0400 (EDT) From: Michael Richardson To: anima@ietf.org X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] [Cbor] FYI: JSON Constrained Notation (fwd) Peter Saint-Andre - Filament: [Cbor] FYI: JSON Constrained Notation X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 18:32:32 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain So, this proposes to use CBOR to "compress" JSON, preserving JWT/JOSE signatures, rather than using CWT. I'm not sure what I think of this as yet. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=168 Content-Description: forwarded message Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3::184] by obiwan.sandelman.ca with IMAP (fetchmail-6.3.26) for (single-drop); Thu, 18 May 2017 14:23:57 -0400 (EDT) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus v2.4.16-Debian-2.4.16-4+deb7u2) with LMTPA; Thu, 18 May 2017 13:23:21 -0400 X-Sieve: CMU Sieve 2.4 Received: from colo19.roaringpenguin.com (unknown [IPv6:2604:1f80:1:478::19]) by tuna.sandelman.ca (Postfix) with ESMTPS id EEBFE203C8; Thu, 18 May 2017 13:23:20 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by colo19.roaringpenguin.com (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v4IGuVtm018167 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 May 2017 12:56:32 -0400 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F7F12EB73; Thu, 18 May 2017 09:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1495126591; bh=7E5ES8nqt9RLTKuj0h31vBwaX+gjmlV/VOvHH4QV7Co=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=wZJ/VtAktNV3/KTDKhw2uBsQloSNNsyc+1NTPdIdgNXoUfRs4Mz2+oUbn5DcEEYom XlEIygN/NzQbYvdYE+S6bZnUDBNAcykgdC7jTpxUwJi+cjd6lxgZpIcwgonn1qgFno 9yaanDaA7v5g2jUuvWGiiyg5rXZlyCOESTdo8biI= X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6672B129B98 for ; Thu, 18 May 2017 09:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Score: 0.00 () [Hold at 5.10] HEADER_FROM_DIFFERENT_DOMAINS:0.001,SPF(pass:0),DKIM(pass:0),DMARC(DMARC_POLICY_PASS) X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=filament-com.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 yiu8tNfkXUho for ; Thu, 18 May 2017 09:56:27 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 2EED012EB4A for ; Thu, 18 May 2017 09:50:36 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id e65so31843052ita.1 for ; Thu, 18 May 2017 09:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:cc:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=yzkhS/oU0BK7crDewMjcmjH7JS+p/86JRLlDkRxckXc=; b=qR2/DYugGsGcyD3zsDKtzMUcBXlJLWGwhWqKQAQvuKPe0QcgU+qHG2IjZg+mfoyrD3 I2ulqTlYG9EWNUO9we20R1zdhgrDZbPR4gW8vsm2VgEhsMbOF72jvcofuYfc1e0+29ii cvz0DokjlWFLwffxvCrdk9cQ0ML6104PiVme3DwCif74ciojjUhTQpzPscdx6oud5qUr SCSBlGehOi9GcgaWvjfdEL+RXYWGIE0faoVpE2OqUozeU9ZHOme3RNtXcIigxVi4Mwdp 8zgB55XPLySyzkuhLMA7kYVGOb4aRaZB8Tx7w/CzDgCeoL7uUKNX64N3A4NTvGhZD3f2 r/XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:cc:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=yzkhS/oU0BK7crDewMjcmjH7JS+p/86JRLlDkRxckXc=; b=DRZeR4n/8pinLOEN6d0nZSDrKd1kn2j+AAK+PXOopLE4ZI4UizOcJg3ISISNo3HYwn +1BKYb4kEtn9cWpu2Az5Necxb6lZX4e32u6rVuaE6ykAvVHWjZ100D0uXsZcvbFF29aq UdPK3xeFKqH5Ct81FQFzm2G0grR8DPaCU/hKWTM04+PWhL27QT4rubuUWSy5712w/eX3 0tkEcHPSn7kwjWlwOnzin+VwJyxzRuvkx+rmp+KfA1LfUnS7pvz+hqddWZvJqbskepmu Yuk65alCioYAAsMSpktbpMvxqokmJw3sBjoA8kHVj7b2zVpaMbZ0upSZCzP/p0CnhCvB rSew== X-Gm-Message-State: AODbwcCbutrthMfOwatKT4EPutjaAtCyIroqbhsvnJ4TRVvqV1JHizBO iJ1JwvcEE5GWtkyEXURMyQ== X-Received: by 10.36.150.193 with SMTP id z184mr5481280itd.89.1495126235557; Thu, 18 May 2017 09:50:35 -0700 (PDT) Received: from aither.local ([2601:282:4202:67d3:5008:a309:499a:146f]) by smtp.gmail.com with ESMTPSA id n22sm2670629itg.25.2017.05.18.09.50.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 09:50:34 -0700 (PDT) To: cbor@ietf.org, ace@ietf.org, json@ietf.org, jose@ietf.org From: Peter Saint-Andre - Filament Message-ID: Date: Thu, 18 May 2017 10:50:33 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Archived-At: Subject: [Cbor] FYI: JSON Constrained Notation X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jeremie Miller Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cbor-bounces@ietf.org Sender: "CBOR" X-Bayes-Prob: 0.0001 (Score 0, tokens from: mcr, @@RPTN) X-CanIt-Geo: ip=4.31.198.44; country=US; latitude=37.7510; longitude=-97.8220; http://maps.google.com/maps?q=37.7510,-97.8220&z=6 X-CanItPRO-Stream: sandelman-ca:mcr (inherits from sandelman-ca:default,rp-01:default,base:default) X-Canit-Stats-ID: 0gTlQUwrf - 947866f04a04 - 20170518 X-Antispam-Training-Forget: https://antispam.roaringpenguin.com/canit/b.php?c=f&i=0gTlQUwrf&m=947866f04a04&rlm=sandelman-ca&t=20170518 X-Antispam-Training-Nonspam: https://antispam.roaringpenguin.com/canit/b.php?c=n&i=0gTlQUwrf&m=947866f04a04&rlm=sandelman-ca&t=20170518 X-Antispam-Training-Phish: https://antispam.roaringpenguin.com/canit/b.php?c=p&i=0gTlQUwrf&m=947866f04a04&rlm=sandelman-ca&t=20170518 X-Antispam-Training-Spam: https://antispam.roaringpenguin.com/canit/b.php?c=s&i=0gTlQUwrf&m=947866f04a04&rlm=sandelman-ca&t=20170518 X-CanIt-Archive-Cluster: irqpXI7aJGyo4Ewta7qVH399FOg Received-SPF: pass (colo19.roaringpenguin.com: domain of cbor-bounces@ietf.org designates 4.31.198.44 as permitted sender) receiver=colo19.roaringpenguin.com; client-ip=4.31.198.44; envelope-from=; helo=mail.ietf.org; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) [Cross-posted to ACE, CBOR, JOSE, JSON because it might be of interest to folks on all four lists.] Folks here might have an interest in an I-D that Jeremie Miller and I just submitted, defining a set of mapping rules from JSON to CBOR that preserves all semantic information. The intent is to use the JOSE standards (and related work such as OpenID Connect) unmodified in constrained environments. https://tools.ietf.org/html/draft-miller-json-constrained-notation-00 For now, please send feedback directly to the authors. Thanks! Peter -- Peter Saint-Andre https://filament.com/ _______________________________________________ CBOR mailing list CBOR@ietf.org https://www.ietf.org/mailman/listinfo/cbor --=-=-= Content-Type: text/plain -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkd540ACgkQgItw+93Q 3WWDKQgAsuUoywve7O+mDPKNZ4xK1dEcjq7ZFQi2GT+Loz017sFAYF7MjDYWbJVO gh5xIvzwaLTt7Shg+ZeyIyD9KJq6OLA91upwTR1aknhuNnEjZ3g8eJ7lioJ1n5b7 wR5ggJj6uTUFkBvejOdLq0PmYCPquWz5p6dAaPUh5kUXoNM81zsFWwjOI3Oa4Igx KgxTl706LbmW8xoKEyOC+ap+BK4zE1sxtCy+BOU+x022+4oadHwaf2eLURNE/xz4 NxmoT1JNxr8okNmNyEullIQI6a/KF4npBW9MncFjv7E8VFPftk4LuzHlu7D5dh69 4Qfwf7065trZKfjP38x07lSfBYgXPQ== =Bm60 -----END PGP SIGNATURE----- --==-=-=-- From nobody Thu May 18 12:08:40 2017 Return-Path: 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 B101D124C27 for ; Thu, 18 May 2017 12:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 SIsKAjwspgoR for ; Thu, 18 May 2017 12:08:36 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 04F9612EB9B for ; Thu, 18 May 2017 12:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v4IJ2LW9003807; Thu, 18 May 2017 21:02:21 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wTLCd0WJJzDGq3; Thu, 18 May 2017 21:02:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <2304.1495132045@obiwan.sandelman.ca> Date: Thu, 18 May 2017 21:02:19 +0200 Cc: anima@ietf.org X-Mao-Original-Outgoing-Id: 516826939.16344-9f924d0dfc13782b2a4adb400d9200cd Content-Transfer-Encoding: quoted-printable Message-Id: <69ABCD80-D844-4C2B-B492-A8E806FAA9DA@tzi.org> References: <2304.1495132045@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Anima] [Cbor] FYI: JSON Constrained Notation (fwd) Peter Saint-Andre - Filament: [Cbor] FYI: JSON Constrained Notation X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 19:08:39 -0000 > On May 18, 2017, at 20:27, Michael Richardson = wrote: >=20 >=20 > So, this proposes to use CBOR to "compress" JSON, preserving JWT/JOSE > signatures, rather than using CWT. I'm not sure what I think of this = as yet. My summary: JSCN is great if you actually *have* to process = JOSE-signed/-encrypted material (such as JWTs) on a device on a = constrained network. JSCN is more compact than pure JOSE. It does, = however, carry all the complexity that JSON brings with it down to the = device: You need to reconstruct actual JSON to generate the signing = inputs. If the source of the protected material can be made constrained-aware, = COSE and CWTs are the better choice. One of the objectives of the = two-tier architecture of constrained/less-constrained devices is to keep = as much of the business logic and complexity up in the less-constrained = devices, which then provide simple, unambiguous instructions to the = constrained devices. But even if you don=E2=80=99t have that = architecture, in a new protocol you can avoid the complexity that would = limit coverage of low-resource, low-energy devices. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 18 16:18:49 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 184EA126E3A; Thu, 18 May 2017 16:18:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149514952704.6683.4476380701346049589@ietfa.amsl.com> Date: Thu, 18 May 2017 16:18:47 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-grasp-12.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 23:18:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : A Generic Autonomic Signaling Protocol (GRASP) Authors : Carsten Bormann Brian Carpenter Bing Liu Filename : draft-ietf-anima-grasp-12.txt Pages : 78 Date : 2017-05-18 Abstract: This document establishes requirements for a signaling protocol that enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with them, and to negotiate parameter settings with them. The document then defines a general protocol for discovery, synchronization and negotiation, while the technical objectives for specific scenarios are to be described in separate documents. An Appendix briefly discusses existing protocols with comparable features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-grasp-12 https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 18 16:30:59 2017 Return-Path: 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 CA5C5129474; Thu, 18 May 2017 16:30:57 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pu3OtHtREpQV; Thu, 18 May 2017 16:30:55 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 741CD129B18; Thu, 18 May 2017 16:26:04 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id 9so30825516pfj.1; Thu, 18 May 2017 16:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=9nVMUhUieHLjft2Iq7OM4qggHkCi4lQDq+VwY8GtnvY=; b=ZLAEn51S46Jkdl+aat9hFj8PSpY4DRXU848D33ea0OorkaUB93hXBXE1h9Jt78sTww rPmjxaA5Cnh4CpvYyxbGVxeU6u8KSb3QJqtX1ZNcEDpCacezgYTIKPV6jAVaqBJdGiQW Gcnnzpu9u5GCvkn0iuuwcIt0xGsJI67A45zucpxPcwezk4OicfFk5gx60CqgES7zgGes fnUFRQ7F5iKjOYepqf1a2WhfOkE356S0AJRYatd0N8UVAc8VDPNIGw10utlRjvYSMn1Y mxqSYxXEaq6AmbvcuOrJyrvH8ykx2kXSvIGLw9oLUxc6/kOGDxD3MTSYU16xpgDMeO+F J6Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=9nVMUhUieHLjft2Iq7OM4qggHkCi4lQDq+VwY8GtnvY=; b=irA4h72fAWEerhIwr/AdKuI/ck8svQq2irwBUHQYryA2pB+RU83kzwWY/45O1Iw5RQ 007VcWehbRMYRiXK2mytSLr4jap0nhJltQ3oo1IEfZedRMlyh3/rqb0fiKkrv6uA5rII XFrreetDtAnMfvg46CqdEOreEcnDRIUe+YBChGfGAW0UDJoi99CuDZXWpgUv4PihYKwc dgIvTFHfI8OklxewIlzzCcwYFSyG5LKSzcQ1NdqMT87etLgUBopq9N7LMfxpJxgZ5HKH gcL3tT/SqKTlJQl/dHHmIdwQtx5h4wKy0i2s7tPnoOJJDmBThOSpVbzPoqYYp59Xqrba wxMA== X-Gm-Message-State: AODbwcDktIHbZRX6XvFCiZSyHQNuDWj+gj/nfQ1Hh5wsB0oCXZjqhbrs EpBS1N58ZIM5LxLJ X-Received: by 10.98.141.199 with SMTP id p68mr7189794pfk.55.1495149963814; Thu, 18 May 2017 16:26:03 -0700 (PDT) Received: from ?IPv6:2406:e001:3fa8:1:28cc:dc4c:9703:6781? ([2406:e001:3fa8:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p13sm12575685pfl.52.2017.05.18.16.26.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 16:26:03 -0700 (PDT) References: <149514952704.6683.4476380701346049589@ietfa.amsl.com> To: anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <9233ce4c-6c17-ffc9-9f88-1493edca1a74@gmail.com> Date: Fri, 19 May 2017 11:26:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149514952704.6683.4476380701346049589@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-12.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 23:30:58 -0000 Hi, This version is intended to deal with the IESG comments and late reviews so far. The changes are: Clarified that GRASP runs in a single addressing realm Improved wording about FQDN resolution, clarified that URI usage is out of scope. Clarified description of negotiation timeout. Noted that 'dry run' semantics are ASA-dependent. Made the ACP a normative reference. Clarified that LL multicasts are limited to GRASP interfaces. Unicast UDP moved out of scope. Note that there is one idnits warning: Downref: Normative reference to an Informational draft: draft-greevenbosch-appsawg-cbor-cddl which is expected to become standards track in the CBOR WG. Regards Brian On 19/05/2017 11:18, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. > > Title : A Generic Autonomic Signaling Protocol (GRASP) > Authors : Carsten Bormann > Brian Carpenter > Bing Liu > Filename : draft-ietf-anima-grasp-12.txt > Pages : 78 > Date : 2017-05-18 > > Abstract: > This document establishes requirements for a signaling protocol that > enables autonomic nodes and autonomic service agents to dynamically > discover peers, to synchronize state with them, and to negotiate > parameter settings with them. The document then defines a general > protocol for discovery, synchronization and negotiation, while the > technical objectives for specific scenarios are to be described in > separate documents. An Appendix briefly discusses existing protocols > with comparable features. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-anima-grasp-12 > https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-12 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri May 19 10:43:20 2017 Return-Path: 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 3C35F129458 for ; Fri, 19 May 2017 10:43:19 -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=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LI40UfRwWRDp for ; Fri, 19 May 2017 10:43:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F40E1287A7 for ; Fri, 19 May 2017 10:43:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DDAB220183; Fri, 19 May 2017 14:10:06 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 10D51636E0; Fri, 19 May 2017 13:43:16 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: anima@ietf.org In-Reply-To: <69ABCD80-D844-4C2B-B492-A8E806FAA9DA@tzi.org> References: <2304.1495132045@obiwan.sandelman.ca> <69ABCD80-D844-4C2B-B492-A8E806FAA9DA@tzi.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [Cbor] FYI: JSON Constrained Notation (fwd) Peter Saint-Andre - Filament: [Cbor] FYI: JSON Constrained Notation X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 17:43:19 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> So, this proposes to use CBOR to "compress" JSON, preserving JWT/JOSE >> signatures, rather than using CWT. I'm not sure what I think of thi= s as yet. > My summary: JSCN is great if you actually *have* to process > JOSE-signed/-encrypted material (such as JWTs) on a device on a > constrained network. JSCN is more compact than pure JOSE. It does, > however, carry all the complexity that JSON brings with it down to the > device: You need to reconstruct actual JSON to generate the signing > inputs. Agreed. > If the source of the protected material can be made constrained-aware, > COSE and CWTs are the better choice. One of the objectives of the > two-tier architecture of constrained/less-constrained devices is to > keep as much of the business logic and complexity up in the > less-constrained devices, which then provide simple, unambiguous > instructions to the constrained devices. But even if you don=E2=80= =99t have > that architecture, in a new protocol you can avoid the complexity that > would limit coverage of low-resource, low-energy devices. I agree. I see it easier to teach non-constrained devices new tricks. I'm not convinced we can use any of the deployed JOSE infrastructure *completely* unchanged, so as long as changes are needed... =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkfLrMACgkQgItw+93Q 3WVe0wf8Dln/vTkbaOdff14JTW8xnLf3aiKxamMZpD/Z8T+fubtP85V3Iamyb+gR ge3kqoDX4Yf/T9ZQqd0NRkCGMqHGQ+m7itonwtv4uNDwW4Op90fuDwh/FrC47muq eyVY32UYtddufPIZt9gAkW9RDOBwhg0625Ec7GdBXF0oSrrqM+Pr1dhDdB/Su+/2 Zw5fIFKThc5/8q3J+/a1pgBFRx6dhJMHXl16u+PRFsfejG5EOdf6+e8IFgBj2/gg H3651nrRKWa7z2RWxpiLhFdHB9hw5jerTtZjLhc2z5R6h+gkfeB63b1DHyMeCpKY mvwxGpUVpiGRcfq9N7HlMucteqwvow== =ZcFz -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 19 14:47:15 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB10128961; Fri, 19 May 2017 14:47:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: draft-ietf-anima-grasp.all@ietf.org, ietf@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149523043416.21589.9385334747760332010@ietfa.amsl.com> Date: Fri, 19 May 2017 14:47:14 -0700 Archived-At: Subject: [Anima] Genart telechat review of draft-ietf-anima-grasp-12 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 21:47:14 -0000 Reviewer: Joel Halpern Review result: Ready 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-anima-grasp-?? Reviewer: Joel Halpern Review Date: 2017-05-19 IETF LC End Date: 2017-03-02 IESG Telechat date: 2017-05-25 Summary: This document is still ready for publication as a Proposed Standard RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A From nobody Sat May 20 15:51:55 2017 Return-Path: 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 97D3E12717E for ; Sat, 20 May 2017 15:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzKjr6TEaav0 for ; Sat, 20 May 2017 15:51:53 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::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 54D7F1200F1 for ; Sat, 20 May 2017 15:51:53 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id u187so52454248pgb.0 for ; Sat, 20 May 2017 15:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=mbK+U/lmZHGccWMdeBTBlMM9OSmXo6E60488CSDkfXU=; b=boiQ28HPez586hJex5gdtcOLhk1bvCpzTZ7gQPb2/w+pv2ARl2Hgvdx6uLdUomxp6T R4zCQZK37g4MIGyczAsREtMSTRPNtYk0yKLl/e+2WHGKY1XYOmjFh12T9A9skuUB6yvj DuEbGWDCsDIf3xGsGoWtLFn7NZ8olr5ccyVU9nL845Vs+NLhrPHMU2CeRjrm/wnrfHr2 7LYzV2qNFVju1DR1uDewJyfGeyH8AHZyWWXP70BcJM+E8zae+6Ewc5Lanb8qcEGaAoHJ 5WTpMVLJ9+4gvYv0n9PiqW6bp83m0Wm2ut30DDlu4PXwrgYuzZQmgCkfgBsYmkSumXi1 fYug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=mbK+U/lmZHGccWMdeBTBlMM9OSmXo6E60488CSDkfXU=; b=mjGvzrk9CTusXAsPKSKHbZnlbxKNp25hJjTUlUY1FLLQ6dqscY89AqBtCf7/vyy/Tu muSYPiUa74bbjSkU1oLm7lZsinfaYp+CLmeJ/zoQ21+pHEMer0N3xe3C/UgKpB3cp2EM B4mSCTTZB0QGFuAB9BQwZQE2nq590Ch5MG8CV7rssbJ28V4s1LE2Zs7hIlLCPoGr1Res NUHsnSgbKht95W2jP/0LdVlMNUQxegmObkOms9EIL461BVECN3wu/HcPvn984goO/9G7 wEfVz4ZcWM/CBXoL5c2d/XCRMC+yihaWg22w6CaQBaKiJvBRCi6lTZ/YfE1w5LTGl1/N ldxg== X-Gm-Message-State: AODbwcAVOOUcYXyY60dm95kz5oIUMKA1VD66d4smOz7g4Mdt/F2j3P4x sZmi8hjD5u9wAQ== X-Received: by 10.99.167.75 with SMTP id w11mr17456798pgo.148.1495320712855; Sat, 20 May 2017 15:51:52 -0700 (PDT) Received: from ?IPv6:2406:e007:6ad6:1:28cc:dc4c:9703:6781? ([2406:e007:6ad6:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 66sm22318887pgd.47.2017.05.20.15.51.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 May 2017 15:51:51 -0700 (PDT) To: Anima WG , Terry Manderson , Sheng Jiang , tte+anima@cs.fau.de From: Brian E Carpenter Organization: University of Auckland Message-ID: <192aefd6-1c4e-57e8-bdcb-71fd130248a4@gmail.com> Date: Sun, 21 May 2017 10:51:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Last minute glitch in draft-ietf-anima-grasp X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2017 22:51:54 -0000 Hi, This is embarrassing since the GRASP draft is already with the IESG, but better now than later. Bill Atwood has been testing the GRASP prototype on a larger setup than previously, and this has just thrown up an issue in discovery relaying. (We tried to do this test at the IETF98 hackathon, but failed for practical reasons.) The issue is minor in terms of words but really needs to be fixed. Consider the following two extracts: > 3.5.4.4. Discovery Relaying ... > Since the relay device is unaware of the timeout set by the original > initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEOUT > milliseconds. > 3.8.5. Discovery Response Message ... > It MUST contain a time-to-live (ttl) for the validity of the > response, given as a positive integer value in milliseconds. Zero > is treated as the default value GRASP_DEF_TIMEOUT (Section 3.6). This is exactly the wrong way round. The TTL for a discovery response needs to be *longer* than the timeout for a (relayed) discovery. If not, the TTL will expire before the relayed discovery completes. This is really an implementation issue but the above text almost guarantees failure. Proposed new text, which intentionally leaves the details for the implementer: > Since the relay device is unaware of the timeout set by the original > initiator it SHOULD set a timeout significantly less than GRASP_DEF_TIMEOUT > milliseconds. ... > It MUST contain a time-to-live (ttl) for the validity of the > response, given as a positive integer value in milliseconds. Zero > implies a value significantly greater than GRASP_DEF_TIMEOUT > milliseconds (Section 3.6). WG Chairs and AD: I will be on personal travel between now and the IESG call on Thursday, so it isn't really possible to post a new draft in time. Regards Brian From nobody Mon May 22 07:56:10 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CD012EADB; Mon, 22 May 2017 07:56:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149546496854.22634.10171422829527352746.idtracker@ietfa.amsl.com> Date: Mon, 22 May 2017 07:56:08 -0700 Archived-At: Subject: [Anima] Warren Kumari's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 14:56:08 -0000 Warren Kumari has entered the following ballot position for draft-ietf-anima-grasp-12: 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-anima-grasp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Firstly, thank you for addressing Joel's OpsDir review. As others have noted, this is a long document :-) I think that, in spite of this, it is very well written.... These comments were written against v-11, but I think are still applicable to -12. Section 2.1, D1: "... the protocol can represent and discover any kind of technical objective ..." While the document *does* say that readers should be familiar with RFC7575, RFC7576, and I-D.ietf-anima-reference-model, I think it would still be helpful to (briefly) describe an objective here, or simply mention that "technical objective" is a term of art and point to the Terminology section (or Sec. 3.10). When I initially read this it sounded incredibly broad, once I found the Terminology section it all made more sense... S2.2. Requirements for Synchronization and Negotiation Capability "SN5. ... It follows that the protocol’s resource requirements must be appropriate for any device that would otherwise need human intervention." I found this sentence confusing / hard to parse. I *think* that you are saying that the protocol should not require so many resources that it cannot be deployed on devices (and so humans would still need to manually manage them)? If so, I think that this could be clearer, but, unfortunately I cannot provide better text... 3.2. High Level Deployment Model "A more common model is expected to be a multi-purpose device capable of containing several ASAs." I'm sure you are right... but for a reader new to the topic this is not obvious (nor clear) - would it be possible to provide some sort of examples of such devices (or brief description of why a more common model would have several ASAs?) E.g: "multi-purpose device capable of containing several ASAs (such as a router or large switch)" (or whatever...) "..it is essential that every implementation is as robust as possible." -- this sounds suspiciously like "Don't write bad code...". What is the purpose if this statement? Do you think that it will somehow make people write better / more robust code? If so, shouldn't this be in our standard boilerplate? This whole paragraph feels like it is not actionable / is something that all code for all implementations of everything should follow... (I have a horrible feeling that I'm heading off on a soapbox rant / that this is a pet-peeve...) From nobody Mon May 22 09:08:50 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA8B12EB14; Mon, 22 May 2017 09:08:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149546932237.14094.15015791485171985477.idtracker@ietfa.amsl.com> Date: Mon, 22 May 2017 09:08:42 -0700 Archived-At: Subject: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 16:08:42 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-anima-grasp-12: Discuss 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-anima-grasp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a small list of issues that I would like to discuss before recommending approval of this document: 1) The first reference to UTF-8 needs a Normative reference to RFC 3629. 2) In Section 3.10.1, you say: The names of generic objectives MUST NOT include a colon (":") and MUST be registered with IANA (Section 7). In Section 7 you only say: GRASP Objective Names Table. The values in this table are UTF-8 strings. Future values MUST be assigned using the Specification Required policy defined by [RFC5226]. IANA is not going to review section 3.10.1 and there is no back reference in Section 7. IANA needs to know that values with ":" are not to be registered. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As a general comment, the document has several SHOULD/MUST level requirements which are sometimes addressed at people deploying the protocol, sometimes at UI designers and sometimes at designers of new objectives. I generally don't mind, but the document doesn't always make it clear what is the intended audience for different requirements. Other smaller things: "Fully Qualified Domain Name" probably needs a Normative Reference. 3.5.4.3. Discovery Procedures In 6th para: The cache mechanism MUST include a lifetime for each entry. The lifetime is derived from a time-to-live (ttl) parameter in each Discovery Response message. Cached entries MUST be ignored or deleted after their lifetime expires. In some environments, unplanned address renumbering might occur. In such cases, the lifetime SHOULD be short compared to the typical address lifetime and a mechanism to flush the discovery cache MUST be implemented. How can the discovery cache be flushed? 3.9.5.4. Locator URI option In fragmentary CDDL, the URI option follows the pattern: uri-locator = [O_URI_LOCATOR, text] I suggest inclusion of optional transport protocol here to match other locators and to follow best practices for not encoding transport information in URIs. From nobody Mon May 22 13:14:47 2017 Return-Path: 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 A5F6F124BE8 for ; Mon, 22 May 2017 13:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 18YAS5XZKGrX for ; Mon, 22 May 2017 13:14:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7274120727 for ; Mon, 22 May 2017 13:14:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 05814200A3; Mon, 22 May 2017 16:41:44 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3873D636E0; Mon, 22 May 2017 16:14:42 -0400 (EDT) From: Michael Richardson To: Kent Watsen cc: "Max Pritikin \(pritikin\)" , "anima\@ietf.org" In-Reply-To: <5DB4ED7C-3427-4AE0-B2C7-4A44D5F8D235@juniper.net> References: <88FB0F4F-2816-4BCE-A775-EBEE1CFCC0CD@juniper.net> <5DB4ED7C-3427-4AE0-B2C7-4A44D5F8D235@juniper.net> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [Anima-bootstrap] Voucher signing method X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 20:14:46 -0000 --=-=-= Content-Type: text/plain Kent Watsen wrote: > BTW, ES256 uses the P-256 curve (aka secp256r1) which has since been > deprecated. I got a kick out of RFC 7518 giving it a "recommended+" > rating ;) Yeah, in my work, I've had to sue secp256r1 because the examples are in that, and the libraries are up-to-date for it. But I'd rather be using Ed25519: it becomed bleeding edge work. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkjRrEACgkQgItw+93Q 3WXglQf9FrgBv6MBVWFxvMnqmbxlJ0iOhiUMIQ8ITLvNSolHG7MgLONctj50l22J b6JXDPkOIhJqCJahyo7VrI3fYYL8xgf+EeY01Ahlc7bRx7BV5wzgxDPoP/t+pwhm d/ne8HnAHHSInhAdzpvqdNf6RxEvuZmGRwcFp1cE+4xW3QZbuNgN1aJN986dJ3jg 2MP4Ka15uZWSbf131Wa6xKiGw5nMOPjQPTYbFLLGgFBwK/XR+ZEvYdttEuNd3MxB yNe2AY4s91jx1IuBGlfkZLGonA4WZrAxW76DiUKvkI3Ed8IB96aISr3Yy5KhJjnA lzqpxEFUqh4vYZ/xaKsGBap5xeaRzA== =JMn6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 22 13:50:24 2017 Return-Path: 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 2A7AB128B8D; Mon, 22 May 2017 13:50:16 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkeC1gVnsC6r; Mon, 22 May 2017 13:50:14 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 349F9128AB0; Mon, 22 May 2017 13:50:14 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id n23so22353701pfb.3; Mon, 22 May 2017 13:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Gk9jEweTm4EJfvtnsTNZzoENjVMMzyfCb7b+V8YdY4Q=; b=FrPK6cG2WV3PiTQs1O+o/UfAWgPSNHNg2b3tbfK3MK0/8+UIKAReVY2saHzdJCtlWe 7wuyXRJCgk8HrA4T/26AlGxVWWYhOwoA2zWa6capgC5n9h8WQuE4t9hybTRbeobFa6pB Uaiync2j5SpLOiR34ewVrzFUSYeDiSojaL5EKr8abH7X6uNUAgVIaL3+3wiLRNcEECrf o1OHp2OvytTmllBNY8jLcslidMqQ8wRwGxqaNufmxQ2Z1glWQg5O5iqQuGyhkTZwnZjY eZGxM+omjIaDnh4lOLtrDuzzXx8LB27yFBD+yG6BobTBc5prbiVXNJk6Y/ITwpxNuYJq Ysqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Gk9jEweTm4EJfvtnsTNZzoENjVMMzyfCb7b+V8YdY4Q=; b=CbpASeSkiCboaEg+MvjZem6ch5YooByd6feOvb4UPV+XdhX0fbOYqHfSG9I9XgivGV phJTUh+p0agudrFjkz+TpkbmPXlQLpAgkwWwFMPnKp/LN0TUSUpJokK09hcItwZV5sWW XThnalQh3GPoefWnGAYhvriNpA0yrJHFVSGUm9xQNzGIWbh2vSi2Yvnd8xK2FVugA++H Q9+jF7pxQixgeml4PSN1VtdPvWx/weMTaRHKzpJPU2nuId9hn9hg9NTnCzdJpaB1aWWx 06Atb7N2i22w2/9Y314GesBF8/h/FPtaGlO9Pc5EtHJBNhDeSYmcu4rii5BZpV+TRF5A ddVw== X-Gm-Message-State: AODbwcBD+Kg3oWZm7Nb4/QNunVAm3FWa6CnnkfrNmdkQT6VKqtmqG89q QXq9hIh+R0p5LA== X-Received: by 10.84.151.3 with SMTP id i3mr31255597pli.81.1495486213730; Mon, 22 May 2017 13:50:13 -0700 (PDT) Received: from [10.100.103.42] (210-55-57-56.adsl.xtra.co.nz. [210.55.57.56]) by smtp.gmail.com with ESMTPSA id q64sm38515061pfi.69.2017.05.22.13.50.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 May 2017 13:50:12 -0700 (PDT) To: Alexey Melnikov , The IESG Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149546932237.14094.15015791485171985477.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <8c6c74dc-14ee-d384-ea24-684d7ff43e4a@gmail.com> Date: Tue, 23 May 2017 08:50:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149546932237.14094.15015791485171985477.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 20:50:16 -0000 Hi Alexy, All your DISCUSS comments are valid and easy to fix. Unfortunately I'm on personal travel this week so can't update until next week. Assuming we need a new version, we will of course also review your and other's COMMENT comments. Specifically, > uri-locator = [O_URI_LOCATOR, text] > > I suggest inclusion of optional transport protocol here to match other > locators and to follow best practices for not encoding transport > information in URIs. I have no objection to that but since it's a (minor) protocol change we would definitely need to run it by the WG. Thanks Brian On 23/05/2017 04:08, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-anima-grasp-12: Discuss > > 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-anima-grasp/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have a small list of issues that I would like to discuss before > recommending approval of this document: > > 1) The first reference to UTF-8 needs a Normative reference to RFC > 3629. > > 2) In Section 3.10.1, you say: > > The names of generic objectives MUST NOT include a colon (":") and > MUST be registered with IANA (Section 7). > > In Section 7 you only say: > > GRASP Objective Names Table. The values in this table are UTF-8 > strings. Future values MUST be assigned using the Specification > Required policy defined by [RFC5226]. > > IANA is not going to review section 3.10.1 and there is no back reference > in Section 7. IANA needs to know that values with ":" are not to be > registered. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > As a general comment, the document has several SHOULD/MUST level > requirements which are sometimes addressed at people deploying the > protocol, sometimes at UI designers and sometimes at designers of new > objectives. I generally don't mind, but the document doesn't always make > it clear what is the intended audience for different requirements. > > Other smaller things: > > "Fully Qualified Domain Name" probably needs a Normative Reference. > > > 3.5.4.3. Discovery Procedures > > In 6th para: > > The cache mechanism MUST include a lifetime for each entry. The > lifetime is derived from a time-to-live (ttl) parameter in each > Discovery Response message. Cached entries MUST be ignored or > deleted after their lifetime expires. In some environments, > unplanned address renumbering might occur. In such cases, the > lifetime SHOULD be short compared to the typical address lifetime > and > a mechanism to flush the discovery cache MUST be implemented. > > How can the discovery cache be flushed? > > > 3.9.5.4. Locator URI option > > In fragmentary CDDL, the URI option follows the pattern: > > uri-locator = [O_URI_LOCATOR, text] > > I suggest inclusion of optional transport protocol here to match other > locators and to follow best practices for not encoding transport > information in URIs. > > > From nobody Mon May 22 15:40:59 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7401293EE; Mon, 22 May 2017 15:40:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> Date: Mon, 22 May 2017 15:40:51 -0700 Archived-At: Subject: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 22:40:52 -0000 Adam Roach has entered the following ballot position for draft-ietf-anima-grasp-12: 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-anima-grasp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The document includes a couple of instances of "reasonable" in normative statements (e.g., "reasonable timeout"). I would strongly recommend having specific recommendations in the document where this happens. The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, but no way to register additional values with IANA. This does not seem future-proof. Section 3.8.4 talks about behavior when a node has a "globally unique address," but provides no guidance for detecting this. Are nodes expected to check for link-local, zeroconf, RFC 1918, and RFC 6598 addresses? Any others? From nobody Mon May 22 18:25:31 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 561E41294A3; Mon, 22 May 2017 18:25:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> Date: Mon, 22 May 2017 18:25:22 -0700 Archived-At: Subject: [Anima] Ben Campbell's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 01:25:22 -0000 Ben Campbell has entered the following ballot position for draft-ietf-anima-grasp-12: 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-anima-grasp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: -3.5.2.1: "Messages MUST be authenticated and encryption MUST be implemented." Should the latter be "... MUST be used"? It seems odd for authentication to be MUST use, but crypto to only be MTI. -3.5.4.3: "An exponential backoff SHOULD be used for subsequent repetitions, to limit the load during busy periods." Why not MUST? Also, is there a retry limit? (Comment applies to the other sections that mention retries with exponential backoff) -3.5.6.2: "To ensure that flooding does not result in a loop, the originator of the Flood Synchronization message MUST set the loop count in the objectives to a suitable value " I assume this is true for discovery and negotiation as well? I don't think it was mentioned in those sections (although I think I saw a related mention in the message format sections.) - 3.10.5: "SHOULD NOT be used in unmanaged networks such as home networks." Why not MUST? -5, Privacy and Confidentiality: Did people consider IP Addresses and other potentially persistent identifiers as impacting privacy? -7, Grasp Message and Options table: Why "Standards Action"? Would you expect some harm to be done if this were only Spec Required? Editorial: - Is section 2 expected to be useful to implementers once this is published as an RFC? Unless there's a reason otherwise, I would suggest moving this to an appendix, or even removing it entirely. As it is, you have to wade through an unusual amount of front material before you get to the meat of the protocol. - Along the lines of the previous comment, I found the organization a bit hard to follow. I didn't find actual protocol details until around page 21. Procedures are split (and sometimes repeated) between the procedure sections and the message format sections. I think that will make this more difficult and error prone than necessary for implementors to read and reference. I fear readers will read one section and think they understand the procedures, and miss a requirement in the other. - 3.5.2.2: First bullet: Please consider a "MUST NOT construction. "MUST only" can be ambiguous. It would be helpful to explain why the loop count must not be more than one. I can infer that from the later sections on relays, but it was not obvious when reading this section. And unless I missed something, there's no text that puts the two ideas together. - 3.5.4.5: This section seems redundant to the similar sections under negotiation . Since those sections have more information, would it make sense to consolidate them there? From nobody Mon May 22 19:23:56 2017 Return-Path: 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 CB363128E19; Mon, 22 May 2017 19:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acRCwYImc-5g; Mon, 22 May 2017 19:23:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA2812951C; Mon, 22 May 2017 19:23:40 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9BEEEE007; Mon, 22 May 2017 22:50:41 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 47099636E0; Mon, 22 May 2017 22:23:39 -0400 (EDT) From: Michael Richardson To: Anima WG , Eliot Lear cc: ibagdona@gmail.com, Zhoutianran , "opsawg\@ietf.org" In-Reply-To: <031d87aa-1839-d7af-0723-dd9a2aa7ad0a@cisco.com> References: <031d87aa-1839-d7af-0723-dd9a2aa7ad0a@cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] dealing with multiple manufacturer services with a single certificate extension X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 02:23:47 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I've read through the thread. It took more brain-power that I've had available of recent. Let me ask some clarification questions about the original proposal. I generally agree with Max that the /.well-known/ part can be omitted. I also prefer passive (static file) initial interactions so that the initial contact point can be most easily maintained over a period of decades. I was surprised when some proprietary uses like this would point = at the www.example.com, rather than something more divorced from marketing, like a "bootstrap.example.com". So I rather like the mfg-services reply which is essentially a redirect which can be updated over the years. > https://example.com/.well-known/mfg/modelname > > which would return something like: > >{ > "mfg-services" : [ > "mud", "v1", "https://mud.example.com/Frobmaster3000.json", > "anima", "v1", "https://masa.example.com/masa-service" > ] >} correct? In this case, the modelname is there to distinguish phones From=20printers from home-routers, which might well be very separate divisions. > At the moment, more manufacturers are coming back to me to say that we > should just leave these as separate and distinct mechanisms. I think that= 's > the simplest approach. Distinct mechanisms, but common certificates? Or distinct certificates? > It seems to me the simplest way to handle this sort of thing is to create= a > table that MUD/ANIMA controllers simply download when they see the URL. It > might look something like this: When you say ANIMA controller, I think you mean the JRC? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkjnSoACgkQgItw+93Q 3WVdmggAurbCds8uJ6tiRZsJPDQSdEgtI3W7TYiX4togTkWe1mwHFDRmBUF0x4zX FigvareLRRpaOv6M33grxrCwkNdwGxw0le8zpTc8YP51LNk4OHMrAptOQe7SvfEZ djaJHB5CYfHJqJgKL9rdP6Jo4ceCxNlXTgnI70E84QxB/eOS4lgjl1/GMDPuhYMG kWHlcRjFNosCXl2fYT9WXQqixvURcAXvDyc8RYspqj4XunUpWJ+D361lPjCt0vOh 0ZKo7zdD0rV22CqvYtKXDe7v1qJYPiZ3QCiqYOFwtBOyDdQl48f96gCdyezIchSx livFGnqAtlHOEZOHRcL9eD/Ypcpsxg== =QU1S -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 22 20:57:23 2017 Return-Path: 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 3C51A12947B; Mon, 22 May 2017 20:57:22 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVK-5hIl099z; Mon, 22 May 2017 20:57:20 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 78DBC12947F; Mon, 22 May 2017 20:57:20 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id u26so24446034pfd.2; Mon, 22 May 2017 20:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pd9Qjj5nSDHnLszzoL2kAyATkh0z2PX+tTJziMMghME=; b=Q0xKOWlcVxB81UjT4Im7NcTM7CT/aX4QxXrNqNUKIkfEREBKabkTrjpSQ0r86FZXSb TwdI/93hcGCNnFM8VYq+Cle90+20KqrV/huTTejiLuiu+D1HfmVCx62nr6N7zrCOLG98 zpl1wsI2lX3xgJ/ybZORADdSl7rwO3KhJLwyOmiyZQdTjzaaOnW+yIa6T0+sk4aqySsm 332Ye50EmN2MLj5N3EC4W3am2gAzyuQ6IFxy3bqoTpxEfRBwjroAmcDAj6qK/qO5rFc2 sz0gP4GgEWMXeSA4ve/dZH4GqM5C267LHkgauYMmsmTrphS4cpoRPvTvu8X88gaScUa8 rGiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=pd9Qjj5nSDHnLszzoL2kAyATkh0z2PX+tTJziMMghME=; b=R40Oi5VezuiScBjq0/LU23QFTz6qaCgHaNLngjJjokJQGQN926u2IXboU/rKleOTGC 3/xUjMyv96Y2b0nTXX3a8LqjsvFxFWGeBZzu2PgIXEDHk/bXsCKt0mnWosIuMoGCRPF2 jiJJdm1eJ0G821nGCr+QfkQyL+YXMwryD2M+PEpT+vhKOS50ojCGvPJkUTlULd+Blje9 9XEI3lQGbMXb0FKqvFeF9tryD8cKPRNVa0xjQLcOZ8vmjFBbJLJbGRV3hZaOEMEXFSmu B1zVeCMedDlEKWkPPqra6oKFmx7cBvbFoeql+EulMqx5ZzKadMdxanLzuWAwXNWeza5D 7Gfw== X-Gm-Message-State: AODbwcC7fqJ3kXAMfxMqCKton/+wtWpIBGlG/is27uN5lzgqtlJxLqT3 1hNCcnV4N22EbdQX X-Received: by 10.99.44.6 with SMTP id s6mr27492374pgs.25.1495511839934; Mon, 22 May 2017 20:57:19 -0700 (PDT) Received: from [10.100.103.42] (210-55-57-56.adsl.xtra.co.nz. [210.55.57.56]) by smtp.gmail.com with ESMTPSA id v64sm35664650pfk.86.2017.05.22.20.57.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 May 2017 20:57:19 -0700 (PDT) To: Adam Roach , The IESG Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> Date: Tue, 23 May 2017 15:57:15 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 03:57:22 -0000 Just cherry-picking a COMMENT point that does need some thinking: > The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, but > no way to register additional values with IANA. This does not seem > future-proof. This is a tricky point. The values are of course already IANA values from https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml If we wanted to add, say, SCTP that would be straightforward enough, without bothering IANA. But what if we wanted to specify, say, HTTP or QUIC or anything else that doesn't run directly over IP? I think that's a much bigger problem than just GRASP. So I personally prefer to leave it alone for now. If the Transport Area has an answer, that would be great. Regards Brian On 23/05/2017 10:40, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-anima-grasp-12: 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-anima-grasp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The document includes a couple of instances of "reasonable" in normative > statements (e.g., "reasonable timeout"). I would strongly recommend > having specific recommendations in the document where this happens. > > The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, but > no way to register additional values with IANA. This does not seem > future-proof. > > Section 3.8.4 talks about behavior when a node has a "globally unique > address," but provides no guidance for detecting this. Are nodes expected > to check for link-local, zeroconf, RFC 1918, and RFC 6598 addresses? Any > others? > > > From nobody Mon May 22 21:07:54 2017 Return-Path: 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 798F8128DE5; Mon, 22 May 2017 21:07:53 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USj6otB7U9hy; Mon, 22 May 2017 21:07:51 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 74FB5124B0A; Mon, 22 May 2017 21:07:51 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id f27so24513655pfe.0; Mon, 22 May 2017 21:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nLUkGsqIZC0Uvyaa5Xq31fKynXVp14Wfay3JVG6Zvvc=; b=tXusjmucT0Bbr9vqNC7IE7sPAMsVRU97/pGj886m/EbP2YKWXhhgiS0SQ8K7AJRVpP 5HB6EeX0pPidg5SHkNyUJOtuz9kjcZVOH81Culb7XgUUaY9hRLEbcYl3VdefaW6eZJCz qR3kxauL3mrQ85RdhhTKTpCzIkCtudm4mNgJGzQqyItztOjD6doLtvzuOPD4svn/7gs6 zQnP0uY38IbQlCfztR7vMr/Wys/VEFKXnpdJ4sVvEPFQNkLcTikdlF7D9xrE2Q71slud jNIMjhm2udvSP36sl+iH57mAJxDutlugphg3HzSBoG3KOcHmwVOpsvV3n9svtx8g7OQw uymQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=nLUkGsqIZC0Uvyaa5Xq31fKynXVp14Wfay3JVG6Zvvc=; b=qHePLjKxhd3zocux4DG2T5n2YOaUzKl839okZ4quU/f2C1Ra0Q5sOeoq4ruqBJumPv jVppGl9VYNMLZn3MvUW5WruEr4auURgWnkcF78Bo9RN7gJvaWv+on/gK3uNP1dCP8cky 3iHg48q4kxBl43q/ZOWqYDIqEBbSVnvUoJfOPr+VYaZsZiTVhR2t4e1zJ4incxFUoZH9 Za1UIQnU2n4zZxqWqehw5evnJ+L045mdpR4ge/By5Gu9YYgCW7+5ZVkyWoi182KIhTmZ j3ivkBJOrOcEEf4X3Xp/pdVVHSam/iVhM8S+HoqlZXEbmabRvqHKVBMlW0RZyRbn63yp 7npw== X-Gm-Message-State: AODbwcAf0EM4E/PNGlWPuTG413TpBhDT8J3ix7cqYX/Q8jo2SiczqzLw iRQTGM6Qoh9+Zw== X-Received: by 10.84.147.71 with SMTP id r7mr12073998ple.58.1495512470906; Mon, 22 May 2017 21:07:50 -0700 (PDT) Received: from [10.100.103.42] (210-55-57-56.adsl.xtra.co.nz. [210.55.57.56]) by smtp.gmail.com with ESMTPSA id 67sm30766956pfn.84.2017.05.22.21.07.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 May 2017 21:07:50 -0700 (PDT) To: Ben Campbell , The IESG Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <69b51774-0e73-433b-f620-12dfbdad8892@gmail.com> Date: Tue, 23 May 2017 16:07:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 04:07:53 -0000 Again cherry-picking in line, as I'm on vacation travel this week: On 23/05/2017 13:25, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-anima-grasp-12: 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-anima-grasp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Substantive: > > -3.5.2.1: "Messages MUST be authenticated and encryption MUST be > implemented." > Should the latter be "... MUST be used"? It seems odd for authentication > to be MUST use, but crypto to only be MTI. This was a bit of a compromise between the authors. Personally I'd prefer MUST be used, but we'd need to ask the WG. > > -3.5.4.3: "An exponential backoff SHOULD be used for subsequent > repetitions, to limit the load during busy periods." > Why not MUST? Also, is there a retry limit? (Comment applies to the > other sections that mention retries with exponential backoff) Personally I'm reluctant to specify this too tightly. I'd expect the retry limit to be use-case dependent; there might be cases where trying for ever is the right thing to do. Similarly for the strictly exponential backoff; for example, backing off to one try per minute might be reasonable for a given application, or to one try per hour for another. > > -3.5.6.2: "To ensure that flooding does not result in a loop, the > originator of > the Flood Synchronization message MUST set the loop count in the > objectives to a suitable value " > I assume this is true for discovery and negotiation as well? I don't > think it was mentioned in those sections (although I think I saw a > related mention in the message format sections.) Discovery and flooding are multicast, so it really is about loop prevention. I thought we did say the same for discovery, if not that needs fixing. In negotiation it's a bit different - it's part of the semantics of the application (how many rounds of negotiation make sense) so there's not much to say from the protocol design viewpoint. More when I get home. Brian > > - 3.10.5: "SHOULD NOT be used in > unmanaged networks such as home networks." > Why not MUST? > > -5, Privacy and Confidentiality: Did people consider IP Addresses and > other potentially persistent identifiers as impacting privacy? > > -7, Grasp Message and Options table: Why "Standards Action"? Would you > expect some harm to be done if this were only Spec Required? > > Editorial: > > - Is section 2 expected to be useful to implementers once this is > published as an RFC? Unless there's a reason otherwise, I would suggest > moving this to an appendix, or even removing it entirely. As it is, you > have to wade through an unusual amount of front material before you get > to the meat of the protocol. > > - Along the lines of the previous comment, I found the organization a bit > hard to follow. I didn't find actual protocol details until around page > 21. Procedures are split (and sometimes repeated) between the procedure > sections and the message format sections. I think that will make this > more difficult and error prone than necessary for implementors to read > and reference. I fear readers will read one section and think they > understand the procedures, and miss a requirement in the other. > > - 3.5.2.2: First bullet: > Please consider a "MUST NOT construction. "MUST only" can be ambiguous. > It would be helpful to explain why the loop count must not be more than > one. I can infer that from the later sections on relays, but it was not > obvious when reading this section. And unless I missed something, there's > no text that puts the two ideas together. > > - 3.5.4.5: This section seems redundant to the similar sections under > negotiation . Since those sections have more information, would it make > sense to consolidate them there? > > > From nobody Tue May 23 01:49:26 2017 Return-Path: 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 2B191129534; Tue, 23 May 2017 01:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=45c1tGwi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JLM7akVH 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 afst4T6yQaTr; Tue, 23 May 2017 01:49:23 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61377128BB6; Tue, 23 May 2017 01:49:23 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 98CA620888; Tue, 23 May 2017 04:49:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Tue, 23 May 2017 04:49:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=HiOHK+nO4o9OS/1iaY /Jok9Pxdu/LQujyJJEh7dlCrs=; b=45c1tGwiREhBwcDm4OaIztzn+n030R0+8P Tcu9uS1tN15Q8JOv7TnJpldfO9kr31JtRlp9Y2jSL+mY3BgjtznKFU9hUKIWckAY GOyJXscsjq9tFtIvOhmm66KFyiW/FrY6E0wC3wjYugrJb2nZ5WPX5FMFqWwIPmpr b3L/UJCMoOXzdrQk03dzhGZSMjGCzY4lz5nCftiDVuFcMXvTrT0TNlmjyFq4BvKW M9wdNYfEAHJNTdP3NIhyPO451ghvT3QZoIfP75S7yZj3zsazlVRdh64ANRzx9xjv aViK+euh5lkbCXg/BLcMyCUL7oXQYSjWY3+MfBhQgM2je8afnrPg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=HiOHK+nO4o9OS/1iaY/Jok9Pxdu/LQujyJJEh7dlCrs=; b=JLM7akVH zYwg7oKvzSi2jgbdPL6CCyLde6SRCu7uG68ME+w3gmqIWNmTU9igBxt/drZ8AVi0 MQCEs86BkeaOfnEdiysX1iegF4ReTYLMRxZwEdTSzJopqKX7LM/15etzVWw7NUyI nuOYmLX9KBeC6s55FX0dImL7Oz+/CjVvrn0YM+pT8u3Q6XBbmodGWyMdsIwsBmv9 89vkXO4sznRKyCbpdJxi+Q7P/77TNVlrp4nRFnwBtv5b6cQZKrvYuSWKXvIoYSQ3 LFZqVI/AAWw61CrbvjEAmXBEHfExOWWSm4zee7O18sgUvFt3XvBktEX8y9gvVcuD PCr4I2Jt6qujrQ== X-ME-Sender: X-Sasl-enc: 8KYTslZeRIzFJQ1ii7oJyoxIZ37pPpjKRP7evBMTZxwn 1495529362 Received: from [10.13.86.3] (unknown [85.255.237.123]) by mail.messagingengine.com (Postfix) with ESMTPA id 2FA0224766; Tue, 23 May 2017 04:49:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> Date: Tue, 23 May 2017 10:06:38 +0100 Cc: Adam Roach , The IESG , anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-grasp@ietf.org, Sheng Jiang Content-Transfer-Encoding: quoted-printable Message-Id: References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> To: Brian E Carpenter Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 08:49:25 -0000 Hi Brian, > On 23 May 2017, at 04:57, Brian E Carpenter w= rote: >=20 > Just cherry-picking a COMMENT point that does need some thinking: >=20 >> The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, but >> no way to register additional values with IANA. This does not seem >> future-proof. >=20 > This is a tricky point. The values are of course already IANA values from > https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > If we wanted to add, say, SCTP that would be straightforward enough, witho= ut > bothering IANA. >=20 > But what if we wanted to specify, say, HTTP or QUIC or anything else that > doesn't run directly over IP? >=20 > I think that's a much bigger problem than just GRASP. So I personally pref= er > to leave it alone for now. If the Transport Area has an answer, that > would be great. Can you at least establish an IANA registry? > Regards > Brian >=20 >> On 23/05/2017 10:40, Adam Roach wrote: >> Adam Roach has entered the following ballot position for >> draft-ietf-anima-grasp-12: No Objection >>=20 >> 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.) >>=20 >>=20 >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html= >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> The document includes a couple of instances of "reasonable" in normative >> statements (e.g., "reasonable timeout"). I would strongly recommend >> having specific recommendations in the document where this happens. >>=20 >> The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, but >> no way to register additional values with IANA. This does not seem >> future-proof. >>=20 >> Section 3.8.4 talks about behavior when a node has a "globally unique >> address," but provides no guidance for detecting this. Are nodes expected= >> to check for link-local, zeroconf, RFC 1918, and RFC 6598 addresses? Any >> others? >=20 From nobody Tue May 23 02:05:08 2017 Return-Path: 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 DE222128CF0; Tue, 23 May 2017 02:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiAAMxk66bjp; Tue, 23 May 2017 02:05:04 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 40C28128B44; Tue, 23 May 2017 02:05:04 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id 123so16810018wmg.1; Tue, 23 May 2017 02:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=ZEYZ4/fyPNKcNzkVePKybSLiRKJRLYYQs60a1TqndIA=; b=t5YRK4mFarA/7QRHcduxvTToCm5xYiiVAyEUfoffjgw5wRBc78NbPbq+n2IKFsIST7 HPVwjB1aZN6yGTfUYZPBWF6pZOnfiutoP3QpuDSWZcq4oOYvrHRUIml870YZpnfnHkpe nEKGVFPVeY7HvsLOnPU0AgOugY/RRSmVAPkDDLt1JQma55hggblo1x+HzfWaFmGGdbIP PX7/x0ZWBoia4/trWfMbvOy75nGsuWLBcrwc4bfQDCBifv/FDs+Iqp6gtyew11sVAKbR E35/VIW9fPA2WbRcoWOI799gpfJMfVEbW3MjdfIFDVpnRMwSGf6agED8FcyemJfH7VFW nb3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=ZEYZ4/fyPNKcNzkVePKybSLiRKJRLYYQs60a1TqndIA=; b=EKsy0Jsa4FuaupKb5IQzqUtntYhN543hjx2WBCyBcx9nLyFq0YxVRwhb1lPQ8Wjzr6 eFvXCfuF6/Tmz91KCNz4wEDtHSjB7xdZaXveC7OSWjeVLDhtno+cSo/F+VBTGX79uW1z obgbUYoroo8bPgZM5UEOystbQUhjEFYOPfRBKCh/E/UTh+mjXVBRH4MuVb1V+EwvaPs9 rO2Gg9SgsZLldTKBfl1mcAEm7AMY6bBXpOsJMyJ39zTHttaPm+lWf+f5/OtshamcgpWz mpJ63Du1iA0pHtJoCbj60A8dCV9ShEjD1F+RuQntupTxjSi9I8Voq8NC3S7hi330ynXX f/HA== X-Gm-Message-State: AODbwcDqykbYJ63f/DHQykm0dmzlshiQhUKcU4zE4rCgGdBU0RRiM66T NBPYVmvAjJlLxRpl X-Received: by 10.28.230.200 with SMTP id e69mr1482529wmi.70.1495530302298; Tue, 23 May 2017 02:05:02 -0700 (PDT) Received: from mn-mn0F-2.local (p57870C10.dip0.t-ipconnect.de. [87.135.12.16]) by smtp.googlemail.com with ESMTPSA id a24sm232992wra.17.2017.05.23.02.05.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 02:05:01 -0700 (PDT) To: anima@ietf.org Cc: tsv-art@ietf.org From: Martin Stiemerling Message-ID: <6b290c47-5ab1-78e4-9f54-fa4f0679143b@gmail.com> Date: Tue, 23 May 2017 11:05:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Anima] TSV-ART review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 09:05:07 -0000 Hi all, Please find below my review of draft-ietf-anima-grasp-11. The comments below are about -11 of the draft, as I did work on this version and did unfortunately not have time to go through -12. I've reviewed this document as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@… if you reply to or forward this review. Summary: This draft has serious issues, described in the review, and needs to be rethought. General comments: * The title is partially misleading as this document is setting requirements for the protocol and is additionally defining the protocol. This is made obvious in the abstract, but nonetheless, the title is misleading * Document structure: I am not sure why the requirements are listed in Section 2. The are never ever used in the document to motivate any design decision or reference to. So what is the purpose of having these requirements here? Couldn’t and shouldn’t they be listed in a separate document? * Security: There is no security proposed or discussed for GRASP in this document. There are solely statements about generic security, such as in Section 1 „a secure and strongly authenticated environment“ or Section 3.5.2.1. "Messages MUST be authenticated and encryption MUST be implemented“. So how must they be authenticated and encrypted and why? What is the standard set of protocols to be used for this and what is the minimal set of crypto algorithms to be implemented to make this work? ************************************************************ This document is always using the escape hatch when it comes to security in any respect! ************************************************************ * Usage of UDP: This document is not discussing any of the aspects in RFC 8085. Every usage of UDP is required by IETF consensus to review RFC 8085 and to address at least the applicable subset of issues listed in RFC 8085 (or the predecessor RFC 5405). * Starting with UDP and switching to TCP for the data transfer looks like the right do. However, UDP should be really only used to discover other devices, but not piggy back further protocol mechanics. However, this document is not really specific on how to make use of TCP, for instance, how long are TCP connections kept open or closed down after a protocol exchange (persistent vs temporary connections). What happens if a TCP connection is shutdown by one end or is forcefully closed, e.g., by a reset? * There is no versioning support in GRASP. Why are we still developing protocols that do not have versioning support in it? * IPv4/IPv6 simultaneous use: I believe the email describing the -12 update of the draft says that IPv4 and IPv6 should not be mixed, so I can skip over this. Detailed comments: * Section 2.1: These are not protocol requirements but system requirements. It would be really good to separate them in the list of requirements. * Section 2.1, Requirement D2: What is this requirements saying? Is it „it should just work whatever?“ * Section 2.1, Requirement D7: What is the rest of the network in the first bullet point? All anima devices or every single element of the network? * Section 2.2, Requirement SN7: I am not sure if any of these points in this requirement related to any part of the GRAPS protocol. If so, you can for sure add forward references or backward references in the protocol specification. * Section 2.3, T1 & T2 are good, but how is this fulfilled by the protocol? * Section 3.2, end of page 12, „appropriate global-scope address“: so GRASP is not intended to run networks that use private RFC 1918 addresses? * Section 3.2, head of page 13: the discussion about interfaces. I am not sure that calling GRASP interfaces just interfaces helps. Why not calling interfaces interfaces and GRASP interfaces if the are used? or active interfaces, etc? * Section 3.3: This section is again bringing up a number of requirements. Wrong place in the document? * Section 3.3, page 14: the unsolicited flooding mode sounds really bad. Has this aspect looked at in terms of how many GRAPS nodes are expected to live on in a single link-local multicast domain (hoping that non link-local multicast is excluded per se). * Section 3.3: last bullet on page 14 and first bullet on page 15: what is this saying other than it is complicated? Aren’t there any tangible details to this? * Section 3.4: " An instance of GRASP is expected to run as a separate core module, providing an API (such as [I-D.liu-anima-grasp-api]) to interface to various ASAs. These ASAs may operate without special privilege, unless they need it for other reasons (such as configuring IP addresses or manipulating routing tables).“ This is implementation specific and does not belong in a protocol specification. * Section 3.5.1, page 17: „virtualized over the ACP“ — what does this mean and how it is done? * Section 3.5.1, page 17: „If there is no ACP, one“ there are two options listed for this case, but which is used when? * Section 3.5.1, page 17: „strong authentication“ — what is strong authentication and what needs to be supported by a minimal, but interoperable implementation? This is extremely underspecified. * Section 3.5.1, page 17: "Network interfaces could be at different security levels,“ what is a security level in the context of this document and specifically here. * Section 3.5.1, page 17: "discovery messages MUST be secured, with one exception mentioned in“ — how secured? This is extremely underspecified. * Section 3.5.2 s/GRAPS subject/GRAPS are subject/ * Section 3.5.2.1., page 17: "As mentioned in Section 3.3“ this isn’t mentioned in this place or I cannot correlate it. * Section 3.5.2.1., page 17 " implemented. TLS [RFC5246] and DTLS [RFC6347] based on a Public Key Infrastructure (PKI) [RFC5280] are RECOMMENDED for this purpose. Further details are out of scope for this document.“ How bad is this that TLS and DTLS are RECOMMENDED but the usage is not specified? * Section 3.5.2.2: Are there any measures in the protocol to ensure that datagrams have really been sent on the same link? I haven’t seen any measures. * Section 3.5.2.3.: " by TLS. A separate instance of GRASP is used, with its own copy of all GRASP data structures. This instance is nicknamed SONN - Secure Only Neighbor Negotiation.“ I am not sure why this document is trying to mandate how implementers are organizing their implementation and how instances are named? * Section 3.5.2.3, page 19, end of bullet list: "Further details are out of scope for this document.“ What further details? Is the WG not sure what the missing details are? * Section 3.5.3.: "They MUST NOT be fragmented, and therefore MUST NOT exceed the link MTU size.“ How should the protocol ensure that such datagrams are not fragmented and do not exceed the MTU? * Section 3.5.3.: " Use of an unreliable transport protocol is therefore NOT RECOMMENDED.“ — very good guidance — thank you! :-) * Section 3.5.3., end of page 19: * Section 3.5.4.4: "Since the relay device is unaware of the timeout set by the original initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEOUT milliseconds.“ The timeout set by the initiator seems to be important, so why is this value not communicated by the initiator within GRASP? * Section 3.5.5: It is unclear to me if the messages here are expected to be sent over TCP or nor? This is not clear. * Section 3.5.5, page 24 and also Section 3.5.6.1: " request is sent (see Section 3.8.6). If no reply message of any kind is received within a reasonable timeout, the negotiation request MAY be repeated, with a newly generated Session ID (Section 3.7). An exponential backoff SHOULD be used for subsequent repetitions.“ What is a reasonable time out? And why is this need if TCP is used? TCP provides reliable data transfer… * Section 3.5.5, page 24: " about different objectives. Thus, GRASP is expected to be used in a multi-threaded mode. Certain negotiation objectives may have restrictions on multi-threading, for example to avoid over-allocating resources. „ Again, talking about the implementation. This is not a protocol specification, isn’t it? * Section 3.5.6.2 (and other places in the document): What is the GRASP core? * Section 3.5.6.2, page 26: „ the result is zero. Also, it MUST limit the total rate at which it relays Flood Synchronization messages to a reasonable value, in order to mitigate possible denial of service attacks. It MUST cache the „ What is a reasonable value? * Message encoding: What is the encoding to be supported for "reason = text ;optional error message“ Is there are any minimal standard to be supported, such as 7 bit ASCII or UTF-8 or whatever? Best regards, Martin Stiemerling From nobody Tue May 23 02:20:36 2017 Return-Path: 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 CAC8F1298A1; Tue, 23 May 2017 02:20:23 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71NLCjdCYRrC; Tue, 23 May 2017 02:20:22 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 336191296C9; Tue, 23 May 2017 02:20:22 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id u26so26280199pfd.2; Tue, 23 May 2017 02:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZCcgTRIGLTkdiHn9ilzJukyqj6ntzvHNRAnlpBLJUmE=; b=IMuFq3O/PAluJEw4Kv5Wc11fanuV9GZfN8zWFApb62cU8NJV8rRZf/7FHP9OKLGdFJ wRlRXvO4U23U76cbLXzCufXJ7f2e6hnl8PXjpLgHr10hSXA544LuCU6UFeRslQnfbjAx DaiOMEe2lNTtHSC4eMIBlljulLPb72vFpmzq1eN9/qv6ONZViw+llNaNVXmFkrgHbp31 Xk2sWhQH6CebP/XdYq8U8XNIai3poJ5xOE36fwfHm27HI3DCul9cmHHZzA116X5vdJyT Fxr+Cl7v6VsEU0Gm24a13laji6I4a3xfdcNFoBQUYVpe2PhTYCzmBjxa6t9nKGu0c3wf YNVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ZCcgTRIGLTkdiHn9ilzJukyqj6ntzvHNRAnlpBLJUmE=; b=fx65jAbsNeceVp3m6CHui/fJQ+FrNOGfGf1m01+g7634xUTm+LHtFh+bTCTh6+nOKK 91JruZb31RCH3wX2Xwnd1xPvq7ZI6KWFZN15RJE87JNMBpQEDhEG2ZHL0HC2+7Xxy4Lw IoSy/up4Bz4+HGtJYXfV4FUxaVKA8CydsMa/Y62tKW0AzlB04iDgPQSFhDMA+fV+qa4b 7P9gZe1lsL4XeUNH6rUV3WBcwR+HewjF+v9mT5O8pafPDT0sK2mWX6A1TF8iIscdrFjm GkLgV+CstIc0drmHKyMncIGA4oOEQD9UcQdJ2DyuiuAGIh7z0onHa2AF5NXOiZAmFwMq BKzQ== X-Gm-Message-State: AODbwcCffVcaTyTtdrx4Pf+IX2nhBTx8ThXJS0UVtWwqAN3fyFuNHmw7 RhSFEuiY2YaOljAa X-Received: by 10.84.224.200 with SMTP id k8mr35146102pln.49.1495531221756; Tue, 23 May 2017 02:20:21 -0700 (PDT) Received: from [10.100.103.42] (210-55-57-56.adsl.xtra.co.nz. [210.55.57.56]) by smtp.gmail.com with ESMTPSA id w76sm600120pfd.76.2017.05.23.02.20.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 02:20:21 -0700 (PDT) To: Alexey Melnikov Cc: Adam Roach , The IESG , anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-grasp@ietf.org, Sheng Jiang References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <7c945da2-06fe-9121-69ac-861ac02e0b05@gmail.com> Date: Tue, 23 May 2017 21:20:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 09:20:24 -0000 On 23/05/2017 21:06, Alexey Melnikov wrote: > Hi Brian, > >> On 23 May 2017, at 04:57, Brian E Carpenter wrote: >> >> Just cherry-picking a COMMENT point that does need some thinking: >> >>> The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, but >>> no way to register additional values with IANA. This does not seem >>> future-proof. >> >> This is a tricky point. The values are of course already IANA values from >> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml >> If we wanted to add, say, SCTP that would be straightforward enough, without >> bothering IANA. >> >> But what if we wanted to specify, say, HTTP or QUIC or anything else that >> doesn't run directly over IP? >> >> I think that's a much bigger problem than just GRASP. So I personally prefer >> to leave it alone for now. If the Transport Area has an answer, that >> would be great. > > Can you at least establish an IANA registry? My concern is that this may turn out to be a much broader problem: how do we express that some upper layer protocol wants to run over a variety of "transport" layers, some of which are traditional transport-over-IP and some of which are transport-over-UDP or whatever. Yes, maybe there should be a registry for that, but it would definitely not be specific to GRASP. I'd really like to hear some Transport Area thinking on that. (And meanwhile I'd like to get GRASP out the door too ;-) Brian > >> Regards >> Brian >> >>> On 23/05/2017 10:40, Adam Roach wrote: >>> Adam Roach has entered the following ballot position for >>> draft-ietf-anima-grasp-12: 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-anima-grasp/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> The document includes a couple of instances of "reasonable" in normative >>> statements (e.g., "reasonable timeout"). I would strongly recommend >>> having specific recommendations in the document where this happens. >>> >>> The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, but >>> no way to register additional values with IANA. This does not seem >>> future-proof. >>> >>> Section 3.8.4 talks about behavior when a node has a "globally unique >>> address," but provides no guidance for detecting this. Are nodes expected >>> to check for link-local, zeroconf, RFC 1918, and RFC 6598 addresses? Any >>> others? >> > > From nobody Tue May 23 02:53:47 2017 Return-Path: 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 1649B1296D2 for ; Tue, 23 May 2017 02:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ia0CK9ARhtPC for ; Tue, 23 May 2017 02:53:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65D2A129445 for ; Tue, 23 May 2017 02:53:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNP50608; Tue, 23 May 2017 09:53:36 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 23 May 2017 10:53:33 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 23 May 2017 17:53:24 +0800 From: "Liubing (Leo)" To: Anima WG Thread-Topic: Regarding ACP routing protocol Thread-Index: AQHS06pqYobAcjfrZUiCrubttqEAIA== Date: Tue, 23 May 2017 09:53:23 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2F4251B@nkgeml514-mbx.china.huawei.com> References: <192aefd6-1c4e-57e8-bdcb-71fd130248a4@gmail.com> In-Reply-To: <192aefd6-1c4e-57e8-bdcb-71fd130248a4@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.592406A1.0134, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3899fcba7186414bdb80ec83fb3a08ac Archived-At: Subject: [Anima] Regarding ACP routing protocol X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 09:53:43 -0000 Hi all, When I discuss ACP with some product people, they are always curious about = why we choose RPL for routing. I understand the benefits of RPL in ACP, it is lightweight and much more sc= alable in a single routing area, but most of the non-IoT network devices se= em like lack the support of RPL.=20 So, please pardon my iteration on this problem, can we possibly make anothe= r more traditional IGP literally legal in the ACP document? (e.g. ISIS-auto= conf or OSPFv3-autoconf) I know supporting multiple protocols would potentially cause interoperation= issue. But in some closed solutions, multi-vendor interoperation is not th= e No.1 consideration for customers. If ACP allows ISIS-autoconf or OSPFv3-a= utoconf, I think ACP could be more widely adopted in non-IoT network device= s. Any comments? Or eggs :) B.R. Bing=20 From nobody Tue May 23 07:28:37 2017 Return-Path: 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 3B414129B57; Tue, 23 May 2017 07:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 gGqePF4ljwxP; Tue, 23 May 2017 07:28:28 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8308D129A8F; Tue, 23 May 2017 07:28:28 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 99AE458C4AF; Tue, 23 May 2017 16:28:24 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6E64EB0C097; Tue, 23 May 2017 16:28:24 +0200 (CEST) Date: Tue, 23 May 2017 16:28:24 +0200 From: Toerless Eckert To: "Max Pritikin (pritikin)" Cc: "consultancy@vanderstok.org" , anima-bootstrap , Anima WG Message-ID: <20170523142824.GA18931@faui40p.informatik.uni-erlangen.de> References: <21915.1490916584@obiwan.sandelman.ca> <6168.1491913071@obiwan.sandelman.ca> <3EB7EB76-B8F6-4A64-918E-307C4F8B20E8@cisco.com> <4cb3eef653ebc2edec8160efb63e5cf6@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] [Anima-bootstrap] Concise version of BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 14:28:30 -0000 It is quite frustrating to see the bootstrap draft be handled in a way that is impossible to track: - it would have been better not to crearte anothrer branch that you can only be aware of by having seen this email - If you use a new branch, it would be great if you would have updated the IETF anima bootstrap wiki page with this information. - for the sake of the non-git experts amongst us, it would be great to also indicate some command how to retrieve this branch. I for once tried: git clone -b concise https://github.com/anima-wg/anima-bootstrap and that totally did not work. So as of right now i am lost in how i should review this version of the document. Toerless On Tue, Apr 18, 2017 at 05:07:18PM +0000, Max Pritikin (pritikin) wrote: > > Peter, > > The current text is wordy and repetitive and says things more than once . Primary focus is to remove repetitive text, tighten remaining text, and consolidate normative statements. > > As an initial example the -05 draft has 3 main sections: > architectural overview > functional overview (contains design considerations discussions) > protocol details > The initial ???concise??? branch commit moves the functional overview to the appendix. Subsequent commits are resolving normative texts that were in there by moving needed bits back into the protocol discussion. You can follow along via the git repository here: > https://github.com/anima-wg/anima-bootstrap/compare/concise > > There was a comment that the design considerations are useful and might be appropriate to keep here or in another document. At the moment I don???t have a formulated position on that. > > - max > > > On Apr 18, 2017, at 3:27 AM, peter van der Stok wrote: > > > > Hi Max, > > > > excellent idea. I looked at the present version, and there is still a lot of text. > > Where in the text do you want to reduce more? What is the end-objective? > > And will this become the final document, or is it a study that will be used later for editing the final document? > > > > Peter > > > > Max Pritikin (pritikin) schreef op 2017-04-15 00:34: > >> For those of you tracking the git repository please note the existence > >> of a new branch. As warned I???m significantly reducing the text. This > >> work is going on in the branch ???concise???. > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap -- --- tte@cs.fau.de From nobody Tue May 23 07:38:03 2017 Return-Path: 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 0A3F4129AEE; Tue, 23 May 2017 07:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISpBNsaHOpEc; Tue, 23 May 2017 07:38:00 -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 2C4F81293F4; Tue, 23 May 2017 07:38:00 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4NEbkuX092775 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 May 2017 09:37:47 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <69b51774-0e73-433b-f620-12dfbdad8892@gmail.com> Date: Tue, 23 May 2017 09:37:46 -0500 Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <17BCE171-7F62-48E7-A09F-C5DE63CF724E@nostrum.com> References: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> <69b51774-0e73-433b-f620-12dfbdad8892@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 14:38:02 -0000 Thanks for the response! Comments inline: Ben. > On May 22, 2017, at 11:07 PM, Brian E Carpenter = wrote: >=20 > Again cherry-picking in line, as I'm on vacation travel this week: >=20 > On 23/05/2017 13:25, Ben Campbell wrote: >> Ben Campbell has entered the following ballot position for >> draft-ietf-anima-grasp-12: No Objection >>=20 >> 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.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Substantive: >>=20 >> -3.5.2.1: "Messages MUST be authenticated and encryption MUST be >> implemented." >> Should the latter be "... MUST be used"? It seems odd for = authentication >> to be MUST use, but crypto to only be MTI. >=20 > This was a bit of a compromise between the authors. Personally I'd = prefer > MUST be used, but we'd need to ask the WG. Okay. I was mainly checking that the existing language was intentional. >=20 >>=20 >> -3.5.4.3: "An exponential backoff SHOULD be used for subsequent >> repetitions, to limit the load during busy periods." >> Why not MUST? Also, is there a retry limit? (Comment applies to the >> other sections that mention retries with exponential backoff) >=20 > Personally I'm reluctant to specify this too tightly. I'd expect the > retry limit to be use-case dependent; there might be cases where = trying > for ever is the right thing to do. Similarly for the strictly = exponential > backoff; for example, backing off to one try per minute might be = reasonable > for a given application, or to one try per hour for another. >=20 Do I understand correctly that you want there to be some congestion = avoidance strategy, but it could be something other than exponential = backoff? Would it make sense to say something like the following:=20 "Some strategy MUST be in effect to avoid causing network congestion = with too many repetition. This stragegy SHOULD be an exponential = backoff, but other strategies might be reasonable for specific = applications." >>=20 >> -3.5.6.2: "To ensure that flooding does not result in a loop, the >> originator of >> the Flood Synchronization message MUST set the loop count in the >> objectives to a suitable value " >> I assume this is true for discovery and negotiation as well? I don't >> think it was mentioned in those sections (although I think I saw a >> related mention in the message format sections.) >=20 > Discovery and flooding are multicast, so it really is about loop > prevention. I thought we did say the same for discovery, if not > that needs fixing. In negotiation it's a bit different - it's part > of the semantics of the application (how many rounds of negotiation > make sense) so there's not much to say from the protocol design > viewpoint.=20 Okay. >=20 > More when I get home. >=20 > Brian >=20 >>=20 >> - 3.10.5: "SHOULD NOT be used in >> unmanaged networks such as home networks." >> Why not MUST? >>=20 >> -5, Privacy and Confidentiality: Did people consider IP Addresses and >> other potentially persistent identifiers as impacting privacy? >>=20 >> -7, Grasp Message and Options table: Why "Standards Action"? Would = you >> expect some harm to be done if this were only Spec Required? >>=20 >> Editorial: >>=20 >> - Is section 2 expected to be useful to implementers once this is >> published as an RFC? Unless there's a reason otherwise, I would = suggest >> moving this to an appendix, or even removing it entirely. As it is, = you >> have to wade through an unusual amount of front material before you = get >> to the meat of the protocol. >>=20 >> - Along the lines of the previous comment, I found the organization a = bit >> hard to follow. I didn't find actual protocol details until around = page >> 21. Procedures are split (and sometimes repeated) between the = procedure >> sections and the message format sections. I think that will make this >> more difficult and error prone than necessary for implementors to = read >> and reference. I fear readers will read one section and think they >> understand the procedures, and miss a requirement in the other. >>=20 >> - 3.5.2.2: First bullet: >> Please consider a "MUST NOT construction. "MUST only" can be = ambiguous. >> It would be helpful to explain why the loop count must not be more = than >> one. I can infer that from the later sections on relays, but it was = not >> obvious when reading this section. And unless I missed something, = there's >> no text that puts the two ideas together. >>=20 >> - 3.5.4.5: This section seems redundant to the similar sections under >> negotiation . Since those sections have more information, would it = make >> sense to consolidate them there? >>=20 >>=20 >>=20 From nobody Tue May 23 08:19:29 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFCF127011; Tue, 23 May 2017 08:19:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149555276275.18049.7515853778089282062.idtracker@ietfa.amsl.com> Date: Tue, 23 May 2017 08:19:22 -0700 Archived-At: Subject: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?anima-grasp-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 15:19:23 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-anima-grasp-12: Discuss 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-anima-grasp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1) Use of transport protocols is not sufficiently defined Especially the following text in section 3.5.3 seems not to reflect later assumptions correctly; it seems to be assumed that TCP is used for all messages other than the discovery and therefore reliable transport is provided for these message (see sections 3.5.5, 3.8.4 and 3.8.5): "All other GRASP messages are unicast and could in principle run over any transport protocol. An implementation MUST support use of TCP. It MAY support use of another transport protocol but the details are out of scope for this specification. However, GRASP itself does not provide for error detection or retransmission. Use of an unreliable transport protocol is therefore NOT RECOMMENDED." In general the usage of the transport protocols is not well enough specified, see also Spencer's comments and this part of Martin's tsv-art review (Thanks!): "* Usage of UDP: This document is not discussing any of the aspects in RFC 8085. Every usage of UDP is required by IETF consensus to review RFC 8085 and to address at least the applicable subset of issues listed in RFC 8085 (or the predecessor RFC 5405). * Starting with UDP and switching to TCP for the data transfer looks like the right do. However, UDP should be really only used to discover other devices, but not piggy back further protocol mechanics. However, this document is not really specific on how to make use of TCP, for instance, how long are TCP connections kept open or closed down after a protocol exchange (persistent vs temporary connections). What happens if a TCP connection is shutdown by one end or is forcefully closed, e.g., by a reset?" I would recommend, as assumed in the rest of the document, to update section 3.5.3 to only use UDP for the initial recovery message and open a TCP connection for the discovery response and require that all other messages to be sent over TCP (also removing any option to use any other reliable transport because TCP seems to be the right choice here.) Further, additional guidance is needed when to open and close a TCP connection (or keep it alive for later use) and what to do if the connection is interrupted. 2) Time-out handling section 3.5.4.4: "Since the relay device is unaware of the timeout set by the original initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEOUT milliseconds." Should a relay really maintain an own time-out? Wouldn't it be sufficient to just relay again if another discovery message is received. Otherwise this can lead to an amplification, when the own time-out expires and another relay message is sent when another discovery message is received due to the time-out of the originating peer. Further in relation to the point about, this should be more specific: section 3.5.4.4: "Also, it MUST limit the total rate at which it relays discovery messages to a reasonable value, in order to mitigate possible denial of service attacks. " 3) Version and extensibility: section 3.5.4.5: "A possible future extension is to allow multiple objectives in rapid mode for greater efficiency." How can this extension be defined if there is no version mechanism? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Other mostly editorial comments: - ASA needs to be spelled out in the intro. - I would recommend to move section 2 and 3.3 into the appendix - section 3.5.4.2: "A neighbor with multiple interfaces will respond with a cached discovery response if any." "cached response" is explained in the next section and not clear in this paragraph. - section 3.5.4.3: "After a GRASP device successfully discovers a locator for a Discovery Responder supporting a specific objective, it MUST cache this information, including the interface index via which it was discovered. This cache record MAY be used for future negotiation or synchronization, and the locator SHOULD be passed on when appropriate as a Divert option to another Discovery Initiator." Not sure why the first is a MUST and the later is a SHOULD. I guess a SHOULD for caching would be sufficient. - section 3.8.6 "If a node receives a Request message for an objective for which no ASA is currently listening, it MUST immediately close the relevant socket to indicate this to the initiator." How is that indicated? Should really be further clarified - Also section 3.8.6: "In case of a clash, it MUST discard the Request message, in which case the initiator will detect a timeout." Why don't you send an error message instead? How does the initiator know that is should retry (assuming there is a TCP connection underneath that provides reliable transport)? - Also section 3.8.9: "If not, the initiator MUST abandon or restart the negotiation procedure, to avoid an indefinite wait." How does the initiator decide for abandoning or restarting instead? Needs clarification! - Could be useful to include an optional reasoning field in the Invalid Message and make copying the received message up to the maximum message size of this message a SHOULD (section 3.8.12.). - Not sure I fully understand the purpose of the No Operation Message (section 3.8.13.). If you just want to open a socket for probing, you perform a TCP handshake and send a RST right after. No need for further application layer interactions. And should there also be an optional reasoning phrase? - Not sure why the objectives flag is needed. I assume that unknown objectives are ignored anyway and if a objective is known the receiver should know if that objective is valid for the respective message type (section 3.10.2). - section 3.10.4: "An issue requiring particular attention is that GRASP itself is a stateless protocol." It's not. It caches information and needs to remember previous messages sent to reply correctly. - section 5: "Generally speaking, no personal information is expected to be involved in the signaling protocol, so there should be no direct impact on personal privacy." I don't think this is true because the protocol is so generic that you cannot say anything about the services it is used for. Please see also further comments from Martin's tsv-art review (Thanks again!)! From nobody Tue May 23 08:53:41 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B659128BA2; Tue, 23 May 2017 08:53:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149555482010.19649.2868324572857769920.idtracker@ietfa.amsl.com> Date: Tue, 23 May 2017 08:53:40 -0700 Archived-At: Subject: [Anima] Kathleen Moriarty's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 15:53:40 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-anima-grasp-12: 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-anima-grasp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing the SecDir review, as well as Ben's questions on the WG decisions for authentication & encryption and Spencer's on running in a secure ACP. Clarifying the text for the latter would be helpful. From nobody Tue May 23 09:30:46 2017 Return-Path: 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 C4E65129B71; Tue, 23 May 2017 09:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 skUEKiRoPh5a; Tue, 23 May 2017 09:30:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97EFE1293D9; Tue, 23 May 2017 09:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6068; q=dns/txt; s=iport; t=1495557041; x=1496766641; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Vxx3tIH1aLg+3pH2FlrKecy05hMZAMlzEgosJ46AKnE=; b=iswy0hJcRfHlasBExnDHuZxCQIchvPIn1SFdb8Us+a0FyHE7Yu2lwAWU w2Wy4WsyZjHPiTJ88Za720Cm+P8n5hNcIS6apN8Sw09iVDiGDsZT4n2Gi T0s1N8+VRtB3Fl0p0iV++m6ddfW+frGj+yXpyL4GkGs0VgvQQwkcNrJ2y 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AACsYiRZ/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHg2iKGJF3lXeCDyENhXYCGoJlPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQEhETcDCwULAgEIDgoCAiYCAgIlCxUQAgQOBYoeCA6tA4Imi0UBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYELh12BZYEMhDUSATOCey+CMQWeGwGHH4w?= =?us-ascii?q?GggWFPIoxlEoBHzh/C3EVRhIBhGQcgWN2hnCBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,382,1491264000"; d="scan'208";a="30919956" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 May 2017 16:30:40 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v4NGUev8018035 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 May 2017 16:30:40 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 23 May 2017 11:30:39 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Tue, 23 May 2017 11:30:39 -0500 From: "Max Pritikin (pritikin)" To: Toerless Eckert CC: anima-bootstrap , Anima WG , "consultancy@vanderstok.org" Thread-Topic: [Anima-bootstrap] [Anima] Concise version of BRSKI Thread-Index: AQHStW9CstO2wlN3FUyI3JGtr7rg8aHLNO2AgACAfICANtU1AIAAIiiA Date: Tue, 23 May 2017 16:30:39 +0000 Message-ID: <3AF89D2E-08BD-4A92-83F3-E80D2538EC96@cisco.com> References: <21915.1490916584@obiwan.sandelman.ca> <6168.1491913071@obiwan.sandelman.ca> <3EB7EB76-B8F6-4A64-918E-307C4F8B20E8@cisco.com> <4cb3eef653ebc2edec8160efb63e5cf6@xs4all.nl> <20170523142824.GA18931@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170523142824.GA18931@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.3] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] [Anima-bootstrap] Concise version of BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 16:30:44 -0000 DQo+IE9uIE1heSAyMywgMjAxNywgYXQgODoyOCBBTSwgVG9lcmxlc3MgRWNrZXJ0IDx0dGVAY3Mu ZmF1LmRlPiB3cm90ZToNCj4gDQo+IEl0IGlzIHF1aXRlIGZydXN0cmF0aW5nIHRvIHNlZSB0aGUg Ym9vdHN0cmFwIGRyYWZ0IGJlIGhhbmRsZWQgaW4gYSB3YXkgdGhhdCBpcyBpbXBvc3NpYmxlDQo+ IHRvIHRyYWNrOg0KPiANCj4gLSBpdCB3b3VsZCBoYXZlIGJlZW4gYmV0dGVyIG5vdCB0byBjcmVh cnRlIGFub3RocmVyIGJyYW5jaCB0aGF0IHlvdSBjYW4gb25seSBiZSBhd2FyZSANCj4gIG9mIGJ5 IGhhdmluZyBzZWVuIHRoaXMgZW1haWwNCg0KQXMgcHJldmlvdXNseSByZXF1ZXN0ZWQgdGhpcyB0 aHJlYWQgd2FzIHNlbnQgdG8gdGhlIGFuaW1hIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IHJh dGhlciB0aGFuIHRoZSBub3cgZGVwcmVjYXRlZCBib290c3RyYXAgbWFpbGVyLiBOb3Qgc3VyZSBo b3cgZWxzZSB0byBjb21tdW5pY2F0ZSBzdGF0dXMuIA0KDQpUaGUgdXAgdG8gZGF0ZSBkb2N1bWVu dCBpcyBhdmFpbGFibGUgdmlhIHRoZSBnaXRodWIgcmVwb3NpdG9yeS4gVGhpcyBpcyBpbiBhbGln bm1lbnQgd2l0aCBtdWx0aXBsZSBjb252ZXJzYXRpb25zIGF0IGlldGYgYW5kIHdhcyB0aGUgc3Vi amVjdCBvZiBhIEJvRiBhdCB0aGUgQ2hpY2FnbyBJRVRGLiBJZiB5b3UgaGF2ZSBjb25jZXJucyBh Ym91dCBob3cgZ2l0IG1pZ2h0IHdvcmsgd2l0aGluIGEgd29ya2luZyBncm91cCBwcm9jZXNzIGZs b3cgaeKAmWxsIGJldCB0aGUgYXV0aG9ycyBvZiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtdGhvbXNvbi1naXRodWItYmNwLTAwIG9yIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gdGhl IGZlZWRiYWNrLiBJIHN1Z2dlc3QgcmFpc2luZyB5b3VyIGNvbmNlcm5zIG9uIHRoZSBpZXRmLWFu ZC1naXRodWIgbWFpbGluZyBsaXN0IHRvIGVuc3VyZSB0aGV54oCZcmUgYWRkcmVzc2VkIGFzIHBh cnQgb2YgdGhhdCBicm9hZGVyIGVmZm9ydC4gDQoNCj4gLSBJZiB5b3UgdXNlIGEgbmV3IGJyYW5j aCwgaXQgd291bGQgYmUgZ3JlYXQgaWYgeW91IHdvdWxkIGhhdmUgdXBkYXRlZCB0aGUgSUVURiBh bmltYSBib290c3RyYXAgd2lraSBwYWdlDQo+ICB3aXRoIHRoaXMgaW5mb3JtYXRpb24uDQo+IC0g Zm9yIHRoZSBzYWtlIG9mIHRoZSBub24tZ2l0IGV4cGVydHMgYW1vbmdzdCB1cywgaXQgd291bGQg YmUgZ3JlYXQgdG8gYWxzbyBpbmRpY2F0ZSBzb21lDQo+ICBjb21tYW5kIGhvdyB0byByZXRyaWV2 ZSB0aGlzIGJyYW5jaC4gSSBmb3Igb25jZSB0cmllZDoNCj4gDQo+ICBnaXQgY2xvbmUgLWIgY29u Y2lzZSBodHRwczovL2dpdGh1Yi5jb20vYW5pbWEtd2cvYW5pbWEtYm9vdHN0cmFwDQoNCmh0dHBz Oi8vZ2l0aHViLmNvbS9hbmltYS13Zy9hbmltYS1ib290c3RyYXAgaW5jbHVkZXMgYSBkcm9wZG93 biB0byBzZWxlY3QgdGhlIGJyYW5jaCBpZiB5b3UganVzdCB3YW50IHRvIGxvb2sgYXQgdGhlIHNw ZWNpZmljIGZpbGVzLiBVc2luZyB0aGlzIGZvciBleGFtcGxlIHRoZSBwcmUwNiB2ZXJzaW9uIGZy b20gdGhlIGNvbmNpc2UgYnJhbmNoIGlzIGF2YWlsYWJsZSBoZXJlOg0KCWh0dHBzOi8vZ2l0aHVi LmNvbS9hbmltYS13Zy9hbmltYS1ib290c3RyYXAvYmxvYi9jb25jaXNlL2R0Ym9vdHN0cmFwLWFu aW1hLWtleWluZnJhLTA2LnR4dCANCk9uZSB3YXkgdG8gZGV0ZXJtaW5lIHdoaWNoIGJyYW5jaCBo YXMgdGhlIG1vc3QgYWN0aXZpdHkgaXMgdG8gbG9vayBoZXJlOg0KCWh0dHBzOi8vZ2l0aHViLmNv bS9hbmltYS13Zy9hbmltYS1ib290c3RyYXAvYnJhbmNoZXMvYWN0aXZlDQoNCj4gIGFuZCB0aGF0 IHRvdGFsbHkgZGlkIG5vdCB3b3JrLg0KDQpVc2luZyAtYiB3b3JrZWQgZm9yIG1lLiBOb3Qgc3Vy ZSB3aGF0IHlvdSBkaWQgd3JvbmcgdGhlbi4gDQoNCj4gIFNvIGFzIG9mIHJpZ2h0IG5vdyBpIGFt IGxvc3QgaW4gaG93IGkgc2hvdWxkIHJldmlldyB0aGlzIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50 Lg0KDQpUaGFua3MgZm9yIGpvaW5pbmcgdGhlIG1lZXRpbmcgdG9kYXkgYW5kIHZvaWNpbmcgeW91 ciBjb25jZXJucy4gVG8gaGVscCB3ZeKAmWxsIHB1c2ggdGhlIDA2IHZlcnNpb24gb2YgdGhlIGRv YyB0byBnaXZlIHlvdSBhIGJldHRlciByZWZlcmVuY2UgZm9yIGdlbmVyYXRpbmcgZmVlZGJhY2su IA0KDQotIG1heA0KDQo+IA0KPiBUb2VybGVzcw0KPiANCj4gT24gVHVlLCBBcHIgMTgsIDIwMTcg YXQgMDU6MDc6MThQTSArMDAwMCwgTWF4IFByaXRpa2luIChwcml0aWtpbikgd3JvdGU6DQo+PiAN Cj4+IFBldGVyLA0KPj4gDQo+PiBUaGUgY3VycmVudCB0ZXh0IGlzIHdvcmR5IGFuZCByZXBldGl0 aXZlIGFuZCBzYXlzIHRoaW5ncyBtb3JlIHRoYW4gb25jZSA8Z3Jpbj4uIFByaW1hcnkgZm9jdXMg aXMgdG8gcmVtb3ZlIHJlcGV0aXRpdmUgdGV4dCwgdGlnaHRlbiByZW1haW5pbmcgdGV4dCwgYW5k IGNvbnNvbGlkYXRlIG5vcm1hdGl2ZSBzdGF0ZW1lbnRzLiANCj4+IA0KPj4gQXMgYW4gaW5pdGlh bCBleGFtcGxlIHRoZSAtMDUgZHJhZnQgaGFzIDMgbWFpbiBzZWN0aW9uczoNCj4+IAlhcmNoaXRl Y3R1cmFsIG92ZXJ2aWV3DQo+PiAJZnVuY3Rpb25hbCBvdmVydmlldyAoY29udGFpbnMgZGVzaWdu IGNvbnNpZGVyYXRpb25zIGRpc2N1c3Npb25zKQ0KPj4gCXByb3RvY29sIGRldGFpbHMNCj4+IFRo ZSBpbml0aWFsID8/P2NvbmNpc2U/Pz8gYnJhbmNoIGNvbW1pdCBtb3ZlcyB0aGUgZnVuY3Rpb25h bCBvdmVydmlldyB0byB0aGUgYXBwZW5kaXguIFN1YnNlcXVlbnQgY29tbWl0cyBhcmUgcmVzb2x2 aW5nIG5vcm1hdGl2ZSB0ZXh0cyB0aGF0IHdlcmUgaW4gdGhlcmUgYnkgbW92aW5nIG5lZWRlZCBi aXRzIGJhY2sgaW50byB0aGUgcHJvdG9jb2wgZGlzY3Vzc2lvbi4gWW91IGNhbiBmb2xsb3cgYWxv bmcgdmlhIHRoZSBnaXQgcmVwb3NpdG9yeSBoZXJlOg0KPj4gCWh0dHBzOi8vZ2l0aHViLmNvbS9h bmltYS13Zy9hbmltYS1ib290c3RyYXAvY29tcGFyZS9jb25jaXNlDQo+PiANCj4+IFRoZXJlIHdh cyBhIGNvbW1lbnQgdGhhdCB0aGUgZGVzaWduIGNvbnNpZGVyYXRpb25zIGFyZSB1c2VmdWwgYW5k IG1pZ2h0IGJlIGFwcHJvcHJpYXRlIHRvIGtlZXAgaGVyZSBvciBpbiBhbm90aGVyIGRvY3VtZW50 LiBBdCB0aGUgbW9tZW50IEkgZG9uPz8/dCBoYXZlIGEgZm9ybXVsYXRlZCBwb3NpdGlvbiBvbiB0 aGF0LiAgDQo+PiANCj4+IC0gbWF4DQo+PiANCj4+PiBPbiBBcHIgMTgsIDIwMTcsIGF0IDM6Mjcg QU0sIHBldGVyIHZhbiBkZXIgU3RvayA8c3Rva2NvbnNAeHM0YWxsLm5sPiB3cm90ZToNCj4+PiAN Cj4+PiBIaSBNYXgsDQo+Pj4gDQo+Pj4gZXhjZWxsZW50IGlkZWEuIEkgbG9va2VkIGF0IHRoZSBw cmVzZW50IHZlcnNpb24sIGFuZCB0aGVyZSBpcyBzdGlsbCBhIGxvdCBvZiB0ZXh0Lg0KPj4+IFdo ZXJlIGluIHRoZSB0ZXh0IGRvIHlvdSB3YW50IHRvIHJlZHVjZSBtb3JlPyBXaGF0IGlzIHRoZSBl bmQtb2JqZWN0aXZlPw0KPj4+IEFuZCB3aWxsIHRoaXMgYmVjb21lIHRoZSBmaW5hbCBkb2N1bWVu dCwgb3IgaXMgaXQgYSBzdHVkeSB0aGF0IHdpbGwgYmUgdXNlZCBsYXRlciBmb3IgZWRpdGluZyB0 aGUgZmluYWwgZG9jdW1lbnQ/DQo+Pj4gDQo+Pj4gUGV0ZXINCj4+PiANCj4+PiBNYXggUHJpdGlr aW4gKHByaXRpa2luKSBzY2hyZWVmIG9wIDIwMTctMDQtMTUgMDA6MzQ6DQo+Pj4+IEZvciB0aG9z ZSBvZiB5b3UgdHJhY2tpbmcgdGhlIGdpdCByZXBvc2l0b3J5IHBsZWFzZSBub3RlIHRoZSBleGlz dGVuY2UNCj4+Pj4gb2YgYSBuZXcgYnJhbmNoLiBBcyB3YXJuZWQgST8/P20gc2lnbmlmaWNhbnRs eSByZWR1Y2luZyB0aGUgdGV4dC4gVGhpcw0KPj4+PiB3b3JrIGlzIGdvaW5nIG9uIGluIHRoZSBi cmFuY2ggPz8/Y29uY2lzZT8/Py4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+Pj4+IEFuaW1hQGll dGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEN Cj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+IEFuaW1hLWJvb3RzdHJhcCBtYWlsaW5nIGxpc3QNCj4+IEFuaW1hLWJvb3RzdHJhcEBpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYS1ib290 c3RyYXANCj4gDQo+IC0tIA0KPiAtLS0NCj4gdHRlQGNzLmZhdS5kZQ0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQW5pbWEtYm9vdHN0cmFw IG1haWxpbmcgbGlzdA0KPiBBbmltYS1ib290c3RyYXBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYS1ib290c3RyYXANCg0K From nobody Tue May 23 09:36:12 2017 Return-Path: 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 74357124D85; Tue, 23 May 2017 09:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9AaMyzwZnql; Tue, 23 May 2017 09:36:08 -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 931CC120046; Tue, 23 May 2017 09:36:08 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4NGZwkt013538 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 May 2017 11:35:59 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Brian E Carpenter , The IESG Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> From: Adam Roach Message-ID: <067da3a3-47f8-2f3e-bb7e-db25d45fb8e4@nostrum.com> Date: Tue, 23 May 2017 11:35:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 16:36:10 -0000 On 5/22/17 22:57, Brian E Carpenter wrote: > Just cherry-picking a COMMENT point that does need some thinking: > >> The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, but >> no way to register additional values with IANA. This does not seem >> future-proof. > This is a tricky point. The values are of course already IANA values from > https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > If we wanted to add, say, SCTP that would be straightforward enough, without > bothering IANA. The document doesn't actually say that the values are taken from that registry, though, does it? I mean, I noticed the parallel, but without any explicit mention, I assumed that the values were inspired by the registry rather than bound to it. For example, SIP has response codes like "200 OK", "300 Multiple Choices," "301 Moved Permanently," "400 Bad Request," "401 Unauthorized," and so on. These will all look very familiar to anyone who has worked with HTTP -- but that doesn't mean they use the same registry. It sounds like the extensibility plan you had in mind here was something like "use the numbers from the protocol numbers registry until we need something new, at which time, panic." Minimally, I'd like to see that plan written down in this document. Ideally, I'd like to see a different plan. But whatever is intended needs to be documented, and the relationship to existing registries (if any) needs to be crystal clear rather than implied. The fact that you wrote it to mean one thing and I read it to mean the other is a pretty compelling example of how doing this in an implicit fashion goes wrong. > But what if we wanted to specify, say, HTTP or QUIC or anything else that > doesn't run directly over IP? Well, if you don't have a registry at all, then it's going to be even harder, isn't it? ;) In particular, one of the ways I've used registries in the past -- and I don't think this is uncommon -- is seeing a value in a protocol that I didn't recognize, going to the governing IANA registry, and looking up that codepoint to find the corresponding protocol definition. Re-using the protocol numbers registry won't allow developers to do that (unless we start adding GRASP RFC numbers to the table, which I suspect would face some resistance). My strong recommendation here would be to define a new GRASP protocol numbers registry, state that any values in the GRASP registry that correspond to a protocol in the https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml registry SHOULD use the same number (which you imply by your current choices to be a Good Thing), and that any values that are appropriate for GRASP but not general protocol numbers SHOULD be assigned by IANA starting with 252, with each subsequent such registration using the next smaller number available. > My concern is that this may turn out to be a much broader problem: how > do we express that some upper layer protocol wants to run over a variety of > "transport" layers, some of which are traditional transport-over-IP > and some of which are transport-over-UDP or whatever. Yes, maybe there > should be a registry for that, but it would definitely not be specific > to GRASP. That seems like an ocean-boiling exercise with no discernible benefit. It has the clear anti-benefit of lacking the code-point-to-RFC-mapping that I describe above. I would strongly desire that this never happen. /a From nobody Tue May 23 13:12:56 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0452312EB0D; Tue, 23 May 2017 13:12:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Deborah Brungard To: "The IESG" Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149557037501.28451.8442609199900920951.idtracker@ietfa.amsl.com> Date: Tue, 23 May 2017 13:12:55 -0700 Archived-At: Subject: [Anima] Deborah Brungard's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 20:12:55 -0000 Deborah Brungard has entered the following ballot position for draft-ietf-anima-grasp-12: 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-anima-grasp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The comparison text to routing protocols is outdated as ignores TE which can support any link/node attribute desired (bandwidth, availability, latency, etc.), discovery, bidirectional negotiation for use, and autoconfiguration (e.g. RFC 5340). When first discussing automatic networks, it may have been useful to compare with routing, as at a very high level view, it may look similar, but I think it is no longer relevant, and very confusing for a routing person. Suggest instead of a "I'm more complex than you" approach, remove these paragraphs. A few minor edits will fix. Suggest to remove the first paragraph of Section 2.2. Or edit: 1. links are no longer simple: "consider simple link"/s/"consider link" 2. Delete from "nodes need a consistent, although partial, view of the network topology in order for the routing algorithm to converge. Also, routing is mainly based on simple information synchronization between peers, rather than on bi-directional negotiation." I think what you want to infer by "partial" is for a protocol instance/region. But there is support today for multi-layer and multi-region networks. And convergence scale is implementation. But none of this is relevant to anima so best is to delete vs. trying to fix. Appendix E Remove the paragraph on routing or preface with "Early routing protocols.." And the paragraph on RSVP is really not relevant for this comparison. Unless want to edit, as RSVP-TE does do "discovery". From nobody Tue May 23 13:35:07 2017 Return-Path: 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 9A33212EA8C; Tue, 23 May 2017 13:34:58 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75klRija8VsN; Tue, 23 May 2017 13:34:56 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 9A52112EB13; Tue, 23 May 2017 13:34:56 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id n23so29800409pfb.3; Tue, 23 May 2017 13:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hFHONYGYgnWG8c5jBq2ZaIrxu3mEr69haExjC8sjIhs=; b=EPAD90ClN+hThuT3XErHWowGO+mNWFAZMV0uyzZKKsa3eb3G5X/+7obNKTi5Tdt+wy daJO9iVkt1OWWegPyVS+6++UQYpys3dJuY10Cyr16NV3vnX3lP2G5jN/IqtQhgB8Ixlr 90aSyUsSPLNJ8vp6nlC0zAZZyznxj6Dfd4o4I/bK02rZnILfqBLzfV3pq0IcwNAaI2Jy KFeOwe1gZ7w8Rsvkrcd0OXgWeH5AmLFCKzhT7SFjk/K7lKgklQQZEX1pP0E1paIKUMei pIWT7+N0nrbqAMLqFRyfqq1l9nE8aK7jB2GUWuWuTpKWISaootkILL9VomCy1rF3vJYa lULA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=hFHONYGYgnWG8c5jBq2ZaIrxu3mEr69haExjC8sjIhs=; b=HLTx2qbH4feiU4f807k4YE9C1vPI37kL7f4n8v7ddRjvu8NWu8z5dVRsSjdDEXRQtK npVU+ViarKTLvoWGprODA4KEV00gQlPuk1Ig/zKDT2GDZVY+uw8zB5xBAUjFK4w8aE/6 3GTQOUY97DryiRajKTpWzCi6HnEXB0umiVO2gBOXYzYO5GOLPhlGKJAi0TuUfZ8wDPQi jRfbNhlLBoqSv0GlfkVPk6Jh4jpfqaTsJoIjxJVsWk2heEY4EYS4OnMxy5nuUcby+mch OPHu60Zapkdxa//vXurtSdhJRwJP3yxKvcoS/x+dzMYWlvfzB6OnF8I0DWWeJFpmIjqL Z8/g== X-Gm-Message-State: AODbwcDLQEgIaFFvWWIEHXEfOYQEDzRK3QNEvL38wvZ4nRWsUY5aXdpY UQSqo7zmmujXgw== X-Received: by 10.99.50.135 with SMTP id y129mr35065023pgy.138.1495571696061; Tue, 23 May 2017 13:34:56 -0700 (PDT) Received: from [10.100.103.42] (210-55-57-56.adsl.xtra.co.nz. [210.55.57.56]) by smtp.gmail.com with ESMTPSA id j17sm4006676pfk.23.2017.05.23.13.34.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 13:34:55 -0700 (PDT) To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , The IESG Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149555276275.18049.7515853778089282062.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <68206ee7-9e3d-cfda-5466-247339352975@gmail.com> Date: Wed, 24 May 2017 08:34:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149555276275.18049.7515853778089282062.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-anima-grasp-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 20:34:59 -0000 On 24/05/2017 03:19, Mirja K=C3=BChlewind wrote: =2E.. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > 1) Use of transport protocols is not sufficiently defined At this point I think we are only talking about wording; the intention of the -12 version is pretty much what you say below, following some earlier IESG comments. (Martin reviewed the -11 version.) > Especially the following text in section 3.5.3 seems not to reflect lat= er > assumptions correctly; it seems to be assumed that TCP is used for all > messages other than the discovery and therefore reliable transport is > provided for these message (see sections 3.5.5, 3.8.4 and 3.8.5): > "All other GRASP messages are unicast and could in principle run over > any transport protocol. An implementation MUST support use of TCP. > It MAY support use of another transport protocol but the details are= > out of scope for this specification. However, GRASP itself does not= > provide for error detection or retransmission. Use of an unreliable= > transport protocol is therefore NOT RECOMMENDED." >=20 > In general the usage of the transport protocols is not well enough > specified, see also Spencer's comments and this part of Martin's tsv-ar= t > review (Thanks!): > "* Usage of UDP: This document is not discussing any of the aspects in > RFC 8085. Every usage of UDP is required by IETF consensus to review RF= C > 8085 and to address at least the applicable subset of issues listed in > RFC 8085 (or the predecessor RFC 5405). >=20 > * Starting with UDP and switching to TCP for the data transfer looks li= ke > the right do. However, UDP should be really only used to discover other= > devices, but not piggy back further protocol mechanics. However, this > document is not really specific on how to make use of TCP, for instance= , > how long are TCP connections kept open or closed down after a protocol > exchange (persistent vs temporary connections). What happens if a TCP > connection is shutdown by one end or is forcefully closed, e.g., by a > reset?" >=20 > I would recommend, as assumed in the rest of the document, to update > section 3.5.3 to only use UDP for the initial recovery message and open= a > TCP connection for the discovery response and require that all other > messages to be sent over TCP (also removing any option to use any other= > reliable transport because TCP seems to be the right choice here.) > Further, additional guidance is needed when to open and close a TCP > connection (or keep it alive for later use) and what to do if the > connection is interrupted. >=20 > 2) Time-out handling > section 3.5.4.4: "Since the relay device is unaware of the timeout set = by > the original > initiator it SHOULD set a timeout at least equal to > GRASP_DEF_TIMEOUT > milliseconds." > Should a relay really maintain an own time-out? Wouldn't it be sufficie= nt > to just relay again if another discovery message is received. Otherwise= > this can lead to an amplification, when the own time-out expires and > another relay message is sent when another discovery message is receive= d > due to the time-out of the originating peer. Yes, there is an issue in this area, which some very recent testing of th= e prototype showed up. I will propose text next week. >=20 > Further in relation to the point about, this should be more specific: > section 3.5.4.4: "Also, it MUST limit the total rate at which it relays= > discovery messages to a reasonable value, in order to mitigate > possible denial of service attacks. " >=20 > 3) Version and extensibility: > section 3.5.4.5: "A possible future extension > is to allow multiple objectives in rapid mode for greater > efficiency." > How can this extension be defined if there is no version mechanism? Simply by adding it - the other end sends back M_INVALID if it doesn't understand. That goes for all potential extensions. >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- Will deal with the rest next week when back from vacation. Brian =20 > Other mostly editorial comments: > - ASA needs to be spelled out in the intro. > - I would recommend to move section 2 and 3.3 into the appendix > - section 3.5.4.2: "A neighbor with multiple interfaces will respond wi= th > a cached discovery response if any." > "cached response" is explained in the next section and not clear in > this paragraph. > - section 3.5.4.3: "After a GRASP device successfully discovers a locat= or > for a Discovery > Responder supporting a specific objective, it MUST cache this > information, including the interface index via which it was > discovered. This cache record MAY be used for future negotiation or= > synchronization, and the locator SHOULD be passed on when > appropriate > as a Divert option to another Discovery Initiator." > Not sure why the first is a MUST and the later is a SHOULD. I guess = a > SHOULD for caching would be sufficient. > - section 3.8.6 "If a node receives a Request message for an objective > for which no > ASA is currently listening, it MUST immediately close the relevant > socket to indicate this to the initiator." > How is that indicated? Should really be further clarified > - Also section 3.8.6: "In case of a clash, it MUST discard the Request > message, in > which case the initiator will detect a timeout." > Why don't you send an error message instead? How does the initiator > know that is should retry (assuming there is a TCP connection underneat= h > that provides reliable transport)? > - Also section 3.8.9: "If not, the initiator MUST abandon or restart th= e > negotiation > procedure, to avoid an indefinite wait." > How does the initiator decide for abandoning or restarting instead? > Needs clarification! > - Could be useful to include an optional reasoning field in the Invalid= > Message and make copying the received message up to the maximum message= > size of this message a SHOULD (section 3.8.12.). > - Not sure I fully understand the purpose of the No Operation Message > (section 3.8.13.). If you just want to open a socket for probing, you > perform a TCP handshake and send a RST right after. No need for further= > application layer interactions. And should there also be an optional > reasoning phrase? > - Not sure why the objectives flag is needed. I assume that unknown > objectives are ignored anyway and if a objective is known the receiver > should know if that objective is valid for the respective message type > (section 3.10.2). > - section 3.10.4: "An issue requiring particular attention is that GRAS= P > itself is a stateless protocol." > It's not. It caches information and needs to remember previous > messages sent to reply correctly. > - section 5: "Generally speaking, no personal information is expected t= o > be > involved in the signaling protocol, so there should be no direct > impact on personal privacy." > I don't think this is true because the protocol is so generic that y= ou > cannot say anything about the services it is used for. > Please see also further comments from Martin's tsv-art review (Thanks > again!)! >=20 >=20 >=20 From nobody Tue May 23 13:53:52 2017 Return-Path: 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 42059127A91; Tue, 23 May 2017 13:53:45 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoWa1-yhxgMk; Tue, 23 May 2017 13:53:42 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 A0C1D127B31; Tue, 23 May 2017 13:53:42 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id w69so29903592pfk.1; Tue, 23 May 2017 13:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=c9LkRER2mErkUCIUScL+fZ7GY4oBfAAIidoUydezW9M=; b=E/jjW/PMNQMFPX9qIzLOHN0Sw/xUHgV/0f9bJVIEtW19HUH2UUaYJACvD0WgA1cTFi JQioe6oiTNoMntLLSTE9FGwTZlRLZeF26LeEbK0v1nFgKb984pV6jLHVtoiV39ZuK2gP JGckztcrwUqTrZyDKLqwboioCkYgSOnrdhGTahpMML0QFTUps/E4W4uCsNu22SKTdR10 4kotR/yqpKjmEoYjS4Iov7N5FlECA1MXZeemOp/jSFfzcp33vimH5h+YRs+ogflrXqc5 Cxpv8s2FiownpKEGORHAe/BGRfBMufJEisnnAPIiOt44ilYaYz3jycM+IireGOYRgOV6 +XWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=c9LkRER2mErkUCIUScL+fZ7GY4oBfAAIidoUydezW9M=; b=tlNGpIWxFyD+kLUOAeB4C4ZdDuXtABaDyVAldNBoYbhypRFa0u8y4g74eN0V0fbrUZ SFcfD3EsSCAh1nsSZvlhtVAbh08m+SUpqYq9fxH7icuXwyXt9zYFlZFME56NIrypbRRN iKoHYCAUhKgsuEvL8tfOSVOaw1fgBqNOCR1XVZxA6zYdONn1QFzrd9q4awaddRzwsrHS nb0+woQ1hSv57CqFF/QEjqimEVarHETsUAWpvkU1XBewGZGh8Sp3jrfZ8DxO0lg2uNLw s3lgzSI4CUsE+CXgmh9k3HZ0YK5ufiEmjYkhMDk12KAe7/BF+/QgL0bCbvplnI0YZoVm +COA== X-Gm-Message-State: AODbwcCr0kSPSmErfg/ZlBS9+A7brpy3bI8h0wclYcpmcqbXjV+vsfmb J6vjVqhl79hvPA== X-Received: by 10.84.173.195 with SMTP id p61mr38570121plb.83.1495572822015; Tue, 23 May 2017 13:53:42 -0700 (PDT) Received: from [10.100.103.42] (210-55-57-56.adsl.xtra.co.nz. [210.55.57.56]) by smtp.gmail.com with ESMTPSA id g86sm3124135pfe.116.2017.05.23.13.53.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 13:53:41 -0700 (PDT) From: Brian E Carpenter To: Martin Stiemerling , anima@ietf.org Cc: tsv-art@ietf.org References: <6b290c47-5ab1-78e4-9f54-fa4f0679143b@gmail.com> Organization: University of Auckland Message-ID: <192f8891-5509-5201-1335-33bc7a04b7eb@gmail.com> Date: Wed, 24 May 2017 08:53:40 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <6b290c47-5ab1-78e4-9f54-fa4f0679143b@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] TSV-ART review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 20:53:45 -0000 Martin, Thanks for the thorough review. First reactions: On 23/05/2017 21:05, Martin Stiemerling wrote: > Hi all, >=20 > Please find below my review of draft-ietf-anima-grasp-11. > The comments below are about -11 of the draft, as I did work on this=20 > version and did unfortunately not have time to go through -12. >=20 >=20 > I've reviewed this document as part of the transport area review team's= =20 > ongoing effort to review key IETF documents. These comments were writte= n=20 > primarily for the transport area directors, but are copied to the=20 > document's authors for their information and to allow them to address=20 > any issues raised. When done at the time of IETF Last Call, the authors= =20 > should consider this review together with any other last-call comments = > they receive. Please always CC tsv-art@=E2=80=A6 if you reply to or for= ward this=20 > review. >=20 > Summary: > This draft has serious issues, described in the review, and needs to be= =20 > rethought. >=20 >=20 > General comments: > * The title is partially misleading as this document is setting=20 > requirements for the protocol and is additionally defining the protocol= =2E=20 > This is made obvious in the abstract, but nonetheless, the title is=20 > misleading I really don't see that. It's very general title. >=20 > * Document structure: I am not sure why the requirements are listed in = > Section 2. The are never ever used in the document to motivate any=20 > design decision or reference to. So what is the purpose of having these= =20 > requirements here? Couldn=E2=80=99t and shouldn=E2=80=99t they be liste= d in a separate=20 > document? We had specific instructions from our original AD not to do separate requirements analysis. We've also asked the WG a couple of times whether to move the requirements to an Appendix and never got a Yes on that. >=20 > * Security: There is no security proposed or discussed for GRASP in thi= s=20 > document. There are solely statements about generic security, such as i= n=20 > Section 1 =E2=80=9Ea secure and strongly authenticated environment=E2=80= =9C or Section=20 > 3.5.2.1. "Messages MUST be authenticated and encryption MUST be=20 > implemented=E2=80=9C. So how must they be authenticated and encrypted a= nd why?=20 > What is the standard set of protocols to be used for this and what is=20 > the minimal set of crypto algorithms to be implemented to make this wor= k? We're on version 12 now but I'm at a loss to know what is unclear about the statement in https://tools.ietf.org/html/draft-ietf-anima-grasp-12#section-3.5.1 (and the ACP is now a normative reference). > ************************************************************ > This document is always using the escape hatch when it comes to securit= y=20 > in any respect! > ************************************************************ It isn't an escape hatch, it's an explicit statement: "Required External Security Mechanism" =20 > * Usage of UDP: This document is not discussing any of the aspects in=20 > RFC 8085. Every usage of UDP is required by IETF consensus to review RF= C=20 > 8085 and to address at least the applicable subset of issues listed in = > RFC 8085 (or the predecessor RFC 5405). The somewhat weak language about unicast UDP has gone in version 12: https://tools.ietf.org/html/draft-ietf-anima-grasp-12#section-3.5.3 We now say "Use of an unreliable transport protocol is therefore NOT RECOMMENDED." As far as multicast goes, https://tools.ietf.org/html/rfc8085#section-4.1 is new work but at a quick glance I don't think there is any concern. We use link-local multicast with precautions against excessive rates or loops. RFC8085 seems to be worrying about completely different types of usage. Of course we can add a statement about that. >=20 > * Starting with UDP and switching to TCP for the data transfer looks=20 > like the right do. However, UDP should be really only used to discover = > other devices, but not piggy back further protocol mechanics. However, = > this document is not really specific on how to make use of TCP, for=20 > instance, how long are TCP connections kept open or closed down after a= =20 > protocol exchange (persistent vs temporary connections).=20 They can all be temporary. We can add that. > What happens if=20 > a TCP connection is shutdown by one end or is forcefully closed, e.g., = > by a reset? What's to say? The operation fails, and then it's up to the user (the autonomic service agent) what to do next. If that isn't quite obvious, we can certainly add it. >=20 > * There is no versioning support in GRASP. Why are we still developing = > protocols that do not have versioning support in it? Because the protocol is indefinitely extensible by adding message types and options. We really don't see any need for a version number. The M_INVALID message was added so that old and new code can discover what works and what doesn't. >=20 > * IPv4/IPv6 simultaneous use: I believe the email describing the -12=20 > update of the draft says that IPv4 and IPv6 should not be mixed, so I=20 > can skip over this. >=20 > Detailed comments: >=20 > * Section 2.1: These are not protocol requirements but system=20 > requirements. It would be really good to separate them in the list of=20 > requirements. >=20 > * Section 2.1, Requirement D2: What is this requirements saying? Is it= =20 > =E2=80=9Eit should just work whatever?=E2=80=9C Yes. There should be no uncaught exceptions. That's a pretty general rule in autonomic systems, so it must also be true in the protocol itself. >=20 > * Section 2.1, Requirement D7: What is the rest of the network in the=20 > first bullet point? All anima devices or every single element of the=20 > network? All autonomic devices; this could be clarified. >=20 > * Section 2.2, Requirement SN7: I am not sure if any of these points in= =20 > this requirement related to any part of the GRAPS protocol. If so, you = > can for sure add forward references or backward references in the=20 > protocol specification. That's hard to do. It's really saying (computer science hat on) that GRAS= P needs to be powerful enough to express all kinds of semantics that you might need. >=20 > * Section 2.3, T1 & T2 are good, but how is this fulfilled by the proto= col? T1 is in practice fulfilled by the choice of CBOR and its ability to expr= ess almost any kind of data structure. T2, by the ability to add message type= s and options in future. (But getting back to our original instructions fro= m Benoit, do we really need to map requirements:features ?) > * Section 3.2, end of page 12, =E2=80=9Eappropriate global-scope addres= s=E2=80=9C: so=20 > GRASP is not intended to run networks that use private RFC 1918 address= es? Well, we tend to think in IPv6 terms, where anything that isn't link-loca= l has global scope. And we *really* hope that GRASP itself will always run = over IPv6 even if it's managing an IPv4 data plane. But you're right, it shoul= d be phrased to cover the RFC1918 case. >=20 > * Section 3.2, head of page 13: the discussion about interfaces. I am=20 > not sure that calling GRASP interfaces just interfaces helps. Why not=20 > calling interfaces interfaces and GRASP interfaces if the are used? or = > active interfaces, etc? That's been tweaked in the -12 draft already. >=20 > * Section 3.3: This section is again bringing up a number of=20 > requirements. Wrong place in the document? Sorry, I don't see any requirements there; it describes decisions IMHO. >=20 > * Section 3.3, page 14: the unsolicited flooding mode sounds really bad= =2E=20 > Has this aspect looked at in terms of how many GRAPS nodes are expected= =20 > to live on in a single link-local multicast domain (hoping that non=20 > link-local multicast is excluded per se). It is a trade-off, but we have use cases (such as distributing Intent to every autonomic node, a low frequency operation) where flooding really= does look like a necessary tool. =20 > * Section 3.3: last bullet on page 14 and first bullet on page 15: what= =20 > is this saying other than it is complicated? Aren=E2=80=99t there any t= angible=20 > details to this? I don't really understand your point there. =20 > * Section 3.4: > " An instance of GRASP is expected to run as a separate core module, > providing an API (such as [I-D.liu-anima-grasp-api]) to interface t= o > various ASAs. These ASAs may operate without special privilege, > unless they need it for other reasons (such as configuring IP > addresses or manipulating routing tables).=E2=80=9C > This is implementation specific and does not belong in a protocol=20 > specification. Disagree. I think an implementer needs to keep this in mind. > * Section 3.5.1, page 17: =E2=80=9Evirtualized over the ACP=E2=80=9C =E2= =80=94 what does this=20 > mean and how it is done? See the ACP draft. >=20 > * Section 3.5.1, page 17: =E2=80=9EIf there is no ACP, one=E2=80=9C the= re are two=20 > options listed for this case, but which is used when? I think section 3.5.2 covers this clearly. >=20 > * Section 3.5.1, page 17: =E2=80=9Estrong authentication=E2=80=9C =E2=80= =94 what is strong=20 > authentication and what needs to be supported by a minimal, but=20 > interoperable implementation? This is extremely underspecified. See the ACP draft or in 3.5.2. =20 > * Section 3.5.1, page 17: "Network interfaces could be at different=20 > security levels,=E2=80=9C what is a security level in the context of th= is=20 > document and specifically here. OK will clarify >=20 > * Section 3.5.1, page 17: "discovery messages MUST be secured, with one= =20 > exception mentioned in=E2=80=9C =E2=80=94 how secured? This is extremel= y underspecified. See the ACP draft or in 3.5.2. >=20 > * Section 3.5.2 s/GRAPS subject/GRAPS are subject/ OK >=20 > * Section 3.5.2.1., page 17: "As mentioned in Section 3.3=E2=80=9C this= isn=E2=80=99t=20 > mentioned in this place or I cannot correlate it. Will check >=20 > * Section 3.5.2.1., page 17 > " implemented. TLS [RFC5246] and DTLS [RFC6347] based on a Public Ke= y > Infrastructure (PKI) [RFC5280] are RECOMMENDED for this purpose. > Further details are out of scope for this document.=E2=80=9C > How bad is this that TLS and DTLS are RECOMMENDED but the usage is not = > specified? Because we decided it was out of scope for now.=20 >=20 > * Section 3.5.2.2: Are there any measures in the protocol to ensure tha= t=20 > datagrams have really been sent on the same link? I haven=E2=80=99t see= n any=20 > measures. As far as I can tell that's an implementation detail that depends on the socket API. >=20 > * Section 3.5.2.3.: > " by TLS. A separate instance of GRASP is used, with its own copy of= > all GRASP data structures. This instance is nicknamed SONN - Secur= e > Only Neighbor Negotiation.=E2=80=9C > I am not sure why this document is trying to mandate how implementers=20 > are organizing their implementation and how instances are named? Because this is how we can specify a minimal amount of security during th= e bootstrap process that depends on GRASP. > * Section 3.5.2.3, page 19, end of bullet list: "Further details are ou= t=20 > of scope for this document.=E2=80=9C What further details? Is the WG no= t sure=20 > what the missing details are? Again, implementation details that are very likely o/s dependent. > * Section 3.5.3.: > "They MUST NOT be fragmented, and therefore MUST > NOT exceed the link MTU size.=E2=80=9C > How should the protocol ensure that such datagrams are not fragmented=20 > and do not exceed the MTU? By magic? I think this needs rephrasing. >=20 > * Section 3.5.3.: " Use of an unreliable transport protocol is therefor= e=20 > NOT RECOMMENDED.=E2=80=9C =E2=80=94 very good guidance =E2=80=94 thank = you! :-) >=20 > * Section 3.5.3., end of page 19: >=20 > * Section 3.5.4.4: > "Since the relay device is unaware of the timeout set by the original > initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEO= UT > milliseconds.=E2=80=9C >=20 > The timeout set by the initiator seems to be important, so why is this = > value not communicated by the initiator within GRASP? As I replied to Mirja, we do need a little more work on this text. >=20 > * Section 3.5.5: It is unclear to me if the messages here are expected = > to be sent over TCP or nor? This is not clear. Will clarify >=20 > * Section 3.5.5, page 24 and also Section 3.5.6.1: > " request is sent (see Section 3.8.6). If no reply message of any ki= nd > is received within a reasonable timeout, the negotiation request MA= Y > be repeated, with a newly generated Session ID (Section 3.7). An > exponential backoff SHOULD be used for subsequent repetitions.=E2=80= =9C > What is a reasonable time out? And why is this need if TCP is used? TCP= =20 > provides reliable data transfer=E2=80=A6 Right, but the other end might die. >=20 > * Section 3.5.5, page 24: > " about different objectives. Thus, GRASP is expected to be used in = a > multi-threaded mode. Certain negotiation objectives may have > restrictions on multi-threading, for example to avoid over-allocati= ng > resources. > =E2=80=9E > Again, talking about the implementation. This is not a protocol=20 > specification, isn=E2=80=99t it? Again, an area where implementers need to pay attention. >=20 > * Section 3.5.6.2 (and other places in the document): What is the GRASP= =20 > core? Maybe need to mention that in the terminology section. >=20 > * Section 3.5.6.2, page 26: > =E2=80=9E the result is zero. Also, it MUST limit the total rate at = which it > relays Flood Synchronization messages to a reasonable value, in ord= er > to mitigate possible denial of service attacks. It MUST cache the > =E2=80=9E > What is a reasonable value? I'm not sure we can put a number on it. It is surely technology-dependent= =2E >=20 > * Message encoding: What is the encoding to be supported for "reason =3D= =20 > text ;optional error message=E2=80=9C Is there are any minimal standar= d to be=20 > supported, such as 7 bit ASCII or UTF-8 or whatever? It is intended to be UTF-8, if that isn't clear it needs to be written. Regards, Brian (in a rush, on vacation) >=20 > Best regards, >=20 > Martin Stiemerling >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Tue May 23 23:52:42 2017 Return-Path: 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 5925D1205D3 for ; Tue, 23 May 2017 23:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6EdXUw3YGEL for ; Tue, 23 May 2017 23:52:39 -0700 (PDT) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274FA1204DA for ; Tue, 23 May 2017 23:52:38 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:217]) by smtp-cloud3.xs4all.net with ESMTP id Q6sd1v0090nKt58016sdnr; Wed, 24 May 2017 08:52:37 +0200 Received: from AMontpellier-654-1-156-89.w90-0.abo.wanadoo.fr ([90.0.251.89]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 24 May 2017 08:52:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 24 May 2017 08:52:37 +0200 From: peter van der Stok To: "Max Pritikin (pritikin)" Cc: Toerless Eckert , anima-bootstrap , Anima WG , consultancy@vanderstok.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <3AF89D2E-08BD-4A92-83F3-E80D2538EC96@cisco.com> References: <21915.1490916584@obiwan.sandelman.ca> <6168.1491913071@obiwan.sandelman.ca> <3EB7EB76-B8F6-4A64-918E-307C4F8B20E8@cisco.com> <4cb3eef653ebc2edec8160efb63e5cf6@xs4all.nl> <20170523142824.GA18931@faui40p.informatik.uni-erlangen.de> <3AF89D2E-08BD-4A92-83F3-E80D2538EC96@cisco.com> Message-ID: <579b63e48f3894706b1c0550191b6366@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Anima] [Anima-bootstrap] Concise version of BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 06:52:40 -0000 Hi Max, > > Thanks for joining the meeting today and voicing your concerns. To > help we’ll push the 06 version of the doc to give you a better > reference for generating feedback. > > - max I'm looking forward to that version. I did like the lay-out of -06pre. Can you make sure that all terminology is consistent, like circuit proxy, join proxy, proxy; join registrar, domain registrar, cloud registrar, and others. (also in the figures) If they are different concepts, please specify their differences. many thanks, peter From nobody Wed May 24 09:52:15 2017 Return-Path: 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 4119712EB5B for ; Wed, 24 May 2017 09:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 Yza-qNphsYhH for ; Wed, 24 May 2017 09:52:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6A712EB5A for ; Wed, 24 May 2017 09:52:12 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B7B012009E; Wed, 24 May 2017 12:52:11 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6E13E6380F; Wed, 24 May 2017 12:52:11 -0400 (EDT) From: Michael Richardson To: anima@ietf.org CC: ietf@kuehlewind.net In-Reply-To: <149555276275.18049.7515853778089282062.idtracker@ietfa.amsl.com> References: <149555276275.18049.7515853778089282062.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-anima-grasp-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 16:52:14 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mirja K=C3=BChlewind wrote: > a TCP connection for the discovery response and require that all other > messages to be sent over TCP (also removing any option to use any oth= er > reliable transport because TCP seems to be the right choice here.) Some parts of GRASP are really begging for SCTP :-) I wish it was more clearly an option.... no firewalls in the ACP to screw i= t up. > 3) Version and extensibility: section 3.5.4.5: "A possible future > extension is to allow multiple objectives in rapid mode for greater > efficiency." How can this extension be defined if there is no version > mechanism? :-) Try the new extension and get back M_INVALID if not suppored. I insisted upon M_INVALID for this reason. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlklujsACgkQgItw+93Q 3WVLrAgAnT+4a/7y/2PY863V28QiRGzZiyMPIU4pr3B+YgpntaNbhOEU7s5lMAuG joV+Y3dxwAbXd+TCM6h71yL6cpwo995PhJGuJigH4O+fKfIpLa5XV0c11HaRV04b NYB+lz2mXjG4sldjn+P3wn2t7sbGHjRsILirZnNBdPhmTzqxNC3ib//anBa+gKxG DvOPXymVX70YG4q9yHc6EHgh9IqNR1xODbeunvZhCtcZ+czuX/SkSFy8pTrGi2h/ asWa6y/tdmE31sRKRd3sSivrjT94TOHBpBVz/+F9ef0teQn5JySACKelBk2IOBPg AtICcJPIP3tuX0s5mmBweFfKjg0S3Q== =ckyz -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 24 10:07:32 2017 Return-Path: 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 8B5F21200CF; Wed, 24 May 2017 10:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 9Ku7T3tcOM5B; Wed, 24 May 2017 10:07:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C3012EB71; Wed, 24 May 2017 10:07:27 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7C1AE2009E; Wed, 24 May 2017 13:07:27 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 266F26380F; Wed, 24 May 2017 13:07:27 -0400 (EDT) From: Michael Richardson To: Adam Roach cc: Brian E Carpenter , The IESG , anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-grasp@ietf.org, Sheng Jiang In-Reply-To: <067da3a3-47f8-2f3e-bb7e-db25d45fb8e4@nostrum.com> References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> <067da3a3-47f8-2f3e-bb7e-db25d45fb8e4@nostrum.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 17:07:30 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Adam Roach wrote: > My strong recommendation here would be to define a new GRASP protocol > numbers registry, state that any values in the GRASP registry that > correspond to a protocol in the > https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xh= tml > registry SHOULD use the same number (which you imply by your current > choices to be a Good Thing), and that any values that are appropriate > for GRASP but not general protocol numbers SHOULD be assigned by IANA > starting with 252, with each subsequent such registration using the > next smaller number available. Actually, we aren't limited to 1-octet. It's a CBOR integer, and grows automatically. So we could have >=3D256 for GRASP-only things. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlklvc4ACgkQgItw+93Q 3WVnvgf/ehZ16nAWyGON0Wc6MAo977k91ZT7YtSY8p9TrGg/53UsRnpeRitL5+UI ILSYcbhAGuICRNhOQIcABwjwUh9bdYG508kWxhAfNgP/jNpI32oMyE47BUjds/r2 nTh+TkJpBysMCAqX1Uoft8ooT/nsqG6WpZm4G7OSgeObpzk3N/Pqy50SmqV4lv+I sZ4doasfDZmDoqSG+NBoXm+43ieudWTjAb1KJ42Nba0mj+AC1uGygxh+xf7ub3MJ gIPIHZvm3/1k65TNf62r+sb4dTJs/By/HgvyjcIL1UdPatNqxclhMDz0vcjOl2mZ 9yBJiFv1pU1fr3x7akCR0Pg7xK0HJA== =NsAq -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 24 10:35:39 2017 Return-Path: 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 76CB5129577 for ; Wed, 24 May 2017 10:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 k4balSGU-W9t for ; Wed, 24 May 2017 10:35:37 -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 E75DD1201F8 for ; Wed, 24 May 2017 10:35:36 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4OHZNil072147 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 May 2017 12:35:24 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Michael Richardson Cc: draft-ietf-anima-grasp@ietf.org, anima-chairs@ietf.org, The IESG , Brian E Carpenter , anima@ietf.org, Sheng Jiang References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> <067da3a3-47f8-2f3e-bb7e-db25d45fb8e4@nostrum.com> <7167.1495645647@obiwan.sandelman.ca> From: Adam Roach Message-ID: Date: Wed, 24 May 2017 12:35:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <7167.1495645647@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 17:35:38 -0000 On 5/24/17 12:07 PM, Michael Richardson wrote: > Adam Roach wrote: > > My strong recommendation here would be to define a new GRASP protocol > > numbers registry, state that any values in the GRASP registry that > > correspond to a protocol in the > > https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > > registry SHOULD use the same number (which you imply by your current > > choices to be a Good Thing), and that any values that are appropriate > > for GRASP but not general protocol numbers SHOULD be assigned by IANA > > starting with 252, with each subsequent such registration using the > > next smaller number available. > > Actually, we aren't limited to 1-octet. > It's a CBOR integer, and grows automatically. > So we could have >=256 for GRASP-only things. > That's even better. /a From nobody Wed May 24 11:18:22 2017 Return-Path: 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 2EAE4126C3D for ; Wed, 24 May 2017 11:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 p3Nthq5qKf6B for ; Wed, 24 May 2017 11:18:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACA8126BF3 for ; Wed, 24 May 2017 11:18:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9324C20549; Wed, 24 May 2017 14:18:19 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 182266380F; Wed, 24 May 2017 14:18:19 -0400 (EDT) From: Michael Richardson To: consultancy@vanderstok.org, Anima WG In-Reply-To: <579b63e48f3894706b1c0550191b6366@xs4all.nl> References: <21915.1490916584@obiwan.sandelman.ca> <6168.1491913071@obiwan.sandelman.ca> <3EB7EB76-B8F6-4A64-918E-307C4F8B20E8@cisco.com> <4cb3eef653ebc2edec8160efb63e5cf6@xs4all.nl> <20170523142824.GA18931@faui40p.informatik.uni-erlangen.de> <3AF89D2E-08BD-4A92-83F3-E80D2538EC96@cisco.com> <579b63e48f3894706b1c0550191b6366@xs4all.nl> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [Anima-bootstrap] Concise version of BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 18:18:21 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable peter van der Stok wrote: > I'm looking forward to that version. I did like the lay-out of -06pre. > Can you make sure that all terminology is consistent, like circuit > proxy, join proxy, proxy; join registrar, domain registrar, cloud > registrar, and others. (also in the figures) If they are different > concepts, please specify their differences. I don't think we changed much in the terminology section. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlklzmoACgkQgItw+93Q 3WUXegf7Bhcz09LuE0NLFIGIcLw3ifRmmdjM3H4hWaL4ruJPrjBu717CoYavNdMR m4dC2DRfvJmuzV2YW4xXj6oIiPuxRmyNFxFUeNEaSV+EbD8sE9UQ8tUNloKGRj2L 6bREuk/66OuElUf8T4FGnZUN0LNMe8lTe0NS2iX/lFvUUwRXg6jtaIQZcss/mxcw tlmXaKAol+rPpaFVykPxIC1MzelNsUCDvOrSTIUVRG41SzTZ3Z3hyYuQOFlCurxL +8iy3bBnag4apDh4BYbJrLm8OAMQKLZq7kv5SVMgT96k+SLjp5H8RlQjZaBirRg+ RQT7665+ojTU+SM6UmaZb0/JB8bjTQ== =FQo4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 24 12:47:25 2017 Return-Path: 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 1FB23126C23; Wed, 24 May 2017 12:47:24 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBQNBmmllVfw; Wed, 24 May 2017 12:47:22 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 77917127977; Wed, 24 May 2017 12:47:22 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id w69so34126673pfk.1; Wed, 24 May 2017 12:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lkaBjHZKUuyHtGyPn8G4Wy0zeOMNHUey7Lu0xDh2J20=; b=AiR2x/j3MicwSPWVjnuB11peZv2ci2SlIev0ordvkJU+XDDoFIW1td6/rgIiNQlQ62 PcbuhT37bTr1P4BkIZ0d2nYGSm3CABn87uiwalscnqCDpXPTSpbTWEdIH4aE17SlftuQ y+0hecwkX17cZD4l442qehQLI1TZe2t3hxDwZsy4iIFlBHzh1zlP3ONmjnbK+2kiJzF/ KJsEH/oDaMdgC3MDeXamHlnbsbK/+qeALtCP64WpeQq1Or5Rz5FdTbDGrbae4/efzMYU CTYzP5QJ21/mDGtZlhqkwv2WO+qNTee/TkSzcGAYEeEJQ9jk7h3FQj+KyG7SpSE0p0J6 M+1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=lkaBjHZKUuyHtGyPn8G4Wy0zeOMNHUey7Lu0xDh2J20=; b=cyG0u9rxMl0FZEuYTJ+aRpJIeXCuWO1/9PCKxkG0EVO9wgxyqDc+j5ut5BaSJ+xtMa C695iY0/97IMOSPCL98QzJjGw2HpwvHRNl6iZ+P7vUmPyJn4W+1DCqxZMnLZYJVHMorw slptTOo5jVZJX0yPYdHR5pt6lMCH4rfFRW/CheUheUt7gs3FC6v2NGBuT0sje1hcb4xs dFQWjbbcYnCYd3+Gs6nxy5AmFG4L16WFKAZXi+7NRC8t9A/cfdJK110Atv7vPKJdo59k HDaL+ZvfUdX6q4SVW85Cwp626n2KftVZHwk1o818/RB6jRnEnr2jJ/nNmELjb1J9KUHw BZzg== X-Gm-Message-State: AODbwcBLvXyO+LisrEl96d+knXvcFnCkTOiEA1bzgIMKNeBOL/dJhCcq ImBFm+4S7qKm8g== X-Received: by 10.98.32.18 with SMTP id g18mr40795034pfg.153.1495655242082; Wed, 24 May 2017 12:47:22 -0700 (PDT) Received: from [10.100.103.42] (210-55-57-56.adsl.xtra.co.nz. [210.55.57.56]) by smtp.gmail.com with ESMTPSA id c19sm7794451pgk.32.2017.05.24.12.47.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 12:47:21 -0700 (PDT) To: Adam Roach , Michael Richardson Cc: draft-ietf-anima-grasp@ietf.org, anima-chairs@ietf.org, The IESG , anima@ietf.org, Sheng Jiang References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> <067da3a3-47f8-2f3e-bb7e-db25d45fb8e4@nostrum.com> <7167.1495645647@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 25 May 2017 07:47:22 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 19:47:24 -0000 On 25/05/2017 05:35, Adam Roach wrote: > On 5/24/17 12:07 PM, Michael Richardson wrote: >> Adam Roach wrote: >> > My strong recommendation here would be to define a new GRASP protocol >> > numbers registry, state that any values in the GRASP registry that >> > correspond to a protocol in the >> > https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml >> > registry SHOULD use the same number (which you imply by your current >> > choices to be a Good Thing), and that any values that are appropriate >> > for GRASP but not general protocol numbers SHOULD be assigned by IANA >> > starting with 252, with each subsequent such registration using the >> > next smaller number available. >> >> Actually, we aren't limited to 1-octet. >> It's a CBOR integer, and grows automatically. >> So we could have >=256 for GRASP-only things. >> > > That's even better. I'm still puzzled about doing this *specifically* for GRASP. Can this be the only upper layer that would like to signal a choice of this kind? Brian From nobody Wed May 24 12:53:14 2017 Return-Path: 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 46D9A127B5A for ; Wed, 24 May 2017 12:53:12 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1S6KmMq-v0RV for ; Wed, 24 May 2017 12:53:10 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 53F78127871 for ; Wed, 24 May 2017 12:53:10 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id e193so145342349pfh.0 for ; Wed, 24 May 2017 12:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sB30e1C85PzZsXWViDzqXnxuIpGlhJYD8dYYgmVm3EI=; b=VlWQcPrLE4gOEiMBgPT0quhcD2XKtM834U9UMoaYBqsW2scSebFYU5/IfTH8sI+KwI B2kovY3I/kTtJCIJXkA1Aq6cr+i7vUKEzTJUGPdrCBZFU5yJIYAic831+C9U5a9VHfU0 d93sYD3h6rvEEmpJO4mqQuQThXu8fG+zdhV1l6+NZ2GMlUv+ALxYs8OLiK7yJozbxgZ5 SKzJKcBFbGaVoObLWn9L+3kG0YeL4RkYdEUKLvYmFJte768lzNrRGiVO1tVpp7/VosfP YF35McmCViyrXs2yUdlfYs9XDMWzVntGgh84orEUVOkkJOI/U0Yd7+Va6jp8bdv1A/P3 S/MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=sB30e1C85PzZsXWViDzqXnxuIpGlhJYD8dYYgmVm3EI=; b=fN7wPpbcgWp0ZmITqyk74PS64tjBeTmv6EU9BiM+DXU1HgFVii4LOXwSwKUB5YwXHc D/Bp6nkeMGZDvYqKX2I3sxsI6T72uaYnR3XifPDvzkXX65pkwoq2QhGb07Z7XRGo1fbP gd+xV4X3qutAbskKDKHRXJKTbqtbVIrxYZ+9OY/0jJGHvyjb9GAAh/qYtm7nY0yXAnb6 x1X/OIxtOU6BucbgE8LzTH324VEHcGWfSAsR3tPEZdWtYvThY4pu+npHjhJ7vnbaKfq4 9TlpX5Iwzj208o/IWFmy1AwBd9nT7Ztb6xXhd23PPJqHw4hpz0YPW0oXf05ysW2sZMB/ 684g== X-Gm-Message-State: AODbwcDt9gzGsgne5JilbYiot7Ek/JH/md2Gd8hyXSjZZJo5sFaLPLg8 QhJ3KkKslMJ+sbk2 X-Received: by 10.84.141.36 with SMTP id 33mr44219680plu.99.1495655589959; Wed, 24 May 2017 12:53:09 -0700 (PDT) Received: from [10.100.103.42] (210-55-57-56.adsl.xtra.co.nz. [210.55.57.56]) by smtp.gmail.com with ESMTPSA id t13sm9355729pfa.126.2017.05.24.12.53.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 12:53:09 -0700 (PDT) To: anima@ietf.org References: <149555276275.18049.7515853778089282062.idtracker@ietfa.amsl.com> <3637.1495644731@obiwan.sandelman.ca> Cc: ietf@kuehlewind.net From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 25 May 2017 07:53:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <3637.1495644731@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-anima-grasp-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 19:53:12 -0000 On 25/05/2017 04:52, Michael Richardson wrote: > Mirja K=C3=BChlewind wrote: > > a TCP connection for the discovery response and require that all = other > > messages to be sent over TCP (also removing any option to use any= other > > reliable transport because TCP seems to be the right choice here.= ) >=20 > Some parts of GRASP are really begging for SCTP :-) > I wish it was more clearly an option.... no firewalls in the ACP to scr= ew it up. I tend to give the same answer as for UDP (or COAP): let's get the basic = spec out and then discuss whether to add GRASP-over-foo specs. If GRASP succeeds, that will be an obvious next step. Brian > > 3) Version and extensibility: section 3.5.4.5: "A possible future= > > extension is to allow multiple objectives in rapid mode for great= er > > efficiency." How can this extension be defined if there is no ve= rsion > > mechanism? >=20 > :-) >=20 > Try the new extension and get back M_INVALID if not suppored. > I insisted upon M_INVALID for this reason. >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Wed May 24 13:38:56 2017 Return-Path: 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 85DEA1287A3 for ; Wed, 24 May 2017 13:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 G0jXsXBNstRA for ; Wed, 24 May 2017 13:38:51 -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 6C784129B91 for ; Wed, 24 May 2017 13:38:51 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4OKcid1003875 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 May 2017 15:38:45 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Brian E Carpenter , Michael Richardson Cc: draft-ietf-anima-grasp@ietf.org, anima-chairs@ietf.org, The IESG , anima@ietf.org, Sheng Jiang References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> <067da3a3-47f8-2f3e-bb7e-db25d45fb8e4@nostrum.com> <7167.1495645647@obiwan.sandelman.ca> From: Adam Roach Message-ID: <60f590ed-1049-30f5-32d8-f38d6ed533ce@nostrum.com> Date: Wed, 24 May 2017 15:38:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 20:38:52 -0000 On 5/24/17 2:47 PM, Brian E Carpenter wrote: > On 25/05/2017 05:35, Adam Roach wrote: >> On 5/24/17 12:07 PM, Michael Richardson wrote: >>> Adam Roach wrote: >>> > My strong recommendation here would be to define a new GRASP protocol >>> > numbers registry, state that any values in the GRASP registry that >>> > correspond to a protocol in the >>> > https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml >>> > registry SHOULD use the same number (which you imply by your current >>> > choices to be a Good Thing), and that any values that are appropriate >>> > for GRASP but not general protocol numbers SHOULD be assigned by IANA >>> > starting with 252, with each subsequent such registration using the >>> > next smaller number available. >>> >>> Actually, we aren't limited to 1-octet. >>> It's a CBOR integer, and grows automatically. >>> So we could have >=256 for GRASP-only things. >>> >> That's even better. > I'm still puzzled about doing this *specifically* for GRASP. Can this be > the only upper layer that would like to signal a choice of this kind? You do take my point about being able to find the specification for a codepoint by way of the IANA registry, right? Can you take an explicit position on whether you think that's something we should ignore? I can't tell whether you missed the point or just believe it's unimportant. /a From nobody Wed May 24 15:11:34 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6015A129494; Wed, 24 May 2017 15:11:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149566389334.8737.940293315082013190@ietfa.amsl.com> Date: Wed, 24 May 2017 15:11:33 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-06.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 22:11:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Michael H. Behringer Steinthor Bjarnason Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-06.txt Pages : 59 Date : 2017-05-23 Abstract: This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using vendor installed X.509 certificate, in combination with a vendor's authorizing service, both online the Internet, and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-06 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 24 15:15:25 2017 Return-Path: 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 A52DC1287A7 for ; Wed, 24 May 2017 15:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 AppQzYY5Dk_i for ; Wed, 24 May 2017 15:15:22 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8136F12778E for ; Wed, 24 May 2017 15:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=264; q=dns/txt; s=iport; t=1495664122; x=1496873722; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/ciYtYc0CU3c36jlqZZiRnCNKKJp3ho2hBuOemITmi4=; b=SduDzoFC86DxDmI6thfuFN3NTcPF48o0oyLP+NCsxIQQrXepSgsQh22Q t8AVo9PoX0XwCmo5DYwjo032uNeO7PvpTPMKbAxydAXhbJkWlcJnuOQmd Kkk0IAo5zPurxbD7GMvRNxmUIAoaXYSGeMLQR4S9hVELQ25cZC1T4I+vy E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAQBeBSZZ/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1WBdbVTgg+GJAKCc0AXAQIBAQEBAQEBayiFGQY6PxACAT4QMiU?= =?us-ascii?q?CBAENiiuwP4tBAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYhoixaCMQEEniMBkycLg?= =?us-ascii?q?WMBF49vAokBi0wBIAE2gQpxFVgBhmOJK4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,388,1491264000"; d="scan'208";a="31526867" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2017 22:15:21 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v4OMFLo5011517 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 May 2017 22:15:21 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 24 May 2017 17:15:21 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Wed, 24 May 2017 17:15:20 -0500 From: "Max Pritikin (pritikin)" To: Michael Richardson , Kent Watsen , Toerless Eckert CC: "consultancy@vanderstok.org" , Anima WG Thread-Topic: BRSKI -06 posted (was: Re: [Anima] [Anima-bootstrap] Concise version of BRSKI) Thread-Index: AQHS1Ns7LHQPlLe32Um/URaNm0bsEQ== Date: Wed, 24 May 2017 22:15:20 +0000 Message-ID: References: <21915.1490916584@obiwan.sandelman.ca> <6168.1491913071@obiwan.sandelman.ca> <3EB7EB76-B8F6-4A64-918E-307C4F8B20E8@cisco.com> <4cb3eef653ebc2edec8160efb63e5cf6@xs4all.nl> <20170523142824.GA18931@faui40p.informatik.uni-erlangen.de> <3AF89D2E-08BD-4A92-83F3-E80D2538EC96@cisco.com> <579b63e48f3894706b1c0550191b6366@xs4all.nl> <23012.1495649899@obiwan.sandelman.ca> In-Reply-To: <23012.1495649899@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <5B68002427AB1440B19015A88FCE5EA3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Anima] BRSKI -06 posted (was: Re: [Anima-bootstrap] Concise version of BRSKI) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 22:15:24 -0000 The -06 version is posted. We are midstream and expect to keep working on t= his.=20 In particular the voucher document is currently undergoing focused update a= nd we expect an -07 of BRSKI to be published soon after to reflect those up= dates. - max From nobody Wed May 24 18:24:04 2017 Return-Path: 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 AFA38129BAA; Wed, 24 May 2017 18:23:54 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwosgRemlaXV; Wed, 24 May 2017 18:23:52 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 CF23112702E; Wed, 24 May 2017 18:23:52 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id w69so35592661pfk.1; Wed, 24 May 2017 18:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5LaXIMGYh9h0s4Q+HeKtSeBtBOxxrlzmLpaZgFlSWR0=; b=e8qQ5co5kZh2/PXmFR+DZsEHBfjPRZTKNYkjzuI/gTk3QGPAFDm8TiFFYT5gjIWQrs Zk+NXQ8I8ss7i0EKx3KvGRDB24EuVvehGreoZFw26zv1CuImF1cMpggmwAq/OzJ/lj93 8CvZ3gzmvkrdAzy8Iw35ZE4qZBwJQFaBJaG9q6mkS4BdaueUC5ryDZRd9OvZOcJ51es2 NV8jBPWiv9v5j42zsy389rAj8p8G15cELVL0xazkkg81xaaAnBAoRjzLNYp5CP1I8aQu hNEf9KcxxLRoV8CUg5uP2BxwoyIbeN+Z28fmTHRh94CPP7UHM1RIVgUib1hRbnQm5WFD p5Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=5LaXIMGYh9h0s4Q+HeKtSeBtBOxxrlzmLpaZgFlSWR0=; b=CsDG2RVq0isghSD1RdSgh6q3H5r7QcBVDvBY1xPyBNLBMAa80+rigAcZTPMs9dlftW 96NZzz9Rnph4MpXDqcuEdZWmvAyOqqjxogieCQ24zHPK3DFBOeE2eNsDXSJciWfw85bl yMRQdZ2dt7+3ycdEd2vfjBu3UgHnEYDRUj8CmqiZhsVScqUIEJwA51YIzrPkl8tcB9Ru sz4ofXe4+RNa51wkLDAi2aDTT9R7BkYnLv1A0cYHljHXWqsL5dFXrmmDNJeMUbJvpvJS VVxYd5cNspJNy739u2qhrERkZ1i8NQDyE52CESRkj1gFtU7s+RWZKLCImaCQv7apoZMu gCzQ== X-Gm-Message-State: AODbwcAogQ1YwKgVmVHo7725SwLB7iWndUUit/MsSGoQKRfxOqGFFDqf yESEazvh/4bzKF5Q X-Received: by 10.98.68.197 with SMTP id m66mr41484116pfi.80.1495675432438; Wed, 24 May 2017 18:23:52 -0700 (PDT) Received: from [10.100.103.42] (210-55-57-56.adsl.xtra.co.nz. [210.55.57.56]) by smtp.gmail.com with ESMTPSA id m5sm14830419pgd.28.2017.05.24.18.23.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 18:23:51 -0700 (PDT) To: Adam Roach , Michael Richardson Cc: draft-ietf-anima-grasp@ietf.org, anima-chairs@ietf.org, The IESG , anima@ietf.org, Sheng Jiang References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> <067da3a3-47f8-2f3e-bb7e-db25d45fb8e4@nostrum.com> <7167.1495645647@obiwan.sandelman.ca> <60f590ed-1049-30f5-32d8-f38d6ed533ce@nostrum.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 25 May 2017 13:23:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <60f590ed-1049-30f5-32d8-f38d6ed533ce@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 01:23:55 -0000 On 25/05/2017 08:38, Adam Roach wrote: > On 5/24/17 2:47 PM, Brian E Carpenter wrote: >> On 25/05/2017 05:35, Adam Roach wrote: >>> On 5/24/17 12:07 PM, Michael Richardson wrote: >>>> Adam Roach wrote: >>>> > My strong recommendation here would be to define a new GRASP protocol >>>> > numbers registry, state that any values in the GRASP registry that >>>> > correspond to a protocol in the >>>> > https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml >>>> > registry SHOULD use the same number (which you imply by your current >>>> > choices to be a Good Thing), and that any values that are appropriate >>>> > for GRASP but not general protocol numbers SHOULD be assigned by IANA >>>> > starting with 252, with each subsequent such registration using the >>>> > next smaller number available. >>>> >>>> Actually, we aren't limited to 1-octet. >>>> It's a CBOR integer, and grows automatically. >>>> So we could have >=256 for GRASP-only things. >>>> >>> That's even better. >> I'm still puzzled about doing this *specifically* for GRASP. Can this be >> the only upper layer that would like to signal a choice of this kind? > > You do take my point about being able to find the specification for a > codepoint by way of the IANA registry, right? Can you take an explicit > position on whether you think that's something we should ignore? I can't > tell whether you missed the point or just believe it's unimportant. Sorry, yes I do take the point. I now recall finding myself in a dilemma many months ago when I realised that (a) to specify a foo-over-IP transport layer there is already a well-defined registry and that (b) to specify a foo-over-something-over IP transport layer, there is no registry. In the draft we ducked this, as you noticed. Indeed we can add a registry, or perhaps a note that a registry needs to be created for any transports that are not directly over IP. But then I got to thinking: isn't this a general problem, not a GRASP-specific problem? Which is something to be discussed in the transport and ART areas, I guess. Is it sufficient to state that the currently defined values are from https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml and that the encoding of values for protocols that do not have IP protocol numbers is for further study? Personally I'd rather do that than try to resolve this question on the fly. As Michael pointed out, CBOR gives us a lot of freedom on how to resolve this without any change to the protocol syntax. Brian From nobody Wed May 24 19:33:06 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30ECA12947C; Wed, 24 May 2017 19:32:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> Date: Wed, 24 May 2017 19:32:57 -0700 Archived-At: Subject: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 02:32:57 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-anima-grasp-12: Discuss 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-anima-grasp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ISSUE 1 The security situation here is pretty unspecified here, in at least two respects: 1. In terms of communication security, you seem to have two modes: (a) Punt it to ACP (b) Use TLS as specified in S 3.5.2.1 I'm not reviewing ACP here (though I have some comments on that too) but S 3.5.2.1 doesn't (for) instance explain how to do certificate validation, which it clearly needs to do. Finally, I don't understand the security story for the multicast packets. This is especially relevant for Rapid mode, where you are attaching real work to these multicast packets. 2. I didn't find the security model very clear. As I understand things, basically anyone on the network who has ACP credentials is trusted to engage in negotiation with you, so, for instance, if you want to get parameter X, then you basically just trust whoever on the network offers you X. is that correct? That seems like it needs to be very explicitly called out. And if that's not true, then I don't understand the spec. ISSUE 2 This document seems like it provides incomplete guidance on how to actually implement it. For instance: discovery messages to a reasonable value, in order to mitigate possible denial of service attacks. It MUST cache the Session ID value and initiator address of each relayed Discovery message until What's "reasonable"? ISSUE 3. I don't think I understand how the transition from UDP multicast to TCP/TLS unicast works. Maybe I'm just misreading the spec, so could you point me to the section that describes this. Finally, I don't see a spec for how you map CBOR onto the wire. Do you just shove them on? Something else? I see that Martin Thomson raised a number of these issues in his review in more detail. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 3.5.4.3. After a GRASP device successfully discovers a locator for a Discovery Responder supporting a specific objective, it MUST cache this information, including the interface index via which it was discovered. This cache record MAY be used for future negotiation or synchronization, and the locator SHOULD be passed on when appropriate as a Divert option to another Discovery Initiator. What's an "interface index" S 3.5.4.4. Since the relay device is unaware of the timeout set by the original initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEOUT milliseconds. I'm not sure I'm following here. Does the relay instance retransmit with its own timeout? It MUST cache the Session ID value and initiator address of each relayed Discovery message until any Discovery Responses have arrived or the discovery process has timed out. How does this behave if the original initiator's timeout is longer than GRASP_DEF_TIMEOUT? S 3.5.5. A negotiation procedure concerns one objective and one counterpart. Both the initiator and the counterpart may take part in simultaneous negotiations with various other ASAs, or in simultaneous negotiations about different objectives. Thus, GRASP is expected to be used in a multi-threaded mode. Certain negotiation objectives may have restrictions on multi-threading, for example to avoid over-allocating resources. "multi-threaded" is an odd word here. I assume you mean that you are doing multiple stuff at once, but you might actually write the system using non-multi-threaded techniques. S 3.7. You seem to be going to a lot of trouble to deal wit session ID collisions. Why don't you just make session IDs 128-bit random values and then you won't have to worry about collisions. The Session ID SHOULD have a very low collision rate locally. It MUST be generated by a pseudo-random algorithm using a locally generated seed which is unlikely to be used by any other device in the same network [RFC4086]. Why don't you just require a cryptographically secure PRNG? That will be required to implement the rest of this protocol S 3.8.2. You seem to introduce a normative dependency on CDDL here. I see that it's in your changelog here, but what are your intentions about this document, given that CDDL seems to not even be a WG document S 3.8.5. It MUST contain a time-to-live (ttl) for the validity of the response, given as a positive integer value in milliseconds. Zero is treated as the default value GRASP_DEF_TIMEOUT (Section 3.6). Why do this, rather than just forbidding 0. S 3.8.6. If a node receives a Request message for an objective for which no ASA is currently listening, it MUST immediately close the relevant socket to indicate this to the initiator. This is to avoid unnecessary timeouts if, for example, an ASA exits prematurely but the GRASP core is listening on its behalf. This is not secure. You need a secure indication of non-knowledge, not a transport-level close. S 3.9.5.4. What are the semantics of a Divert URI? What do I dow ith the path part? S 3.10.4. The semantics of "dry run" seem pretty unclear. Is it just "tell me if you would be sad about doing this"? From nobody Wed May 24 20:57:36 2017 Return-Path: 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 A4FC81294F3 for ; Wed, 24 May 2017 20:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 clrWaCxprUA5 for ; Wed, 24 May 2017 20:57:26 -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 63A301294FA for ; Wed, 24 May 2017 20:57:25 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4P3vFEQ085975 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 May 2017 22:57:17 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Brian E Carpenter , Michael Richardson Cc: draft-ietf-anima-grasp@ietf.org, anima-chairs@ietf.org, The IESG , anima@ietf.org, Sheng Jiang References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> <067da3a3-47f8-2f3e-bb7e-db25d45fb8e4@nostrum.com> <7167.1495645647@obiwan.sandelman.ca> <60f590ed-1049-30f5-32d8-f38d6ed533ce@nostrum.com> From: Adam Roach Message-ID: Date: Wed, 24 May 2017 22:57:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 03:57:28 -0000 On 5/24/17 8:23 PM, Brian E Carpenter wrote: > Sorry, yes I do take the point. I now recall finding myself in a dilemma > many months ago when I realised that (a) to specify a foo-over-IP transport > layer there is already a well-defined registry and that (b) to specify a > foo-over-something-over IP transport layer, there is no registry. In the > draft we ducked this, as you noticed. Indeed we can add a registry, or > perhaps a note that a registry needs to be created for any transports > that are not directly over IP. But then I got to thinking: isn't this > a general problem, not a GRASP-specific problem? Which is something to > be discussed in the transport and ART areas, I guess. It's worth noting that, with relatively rare exception, application-layer protocols aren't really going to have a compelling reason to use numeric representation for transports. See, for example, and . At best, even if you limit this to protocols that use numbers to represent transports [1] , you might end up with some kind of unified registry, similar to what we did with , although I've never been able to ascertain the value of that approach over having four different tables. In any case, I agree with you that halting the processing of GRASP to create some kind of pan-area unified numeric transport registry is going to take a lot of time; and I would make the further observation that doing so in the future, after we are done discussing GRASP, will *also* take a lot of time. But why? Why would we ever spend that time? I see absolutely no concrete benefits to doing so. You clearly do. Can you lay those benefits out so that we can discuss their merits relative to the extra work you're implying might be taken on to achieve them? /a ____ [1] How many are there? Based on a skim through IANA, it looks like GRASP may be the second over the past 31 years. From nobody Thu May 25 02:19:34 2017 Return-Path: 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 E984B1293EE; Thu, 25 May 2017 02:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=QhbU7J/9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZuUMnbpm 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 a2M1n5fsW8Yz; Thu, 25 May 2017 02:19:25 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B871270A3; Thu, 25 May 2017 02:19:25 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A3FAD209C7; Thu, 25 May 2017 05:19:24 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 25 May 2017 05:19:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=82oUk9mm0ED/YPwZoK P8LKlc5TSeAahbvU58gb1Ef6s=; b=QhbU7J/9iZPCHizX4BQCa4MEJe+s3pjlnJ x5nWgJkzIOgbLq3h5QvNBO3jZBfL9KFVU74PiikZff0mKgSjJ0hKAcfvYFKLPl5A gmGJs2w8KJeBi9johR5ojv0ynaNogRxAqFrm9D1ZijQIYl6Di0kQGBPjIZcy51dp z0t1Wn+3hjVm1H9ZzfyKW8a8v5oRYcUTE/ay4YU+7xhARQtFz+0lO0KBwVOKRmix f5GgcHMwiEJmmQ48PcqGH53jcWoOBlXSsaD0OkscV2c7rJ5e/J0DM2WpzSPNIUaG YI8lPTAOngP2qWyU8tCvfia6Cmk9tMt6nbKLm27zaDo40Ft0ZRsQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=82oUk9mm0ED/YPwZoKP8LKlc5TSeAahbvU58gb1Ef6s=; b=ZuUMnbpm j6RyIrvHgfJ+ySRWG2/yNi7aXAOMQXqbVANRrnACyGiVdjweSP8NY38VCfJ0wA4O 7qZ860LpiNQDLbJ/BWvAtxf7O7uUlRoIcSacX+49SAZyjtGKLNjf/EVFAjhJywBg sWIDhUJDPgvQxZCbgDfBlC4Jpj95xyhj4n3MLqvO7KM5dpDLwffxDA6REv7FlSZM VJ5YRUV8x9CcU+1omwa8zh5so0AXlPqOE+5vQf5aK894EJWr3H2vgq+ciVJjJqdr mz79LTEMK04G4V0LLJLp4tVxstzCkTs7U5koFEmQmWlMXrwyuhSgHGSwWXzGdatn eP7+Wffej1mKBw== X-ME-Sender: X-Sasl-enc: C4BwsqPqlfzhBGaKX89mF4gFMM5e56EoJPLF0Jmj1dnl 1495703964 Received: from [10.105.147.226] (unknown [88.128.80.119]) by mail.messagingengine.com (Postfix) with ESMTPA id 3CAAD7E545; Thu, 25 May 2017 05:19:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Thu, 25 May 2017 11:36:46 +0200 Cc: Michael Richardson , anima-chairs@ietf.org, anima@ietf.org, The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang Content-Transfer-Encoding: quoted-printable Message-Id: <02AEF661-4D9F-4E8A-BBD8-E4ECE7B217A3@fastmail.fm> References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> <067da3a3-47f8-2f3e-bb7e-db25d45fb8e4@nostrum.com> <7167.1495645647@obiwan.sandelman.ca> <60f590ed-1049-30f5-32d8-f38d6ed533ce@nostrum.com> To: Brian E Carpenter , Adam Roach Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 09:19:27 -0000 Hi, > On 25 May 2017, at 03:23, Brian E Carpenter w= rote: >=20 > Is it sufficient to state that the currently defined values are from > https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > and that the encoding of values for protocols that do not have IP protocol= > numbers is for further study? Personally I'd rather do that than try to > resolve this question on the fly. As Michael pointed out, CBOR gives > us a lot of freedom on how to resolve this without any change to > the protocol syntax. I know that IANA registries can be peoples' favourite bike sheds, but from w= here I stand doing what you suggest above would be better than doing nothing= . I am happy for you and Adam to reach an alternative agreement on what should= be done for GRASP, but the above looks sufficient for now. Best Regards, Alexey From nobody Thu May 25 06:57:13 2017 Return-Path: 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 A968312942F; Thu, 25 May 2017 06:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=RY5eKtyz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gi+bCKds 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 u7kf4ei2_RYK; Thu, 25 May 2017 06:57:10 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C545124234; Thu, 25 May 2017 06:57:10 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B03E620CCC; Thu, 25 May 2017 09:57:09 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 25 May 2017 09:57:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=8+5GAz3kurg3XIWLar zFpef5ElRho2vIeE0DFv5tRgA=; b=RY5eKtyzXeLR3YiFouexCs9ZdX1pCyKh6h 7LnivXfV+XmHuGYjyluDol9Jpsmg6HKnNtYbvFMVGEWKQYji8Grp3RyyaLda/0Fo P/d+rEGJsBqfKtpPkzYy6ZqUsLzkYIOgPiZVe0Abk3eG7tbP5+h+Tle9aT//d+OI LdB6BEl7cRaed2ZBqyjV5x7gCWTZ1vKuFX8IumDiPvNvYnplMc28WQ4dj+7Ngyai E/S0BJDWPqyTKlFYn93Dt/YvU5P5LBBtkbsrBjpZjfatkbmJs6K8gj5nO+rdB8+3 2pdknQR2DTJKsV+CIoKlEqUeXvRyx10EtDluTdwURPolcFC18ZWQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=8+5GAz3kurg3XIWLarzFpef5ElRho2vIeE0DFv5tRgA=; b=gi+bCKds XKetans/ya9aKs4APsFy0G9vTa7sMixLH+qZImpDtbVYSkuaqis/cVLU6N5Bajs9 qZQz3hh9urkBBxsc1qeZv3OPJrandzN+WX7fK/rreiY9MwsDTXMZCpGYG2EYTiZ/ nM4DmviL2DXI7uSQA97yF1XgbKqFlttUVAUx++JbgxK3Q4OVapvzg5wgfh1Tjv0+ d3CLOTTlGHJFG02VsIQTBAwDjK7+Ga5VjfDm4edqcRRmzW0l6ztcMvmNCWwrZQf2 16Al49jyTof9alefmpzwY3AJr2EwcAIXNTcjQUBBbuPU+iVXrMu/iD3JsYDOe/eJ qiSaWzmKB+r3IQ== X-ME-Sender: X-Sasl-enc: 18FSE1jsTEciivkPB0sZDh9R92JlkEMvVhpiMiqFGjrv 1495720629 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.164]) by mail.messagingengine.com (Postfix) with ESMTPA id B90AF7E81A; Thu, 25 May 2017 09:57:08 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <149523043416.21589.9385334747760332010@ietfa.amsl.com> Date: Thu, 25 May 2017 09:57:06 -0400 Cc: "gen-art >> General area reviewing team" , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <2BDD2C3C-029D-46F8-93F8-6B95C1802D69@cooperw.in> References: <149523043416.21589.9385334747760332010@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Anima] [Gen-art] Genart telechat review of draft-ietf-anima-grasp-12 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 13:57:11 -0000 Joel, thank you for your review. I have balloted No Objection. Alissa > On May 19, 2017, at 5:47 PM, Joel Halpern wrote: > > Reviewer: Joel Halpern > Review result: Ready > > 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 wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-anima-grasp-?? > Reviewer: Joel Halpern > Review Date: 2017-05-19 > IETF LC End Date: 2017-03-02 > IESG Telechat date: 2017-05-25 > > Summary: This document is still ready for publication as a Proposed > Standard RFC > > Major issues: N/A > > Minor issues: N/A > > Nits/editorial comments: N/A > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu May 25 06:58:27 2017 Return-Path: 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 36650128B8F for ; Thu, 25 May 2017 06:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wA9e-E_1cHKd for ; Thu, 25 May 2017 06:58:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9BC124234 for ; Thu, 25 May 2017 06:58:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D41A4203B2; Thu, 25 May 2017 09:58:25 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8669E636BB; Thu, 25 May 2017 09:58:22 -0400 (EDT) From: Michael Richardson To: anima@ietf.org cc: Adam Roach , Brian E Carpenter In-Reply-To: References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> <067da3a3-47f8-2f3e-bb7e-db25d45fb8e4@nostrum.com> <7167.1495645647@obiwan.sandelman.ca> <60f590ed-1049-30f5-32d8-f38d6ed533ce@nostrum.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 13:58:25 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Adam Roach wrote: > It's worth noting that, with relatively rare exception, > application-layer protocols aren't really going to have a compelling > reason to use numeric representation for transports. See, for example, > > and > . > At best, even if you limit this to protocols that use numbers to > represent transports [1] , you might end up with some kind of unified > registry, similar to what we did with > , > although I've never been able to ascertain the value of that approach > over having four different tables. Noting that we can in fact, omit the IANA indirection, and put something li= ke 'rfc9123' in as the actual value. I'm not sure that is a good idea for a a number of real reasons. At this point, we need to indicate *UDP*, or *TC= P* with flexibility to specify SCTP in the future. There was a further locator that I tried to create, see: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-0= 6#section-3.1.2 which was to use an IPIP tunnel. The use of '41' was disputed, and maybe this is a case where it should have been a literal 'ipip' or some such. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkm4v4ACgkQgItw+93Q 3WWBIQf9G6QBOR72ZL7PgS320rujMow29719NMCqVoxRoWr1mi9S3Bu/xDl0yfCS NcLQ6E8mYnTTq5PyLDByC3VFhIv5U0BAV5rcvi3FbFokbxadiwY+PkLcAltpl5td KyWyNZgKqKv+6p6Cfx1QKCu0tDRVcoHyI4xQExOrmh6ZXFwROzLNyyT6woaMn/YQ NIM90LG8zfZ19WoVk2FSKbvYv8930uI9vf+If6vMdRYRlwPYn6Z0RxjwprFDNgON bEL4e/29sVQryqNclzSPyWaGTH2uO2Vs9YZUW6rgO6cckPEonCI8QFxprtMDBe73 GrgLyPj6muy3JlVA+Ph+we3pn2xYhA== =Xu4b -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 25 08:35:03 2017 Return-Path: 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 6C70E129B0D for ; Thu, 25 May 2017 08:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNrT3vJACYAk for ; Thu, 25 May 2017 08:34:56 -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 0255E129459 for ; Thu, 25 May 2017 08:34:55 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4PFYpxi010634 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 25 May 2017 10:34:54 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Michael Richardson , anima@ietf.org References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> <067da3a3-47f8-2f3e-bb7e-db25d45fb8e4@nostrum.com> <7167.1495645647@obiwan.sandelman.ca> <60f590ed-1049-30f5-32d8-f38d6ed533ce@nostrum.com> <25205.1495720702@obiwan.sandelman.ca> From: Adam Roach Message-ID: Date: Thu, 25 May 2017 10:34:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <25205.1495720702@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 15:34:57 -0000 On 5/25/17 08:58, Michael Richardson wrote: > There was a further locator that I tried to create, see: > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-06#section-3.1.2 Yes, the fact that we're already seeing this field extended tells me that this is crying out for a registry. So we have an extension point, we have a need to ensure uniqueness, and the IETF as an institution have known way to handle situations like that. With regards to this being a bikeshed -- I'm not keen to argue about the color of the bikeshed too much, but I think it's manifestly obvious that we *need* a bikeshed here. If we could get agreement on that fact -- that a registry is called for -- I'd be happy to let the WG and authors figure out the exact color. My advice? Do what's simple. /a From nobody Thu May 25 11:35:13 2017 Return-Path: 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 BACAD129C26; Thu, 25 May 2017 11:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 yLZMELkblO7b; Thu, 25 May 2017 11:34:59 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 86FF3129418; Thu, 25 May 2017 11:34:59 -0700 (PDT) Received: from [128.9.184.77] ([128.9.184.77]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v4PIYKLQ006586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 11:34:21 -0700 (PDT) To: Brian E Carpenter , Martin Stiemerling , anima@ietf.org Cc: tsv-art@ietf.org References: <6b290c47-5ab1-78e4-9f54-fa4f0679143b@gmail.com> <192f8891-5509-5201-1335-33bc7a04b7eb@gmail.com> From: Joe Touch Message-ID: <5e92dd05-074f-fde7-9281-10eaea4b0169@isi.edu> Date: Thu, 25 May 2017 11:34:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <192f8891-5509-5201-1335-33bc7a04b7eb@gmail.com> Content-Type: multipart/alternative; boundary="------------F1329C1C042427F7A5661688" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Anima] [Tsv-art] TSV-ART review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 18:35:01 -0000 This is a multi-part message in MIME format. --------------F1329C1C042427F7A5661688 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Brian, On 5/23/2017 1:53 PM, Brian E Carpenter wrote: >> * There is no versioning support in GRASP. Why are we still developing >> protocols that do not have versioning support in it? > Because the protocol is indefinitely extensible by adding message types > and options. We really don't see any need for a version number. The > M_INVALID message was added so Version support is recommended by IANA (see RFC7506, Sec 7.5). Extensibility is a separate issue and doesn't replace the benefit of version support. The goal is to avoid needing to assign a new port number for GRASPv2 in the future. IMO, all messages (including NOOP) should start with a version number, and I'd suggest at least 2 bits (if not 4). Joe --------------F1329C1C042427F7A5661688 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi, Brian,

On 5/23/2017 1:53 PM, Brian E Carpenter wrote:
* There is no versioning support in GRASP. Why are we still developing 
protocols that do not have versioning support in it?

Because the protocol is indefinitely extensible by adding message types
and options. We really don't see any need for a version number. The
M_INVALID message was added so
Version support is recommended by IANA (see RFC7506, Sec 7.5).

Extensibility is a separate issue and doesn't replace the benefit of version support.

The goal is to avoid needing to assign a new port number for GRASPv2 in the future.

IMO, all messages (including NOOP) should start with a version number, and I'd suggest at least 2 bits (if not 4).

Joe
--------------F1329C1C042427F7A5661688-- From nobody Thu May 25 12:37:20 2017 Return-Path: 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 2C9E512E85E; Thu, 25 May 2017 12:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACdlr2DiRxIE; Thu, 25 May 2017 12:37:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5C8129422; Thu, 25 May 2017 12:37:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ABC75203AF; Thu, 25 May 2017 15:37:19 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 817FA636BB; Thu, 25 May 2017 15:37:15 -0400 (EDT) From: Michael Richardson To: Joe Touch cc: Brian E Carpenter , Martin Stiemerling , anima@ietf.org, tsv-art@ietf.org In-Reply-To: <5e92dd05-074f-fde7-9281-10eaea4b0169@isi.edu> References: <6b290c47-5ab1-78e4-9f54-fa4f0679143b@gmail.com> <192f8891-5509-5201-1335-33bc7a04b7eb@gmail.com> <5e92dd05-074f-fde7-9281-10eaea4b0169@isi.edu> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [Tsv-art] TSV-ART review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 19:37:18 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Joe Touch wrote: > Version support is recommended by IANA (see RFC7506, Sec 7.5). > Extensibility is a separate issue and doesn't replace the benefit of > version support. > The goal is to avoid needing to assign a new port number for GRASPv2 = in > the future. > IMO, all messages (including NOOP) should start with a version number, > and I'd suggest at least 2 bits (if not 4). Everything is CBOR encoded, so we have no dependancy upon encoded bits on t= he wire changing. {Should CBOR change in an incompatible way, we'd need a new port number, tr= ue} Otherwise, we could obsolete any of the M_ operations trivially. We currently expect to encode the "first" layer as a CBOR array (which creates the record boundary for TCP as well). We could even decide that "version 2" would start with [M_GRASP2, [stuff]] costing us perhaps two bytes, which is about the same as inserting a version would cost, but I'm still not convinced we'd ever need to do that. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlknMmsACgkQgItw+93Q 3WXxxwf/Zp37J/EglSDeeU4FSU4ig/nqRxd4Tx6wskARI+CaWs57k8vdO/9jANkW aUhmuPzZVyPWdO84J7j5s7SJfgRbqXHp1Hiy/QI88dmBkaDd829roLX/KQqZw6VG y5YZT8nMVCpf6JglWPczdeT3bGrkpeIM3wVPb8thh/5A323uC8N5TK5vrfBlaTEp VHMcOJAjA5QwwZa0R1AQRJv417Owe9J88nLqmIKp0rrw0cKHj4bdXBD9wmvSO4KQ JutEV0rPSdF0PXaKI1CrNTiUrENxlofX+lH44/ghGd0jW/P9sQyosRfG2DnQB3ub RNNLpYw/iffmY+XLXG0VfZbGDEVKXQ== =xvJz -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 25 13:05:08 2017 Return-Path: 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 AFB80129AC5 for ; Thu, 25 May 2017 13:05:06 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8B-vTy2IVtQ for ; Thu, 25 May 2017 13:05:05 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 6556D1294E7 for ; Thu, 25 May 2017 13:05:05 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id n23so41169846pfb.3 for ; Thu, 25 May 2017 13:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ILZs1SDGKTNLxHzs18OuqBRJtSY30q6vO1tL78IpTE8=; b=jxJvYBEyfjGtCfLiQxsRYGEq6DYLImUng3edo+BA01Ecj3ZgAMGi4vnJuTHjOoBeXk Mk/wNh9fJcD5u6O8xEctuR/SRqW7zW8VBRM58UaZWnRwycVGYdIoPBcTQDaYxLW3kOQU 2GezZkiDuRc8uDxB9E03Izd3woTx1j/gRzwGSpsi7bHFQINoj/X/sRxxZNrfy5D1GZcw jwlNMmWaVuma6jM7Wv7EkH2Jka4EdkUtz3aP2PbTFVKcuyrDL4Bw7n59c9G4pxKsT8IJ aSK8peD2ne/P4K5tKnyVJp3s47b9i5ayB5HcL2Qi9J1p5D36PJksLYd0Wf3kxOc6p1DT UCJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ILZs1SDGKTNLxHzs18OuqBRJtSY30q6vO1tL78IpTE8=; b=cGcJDSV/w5wS8BldNAohHCjmSEs8hHatz/MzMvwYcIsh+uaMU2EIbC9Pt99eFN3PKu XnTOYVyEV6/DXz7quNOUz/BGv83wdqDEq6TV5WFmULgAuibzlFuQGk4f3he01imrNWKs p7xqp3zm2XI+CfrfjsRmj1xcnK1ojoK9FG+ydPm1Q1hpqaDS/xRZdBUhgCT/xQ77txY8 JaV4ups2CxgwKJvRo1v3etdkF8ppKVQQYhCsFiwWbJ+eg1pPuev581tPTU5nJEprSROX 0vRiuGitLlqdsWIqB0sHSzBSYtcBw6u/3sTSNjs+hwis4DP2xiATjVpalrqBlnMdRqbP 9SDQ== X-Gm-Message-State: AODbwcCLQxBoSwg4+CIjLun1C35+POeAAH1lczGNm5OBMdCvd8ksdLMQ yaAsfTVyR0BKSA== X-Received: by 10.98.60.206 with SMTP id b75mr46589255pfk.19.1495742705055; Thu, 25 May 2017 13:05:05 -0700 (PDT) Received: from [10.100.103.42] (210-55-57-56.adsl.xtra.co.nz. [210.55.57.56]) by smtp.gmail.com with ESMTPSA id q20sm8995475pfa.58.2017.05.25.13.05.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 13:05:04 -0700 (PDT) To: Adam Roach , Michael Richardson , anima@ietf.org References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <3dddfba7-bcf7-cff4-f83e-9a003175cab0@gmail.com> <067da3a3-47f8-2f3e-bb7e-db25d45fb8e4@nostrum.com> <7167.1495645647@obiwan.sandelman.ca> <60f590ed-1049-30f5-32d8-f38d6ed533ce@nostrum.com> <25205.1495720702@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6564c2b8-24b1-4cd6-7733-a09c208dbf4d@gmail.com> Date: Fri, 26 May 2017 08:05:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 20:05:07 -0000 On 26/05/2017 03:34, Adam Roach wrote: > On 5/25/17 08:58, Michael Richardson wrote: >> There was a further locator that I tried to create, see: >> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-06#section-3.1.2 > > > Yes, the fact that we're already seeing this field extended tells me > that this is crying out for a registry. > > So we have an extension point, we have a need to ensure uniqueness, and > the IETF as an institution have known way to handle situations like that. > > With regards to this being a bikeshed -- I'm not keen to argue about the > color of the bikeshed too much, but I think it's manifestly obvious that > we *need* a bikeshed here. If we could get agreement on that fact -- > that a registry is called for -- I'd be happy to let the WG and authors > figure out the exact color. My advice? Do what's simple. Yes. Point taken Brian From nobody Thu May 25 13:09:34 2017 Return-Path: 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 8221F12EAC2; Thu, 25 May 2017 13:09:25 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGARor58GFlr; Thu, 25 May 2017 13:09:24 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 08B6812EAC0; Thu, 25 May 2017 13:09:24 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id n23so41187188pfb.3; Thu, 25 May 2017 13:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=niM8hS6pNLq3R5gZt6KMFWU65UB5DFi1OhGLeRlF+GI=; b=s0OZzTyakYv1bQwABaQanGSFY52m2zsiyZzp/CwpXjplhg60rm9INPPPj80vJ7opNh JNAE/vf+Y2hriKOwwpfEfNb2wTwJj7IXhZiPkqPPJnJrETjLt+So7tqaWzo3Xpw5/nXB 8mLOlCZmtoiS5M0GWgNG8x089ffv84E18YY5cEt/k3X+SaLHAgbnOsFY90Bcszb/dxJr VpqRanLVo+OeCQikN2vtdsBuEtkB1MjboIx3AcvkRHXhOXWm7rubSgl8n0U0AJncpz1O n3PNNdBMzYXC/k9BefjXxG10YgSLWHK66qM+7jpq7illS+6VJBrtvNIpfk0dK5Nl0ZXM zJwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=niM8hS6pNLq3R5gZt6KMFWU65UB5DFi1OhGLeRlF+GI=; b=FgajLGBwu44bETWIr4oLdn3Oq6RUI0Fjt0Wf8uPaP3x1Pc7K3Er/Ds+400NU1yNGIR 8jgl/8AbYyBt8AQ7D2kMapFCZllhB3QHSqf8FQPt1F23qy8fhdQT1wJF1eAizN6kF+su fnlVnZlyaN8nOatKXyUA3Lonhy68+xFrTdjmJRwUDyWCDsd8vqbkib6dmIlogEJDULny ZpaRkUKRvKa6eRxyqBI6ISGcEo1jLEi2NSHyYWBu9Q99Zt3Xt/Zh0Yy8GznDkv4XPa00 DOFY6w4Q3N3eJDm4eZWm/kbJTHrsAd4ZRi4QHjFcBvCyO46FIGBZzURP01jQVkIleegt ZkkA== X-Gm-Message-State: AODbwcBj0KuadyghsAxqhhs2dFUJhoZ9ALQ7fZln1hGvRBE+KkLvRZr+ LYTvVgBSztaGIg== X-Received: by 10.98.18.157 with SMTP id 29mr45763176pfs.75.1495742963680; Thu, 25 May 2017 13:09:23 -0700 (PDT) Received: from [10.100.103.42] (210-55-57-56.adsl.xtra.co.nz. [210.55.57.56]) by smtp.gmail.com with ESMTPSA id e124sm15261587pfc.64.2017.05.25.13.09.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 13:09:23 -0700 (PDT) To: Michael Richardson , Joe Touch Cc: Martin Stiemerling , anima@ietf.org, tsv-art@ietf.org References: <6b290c47-5ab1-78e4-9f54-fa4f0679143b@gmail.com> <192f8891-5509-5201-1335-33bc7a04b7eb@gmail.com> <5e92dd05-074f-fde7-9281-10eaea4b0169@isi.edu> <5640.1495741035@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <606e09b0-5046-d3f5-c3ba-bf373e300f15@gmail.com> Date: Fri, 26 May 2017 08:09:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5640.1495741035@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [Tsv-art] TSV-ART review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 20:09:25 -0000 On 26/05/2017 07:37, Michael Richardson wrote: > > Joe Touch wrote: > > Version support is recommended by IANA (see RFC7506, Sec 7.5). > > > Extensibility is a separate issue and doesn't replace the benefit of > > version support. > > > The goal is to avoid needing to assign a new port number for GRASPv2 in > > the future. > > > IMO, all messages (including NOOP) should start with a version number, > > and I'd suggest at least 2 bits (if not 4). > > Everything is CBOR encoded, so we have no dependancy upon encoded bits on the > wire changing. > {Should CBOR change in an incompatible way, we'd need a new port number, true} > > Otherwise, we could obsolete any of the M_ operations trivially. > We currently expect to encode the "first" layer as a CBOR array (which > creates the record boundary for TCP as well). > > We could even decide that "version 2" would start with [M_GRASP2, [stuff]] > costing us perhaps two bytes, which is about the same as inserting a version > would cost, but I'm still not convinced we'd ever need to do that. You're right. If we had stuck to the original TLV model I would have agreed that a version number is needed, but the nature of CBOR means that it really isn't useful. Even the limit MESSAGE_TYPE = 0..255 in the syntax isn't restrictive; a message type >255 or <0 would just kick back an M_INVALID with old code, and would be happily accepted by new code, if we increased the valid range. Brian From nobody Thu May 25 15:11:23 2017 Return-Path: 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 85EEA129B7E; Thu, 25 May 2017 15:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 tjZTzrQo4rpr; Thu, 25 May 2017 15:11:15 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 7463D127B5A; Thu, 25 May 2017 15:11:15 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4PMArMu006974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 15:11:04 -0700 (PDT) To: Brian E Carpenter , Michael Richardson Cc: Martin Stiemerling , anima@ietf.org, tsv-art@ietf.org References: <6b290c47-5ab1-78e4-9f54-fa4f0679143b@gmail.com> <192f8891-5509-5201-1335-33bc7a04b7eb@gmail.com> <5e92dd05-074f-fde7-9281-10eaea4b0169@isi.edu> <5640.1495741035@obiwan.sandelman.ca> <606e09b0-5046-d3f5-c3ba-bf373e300f15@gmail.com> From: Joe Touch Message-ID: <73b206be-2989-e7ce-a17a-c4819c4bbbab@isi.edu> Date: Thu, 25 May 2017 15:10:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <606e09b0-5046-d3f5-c3ba-bf373e300f15@gmail.com> Content-Type: multipart/alternative; boundary="------------2788B1BA88BFA03DADA6C971" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Anima] [Tsv-art] TSV-ART review of draft-ietf-anima-grasp-11 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 22:11:16 -0000 This is a multi-part message in MIME format. --------------2788B1BA88BFA03DADA6C971 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 5/25/2017 1:09 PM, Brian E Carpenter wrote: >> We could even decide that "version 2" would start with [M_GRASP2, [stuff]] >> costing us perhaps two bytes, which is about the same as inserting a version >> would cost, but I'm still not convinced we'd ever need to do that. > You're right. If we had stuck to the original TLV model I would have agreed > that a version number is needed, but the nature of CBOR means that it > really isn't useful. Even the limit MESSAGE_TYPE = 0..255 in the syntax > isn't restrictive; a message type >255 or <0 would just kick back an M_INVALID > with old code, and would be happily accepted by new code, if we increased > the valid range. > > Brian AOK - thanks for the explanation. Joe --------------2788B1BA88BFA03DADA6C971 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 5/25/2017 1:09 PM, Brian E Carpenter wrote:
We could even decide that "version 2" would start with [M_GRASP2, [stuff]]
costing us perhaps two bytes, which is about the same as inserting a version
would cost, but I'm still not convinced we'd ever need to do that.

You're right. If we had stuck to the original TLV model I would have agreed
that a version number is needed, but the nature of CBOR means that it
really isn't useful. Even the limit MESSAGE_TYPE = 0..255 in the syntax
isn't restrictive; a message type >255 or <0 would just kick back an M_INVALID
with old code, and would be happily accepted by new code, if we increased
the valid range.

    Brian
AOK - thanks for the explanation.
Joe
--------------2788B1BA88BFA03DADA6C971-- From nobody Sun May 28 18:13:32 2017 Return-Path: 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 C3CE5126DFF; Sun, 28 May 2017 18:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlKQyGUFol8w; Sun, 28 May 2017 18:13:30 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 0E268124D85; Sun, 28 May 2017 18:13:30 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id n23so10478958pfb.3; Sun, 28 May 2017 18:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zL9tRPgvqN7eBgcJxexYflCm7Xu5WKl2IuvH5bUS0/I=; b=u9BS4HFz10+bgo1Zelj51IteX83y5xVew154Q0fwkUgI3Luc0Um/QTpGjNebmMybtk BD8tJY05ugmVokbpbArvAk8EkkyJ1/a6/1tps0gTjF1Py/qzXJR2GFzmo33hFdSYX+OI Xx65a4KdMyRufG4ZPsieP5KpqpvDcNXjVpZaynPF6700t0lI4r1Sv/4Pqe0kS2vvZLdP M3RHWobkNkhfyyPC14RBZ4+c0VKv1D7yQebkN0eH96mGXDXiGfsF7h/Vst6vY6x5pgxj Cr2HJuXXINKfLsD4qed1u1kTtawb653/S6XtrSbwzQamtn1jJ2P6WTfRD/DRGHkkUNna mwUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=zL9tRPgvqN7eBgcJxexYflCm7Xu5WKl2IuvH5bUS0/I=; b=nfrM82znFmaz8TBFtdUpp8w0WsEP0bQXzY7j/yF+QASxjGx7ULhC06nK+PmPeksb0E CbyGfoAMZcIvXGZdmK8W9K223C1jLYn3O52gZEhidvKcwl0huxa5zpQkQTlAlO0/iG43 Y8n/RQS4S983TSE62MvKsELwMBdmB6ZsmSVLZ5U4qBU3AK46c6wFmcnDGhKMUTcqbbkg Pi0m43KddlgSkKSkMhTl0TorcJ76bP6BZGzJNZUKtIYksuC8Hn84FOLfgO9Wr2BKMEfp 5hmQHA6JTkzHCzf0j/jFqgpyf3d0hmhUzsDRIhRs5t286MDAqELrsXVYTfkAaEykTo1T 9hpg== X-Gm-Message-State: AODbwcA2rAGiBMz8kHrHHcIJF8HPKMLy33kanoIZYabZDLMDX3IyAsI3 cRBWpyzm+wmKZ37Z X-Received: by 10.99.116.28 with SMTP id p28mr15814545pgc.8.1496020409380; Sun, 28 May 2017 18:13:29 -0700 (PDT) Received: from [192.168.178.21] (139.25.255.123.static.snap.net.nz. [123.255.25.139]) by smtp.gmail.com with ESMTPSA id t30sm13263961pgo.63.2017.05.28.18.13.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 May 2017 18:13:28 -0700 (PDT) To: Warren Kumari , The IESG Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149546496854.22634.10171422829527352746.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 29 May 2017 13:13:23 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149546496854.22634.10171422829527352746.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Warren Kumari's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 01:13:32 -0000 Warren, Will fix all of those. As for "as robust as possible", you are correct that it's an empty phrase. I will change it to "it is essential that every implementation continues to operate in adverse conditions." While I agree that this should apply to everything, even the British Airways checkin system, it does seem of special importance for autonomics. Regards Brian On 23/05/2017 02:56, Warren Kumari wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-anima-grasp-12: No Objection >=20 > 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.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Firstly, thank you for addressing Joel's OpsDir review. > As others have noted, this is a long document :-) I think that, in spit= e > of this, it is very well written....=20 >=20 > These comments were written against v-11, but I think are still > applicable to -12. >=20 >=20 > Section 2.1, D1: > "... the protocol can represent and discover any kind of > technical objective ..." While the document *does* say that readers > should be familiar with RFC7575, RFC7576, and > I-D.ietf-anima-reference-model, I think it would still be helpful to > (briefly) describe an objective here, or simply mention that "technical= > objective" is a term of art and point to the Terminology section (or Se= c. > 3.10). When I initially read this it sounded incredibly broad, once I > found the Terminology section it all made more sense... >=20 >=20 > S2.2. Requirements for Synchronization and Negotiation Capability >=20 > "SN5.=20 > ... > It follows that the protocol=E2=80=99s resource requirements must be= > appropriate for any device that would otherwise need human intervention= =2E" >=20 >=20 > I found this sentence confusing / hard to parse. I *think* that you are= > saying that the protocol should not require so many resources that it > cannot be deployed on devices (and so humans would still need to manual= ly > manage them)? > If so, I think that this could be clearer, but, unfortunately I cannot > provide better text... >=20 > 3.2. High Level Deployment Model > "A more common model is expected to be a multi-purpose device capable o= f > containing several ASAs." > I'm sure you are right... but for a reader new to the topic this is not= > obvious (nor clear) - would it be possible to provide some sort of > examples of such devices (or brief description of why a more common mod= el > would have several ASAs?) E.g: "multi-purpose device capable of > containing several ASAs (such as a router or large switch)" (or > whatever...) >=20 >=20 > "..it is essential that every implementation is as robust as possible."= > -- this sounds suspiciously like "Don't write bad code...". What is > the purpose if this statement? Do you think that it will somehow make > people write better / more robust code? If so, shouldn't this be in our= > standard boilerplate? This whole paragraph feels like it is not > actionable / is something that all code for all implementations of > everything should follow... (I have a horrible feeling that I'm heading= > off on a soapbox rant / that this is a pet-peeve...) >=20 >=20 >=20 From nobody Sun May 28 18:38:43 2017 Return-Path: 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 D03881274D0 for ; Sun, 28 May 2017 18:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8wttz_j6fr8 for ; Sun, 28 May 2017 18:38:40 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 CE3B0127077 for ; Sun, 28 May 2017 18:38:40 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id x64so15718989pgd.3 for ; Sun, 28 May 2017 18:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=OkFFRkgjznzghX8oN6st2F0u9qivFkb7u5Hvrk8/aIk=; b=YZCiKteiOUNuODnQEuX/AWzJxZua0ZpPPoHoFMwvRU3IUEweyDxva4rVADYikS4j2t jrWlONQtOpzYkzMoIsk73b5dc1mUPkcUR6/wy7k9L8VeDYU/kLX7IdO1fKoHrHNgqJxR daRZWIfGn7Z/SHANWtPuFaMpXE+BxjZYvBZsYFUaTUbs92GxsxpqvdR/rptIm3NaluQF D8OHzuAxr5MNKU2DYNuFPzsq5GeXl7/lP4QBHc/molNzP+aSQ9ZaDSvpUp7IHthe6jDY EI5xr82i5JGH15hhMAaIS0vAe27/4OmclUdpI5cik0yK+YgdoUtwGdQl1ResodxwVWGG y6OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=OkFFRkgjznzghX8oN6st2F0u9qivFkb7u5Hvrk8/aIk=; b=rt4IFw5moO6Vj822T4VsCx/eZVOQRyoqYx9JzR3rfZqcqEXsHRfybjA5DWCQkxwx7V tIXkt4yTCAKn1pc7AFqbylu4pQC+2NSi6DSp6No0hm36Wj+dfCwOqRZa5V/MvWjKcIq4 l0uYqZECHakgEqcv/gX09uLmr5vmPQQDbKzguDo+SfsyMa9XsxTpdJeenfGgnn6t5Hel oftUnlocCeicJwd2Wwdhn592CdEpqvPvj7Myke0MDavvMXnfHcImHiWZdVWR964H+qyp TW2Nad+RSOG0PRKEdCVU3tmwIBAYnColfj+MxPM99Y9T2//6QgfKibtPTAZwJQoc7Pah Vdig== X-Gm-Message-State: AODbwcDHzkCaYfBNspRO2+7Pp7QE/0KKgaKI6jS4ehajQ15e62bqZx4d YAHOd0CGr3SPj79i X-Received: by 10.84.210.205 with SMTP id a71mr73138857pli.136.1496021920270; Sun, 28 May 2017 18:38:40 -0700 (PDT) Received: from [192.168.178.21] (139.25.255.123.static.snap.net.nz. [123.255.25.139]) by smtp.gmail.com with ESMTPSA id g10sm13426873pgn.35.2017.05.28.18.38.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 May 2017 18:38:39 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <05b21e01-d856-ded5-87ec-da9d0f983310@gmail.com> Date: Mon, 29 May 2017 13:38:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Need WG input: Alexy Melnikov's suggestion on GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 01:38:42 -0000 Hi, I have started the process of going through IESG comments on the GRASP draft. Where something is editorial or obviously non-controversial, I will not ask for input. But I do need input on some things, and here is the first. Please answer quickly; no answer will be taken to mean that you don't care... Alexy wrote: >> uri-locator = [O_URI_LOCATOR, text] >> >> I suggest inclusion of optional transport protocol here to match other >> locators and to follow best practices for not encoding transport >> information in URIs. That would become uri-locator = [O_URI_LOCATOR, text, transport-proto, port-number] Opinions? Objections? Brian From nobody Sun May 28 18:48:28 2017 Return-Path: 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 4E2AA1274D2 for ; Sun, 28 May 2017 18:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 da2Tcj0bL0MF for ; Sun, 28 May 2017 18:48:25 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 2BF32126CF9 for ; Sun, 28 May 2017 18:48:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1046D240F6C; Sun, 28 May 2017 18:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1496022505; bh=6hEuEWeituOCPLSxd201DRHoF58L9C8lw9BIYQcTezw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Y9EMpYHNWDXm3ZjLzWRO6RdHew7m4/onlaV1RASO4PklTtv0mzLvzqGEhud7FxKy5 hZXeK9dBsNCwWFlT8YeOlj69p7jyYqKrDVwP8FktANS1TXXJFSxZeOxF0nkQ6O0Zwr PzEOfpzsEsfBXGlhvQxrQ/PkYBpb1a2xMMn2Ht9E= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 98A76240E53; Sun, 28 May 2017 18:48:24 -0700 (PDT) To: Brian E Carpenter , Anima WG References: <05b21e01-d856-ded5-87ec-da9d0f983310@gmail.com> From: "Joel M. Halpern" Message-ID: <8715f6a8-6c4e-debc-b5b2-111841f327c5@joelhalpern.com> Date: Sun, 28 May 2017 21:48:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <05b21e01-d856-ded5-87ec-da9d0f983310@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Need WG input: Alexy Melnikov's suggestion on GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 01:48:26 -0000 If, as he says, that is the best current practice then lets go for it. Joel On 5/28/17 9:38 PM, Brian E Carpenter wrote: > Hi, > > I have started the process of going through IESG comments on the GRASP draft. > Where something is editorial or obviously non-controversial, I will not > ask for input. But I do need input on some things, and here is the first. > Please answer quickly; no answer will be taken to mean that you don't care... > > Alexy wrote: >>> uri-locator = [O_URI_LOCATOR, text] >>> >>> I suggest inclusion of optional transport protocol here to match other >>> locators and to follow best practices for not encoding transport >>> information in URIs. > > That would become > uri-locator = [O_URI_LOCATOR, text, transport-proto, port-number] > > Opinions? Objections? > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sun May 28 18:57:56 2017 Return-Path: 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 AB4FA127871; Sun, 28 May 2017 18:57:55 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPpqV_iNEd5g; Sun, 28 May 2017 18:57:54 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 404461274D2; Sun, 28 May 2017 18:57:54 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id w69so10572257pfk.1; Sun, 28 May 2017 18:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YL9cAOSQCV2gFkO5AZ69pHhVXVB+EK7VYjg2GdSgTtg=; b=YeV5BjVb9C9bZtf6EUC3wyRAUDCbkeDJ4TJ6s4x0g8bV9rhgmoUaB6Sm7I7JxTuEO/ +AijJJqkpcJyIY03WkwfV2fN68eM0yUHU3qggTG8WSoNudQtIyHW4CjLqtjplfpNS95O k7k7yajs7MIpL9uwhtqp4hJsDCYVJOA2V+V720fpgvnLUJKGvvOrJsYmkA/OukgiehkX +u35ftJ3qH5aaZSp6azDWyBpiYpQP0FTbOY5MvBqdZtQMapRGEyechLhpW9gCjwyj0k8 haAlZYH/hLLB0nHlGUdbwgumdN4uqaKF/zWErIQQ5JXZE/DeNVahyZQgnyIS0aDlvkZa NWjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=YL9cAOSQCV2gFkO5AZ69pHhVXVB+EK7VYjg2GdSgTtg=; b=tjgFibfSUiAPe5sNk3iyYrGdWCfVd8gm/qC+WEGshVD1qBM6b33qz7Dl19knVhqGqq 2w3CCuixTLQD/n4bQJ5+O8VjiwLmpNzJ71FHEadUTpESjDdNeSd6jiY6cI5r2b3GtGvi 1YP/t628PT/KTDZE4YF8XgsL83OC/XfM22dLyH8kC1/aZzWoBcu1bOtpi/jf51OKW1MY WVfWVylqZqlCZWZwe8TVPWe1gkjKXNgxLOnqD/cv2XqfiSS1FmJ9O/jMZxPwNkw420Cz A+IVUaiFJplVzVirdRG3tYouDTeQX6kZUJZY4IV03ncluicYk1UkUeGKywAGvygdWx8V rUbg== X-Gm-Message-State: AODbwcDtqTCMVrIwU53kz9eZxkR/krly0YawqUYKhvXUWQpI4dkxC6zx MGL2r6X90Qu2VwGX X-Received: by 10.98.135.71 with SMTP id i68mr15089883pfe.92.1496023073728; Sun, 28 May 2017 18:57:53 -0700 (PDT) Received: from [192.168.178.21] (139.25.255.123.static.snap.net.nz. [123.255.25.139]) by smtp.gmail.com with ESMTPSA id a24sm13143769pfl.70.2017.05.28.18.57.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 May 2017 18:57:53 -0700 (PDT) To: Alexey Melnikov , The IESG Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149546932237.14094.15015791485171985477.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 29 May 2017 13:57:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149546932237.14094.15015791485171985477.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 01:57:56 -0000 Alexey, Skipping your DISCUSSes, which are easy to fix: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > As a general comment, the document has several SHOULD/MUST level > requirements which are sometimes addressed at people deploying the > protocol, sometimes at UI designers and sometimes at designers of new > objectives. I generally don't mind, but the document doesn't always make > it clear what is the intended audience for different requirements. We'll look at that, but specific pointers would help. > Other smaller things: > > "Fully Qualified Domain Name" probably needs a Normative Reference. FQDN is in the RFC Editor's list of acceptable abbreviations. But I don't believe it has a normative reference - it isn't defined in the DNS spec, anyway. I've had this problem before, way back in RFC1900! > 3.5.4.3. Discovery Procedures > > In 6th para: > > The cache mechanism MUST include a lifetime for each entry. The > lifetime is derived from a time-to-live (ttl) parameter in each > Discovery Response message. Cached entries MUST be ignored or > deleted after their lifetime expires. In some environments, > unplanned address renumbering might occur. In such cases, the > lifetime SHOULD be short compared to the typical address lifetime and > a mechanism to flush the discovery cache MUST be implemented. > > How can the discovery cache be flushed? I think that's completely implementation-dependent, so what can we say? (In the prototype, it's an API call.) > 3.9.5.4. Locator URI option > > In fragmentary CDDL, the URI option follows the pattern: > > uri-locator = [O_URI_LOCATOR, text] > > I suggest inclusion of optional transport protocol here to match other > locators and to follow best practices for not encoding transport > information in URIs. I have asked the WG about this in a separate mail. Brian From nobody Sun May 28 19:34:32 2017 Return-Path: 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 A510C128799; Sun, 28 May 2017 19:34:30 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZAqeXBhbOQP; Sun, 28 May 2017 19:34:29 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 3F143128792; Sun, 28 May 2017 19:34:29 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id i63so4917685pgd.2; Sun, 28 May 2017 19:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NQekHb2kPwXbfCVtS7hJeHbkQRbXP/+vUB53e2nBFDU=; b=IIG3sBtYYkWOpzTYDgCQhlIY5873hk/8Qr3WjmdN2ZgMJg2ci0Lo9r0LYS3N1gl/St Bb/4hb77LgI59KbhZAaGu9r/Wx7vB4A+E/KPrtO4Lh1bCrG2b/a81Wwi070q1rejuewo 82vaK1TotsQw6cNnxbUBhuHfsuzuHqE7IMm01QJQSccEFp1OzqtHRPyxA1Id00g82B8u 9tG8tX3F7zRB8Fa/qdUap0SAwyPjkoEkk17FM1hgVjcGbVHGJ83YCb8uiuwuu9+M1phr m7eH1R2b5SVdEZNOfqU4XDS03fsc/eKGKu9aCszZLWhmOUJ31B7Wp2C/fG8ljZEG9aZs fX1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=NQekHb2kPwXbfCVtS7hJeHbkQRbXP/+vUB53e2nBFDU=; b=GmJynDZ0MNCa7H5e+jcnF0aatP6f/6pm7fffOmn+A59NcgtDunJWvO2Eq22OrNp+lA LOuCQDhsYFpVv7Rl0h8SLAuawHztbFBRbY0K3Fb2M3Fj3viWGifwMBlyMl2NvUhiXkV3 S0Fk7XzK1iOHz1muVouvGTcLod/S/IJHx9y24kztqYft170X6IZNpRORxpvb+ZoDloqr JSFfCl3fP3ahaKBRo85weO1EfnH8rSUXttfbIUI/4xTcpE8XaMb2gAUEXhvm5nLy1erX HnSP+gkwSBiTMgDQWMSGDXVSo7LMmGNTqtl4RjbDFf7yJ8ZBEEI7x2Qo+AtcL8q6kBmB YmHA== X-Gm-Message-State: AODbwcBaPCrknozPX1+ipKoUe1llVXbzP/MN4pb4nnPnGOngpQTe6Xlp E31QZH4hRmciYSMW X-Received: by 10.99.98.65 with SMTP id w62mr16115909pgb.207.1496025268648; Sun, 28 May 2017 19:34:28 -0700 (PDT) Received: from [192.168.178.21] (139.25.255.123.static.snap.net.nz. [123.255.25.139]) by smtp.gmail.com with ESMTPSA id o10sm12431548pge.67.2017.05.28.19.34.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 May 2017 19:34:27 -0700 (PDT) To: Adam Roach , The IESG Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <21670722-c198-6220-5906-262877d4f2bb@gmail.com> Date: Mon, 29 May 2017 14:34:22 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adam Roach's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 02:34:30 -0000 On 23/05/2017 10:40, Adam Roach wrote: ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The document includes a couple of instances of "reasonable" in normative > statements (e.g., "reasonable timeout"). I would strongly recommend > having specific recommendations in the document where this happens. Yes, will do. > The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, but > no way to register additional values with IANA. This does not seem > future-proof. Separate message to follow. > Section 3.8.4 talks about behavior when a node has a "globally unique > address," but provides no guidance for detecting this. Are nodes expected > to check for link-local, zeroconf, RFC 1918, and RFC 6598 addresses? Any > others? Think IPv6, where this is quite well defined. The trouble is that it's not well supported in the socket API. I think the best we can say in the text is that it's implementation dependent. (To find the code for this in the prototype, search for the comment "This is a hack.") We did want to write the text independent of the IP version as far as possible, but trying to do this bit in IPv4 would be masochism. Regards, Brian From nobody Sun May 28 19:51:15 2017 Return-Path: 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 F264A1294DF; Sun, 28 May 2017 19:51:13 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBmbP1FQIPCz; Sun, 28 May 2017 19:51:12 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 979541275AB; Sun, 28 May 2017 19:51:12 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id f27so10691340pfe.0; Sun, 28 May 2017 19:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uZJG4250prUw8hv8L5/SsUDaeRCeiHAXk5a6ZXPXmsY=; b=ajqqlcbRMPEZzi0WJBoqzpsG4aTn/Legqez9M/4uQdHsn2dDBk6UsndlYFIPHKfMWS NrncLxAmboHsAS+aDAsLsFTNd5UaA1B6gEeXg/RVmwqEjjvLjjCCMl8jgBkjD7vgOvPe LPEFVvhyyhHw/ZFfI0dMNLX8CzfLCRrmJgoBUIXMezCGLgfrpToY7xf3nZNCivqtQ7Mo Knsef9WQLiPaqA3FSC4bS02YotmnkXVT8o1orEI1GCWvumbf3Uk0mV3Ysgl6CKbapNao kd+HB+zwP3b4+aBN3lkZQhviBAy/csCs3b6sJXKasjAUmcRtAf8JzOTuhRvSCvVwGfro A9Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=uZJG4250prUw8hv8L5/SsUDaeRCeiHAXk5a6ZXPXmsY=; b=pmHcNHaesuvxjgVBhKR3tR1laeQSlfpYp7nr0ueMgI5c32eRZaI8jM4ysSwn09vbwd mslu+iDNJi4P/vZ0Zpoi9vq3maz5gyQjTMGKnTFG6tor6Hzz4EUO7y+nYB95XsaX2AGX uGerFE7YyVKjgREpGCrUeHhMpLIIQHApC2o4fRl513KbZXNdRA0sIkQ/ENiuxevxKsGI UZIAmc+32hXPQOn6AONgq/x0urtAvSjwl+SW3MbxKbGRfVdNAMs6BvJF+s1F2hcqJxWB iSKw2pO5l0TDP7byEaLmgr2SNJPU4zPSsP6OOss50RoNZ4wIU8/BQfZ4iME4Cj41yC63 o7iw== X-Gm-Message-State: AODbwcDWCPLlS9jAJJlcpoIRMg/kS6b6Aa0NK+tf94i9bRCgAVp+pWls wT2BbQQ7BhpNGCb2 X-Received: by 10.99.137.198 with SMTP id v189mr16252598pgd.205.1496026272011; Sun, 28 May 2017 19:51:12 -0700 (PDT) Received: from [192.168.178.21] (139.25.255.123.static.snap.net.nz. [123.255.25.139]) by smtp.gmail.com with ESMTPSA id m25sm12710238pfk.15.2017.05.28.19.51.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 May 2017 19:51:11 -0700 (PDT) To: anima@ietf.org Cc: Adam Roach , draft-ietf-anima-grasp@ietf.org, anima-chairs@ietf.org References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1a4b149e-25f0-d4d8-1e31-4d497703129d@gmail.com> Date: Mon, 29 May 2017 14:51:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Need WG input: Adam Roach's comment on GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 02:51:14 -0000 On 23/05/2017 10:40, Adam Roach wrote: ... > The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, but > no way to register additional values with IANA. This does not seem > future-proof. Adam is correct. The current values (6 and 17) are of course values from https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml and the names are those used in the socket API. If we wanted to add, say, SCTP it would be easy: IP_PROTO_SCTP = 132. The problem comes if we want to add "transport" protocols that aren't directly over IP: things like HTTP, COAP, QUIC... for example. There's no registry for them. We have considerable flexibility thanks to CBOR; for example, as Michael Richardson noted, we could define values >255 for transport protocols that are *not* directly over IP. However, that would need a new IANA registry. Proposal: Note in the text that the current values are taken from the existing Protocol Numbers registry. Also note that if values are required in future that are not in that registry, a new registry for values >255 will be created. So IANA doesn't have to do anything now. Opinions? Objections? Brian From nobody Sun May 28 21:00:05 2017 Return-Path: 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 313A3128C81; Sun, 28 May 2017 21:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27bSiq7Ji5vp; Sun, 28 May 2017 21:00:03 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 E9A13128BA2; Sun, 28 May 2017 21:00:02 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id h64so5103528pge.3; Sun, 28 May 2017 21:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=knAfG5/FeoANRF6ycEM3AroKpR9RooTTzMxjNyRNuzI=; b=Dn1Sppz64MB7zeocc/DyGCjjaLWREIbYMwoNFZn7tB+BoSJJC81kzGkptKuLIdr4TX fjiR6hHWDt8JGLyBUtCUSTafE1uCGqphjSnx12v8ay/RGx483wih29Ih+NoSPrm/RY+7 Ehrxq7iJo5IgWl7da1SeOCIIYiL8w5wd7PIufis1T5ytCNmupHWBBxhEyG4N41UuZ8pT e8/5ElsLysEG+QE5Wt+kKCbhXCABM7Spxh+dji0VFbiguAGKdJ+iDhDMArxTYfa+KPzx V5cgxUF0PO7geQZOwHEpvfIAF6udCJfYViStyTyRRevb8lmW6Zw9tGUVO/IWr22pzJO8 PdFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=knAfG5/FeoANRF6ycEM3AroKpR9RooTTzMxjNyRNuzI=; b=a3ddMryCI6+gh5mv2gyq0oJxe4kWhJuUwiMsx99etYfSZe0+TQy39LjWHensT+JQZf S8PnVXAZ8sYIf/9OGMYKhEYvrbaHqlpWbpeg+7wBs1SkHb5uV1tI7+WUKiQIl5BrUB57 aKkMPbdk5DzIGY8tNuRxqKjZdrP6c893fQJJmkgvECKM9nvoqId17bhYaMbqYfb1yiPe 1k6cbuFAF3GYcbJUe5cGGVWd2yH8kH0NdlxNWpCITfrbSGRglb8oGSeCFmA4B9TPMfVE GGVeEQehALKOtA5Yxh9U/xKjMd1zwSgpuqyBhFd67+eeEbUdy6y9FNs/ZDLg/seNPjzR vEaA== X-Gm-Message-State: AODbwcC8Fhj4X0Min84oxuUrrtvpqQmXC44/sImpSXm6X8VN4AxMjFUd WkgriLD5egTgLRxG X-Received: by 10.99.103.7 with SMTP id b7mr16807079pgc.2.1496030402114; Sun, 28 May 2017 21:00:02 -0700 (PDT) Received: from [192.168.178.21] (139.25.255.123.static.snap.net.nz. [123.255.25.139]) by smtp.gmail.com with ESMTPSA id o76sm16749339pfi.119.2017.05.28.20.59.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 May 2017 21:00:01 -0700 (PDT) To: Ben Campbell Cc: draft-ietf-anima-grasp@ietf.org, anima-chairs@ietf.org, anima@ietf.org References: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 29 May 2017 15:59:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] WG input needed: Ben Campbell's question on GRASP (1) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 04:00:04 -0000 On 23/05/2017 13:25, Ben Campbell wrote: ... > -7, Grasp Message and Options table: Why "Standards Action"? Would you > expect some harm to be done if this were only Spec Required? Personal opinion: I see potential for harm. I could imagine that if GRASP is a success, then with experience we might be more relaxed about it, but for now I tend to be conservative about it. Of course, the WG may disagree... Brian From nobody Sun May 28 21:03:00 2017 Return-Path: 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 E6CBA128CDC; Sun, 28 May 2017 21:02:57 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slaoEGGPb0ca; Sun, 28 May 2017 21:02:56 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 B385B128BA2; Sun, 28 May 2017 21:02:56 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id i63so5111495pgd.2; Sun, 28 May 2017 21:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=slWSYx5X2SGRTsZRl20y0MCLofdq1RzUhyaAOOoIgSA=; b=XJuuPslquI2O2lN83YXXtDQq9Vcg1r/X67g0LBZ8iIu7+8Goqj2sYTfO6mnOGqqWq5 i5I8xb77Q2e2AwNfe2jntUAY0MjCYfNcOR1OiQ6rnqk/eVlRl1j5n6Fx5XhBytad6DNU vGsDxNjSxvEQ4Z1gs9zXfILtjAIqGgZTcMG318hSVBRjzCXmx59Y4bBnpFCBuDDp49zM 7suu4Ic+K21823c55lC421VFhCArofPYN+rUJcaE+VDIXQglRivnl4P+jhDCe3v2oAJo t5HvLl6cVZJ6lq6tuCnI+BmOqz/3Z4CYQnHL6yhsDE3/B8EWfIHaZGmuEiQpC0IbB9Km iVjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=slWSYx5X2SGRTsZRl20y0MCLofdq1RzUhyaAOOoIgSA=; b=izddVS+llqZDoJpKCZiEJ/r3zUScprZtHzC5RIRqOqvnZPbd1500vgBwJ6m7vl9GFK nbilXZ2tfDVFFb4Ydd0IMyPS7AuqdcvLT5J27LvpnmmMquLQ1C4sdX6lMQVPNgPFEScY msgcoTOd4GOLsO9rVIbHzjMxT3e0um+1BaGXH7fYbvvbB8okgiap6HSApugfo1ElQkji VqF5DS1Vg2YgRg6eXhJkSlccOOH1P7iVJE/mvNgT971hNELg7uQ1GSBxrZSKK4BRBxmk v+6Ow0zBcUfsd0UiHnudr+raK27BEcg4Hb8VmtxITeRruAZjLNWnF9/eFAQdsv4uMUe6 vAdA== X-Gm-Message-State: AODbwcDV9R5I02TO5HWvGAHB8Bt/tRJv40Had8XKO01h84UBBQfMnogt dGPLt5nEFI5mTA== X-Received: by 10.84.254.70 with SMTP id a6mr73411080pln.64.1496030576356; Sun, 28 May 2017 21:02:56 -0700 (PDT) Received: from [192.168.178.21] (139.25.255.123.static.snap.net.nz. [123.255.25.139]) by smtp.gmail.com with ESMTPSA id b126sm15439866pga.3.2017.05.28.21.02.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 May 2017 21:02:55 -0700 (PDT) To: Ben Campbell Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <19f8e94f-fe08-f1e8-53f5-6852953690e3@gmail.com> Date: Mon, 29 May 2017 16:02:50 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] WG input needed: Ben Campbell's question on GRASP (2) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 04:02:58 -0000 On 23/05/2017 13:25, Ben Campbell wrote: ... > - Is section 2 [Requirements] expected to be useful to implementers once this is> published as an RFC? Unless there's a reason otherwise, I would suggest > moving this to an appendix, or even removing it entirely. As it is, you > have to wade through an unusual amount of front material before you get > to the meat of the protocol. I'm open to that, and you are not the only reader with that comment. But we'd need WG consent... Brian From nobody Sun May 28 21:16:40 2017 Return-Path: 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 77FF5128BA2; Sun, 28 May 2017 21:16:31 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-ZAVxBKShHN; Sun, 28 May 2017 21:16:30 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 458EA1272E1; Sun, 28 May 2017 21:16:30 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id x64so17098171pgd.3; Sun, 28 May 2017 21:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aGyKHSMFnUPSHla5ZeI3dY0uivgCfPb4Bu2dTLKaHN4=; b=a3nud3sVmemVX3ikmLb+H1bC+c/Nd/yGfomIRebSmZL4AbEhvqAPtmtkG8ibkokCOO e3+jg8VJxsHci+u7iCd8ZIDpIfSv1EJ54fv48JTlH4Ph/Gh7VH1sv2Woon4cu+5JRaY9 w6JRwseSKprua0kH0Hkcpfgbex37ie49nocKjc50YhMOfka1c80OUq3EfnYw6h3b3y/q vHmSwkk8ZCjvAQXtR6O+IYvCBX/BfbbpzfRU/3ShXrSv4EbrYfDSfil+sT9lz9KcES6d cXJUgcLzUomZl2NIDE/BDDhH1AwIRl7yU/QDKE+Z0qE5yVVtf97MVBwTuojkdjm9lo/O /3PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=aGyKHSMFnUPSHla5ZeI3dY0uivgCfPb4Bu2dTLKaHN4=; b=P4YADJ1A3flLIGu3cJ1Gf3SBa+43ZHUTmmj9Lt5cx+djaqppYTQRyx1KGRVM6v/fqC e0+0T5D4aWqAFVx/yLYRhelpffQdwafCQOPJ/A0pNPNZ3JF741UWbJ+3sJbRW9Ee2Os8 ELVe0qrHEsD7wgcNw1mm99Z5URf9bhzzi9HZST662gEWHg+gWMQ2OIL5Rodqo21/FN0L Cg6fYG2WmOEIhTT54Qxw34dyY5fFdeVY4Bhn5XVgfpglyRnWTee6lie8/nkXwXNwz2c5 B4IM9oCR6XMqtFhG2x3aF8I5Jn3qOjT9dbMz1GNVfsZLqpOIuUdH1i6TGC3hkU9vZcnQ Todg== X-Gm-Message-State: AODbwcA/QPZuCyQJD35i+YHLpPPtqVN4pQu2Y6/Xb+iYWTaBwHYsuSru WoKOAzVl7yFm/Q== X-Received: by 10.84.176.3 with SMTP id u3mr56189418plb.119.1496031389894; Sun, 28 May 2017 21:16:29 -0700 (PDT) Received: from [192.168.178.21] (139.25.255.123.static.snap.net.nz. [123.255.25.139]) by smtp.gmail.com with ESMTPSA id p13sm15495337pfl.52.2017.05.28.21.16.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 May 2017 21:16:29 -0700 (PDT) To: Ben Campbell , The IESG Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5905c0d9-f664-1207-aa28-d4d45d5d8528@gmail.com> Date: Mon, 29 May 2017 16:16:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 04:16:31 -0000 Comments on some more of Ben's comments: On 23/05/2017 13:25, Ben Campbell wrote: ... > - 3.10.5: "SHOULD NOT be used in > unmanaged networks such as home networks." > Why not MUST? Yes, that is more logical. > > -5, Privacy and Confidentiality: Did people consider IP Addresses and > other potentially persistent identifiers as impacting privacy? Here we are dealing with the addresses of network elements, not user devices, so there don't seem to to be personal privacy issues. > -7, Grasp Message and Options table: Why "Standards Action"? Would you > expect some harm to be done if this were only Spec Required? I have asked the WG's opinion. > Editorial: > > - Is section 2 expected to be useful to implementers once this is > published as an RFC? Unless there's a reason otherwise, I would suggest > moving this to an appendix, or even removing it entirely. As it is, you > have to wade through an unusual amount of front material before you get > to the meat of the protocol. I have asked the WG's opinion. > - Along the lines of the previous comment, I found the organization a bit > hard to follow. I didn't find actual protocol details until around page > 21. Procedures are split (and sometimes repeated) between the procedure > sections and the message format sections. I think that will make this > more difficult and error prone than necessary for implementors to read > and reference. I fear readers will read one section and think they > understand the procedures, and miss a requirement in the other. I understand the problem but I don't have a solution; there is an attempt to give an overview before getting into message formats, but that leads to some repetition as well. > - 3.5.2.2: First bullet: > Please consider a "MUST NOT construction. "MUST only" can be ambiguous. > It would be helpful to explain why the loop count must not be more than > one. I can infer that from the later sections on relays, but it was not > obvious when reading this section. And unless I missed something, there's > no text that puts the two ideas together. OK > > - 3.5.4.5: This section seems redundant to the similar sections under > negotiation . Since those sections have more information, would it make > sense to consolidate them there? It makes sense to condense it. I think the forward reference is useful. Regards Brian From nobody Sun May 28 23:46:59 2017 Return-Path: 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 BC184124217; Sun, 28 May 2017 23:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 FdNCoBwUqY9T; Sun, 28 May 2017 23:46:56 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 9FF7C1200B9; Sun, 28 May 2017 23:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v4T6kogp028359; Mon, 29 May 2017 08:46:50 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wbnMt02gfzDGtp; Mon, 29 May 2017 08:46:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <1a4b149e-25f0-d4d8-1e31-4d497703129d@gmail.com> Date: Mon, 29 May 2017 08:46:48 +0200 Cc: anima@ietf.org, anima-chairs@ietf.org, Adam Roach , draft-ietf-anima-grasp@ietf.org X-Mao-Original-Outgoing-Id: 517733208.534192-7bef01a6a09445290ce83f70279ca23d Content-Transfer-Encoding: quoted-printable Message-Id: References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <1a4b149e-25f0-d4d8-1e31-4d497703129d@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Anima] Need WG input: Adam Roach's comment on GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 06:46:58 -0000 Leaving the registry for later sounds fine to me, in particular if it = isn=E2=80=99t clear yet what the registration policy should be. If we ever add not-over-IP =E2=80=9Ctransports=E2=80=9D, there might be = a need for experiments before we go registering. So I would probably identify a range of numbers that are strictly = reserved for use in experiments. (This needn=E2=80=99t be very small; say, 65280 to 65535.) Gr=C3=BC=C3=9Fe, Carsten > On May 29, 2017, at 04:51, Brian E Carpenter = wrote: >=20 > On 23/05/2017 10:40, Adam Roach wrote: > ... >> The CBOR definition has constants for IP_PROTO_TCP and IP_PROTO_UDP, = but >> no way to register additional values with IANA. This does not seem >> future-proof. >=20 > Adam is correct. The current values (6 and 17) are of course values = from > = https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > and the names are those used in the socket API. If we wanted to add, = say, > SCTP it would be easy: IP_PROTO_SCTP =3D 132. >=20 > The problem comes if we want to add "transport" protocols that aren't > directly over IP: things like HTTP, COAP, QUIC... for example. There's > no registry for them. >=20 > We have considerable flexibility thanks to CBOR; for example, as = Michael > Richardson noted, we could define values >255 for transport protocols = that > are *not* directly over IP. However, that would need a new IANA = registry. >=20 > Proposal: Note in the text that the current values are taken from the > existing Protocol Numbers registry. Also note that if values are = required > in future that are not in that registry, a new registry for values = >255 > will be created. So IANA doesn't have to do anything now. >=20 > Opinions? Objections? >=20 > Brian >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Mon May 29 11:49:09 2017 Return-Path: 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 05F27127873 for ; Mon, 29 May 2017 11:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 DiWKHM-lybJb for ; Mon, 29 May 2017 11:49:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7049A1292FD for ; Mon, 29 May 2017 11:49:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C18AA200A1; Mon, 29 May 2017 14:49:22 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 05EA0636BB; Mon, 29 May 2017 14:49:05 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-Reply-To: <05b21e01-d856-ded5-87ec-da9d0f983310@gmail.com> References: <05b21e01-d856-ded5-87ec-da9d0f983310@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Need WG input: Alexy Melnikov's suggestion on GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 18:49:08 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > I have started the process of going through IESG comments on the GRASP > draft. Where something is editorial or obviously non-controversial, I > will not ask for input. But I do need input on some things, and here is > the first. Please answer quickly; no answer will be taken to mean that > you don't care... > Alexy wrote: >>> uri-locator = [O_URI_LOCATOR, text] >>> >>> I suggest inclusion of optional transport protocol here to match >>> other locators and to follow best practices for not encoding >>> transport information in URIs. > That would become uri-locator = [O_URI_LOCATOR, text, transport-proto, > port-number] > Opinions? Objections? If the resource is really at https://example.com:9943/my/path what would text, transport-proto be? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlksbSAACgkQgItw+93Q 3WXltAf+OtbVTrWRMA/iseABOnPGi2UV3E1cdBRdK208pnFbxyXJm1tIU6oQW+JY H7Gu0ZtxfUeIpu0s3E7hie2x13EvGnJNbusi88HtMKthd7abFKsDQVRq8BO0LdGp lY78qHxQe4TccwKN5T8ON1XBm8RdP7+HlZC/1beDfhu4YuULW3dpCmNP9guodRKQ n03Lt1W0OEA3zWJ9oAaW/4JSY91QG7plBccYTfN583EBJL9+1cecI0SDj27d1fAl sYpXZ/P8taG8VIuhM89K5bPVcLneEz5V2YDQk0YBsZzM2PKD3JWa+9JkZEZJRmlw bCn1z1IGOodEdS9OI5pwxQvwA0/6jA== =bpbJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 29 11:51:52 2017 Return-Path: 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 18C75129B09; Mon, 29 May 2017 11:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb8hqhW4zQUO; Mon, 29 May 2017 11:51:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFACA127873; Mon, 29 May 2017 11:51:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C578C200A1; Mon, 29 May 2017 14:52:06 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F2D3E636BB; Mon, 29 May 2017 14:51:48 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Ben Campbell , anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-grasp@ietf.org In-Reply-To: References: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] WG input needed: Ben Campbell's question on GRASP (1) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 18:51:51 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> -7, Grasp Message and Options table: Why "Standards Action"? Would you >> expect some harm to be done if this were only Spec Required? > Personal opinion: I see potential for harm. I could imagine that if > GRASP is a success, then with experience we might be more relaxed about > it, but for now I tend to be conservative about it. Of course, the WG > may disagree... Is it easier to raise the bar or lower it? I think lowering is easier. I could live with "Spec Required" or even FCFS for M_* values >65536, btw. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlksbcQACgkQgItw+93Q 3WXDVQf/T4B3KHduZBNNAXSFRZ2d9rhAGiytgdYjjhyIpNdWEg+YTlohKx0t8oDw t/IKDumolFQoj63SA3XTJYHIm6Pp6Y7W0Ghb9X7dsUayGxxGZQBWcZPOt4bw7Yya HFUh/fE8rjAOoMQGjF5XODSiH7h4mYGCMLGbQmW45WJd3zqCnzp625YD4/7Kwel7 55fhXY+K0tV49Z39Dc2lBrIVvnbwURV1FpGGOSAV+0974wz4V2HlCXzkXKbrjC2C BCXu+R96Sx//tIHQaS1nXTU/O4/WO4ZX1f5dhY1RB8XL14Ucqodp4lumeGdqeGMR cOl8EJ7mc0c3ODkGDmWGKC27DBaYBQ== =bLGy -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 29 13:07:11 2017 Return-Path: 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 447DC127333; Mon, 29 May 2017 13:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=BqvvB/R7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZOIK3cwD 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 Y9ZwKGDnobRq; Mon, 29 May 2017 13:07:08 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A601205D3; Mon, 29 May 2017 13:07:08 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7C946209F2; Mon, 29 May 2017 16:07:07 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Mon, 29 May 2017 16:07:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=4jfxmGJuQ/gGvCczYX urcli87N43nzXP8i8tP/DZvc4=; b=BqvvB/R75w4myDe9+yBn0AcnPYhNWM3fsu RTGb3AE1RZFtnH2toc4878zIAqgYnQoXboxM93kOQvP7kUaw93O4GHyWb6h+94ha HxiZNilbUI/MAcGSWWncsPYl2WQDFYgQecb9Xd4M8h0eGocDPJuLyu3dUL07V8bu BmX4ij1+Ve4vN6ZvJVlmX585DkzjLbKS/UhtXDRoiJ3YFxSj/XYfZJ960Sop1V43 ZxH30nrjdf6sBD4Cj2KJJBSNQ7WZRzzj5HbUDTbWl5VrcLVQN3M5sH2cuYBOGWbD 4AUwrAkXFfHgBJRSj8QWIGQVnE8K18savDXgJmcXqPwLQkH5Lqfw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=4jfxmGJuQ/gGvCczYXurcli87N43nzXP8i8tP/DZvc4=; b=ZOIK3cwD YNrs4/MUqChZinVvtgqdbVHcNP0Z8aUi61z5Wy+blqil6XLu0H8rHYeITtTe1O9q 87fDWnzo4zsJpu7KJtlZZDuWnbXqt7X183YusogDztE/6ZoFNx8JBDEEvThzVTIt xAquXRYDubvCc0VQDGQXgDvzZOIN3qIjgNBlHAEcgNjf3lIrus28y0O82af9ekbJ 8Oa9oXocSS0gJs93uRzHry/+Ul+r5W+bRUt6/Pwy6bxLl1e4zjdYB1GFFvpafri9 AEvMyu/Fm97AyrXsBtQedwb7F9rPtb+g8OiVV0CKEHYaSuCGoVTTw7x94YSXUYrI zbdnbgKDMLR4wg== X-ME-Sender: X-Sasl-enc: gK8ZkLGBI4bFZc4PCoDptpVz0YcIWEKQlcYkZ6ci1PLu 1496088425 Received: from [10.3.211.251] (unknown [85.255.237.99]) by mail.messagingengine.com (Postfix) with ESMTPA id 5982E7E271; Mon, 29 May 2017 16:07:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Mon, 29 May 2017 21:24:44 +0100 Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <693C8613-EAAA-4BB2-AFE5-3DD58151587E@fastmail.fm> References: <149546932237.14094.15015791485171985477.idtracker@ietfa.amsl.com> To: Brian E Carpenter Archived-At: Subject: Re: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 20:07:10 -0000 Hi Brian, On 29 May 2017, at 02:57, Brian E Carpenter wr= ote: >> 3.5.4.3. Discovery Procedures >>=20 >> In 6th para: >>=20 >> The cache mechanism MUST include a lifetime for each entry. The >> lifetime is derived from a time-to-live (ttl) parameter in each >> Discovery Response message. Cached entries MUST be ignored or >> deleted after their lifetime expires. In some environments, >> unplanned address renumbering might occur. In such cases, the >> lifetime SHOULD be short compared to the typical address lifetime and >> a mechanism to flush the discovery cache MUST be implemented. >>=20 >> How can the discovery cache be flushed? >=20 > I think that's completely implementation-dependent, so what can we say? > (In the prototype, it's an API call.) I think you just demonstrated my point that some requirements are not very c= lear whom they apply to. Passive voice is causing ambiguity here. I think I would like to see more text on what different possible alternative= s are and which entities need to implement the MUST. From nobody Mon May 29 13:08:22 2017 Return-Path: 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 438E5127333; Mon, 29 May 2017 13:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=VrKuH3pL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o6rxSzXX 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 u5WdoDVK7Qw7; Mon, 29 May 2017 13:08:15 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8E01205D3; Mon, 29 May 2017 13:08:15 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9828B20971; Mon, 29 May 2017 16:08:14 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Mon, 29 May 2017 16:08:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=8B5VaOGG7ECOqrcYBG JZdll4Ld/ak2cWsLBk91vk9PY=; b=VrKuH3pLo36X9aX6XVFAWdvSYRg4m9e2q6 aKm7VTM1lCm09G5z9TU5VCDtKLNe7TgNI2+dG9oft0DGRitgAMObxfKmew5rYbyK 9jNcG57pnq38kLPR6eYLj8yHj6ybrizAqIAzQdM4nn8HRvn3c3C3rqx9zXi3mnP6 StorKGAmZPJYzUZC/F9vS2VauadLkTKDZI/ons+5QWpglm+zxZETTzyksYZPA/Mw kQ/Y5kc+vh7i/F4rzER/XbnXprQDAG61HmvzatH3IgoGBU4e9+NhiyAQDugUfGr+ 4SHfrEoI799ExUgyBrTFSI9vheCxmDoSMf6gSvgPh3s6+PsuKjpg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=8B5VaOGG7ECOqrcYBGJZdll4Ld/ak2cWsLBk91vk9PY=; b=o6rxSzXX hEGU6ix8+boON1NlQE1iMsH5+DxlvFqAqnoYOlRoi5ppsR0w+Pm5pTSj1ZNEp6Oi cgFAR7+gfGPhJ4cPGfO8exm9mM5WJmGXeiBMEDRVzhJktlPg5T3HRnQbf/jxiVBt Tu0Qy0vLlr98p5Qs/Ghp414OpdJFMJoEH3zPCsgTQCZp628Ev0Ai296mDCmIjAn7 dByAN3PVFjlmckir00laiNA+fRBu4XmR1o8YIawEDFXyYUHIQv7+SHOhOJZSpZtH ZQF1YKIioDvdV+DNc4nxoYaI5nMrMw5tHfDq8VEB4R06BP5CwbHqijo6UfjnicSL 1/v1D/s13vLpKQ== X-ME-Sender: X-Sasl-enc: ONo669SHqCWCB5GMDIdMjPQnLEfyYLlrchnLIO3e3HtQ 1496088494 Received: from [10.3.211.251] (unknown [85.255.237.99]) by mail.messagingengine.com (Postfix) with ESMTPA id 3C59E7E7C6; Mon, 29 May 2017 16:08:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Mon, 29 May 2017 21:25:38 +0100 Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149546932237.14094.15015791485171985477.idtracker@ietfa.amsl.com> To: Brian E Carpenter Archived-At: Subject: Re: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 20:08:16 -0000 Hi Brian, On 29 May 2017, at 02:57, Brian E Carpenter wr= ote: >> Other smaller things: >>=20 >> "Fully Qualified Domain Name" probably needs a Normative Reference. >=20 > FQDN is in the RFC Editor's list of acceptable abbreviations. But > I don't believe it has a normative reference - it isn't defined > in the DNS spec, anyway. I've had this problem before, way back > in RFC1900! Thank you. I am Ok with no change. From nobody Mon May 29 13:31:44 2017 Return-Path: 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 982BB12945B; Mon, 29 May 2017 13:31:43 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jMb3RdjVzX7; Mon, 29 May 2017 13:31:42 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 E22D1127869; Mon, 29 May 2017 13:31:41 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id u26so13297467pfd.2; Mon, 29 May 2017 13:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+bSlyDslMzQqFprY1YjpM8w4Z0+p18iVGJ8gygAx9Mw=; b=i4vVmf387csuxQq+lTjHkCfMjTnD3d692Q8aOIqMI4kD+ldv/I3qdG8FBZn2vjQ8hx Jhs3zF3jhJLhkEIvCfar9AdG2W2jT8X0EWsnpyb4hW6lOlHYRBAlHpKf2zQJV5jYTL8u s1dLwXD4PMnbNE8LrzocOBWOBgyT8L3IEg1ALPlpQYWBsiDFyuzLN1kLzlSgQpKV+7sQ 8e8frti/B9xzWAINVxyVUBrULHiVxINK3qd9U41oUv1T6S2KI/9kXICo01Oin/BL5Wt6 dtja9d/fWKDHNhGZVc2VvRjoQk72HpOFjVUe0BwLLkMVq7JsgzhterwDJ6GB3+wXkpdu /g3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+bSlyDslMzQqFprY1YjpM8w4Z0+p18iVGJ8gygAx9Mw=; b=UZCNv2m4dAmwXmhn+Lovlgr5PXvwXNXlunSY9iOpn+9wexkFDKbpKQ1g/Fsqt31QsT EL4ecRSiIumBiif+AZlBdQbA7KOOJ1uBQteUdNTWO5b0T87q4h1kgw1MrnGfzpMg+cGa owur7fgLRpIjn/MrGmZRHbV2roxJoi5Z9HB8g2pKBverP88BX3MpWDvupLkqC+1ocfk3 nGbgtaDpeR6G5uZQoeX98/TdRaCz9stin4oa3tq/ZeQJ/GwOt65LXPIBSuLeryZ22dg2 jMzsqDVfax9O/K1WdSC3xoP7wO7EqolIXn382wvgyFw0bosQIyO9o9/NChZtUCwqYLQ2 6l0w== X-Gm-Message-State: AODbwcDkRIG/TFzd6ZOP85S8Ifvfs0L5bZkiWAEZ2lNxpTQAvMsLKWOO vh2xvwQqEXSySw== X-Received: by 10.84.130.7 with SMTP id 7mr77504152plc.35.1496089901577; Mon, 29 May 2017 13:31:41 -0700 (PDT) Received: from [192.168.178.21] ([118.148.69.51]) by smtp.gmail.com with ESMTPSA id 19sm16354420pfz.39.2017.05.29.13.31.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 May 2017 13:31:41 -0700 (PDT) To: Alexey Melnikov Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149546932237.14094.15015791485171985477.idtracker@ietfa.amsl.com> <693C8613-EAAA-4BB2-AFE5-3DD58151587E@fastmail.fm> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 30 May 2017 08:31:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <693C8613-EAAA-4BB2-AFE5-3DD58151587E@fastmail.fm> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 20:31:44 -0000 On 30/05/2017 08:24, Alexey Melnikov wrote: > Hi Brian, > > On 29 May 2017, at 02:57, Brian E Carpenter wrote: > >>> 3.5.4.3. Discovery Procedures >>> >>> In 6th para: >>> >>> The cache mechanism MUST include a lifetime for each entry. The >>> lifetime is derived from a time-to-live (ttl) parameter in each >>> Discovery Response message. Cached entries MUST be ignored or >>> deleted after their lifetime expires. In some environments, >>> unplanned address renumbering might occur. In such cases, the >>> lifetime SHOULD be short compared to the typical address lifetime and >>> a mechanism to flush the discovery cache MUST be implemented. >>> >>> How can the discovery cache be flushed? >> >> I think that's completely implementation-dependent, so what can we say? >> (In the prototype, it's an API call.) > > I think you just demonstrated my point that some requirements are not very clear whom they apply to. Passive voice is causing ambiguity here. > > I think I would like to see more text on what different possible alternatives are and which entities need to implement the MUST. In this case, I'm more inclined to simply delete the reference to flushing, because it's really part of a much more general problem: https://tools.ietf.org/html/rfc7010#section-7 . The previous comment about the cache lifetime is sufficient. [In fact, renumbering would be an interesting use case for autonomics, but that's a whole topic in itself.] Brian Brian From nobody Mon May 29 13:40:18 2017 Return-Path: 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 1161E12944F for ; Mon, 29 May 2017 13:40:17 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Kun2c9Zsn8b for ; Mon, 29 May 2017 13:40:15 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 A3D87129437 for ; Mon, 29 May 2017 13:40:15 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id n23so53001123pfb.2 for ; Mon, 29 May 2017 13:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3BWztftzuBjM8Cmur3yMkqVAWNgYUlzqo1b7nVdeTG8=; b=MG0+Sk35LAfMyZHK6VdAlVcucBavqq0Av2WNnIMy5dmEmDx7TRK+E/XyqpeOdmaX33 rDoK6ixGoW289CgDR7BIzD4vs4BmqxPtcGK2MRqCuTMJ1bfZvfx8Y4nOv21Dy5vmbWLp bAkKRF4RzkW6wbWie3Is1ohbl5vK+hHuB9qPxt5b5bqU+dC3WTLgJXuck6bva0AxRuGv DN1wmgZ03xejGYK+1Ytr2VL3AnszhN9L7dBmDQsEkYeaI+uNnlb6s7Lb2MDWfZM97A9z kv7IZCQYyJQnBXj+hRSiYNF/KdRME4gu84Spqyli4pZfBtWjrdU9EEvzzs4sfngLBCxO /suw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=3BWztftzuBjM8Cmur3yMkqVAWNgYUlzqo1b7nVdeTG8=; b=N/IRCBkEIcyLjst3mcn9c4nbJKjYyuKvAdWph0IWUr/RhoV46J6JE3C8P7+ga7HTih oxMrA5mnxEsMGLaKEaellAQzziH6CoYC70TJlhV7fIuEdmepuE3cEviwfbQHEKaRvfBl ZF5ojfDAE5aa84YZFuTGL4Sc5x78alTgf1/8fb3z6ShGfaiLXEqrNO5qCpqJT/0j06A/ kWpz7gcPBRNCpSqLmLj6C7nRBO4+tWna3i3pnuZXwnot/gLndfAZ+nWilfZViSadyYoM DQgjcgRHwREHLlS8g1VgndcOPu72l9UaiOvyw9sryCeschZnm+S7EiSiC2lT7uphPhoN yDAw== X-Gm-Message-State: AODbwcDUnpjoGhpIizu74zng4pvXwj+uY4yZjebwq8JmoWWsRjvELi6x WwhpNVJqL3s7J6kz X-Received: by 10.99.174.77 with SMTP id e13mr20903764pgp.145.1496090415018; Mon, 29 May 2017 13:40:15 -0700 (PDT) Received: from [192.168.178.21] ([118.148.69.51]) by smtp.gmail.com with ESMTPSA id k23sm15982255pgn.11.2017.05.29.13.40.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 May 2017 13:40:14 -0700 (PDT) To: Michael Richardson Cc: Anima WG References: <05b21e01-d856-ded5-87ec-da9d0f983310@gmail.com> <26917.1496083744@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <21a266aa-5650-d6bd-5a2d-a02bfc60eedc@gmail.com> Date: Tue, 30 May 2017 08:40:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <26917.1496083744@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Need WG input: Alexy Melnikov's suggestion on GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 20:40:17 -0000 On 30/05/2017 06:49, Michael Richardson wrote: > > Brian E Carpenter wrote: > > I have started the process of going through IESG comments on the GRASP > > draft. Where something is editorial or obviously non-controversial, I > > will not ask for input. But I do need input on some things, and here is > > the first. Please answer quickly; no answer will be taken to mean that > > you don't care... > > > Alexy wrote: > >>> uri-locator = [O_URI_LOCATOR, text] > >>> > >>> I suggest inclusion of optional transport protocol here to match > >>> other locators and to follow best practices for not encoding > >>> transport information in URIs. > > > That would become uri-locator = [O_URI_LOCATOR, text, transport-proto, > > port-number] > > > Opinions? Objections? > > If the resource is really at https://example.com:9943/my/path > > what would text, transport-proto be? "https://example.com:9943/my/path", Null, Null perhaps. Also of course see the thread on Adam Roach's comment. Brian > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Mon May 29 15:41:47 2017 Return-Path: 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 63171129485; Mon, 29 May 2017 15:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBcuW3_AcG0Z; Mon, 29 May 2017 15:41: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 31DE712945A; Mon, 29 May 2017 15:41:44 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4TMffOm096424 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 29 May 2017 17:41:41 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Mon, 29 May 2017 17:41:40 -0500 Cc: draft-ietf-anima-grasp@ietf.org, anima-chairs@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Anima] WG input needed: Ben Campbell's question on GRASP (1) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 22:41:45 -0000 > On May 28, 2017, at 10:59 PM, Brian E Carpenter = wrote: >=20 > On 23/05/2017 13:25, Ben Campbell wrote: > ... >> -7, Grasp Message and Options table: Why "Standards Action"? Would = you >> expect some harm to be done if this were only Spec Required? >=20 > Personal opinion: I see potential for harm. I could imagine that if > GRASP is a success, then with experience we might be more relaxed > about it, but for now I tend to be conservative about it. Of course, > the WG may disagree=E2=80=A6 If that=E2=80=99s the WG answer, I am perfectly happy. I just want to = make sure people have thought about it. Thanks! Ben. From nobody Mon May 29 19:45:37 2017 Return-Path: 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 C5540127698; Mon, 29 May 2017 19:45:35 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlKxSIugrbHq; Mon, 29 May 2017 19:45:34 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 54D641274D0; Mon, 29 May 2017 19:45:34 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id n23so14595394pfb.3; Mon, 29 May 2017 19:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UI28Y9dKqexFGjh/apa3L4+71LiC7t4O5OUcnIR1M78=; b=tojG0AJWPBBX9D98+f+2wrPRYc5ZWtFkMADkAwSOy680F/69+bfxguoVPEMvECsEs+ My/NBUpMXogFnqCJoeS1xSQoIyM9LDWH8jzjked+F/FyrnZNW+K7sSZWpshSt43ZR08e MIzlJm8tVHRWOamyhAe3rmgG49wltqiLOoHdwDRPFTxVOtJURJT8nX2nUyzji5cCXXtU zvTYc6FQI4iU0+CL8JJg1duAYDnOmtKMo81twb63nYKWm8V1+qP8LZzz3UxK+xDYVlhT v4AZgwJpO3Si742Rsn5rGFt9mDLsi5IDNonFMzeeHhFeZoXdnihsDYi2egHdJc9IzLkL nJjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=UI28Y9dKqexFGjh/apa3L4+71LiC7t4O5OUcnIR1M78=; b=uigdK7xqIr96teje8VhZrGL1KUsTQ4DDEmDIN988oOZv+WPcKMKMUih+t97z2Q8evY EDdHAu+x2gzX94fzsxDrxkNzCx8TE0OTozDi7ZJeGgKklp6kcmhcO1cOUCVvpVIIfYiS cUG4roUfPe+1JFwDK6N5NyZWvexp09WMgb4IF0FQX9whYevNjH2q4IcYD81QPu7NoUQd 63bNo+S0QnGS4FKHlJZYO2hG5L4IKu81QsZAYvZrZ8Au8RO7niEVYDVbyPC38MUK3lhG IeHsvzEwPnOylOwEw80G55h12OM/DFJA/uDciXheZEPeVyIv9gPKBJ0M4fGK6drTU608 P/2w== X-Gm-Message-State: AODbwcDhM7KU72F3DzkGqvwFxdU/Zn1CRSU2lHpyR28TEE2mHjq5Sxxg 72WEMdnxM35FQDYl X-Received: by 10.98.60.8 with SMTP id j8mr20597236pfa.72.1496112333504; Mon, 29 May 2017 19:45:33 -0700 (PDT) Received: from [130.216.38.132] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.132]) by smtp.gmail.com with ESMTPSA id k79sm18957882pfj.6.2017.05.29.19.45.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 May 2017 19:45:33 -0700 (PDT) To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , The IESG Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149555276275.18049.7515853778089282062.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 30 May 2017 14:45:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149555276275.18049.7515853778089282062.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-anima-grasp-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 02:45:36 -0000 Responding to Mirja's comments (her DISCUSS points were already discussed in other messages): On 24/05/2017 03:19, Mirja K=C3=BChlewind wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Other mostly editorial comments: > - ASA needs to be spelled out in the intro. It is ;-) > - I would recommend to move section 2 and 3.3 into the appendix Moving the requirements (s2): already asked the WG about this. "High Level Design Choices" (s3.3): But this is a description of the design. Are people confused by the word "choice" perhaps? Just in case that's the issue, I will simply delete it and the section will be "High Level Design". > - section 3.5.4.2: "A neighbor with multiple interfaces will respond wi= th > a cached discovery response if any." > "cached response" is explained in the next section and not clear in > this paragraph. It's hard to give an overview without deferring some details. We'll try to simplify the text. > - section 3.5.4.3: "After a GRASP device successfully discovers a locat= or > for a Discovery > Responder supporting a specific objective, it MUST cache this > information, including the interface index via which it was > discovered. This cache record MAY be used for future negotiation or= > synchronization, and the locator SHOULD be passed on when > appropriate > as a Divert option to another Discovery Initiator." > Not sure why the first is a MUST and the later is a SHOULD. I guess = a > SHOULD for caching would be sufficient. Fair enough, although not implementing a cache would be a bad idea IMHO. > - section 3.8.6 "If a node receives a Request message for an objective > for which no > ASA is currently listening, it MUST immediately close the relevant > socket to indicate this to the initiator." > How is that indicated? Should really be further clarified That's covered by one of Martin's comments - a transport session failure indicates a failed negotiation or synchronization. [BTW I'm impressed that you & Martin picked this up. I discovered it experimentally with the prototype and we have a couple of API error codes for it, but I failed to think about adding it to the text until I saw Martin's comments.] > - Also section 3.8.6: "In case of a clash, it MUST discard the Request > message, in > which case the initiator will detect a timeout." > Why don't you send an error message instead? How does the initiator > know that is should retry (assuming there is a TCP connection underneat= h > that provides reliable transport)? First of all, this is an incredibly rare event, even given the birthday paradox: it's a collision of two random 32 bit numbers. So it really isn't worth any extra machinery. Second, an ASA always needs to be ready to retry anything in case of failure. That's kind of the First Law of Autonomics: never give up. > - Also section 3.8.9: "If not, the initiator MUST abandon or restart th= e > negotiation > procedure, to avoid an indefinite wait." > How does the initiator decide for abandoning or restarting instead? > Needs clarification! It's irrelevant here whether the initiator abandons or retries. All this means is that when the timer pops, the negotiation has failed. We will reword this accordingly. > - Could be useful to include an optional reasoning field in the Invalid= > Message and make copying the received message up to the maximum message= > size of this message a SHOULD (section 3.8.12.). By making the body ?any we certainly allow this. Also, ?any could be a CBOR array like [reason, rcvd-message] Personally I think we might leave this undefined until we have some experience. This is another example where CBOR's flexibility is a great asset. > - Not sure I fully understand the purpose of the No Operation Message > (section 3.8.13.). If you just want to open a socket for probing, you > perform a TCP handshake and send a RST right after. No need for further= > application layer interactions. And should there also be an optional > reasoning phrase? I hope you can agree it's harmless. (Actually your laptop probably received some of these in Chicago, because we were running GRASP sessions on the IETF network quite often.) The reason I found it essential was to discover the port number assigned by the O/S to a multicast socket, which you can only get by sending a multicast and then using getsockname(). It seemed more civilised to use a defined no-op than to just send a null packet. > - Not sure why the objectives flag is needed. I assume that unknown > objectives are ignored anyway and if a objective is known the receiver > should know if that objective is valid for the respective message type > (section 3.10.2). Discovery-only can be useful and the "dry run" flag is dynamic. Also of course it is another hook for extensibility. > - section 3.10.4: "An issue requiring particular attention is that GRAS= P > itself is a stateless protocol." > It's not. It caches information and needs to remember previous > messages sent to reply correctly. Right, but it isn't transaction-safe (ACID) which I guess is what we mean= t. > - section 5: "Generally speaking, no personal information is expected t= o > be > involved in the signaling protocol, so there should be no direct > impact on personal privacy." > I don't think this is true because the protocol is so generic that y= ou > cannot say anything about the services it is used for. Well, we can say what we *expect*, but you're correct. Since we are requiring crypto, we should be OK anyway. Will reword slightly. > Please see also further comments from Martin's tsv-art review (Thanks > again!)! Thanks Brian From nobody Mon May 29 21:21:59 2017 Return-Path: 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 ADBAC127B60; Mon, 29 May 2017 21:21:57 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8jsVeIQv12M; Mon, 29 May 2017 21:21:56 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 801CC1200FC; Mon, 29 May 2017 21:21:56 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id u26so15060137pfd.2; Mon, 29 May 2017 21:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QBeXIGg2far1WgOj8AtXdX/rDApsgVV5DMoyIQEuz4M=; b=nUnRvYTuY1TULv6tzf79Z2K6X4O4qYSrncvQOmnuJby6A8nyIsE2nHMiqMi6qL/GGJ Jrc2Gn1VbtRBpyII/xyPADuGAvtl/Cxoqi0sTV/tHUkyLcJn3jkHfA+8tirMrLm5exx0 yaFtdWCudqazqIooTvldOGgNiQWI3zhjmmncAOwthmsRkMkdFRQERhxVCscS2j9emqF8 Mu/Ii62xrtV/3v3t7ZeDM4QaLNUHHM49gGExeeqaRdbEhnNYraytbievGBxtNL4V37Vt DVF0uUAIZsjsO8QkAc2TDT/cnoRN5hXFe93DM7QeX9rXDKzyq3YhzuiIrlllaeY5Od1J nWhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=QBeXIGg2far1WgOj8AtXdX/rDApsgVV5DMoyIQEuz4M=; b=NSXG5jyc66RQOORybhItjuqzYEpxtQ9wWY5hZwHfso/CkcShhVUQDAArPiRxwvVDJt 8d2wWexoXbnkFDBqlMUwQ0FtT2POof5EeLCH53Vr0hBJ85QBQzOKKHC9XJv47FVbb5bL 4Nf64mtGuC82IP63Zrb1TexTG+HA250mAhCcC7EnENCzkahT5sdoh9BcmF0vLVXh1Z7W nIEpTakFDaYtNsUb+EwDRgNokdAUiiyuL2MjAydwbz7CdfHVhLnkqXHgj9rsUXeF7syE Ft3+T+4ZO8wABsjfCPOd4+BknuvoeaZEYWw88SBxDZFzTgyEuasIy0NLrkP83Pr0Xxit S+5g== X-Gm-Message-State: AODbwcCJqrhEo4/xiv7KQpeSQ1vb5l99DTdmsQqw5RMC+MedbRWcpyb4 18UZg2oRqm8mWyvw X-Received: by 10.98.155.28 with SMTP id r28mr21463200pfd.198.1496118115993; Mon, 29 May 2017 21:21:55 -0700 (PDT) Received: from [192.168.178.21] ([118.148.69.51]) by smtp.gmail.com with ESMTPSA id s68sm20476482pfj.5.2017.05.29.21.21.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 May 2017 21:21:55 -0700 (PDT) To: Deborah Brungard , The IESG Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149557037501.28451.8442609199900920951.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 30 May 2017 16:21:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149557037501.28451.8442609199900920951.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Deborah Brungard's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 04:21:58 -0000 On 24/05/2017 08:12, Deborah Brungard wrote: ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The comparison text to routing protocols is outdated as ignores TE > which can support any link/node attribute desired (bandwidth, > availability, latency, etc.), discovery, bidirectional negotiation for > use, and > autoconfiguration (e.g. RFC 5340). When first discussing automatic > networks, it may have been useful to compare with routing, as at a > very high level view, it may look similar, but I think it is no longer > relevant, and very confusing for a routing person. Suggest instead of a > "I'm more complex than you" approach, remove these paragraphs. > > A few minor edits will fix. > > Suggest to remove the first paragraph of Section 2.2. I agree. > Or edit: > 1. links are no longer simple: "consider simple link"/s/"consider link" > 2. Delete from "nodes need a consistent, although partial, view of the > network topology in order for the routing algorithm to converge. Also, > routing is mainly based on simple information synchronization between > peers, rather than on bi-directional negotiation." I think what you want > to > infer by "partial" is for a protocol instance/region. But there is > support today > for multi-layer and multi-region networks. And convergence scale is > implementation. But none of this is relevant to anima so best is to > delete vs. > trying to fix. > > Appendix E > Remove the paragraph on routing or preface with "Early routing > protocols.." I agree. > And the paragraph on RSVP is really not relevant for this comparison. I think it is, because RSVP for IntServ really does negotiate a QoS spec along the path. > Unless > want to edit, as RSVP-TE does do "discovery". Not quite in the same sense, though. On balance it's a bit irrelevant to the point. Thanks! Brian > > > From nobody Mon May 29 22:15:13 2017 Return-Path: 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 6A0E4129B57; Mon, 29 May 2017 22:15:05 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8lKpBeZuiLd; Mon, 29 May 2017 22:15:03 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 C0CB7127076; Mon, 29 May 2017 22:15:03 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id f27so15343386pfe.0; Mon, 29 May 2017 22:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ITYNkTUwOvZUczFOLOV1sNoj/GzYjgDQpMbzP0Lt5oI=; b=ggqQwt3nR5gRRpJH8fEU6RwnFSc1cCP/jePzgGE/p3SJsN3m7Kia933oDpJ5Autu21 zUWL2EL6Eg3tWCy+haxueh0uEpnM/G1F4WeKa1J1ViApCv1TJE3zqzMhIwfCp/GUmpuJ 1M70070SNySbRj8SjvO0a92P1Cg00L4C81dL48TNTUl+ROvio2Tv3NNaGM+yspaqVpAD +KwOXpnWW3nZ0mm2mtGjHCAmev2e4w3ySMri/zW60DQ0NNzJENq2Hq5ZOXnzHkhgE/7B RVCYBBHUb6fmiCLhzuumLdcvxZ8TolOlvtyg99fYbcI0j5HgUHxvs1fF/PWB3RivQjl4 gs3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ITYNkTUwOvZUczFOLOV1sNoj/GzYjgDQpMbzP0Lt5oI=; b=LkS7Ud9ga17eDpa3m60DmFhQCPdUOLYPRGMjd9uYczgocLKeHvRC26HYpXS5vmRcYv VQVvTequZIaDPAYFFzrlL6jeMtBzrj9EGc11RiOslGbm7/9RykaRv92CoVuEv/8kToGx 9Pxl6W66afpwQPFFKw7nrDuiiUGQ20N/bA+M35VWBcI+djrQJRpwSMGDjSNLlZBQgLKZ 7O2mpk3n8S0wGKgGloLo4SZQsrog4FvFG87Kh8WIERImcq81p4ZvbM/NiCCaLkPTP8WL 0Tm9b3sZiPXt0I03PIRVAc3Um0MHHSzZ+Rp03zmnup7XOpuZrEByTxfJskEweg5Ok8dE Weew== X-Gm-Message-State: AODbwcCTTSFwX/HvVu3aCoGD6BRW6f+ACtFQvKyukMq8MrKqiAgIF0fr ASYTLUrHpTheZQmE X-Received: by 10.99.109.141 with SMTP id i135mr23156888pgc.33.1496121303111; Mon, 29 May 2017 22:15:03 -0700 (PDT) Received: from [192.168.178.21] ([118.148.69.51]) by smtp.gmail.com with ESMTPSA id x12sm18939167pgc.47.2017.05.29.22.14.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 May 2017 22:15:02 -0700 (PDT) To: Eric Rescorla , The IESG Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> Date: Tue, 30 May 2017 17:14:59 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 05:15:05 -0000 Eric, On 25/05/2017 14:32, Eric Rescorla wrote: ... > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > ISSUE 1 > The security situation here is pretty unspecified here, in at least two > respects: > > 1. In terms of communication security, you seem to have two modes: > > (a) Punt it to ACP > (b) Use TLS as specified in S 3.5.2.1 > > I'm not reviewing ACP here (though I have some comments on that too) Yes, that certainly needs a thorough security review ASAP. > but S 3.5.2.1 doesn't (for) instance explain how to do certificate > validation, Indeed not. But... > which it clearly needs to do. We intentionally want to leave this for further study. Surely that is allowed? The text seems very clear on that. Personally, I'm not competent to design that, and this draft is already plenty long enough. So what can we write if we can't write "Further details are out of scope for this document."? > Finally, I don't > understand the security story for the multicast packets. I think I already typed this a day or two ago, but with an ACP, they are secured, because the ACP is a secure virtual overlay network. With no ACP they are of course wide open, unless some new magic has been invented that I'm not aware of. Hence the restrictions in 3.5.2.2. "Discovery Unsolicited Link-Local" > This is especially relevant for Rapid mode, where you are > attaching real work to these multicast packets. Correct. I think we need to forbid that in the no-ACP case. > 2. I didn't find the security model very clear. As I understand > things, basically anyone on the network who has ACP credentials > is trusted to engage in negotiation with you, so, for instance, > if you want to get parameter X, then you basically just trust > whoever on the network offers you X. is that correct? That seems > like it needs to be very explicitly called out. And if that's not > true, then I don't understand the spec. That is the trust model, but really as an explanatory matter I think it belongs in draft-ietf-anima-reference-model rather than here. I will add a few words in the High Level Deployment Model section and/or the Security Considerations. What we do say already is that authorization of ASAs is out of scope. I am certain that it needs to be tackled, but not here. > ISSUE 2 > This document seems like it provides incomplete guidance on how > to actually implement it. For instance: > > discovery messages to a reasonable value, in order to mitigate > possible denial of service attacks. It MUST cache the Session ID > value and initiator address of each relayed Discovery message until > > What's "reasonable"? Yes, we will fix various instances of "reasonable" but I daresay further experience will shed new light. > > > ISSUE 3. > I don't think I understand how the transition from UDP multicast > to TCP/TLS unicast works. Maybe I'm just misreading the spec, > so could you point me to the section that describes this. This only arises for discovery; the discovery result explicitly includes the address/protocol/port for the actual operation. For discovery it's in https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.4 The listening port used for TCP MUST be the same port as used for sending the Discovery UDP multicast, on a given interface. In a low-end implementation this MAY be GRASP_LISTEN_PORT. In a more complex implementation, the GRASP discovery mechanism will find, for each interface, a dynamic port that it can bind to for both UDP and TCP before initiating any discovery. Python code on request ;-) > Finally, I don't see a spec for how you map CBOR onto the wire. Do you > just shove them on? Something else? Yep, CBOR is just a string of bytes. That's CBOR 101 so I don't think we need to say anything more. > > I see that Martin Thomson raised a number of these issues in his review > in more detail. > Martin Stiemerling I think. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- Almost dinner time. I will get to your other comments tomorrow. Thanks Brian From nobody Tue May 30 05:30:16 2017 Return-Path: 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 C5A1E129C13 for ; Tue, 30 May 2017 05:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 eef-6Z92Daba for ; Tue, 30 May 2017 05:30:13 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 2C973129C11 for ; Tue, 30 May 2017 05:30:10 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id l14so39141027ywk.1 for ; Tue, 30 May 2017 05:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+A02bU3ITSM/XEIE6gIoFkTp67IKqrjSm4JT0XWuxqg=; b=dY47sRyjTbIfERtcyFOMRcM2/WjbwSuS55o8E71JRKcNXaYkLtv0fG02si1KMHLA6/ xkzIMS+L/YKEtSQ3CpW55jN8DYM6lrYed5eFsvEpPyLMWSIOBQxEaSG60z7B83k9olIC UGyVF5EjYGzHfwFkOAzpimB5mh5789qeobdo92cYhGoYRN0NnPus9zFtCoxe1NRQWWdc 4bY3VOLhDiQlQC4zhgjqgK+b7o1ECkQZln4BABSw0NjK4N6E7I8L8ZdLfEuzmtfmumvW o0uieObdudFkNy/0q45wNkzHvd54haq7PIQfauSXewR56FARWG7qbQ5o+wm73QMNjmc+ diCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+A02bU3ITSM/XEIE6gIoFkTp67IKqrjSm4JT0XWuxqg=; b=YLDh/7ux59r+XV5lkWXrrlh5hvGNBtTfXDr3aVKw9KRVsMgFvRqtbL63cK6C3CHl7C UhXJG3Dz3jltIvyxEaqMU2ulqHWqWzkZg3jJdepTwFgquAGnslTqKAS0CtHQK98MmJ2m oUAPWlyCZB2TRuKWZKuECDRudIYDlu8EmxMZAPeOqeT+lj6kB3DIWKtf8/ks1D2JeQl7 GUpj62j2LlX6WBU7s29yzkevdwT88Fr6U3ecVg+++uN7o4mT85aZXs8QVmKglgMEVmXV PLe6iBbaFnlqutjo6OslS9zMZJp+t94/pD8ZfuMguKsaKdhG5oMz6ehGxHuHqbPaGCDo 2fRg== X-Gm-Message-State: AODbwcAFlCW9cadyfr9crpS1XgoN87EBxmV9nzhjtudQS6vqDRC+kG+f VEJLMWqtvOttVYyOVbo1tMovixgFG+3h X-Received: by 10.129.104.69 with SMTP id d66mr15335539ywc.74.1496147408629; Tue, 30 May 2017 05:30:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Tue, 30 May 2017 05:29:28 -0700 (PDT) In-Reply-To: <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> From: Eric Rescorla Date: Tue, 30 May 2017 05:29:28 -0700 Message-ID: To: Brian E Carpenter Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Content-Type: multipart/alternative; boundary="001a11490b9ad2e8670550bcf648" Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 12:30:15 -0000 --001a11490b9ad2e8670550bcf648 Content-Type: text/plain; charset="UTF-8" On Mon, May 29, 2017 at 10:14 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Eric, > > On 25/05/2017 14:32, Eric Rescorla wrote: > ... > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > ISSUE 1 > > The security situation here is pretty unspecified here, in at least two > > respects: > > > > 1. In terms of communication security, you seem to have two modes: > > > > (a) Punt it to ACP > > (b) Use TLS as specified in S 3.5.2.1 > > > > I'm not reviewing ACP here (though I have some comments on that too) > > Yes, that certainly needs a thorough security review ASAP. > > > but S 3.5.2.1 doesn't (for) instance explain how to do certificate > > validation, > > Indeed not. But... > > > which it clearly needs to do. > > We intentionally want to leave this for further study. Surely that > is allowed? The text seems very clear on that. Personally, I'm not competent to design that, and this draft is already plenty long enough. > So what can we write if we can't write "Further details are out of scope > for this document."? > It's the job of this group of specifications to provide a complete security story, so it must either be here or it must be in some other document which is normatively referenced from here and which therefore one can read to determine if this document achieves the appropriate security objectives. Just generally pointing in the direction of TLS is not sufficient. You could, of course, say that TLS is not to be used at all and you rely entirely on ACP, but the current text doesn't do that either. > Finally, I don't > > understand the security story for the multicast packets. > > I think I already typed this a day or two ago, but with an ACP, > they are secured, because the ACP is a secure virtual overlay > network. > This document then needs to state which precise properties of ACP it is relying on for that. A brief skim of ACP suggests that it relies on other protocols for its actual transport security and at least some of those protocols (e.g., DTLS) do not support multicast. With no ACP they are of course wide open, unless some new > magic has been invented that I'm not aware of. Hence the > restrictions in 3.5.2.2. "Discovery Unsolicited Link-Local" > As above, you need to specify which properties you are relying on, and how you bridge multicast to unicast. > This is especially relevant for Rapid mode, where you are > > attaching real work to these multicast packets. > > Correct. I think we need to forbid that in the no-ACP case. > > > 2. I didn't find the security model very clear. As I understand > > things, basically anyone on the network who has ACP credentials > > is trusted to engage in negotiation with you, so, for instance, > > if you want to get parameter X, then you basically just trust > > whoever on the network offers you X. is that correct? That seems > > like it needs to be very explicitly called out. And if that's not > > true, then I don't understand the spec. > > That is the trust model, but really as an explanatory matter I think > it belongs in draft-ietf-anima-reference-model rather than here. > I will add a few words in the High Level Deployment Model > section and/or the Security Considerations. > > What we do say already is that authorization of ASAs is out of scope. > I am certain that it needs to be tackled, but not here. > I don't see how you have a complete protocol without that. > > > ISSUE 3. > > I don't think I understand how the transition from UDP multicast > > to TCP/TLS unicast works. Maybe I'm just misreading the spec, > > so could you point me to the section that describes this. > > This only arises for discovery; the discovery result explicitly includes > the address/protocol/port for the actual operation. > > For discovery it's in > https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.4 > > The listening port used for TCP MUST be the same port as used for > sending the > Discovery UDP multicast, on a given interface. In a low-end implementation > this MAY > be GRASP_LISTEN_PORT. In a more complex implementation, the GRASP > discovery mechanism > will find, for each interface, a dynamic port that it can bind to for both > UDP and TCP > before initiating any discovery. > > Python code on request ;-) > Thanks. > Finally, I don't see a spec for how you map CBOR onto the wire. Do you > > just shove them on? Something else? > > Yep, CBOR is just a string of bytes. That's CBOR 101 so I don't > think we need to say anything more. > I don't agree. JSON is just a string of bytes and yet ACME, for instance, contains a rather extensive protocol mapping to HTTP. So, you need to at least state that you just shove them on the wire. > > > > I see that Martin Thomson raised a number of these issues in his review > > in more detail. > > > Martin Stiemerling I think. > Martin Stiemerling may or may not have reviewed this document, but I'm talking about Martin Thomson's review, which can be found at: -Ekr --001a11490b9ad2e8670550bcf648 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 29, 2017 at 10:14 PM, Brian E Carpenter &= lt;brian.e= .carpenter@gmail.com> wrote:
> ------------------------------------------------= ----------------------
> DISCUSS:
> ------------------------------------------------------------= ----------
>
> ISSUE 1
> The security situation here is pretty unspecified here, in at least tw= o
> respects:
>
> 1. In terms of communication security, you seem to have two modes:
>
>=C2=A0 =C2=A0 (a) Punt it to ACP
>=C2=A0 =C2=A0 (b) Use TLS as specified in S 3.5.2.1
>
> I'm not reviewing ACP here (though I have some comments on that to= o)

Yes, that certainly needs a thorough security review ASAP.

> but S 3.5.2.1 doesn't (for) instance explain how to do certificate=
> validation,

Indeed not. But...

> which it clearly needs to do.

We intentionally want to leave this for further study. Surely that is allowed? The text seems very clear on that. Personally, I'm not
competent to design that, and this draft is already plenty long enough.
So what can we write if we can't write "Further details are out of= scope
for this document."?

It's the = job of this group of specifications to provide a complete
securit= y story, so it must either be here or it must be in some other
do= cument which is normatively referenced from here and which
theref= ore one can read to determine if this document achieves the
appro= priate security objectives. Just generally pointing in the direction
<= div>of TLS is not sufficient. You could, of course, say that TLS is not to<= /div>
be used at all and you rely entirely on ACP, but the current text=
doesn't do that either.


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> > Finally, I don't
> understand the security story for the multicast packets.

I think I already typed this a day or two ago, but with an ACP,
they are secured, because the ACP is a secure virtual overlay
network.

This document then needs to st= ate which precise properties of
ACP it is relying on for that. A = brief skim of ACP suggests that
it relies on other protocols for = its actual transport security and
at least some of those protocol= s (e.g., DTLS) do not support
multicast.


With no ACP they are of course wide open, unless some new
magic has been invented that I'm not aware of. Hence the
restrictions in 3.5.2.2. "Discovery Unsolicited Link-Local"

As above, you need to specify which properti= es you are relying
on, and how you bridge multicast to unicast.


> This is especially relevant for Rapid mode, where you are
> attaching real work to these multicast packets.

Correct. I think we need to forbid that in the no-ACP case.

> 2. I didn't find the security model very clear. As I understand > things, basically anyone on the network who has ACP credentials
> is trusted to engage in negotiation with you, so, for instance,
> if you want to get parameter X, then you basically just trust
> whoever on the network offers you X. is that correct? That seems
> like it needs to be very explicitly called out. And if that's not<= br> > true, then I don't understand the spec.

That is the trust model, but really as an explanatory matter I think=
it belongs in draft-ietf-anima-reference-model rather than here.
I will add a few words in the High Level Deployment Model
section and/or the Security Considerations.

What we do say already is that authorization of ASAs is out of scope.
I am certain that it needs to be tackled, but not here.

I don't see how you have a complete protocol without t= hat.

=C2=A0
> ISSUE 3= .
> I don't think I understand how the transition from UDP multicast > to TCP/TLS unicast works. Maybe I'm just misreading the spec,
> so could you point me to the section that describes this.

This only arises for discovery; the discovery result explicitly incl= udes
the address/protocol/port for the actual operation.

For discovery it's in
https://tools.ietf.org/html/= draft-ietf-anima-grasp-11#section-3.8.4

<t>The listening port used for TCP MUST be the same port as used for = sending the
Discovery UDP multicast, on a given interface. In a low-end implementation = this MAY
be GRASP_LISTEN_PORT. In a more complex implementation, the GRASP discovery= mechanism
will find, for each interface, a dynamic port that it can bind to for both = UDP and TCP
before initiating any discovery.</t>

Python code on request ;-)

Thanks.



> Finally, I don't see a spec for how you map CBOR onto the wire. Do= you
> just shove them on? Something else?

Yep, CBOR is just a string of bytes. That's CBOR 101 so I don= 9;t
think we need to say anything more.

I d= on't agree. JSON is just a string of bytes and yet ACME, for instance, = contains
a rather extensive protocol mapping to HTTP. So, you nee= d to at least state that
you just shove them on the wire.=C2=A0


>
> I see that Martin Thomson raised a number of these issues in his revie= w
> in more detail.
>
Martin Stiemerling I think.

Mart= in Stiemerling may or may not have reviewed this document, but I'm talk= ing
about Martin Thomson's review, which can be found at:

-Ekr


--001a11490b9ad2e8670550bcf648-- From nobody Tue May 30 05:50:02 2017 Return-Path: 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 92ADB12953B for ; Tue, 30 May 2017 05:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 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 Yw7SzoiJ8rF7 for ; Tue, 30 May 2017 05:50:00 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCE6129407 for ; Tue, 30 May 2017 05:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3564; q=dns/txt; s=iport; t=1496148599; x=1497358199; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=mgLOQxt2ArumZkjr2sE09guAf49XyqGZVNcKebE9Ej8=; b=L3NVaq51fyBwa4N5dDnh6mjZaloYo/9b8pOF4GiE+Gds1FEm5GQbTabX mDELl1gQtM1ahik5sB4pfegWnJ38GhBwnqHQEQHKKxXGkj9eNPCMsT7CS 4Bx8XAaLaJiO4Mz15+QncgE0tZFujw59xISHMRzKEtr30sPcH2yyh7nFe s=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BnAQAxaS1Z/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDeEf4oYc5BUIZBBhTiCDwclhXgCgwwYAQIBAQEBAQEBayhCEIR?= =?us-ascii?q?HAQUjZgsEAQkKKgICVwYBDAgBAYomEAKtEoImK4scAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBDgoFiGwLgmmHe4JgAQSeI4QNghh7jAiLC4ZslE4fOIEKMCEIGxWFfoF?= =?us-ascii?q?MPoFciC0BAQE?= X-IronPort-AV: E=Sophos;i="5.38,418,1491264000"; d="asc'?scan'208,217";a="655021710" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 May 2017 12:49:55 +0000 Received: from [10.61.248.221] ([10.61.248.221]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v4UCntw2008990; Tue, 30 May 2017 12:49:55 GMT To: Eric Rescorla , Anima WG References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> From: Eliot Lear Message-ID: <9fb43c49-3298-7cd7-2cd4-f7db3ab18909@cisco.com> Date: Tue, 30 May 2017 14:49:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TxX4beh0H1Sd3S6juDmmvHg5sd3VpehKC" Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 12:50:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TxX4beh0H1Sd3S6juDmmvHg5sd3VpehKC Content-Type: multipart/mixed; boundary="aLobB12Dc54hWhwSMO8ApdlQtcRPaUw4h"; protected-headers="v1" From: Eliot Lear To: Eric Rescorla , Anima WG Message-ID: <9fb43c49-3298-7cd7-2cd4-f7db3ab18909@cisco.com> Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> In-Reply-To: --aLobB12Dc54hWhwSMO8ApdlQtcRPaUw4h Content-Type: multipart/alternative; boundary="------------D153076902D1D37841F93AB1" Content-Language: en-US This is a multi-part message in MIME format. --------------D153076902D1D37841F93AB1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/30/17 2:29 PM, Eric Rescorla wrote: > > Martin Stiemerling may or may not have reviewed this document, but I'm > talking > about Martin Thomson's review, which can be found at: > > -Ekr > At.....=20 https://mailarchive.ietf.org/arch/msg/art/tFoac4dniuFvXTk3xXtsGkCtUag ? --------------D153076902D1D37841F93AB1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



On 5/30/17 2:29 PM, Eric Rescorla wrote:

Martin Stiemerling may or may not have reviewed this document, but I'm talking
about Martin Thomson's review, which can be found at:

-Ekr


At.....=C2=A0 https://mailarchive.ietf.org= /arch/msg/art/tFoac4dniuFvXTk3xXtsGkCtUag

?

--------------D153076902D1D37841F93AB1-- --aLobB12Dc54hWhwSMO8ApdlQtcRPaUw4h-- --TxX4beh0H1Sd3S6juDmmvHg5sd3VpehKC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZLWpyAAoJEIe2a0bZ0nozJC8IANCdIJ7CY7dPp5vj+kyYB9/e uitAWH5v82rZfQC9TAwoWpzDv3hq71ZeejN9GHfo/F55nfWq/wCmmjtIcchJO5Vo nNs/Enu1kGA6EnvcLXsqyIzLJw0MIr+U6xrsR1JGeFzXB6ranwOMRMLVWp2lYx0P NgtXgWgKW6JSQcUY3aq+Mj+//gjRJiAlL51AgRrRAIDRL3uRfeWoyVHS2J0HJQUH BiO7lXPrJ2slIiAergt3C7SHSu989KktWt53D4STwE1Vvp1vZxbMwBx8mt98sfu1 +AGuJY1Qa9nhFF/AfgwauaaClV5iQDbn9hR9X+MDJBBxkcefQv+Cs4DNmXZSAoA= =LFrS -----END PGP SIGNATURE----- --TxX4beh0H1Sd3S6juDmmvHg5sd3VpehKC-- From nobody Tue May 30 05:53:38 2017 Return-Path: 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 C3488129C1E for ; Tue, 30 May 2017 05:53:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 XVz47ZL76B6s for ; Tue, 30 May 2017 05:53:36 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 419C6129407 for ; Tue, 30 May 2017 05:53:36 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id 202so4862322ybd.0 for ; Tue, 30 May 2017 05:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p9Pvew03uqR6ZpyArJZI3GH866JygULY41IABREvVPY=; b=lgr1RQVfWJWEwXRxCxql2bUj40ztvSv0KH3IHGCswlS4sZ3dJe0ZcMBcWfSOuX27vF gNG7dZVQJjk8NhgJYwfj8cy4dmG9SN3ZKEOXQI+hslyhsW4/jWz+hRqeLAm3zXP85u8g 8mW1Fxst/1FiCZeI/7xTwX3ydyrj+Q8S80n9ZF11Ak0bgGJRG85eZmHKObjZMGTfta3W 2iCS2vK05JScRO2Iaenx/3OU1fwRJ/lBvRfo2jikTAa9m5CvXzzYgkp8cJV3OHn/S+jq ir5U70lcv2M+uKxof8LBH0p+lEk7iYndaaEDKe6AnmS2pxMzIHatp6Q5rH4XcmznKDd0 2POQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p9Pvew03uqR6ZpyArJZI3GH866JygULY41IABREvVPY=; b=WhA5X6idfR3zzC8Py8mG80AkeTrxpTPRzHtgyA2Lrct6NoIxsm1EojIUYmaInn5N2b kgqA4XIZig/vO/DIa7Ljzt5dVumJXONeqtA0prYWOwsae/nae18UHEPtY5aE9rpq6XxX vDLvfjgWL2DSR3dGLi50xyBW/QlIeOOhjqHd0hZ8xLsi4gQymusOB2uF15ZmHELGWxd1 8f1drOVnVhUNjlMseQIOndXDRpYxpvR4R6pyIrOXGpIui9KOhXL/lAEdUpdUAYXgDVzi 4zy3obquTbyy62DC7V6j3ZSJj8jKP1A8D3kjIyBgJyrC3x1IffpYvAM7t7hU9g1FJtAw JXCw== X-Gm-Message-State: AODbwcC2dVAeOuJdD3WdA2lpu4WUf66YBzvzrO7qj5FBT7ywv1J6joNK kzQbKi784LwJsGDwGri9oxuFay0Kz3Sl X-Received: by 10.37.55.207 with SMTP id e198mr15643027yba.24.1496148815566; Tue, 30 May 2017 05:53:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Tue, 30 May 2017 05:52:55 -0700 (PDT) In-Reply-To: <9fb43c49-3298-7cd7-2cd4-f7db3ab18909@cisco.com> References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> <9fb43c49-3298-7cd7-2cd4-f7db3ab18909@cisco.com> From: Eric Rescorla Date: Tue, 30 May 2017 05:52:55 -0700 Message-ID: To: Eliot Lear Cc: Anima WG Content-Type: multipart/alternative; boundary="001a11473996aef0300550bd4a22" Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 12:53:38 -0000 --001a11473996aef0300550bd4a22 Content-Type: text/plain; charset="UTF-8" Yes. Thanks. -Ekr On Tue, May 30, 2017 at 5:49 AM, Eliot Lear wrote: > > > On 5/30/17 2:29 PM, Eric Rescorla wrote: > > > Martin Stiemerling may or may not have reviewed this document, but I'm > talking > about Martin Thomson's review, which can be found at: > > -Ekr > > > At..... https://mailarchive.ietf.org/arch/msg/art/tFoac4dniuFvXTk3xX > tsGkCtUag > > ? > > --001a11473996aef0300550bd4a22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes. Thanks.

-Ekr
=

On Tue,= May 30, 2017 at 5:49 AM, Eliot Lear <lear@cisco.com> wrote:
=20 =20 =20



On 5/30/17 2:29 PM, Eric Rescorla wrote:
=20

Martin Stiemerling may or may not have reviewed this document, but I'm talking
about Martin Thomson's review, which can be found at:<= /div>

-Ekr


 At.....=C2=A0 https://mailarchive.ietf.org/arch/msg/art= /tFoac4dniuFvXTk3xXtsGkCtUag

?


--001a11473996aef0300550bd4a22-- From nobody Tue May 30 09:37:13 2017 Return-Path: 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 24821129AAD for ; Tue, 30 May 2017 09:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 0SRMVQ6jmHmz for ; Tue, 30 May 2017 09:37:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0B7129A97 for ; Tue, 30 May 2017 09:37:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DDD582009E; Tue, 30 May 2017 12:37:29 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0816E636BB; Tue, 30 May 2017 12:37:09 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-Reply-To: <21a266aa-5650-d6bd-5a2d-a02bfc60eedc@gmail.com> References: <05b21e01-d856-ded5-87ec-da9d0f983310@gmail.com> <26917.1496083744@obiwan.sandelman.ca> <21a266aa-5650-d6bd-5a2d-a02bfc60eedc@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Tue, 30 May 2017 12:37:08 -0400 Message-ID: <30412.1496162228@obiwan.sandelman.ca> Archived-At: Subject: Re: [Anima] Need WG input: Alexy Melnikov's suggestion on GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 16:37:12 -0000 Brian E Carpenter wrote: >> Brian E Carpenter wrote: > I have >> started the process of going through IESG comments on the GRASP > >> draft. Where something is editorial or obviously non-controversial, I >> > will not ask for input. But I do need input on some things, and here >> is > the first. Please answer quickly; no answer will be taken to >> mean that > you don't care... >> >> > Alexy wrote: >>> uri-locator = [O_URI_LOCATOR, text] >> >>> >> >>> I suggest inclusion of optional transport protocol here to match >> >>> other locators and to follow best practices for not encoding >>> >> transport information in URIs. >> >> > That would become uri-locator = [O_URI_LOCATOR, text, >> transport-proto, > port-number] >> >> > Opinions? Objections? >> >> If the resource is really at https://example.com:9943/my/path >> >> what would text, transport-proto be? > "https://example.com:9943/my/path", Null, Null perhaps. > Also of course see the thread on Adam Roach's comment. okay, then give me an example where it wouldn't be null and null? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Tue May 30 10:02:36 2017 Return-Path: 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 E63C6129AC6; Tue, 30 May 2017 10:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 J3nutnnzoKzA; Tue, 30 May 2017 10:02:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BBE412778E; Tue, 30 May 2017 10:02:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 858A62009E; Tue, 30 May 2017 13:02:52 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8FB4B636BB; Tue, 30 May 2017 13:02:31 -0400 (EDT) From: Michael Richardson To: Eric Rescorla cc: Brian E Carpenter , anima-chairs@ietf.org, anima@ietf.org, The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang In-Reply-To: References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 17:02:34 -0000 --=-=-= Content-Type: text/plain Eric Rescorla wrote: > It's the job of this group of specifications to provide a complete > security story, so it must either be here or it must be in some other > document which is normatively referenced from here and which therefore > one can read to determine if this document achieves the appropriate > security objectives. Just generally pointing in the direction of TLS is > not sufficient. You could, of course, say that TLS is not to be used at > all and you rely entirely on ACP, but the current text doesn't do that > either. The use case for TLS is inter-domain (while the ACP is intra-domain). I.e. between two ISPs. Such a GRASP instance would be isolated from other ANIMA GRASP instances, would perhaps not be hop-by-hop. Or might be. As that use case is not well understood at all, and I think can (and SHOULD) be addressed later on, I have argued for simply not mentioning it because we don't have a story about certificates or identities or validation, etc. (I suspect that many initial uses will use pinned self-signed certificates, manually configured). Brian has argued to continue to include the reference so that we remember that use over a secured ACP is not the only use, and that we shouldn't write some complex interaction that involves many UDP/TCP port combinations that would be hard to support over TLS. Use of GRASP at an Internet Exchange (IX) might be different again, perhaps using COSE to sign GRASP multicast messages. Can anyone suggest a way to keep TLS in mind while not actually saying we know how to use it? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlktpacACgkQgItw+93Q 3WVuqwf/UYx6N3lNEiSMyCHwfUEi1QSVSu3sPV78wLmfyaZOnaTMY+888hP0tc9q 5FTK/IAPAVUkALzL5jQr+f8o1Mip61NMQWCPYP+qzCxuNrqZrRjhLnXlRfMXS1kc iY5CK9RnESVqBBIDL241+ED93Jftfha4AoFesNwpQrutAh6+8tRMRmdOVJIkZI3P LmqUHUHcWd208fkFodiVTbzbIX4liWYRdyOhxbYUD/sUz4ynC9UDvfMitIUlhH1r y6I2z8BUPgL7Snq5C3ILNEGLk46M8gbd41XOh/ecXxac+5V/JnAFodgUvWE1nrKM JpleaSZX+U1Tv9Zo+q79vkcqqBYj0A== =iNQY -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 30 10:11:43 2017 Return-Path: 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 59190129ADE for ; Tue, 30 May 2017 10:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 zNZEDZta2Czr for ; Tue, 30 May 2017 10:11:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACF6129AD3 for ; Tue, 30 May 2017 10:11:40 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CE0E82009E; Tue, 30 May 2017 13:12:00 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D617E636BB; Tue, 30 May 2017 13:11:39 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter CC: anima@ietf.org In-Reply-To: <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] transitive trust in GRASP ASA negotiations X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 17:11:42 -0000 --=-=-= Content-Type: text/plain ekr> 2. I didn't find the security model very clear. As I understand ekr> things, basically anyone on the network who has ACP credentials is ekr> trusted to engage in negotiation with you, so, for instance, if you ekr> want to get parameter X, then you basically just trust whoever on the ekr> network offers you X. is that correct? That seems like it needs to be ekr> very explicitly called out. And if that's not true, then I don't ekr> understand the spec. bc> That is the trust model, but really as an explanatory matter I think it bc> belongs in draft-ietf-anima-reference-model rather than here. I will bc> add a few words in the High Level Deployment Model section and/or the bc> Security Considerations. I am increasingly uncomfortable with leaving things like this. There are a number of things that we could do as GRASP extensions: 1a) M_SIGNED: could be container that encapsulates a GRASP message into a COSESign1 structure to indicate who sent the message. 1b) M_MULTISIGNED: a be a container with a COSESign structure in which every passing node signs as it goes through. 2) transport end to end, run it over TLS or something. Might be implied or might require a M_STARTTLS message. 3) hop-by-hop, with some kind of M_TUNNEL message, or using COSE Encrypt messages with relaying on the outside. I think that all of these things could be ASA specific, but I think that ASA should not have to re-invent the wheel here, but can use the GRASP "kernel" (aka "libgrasp") to do the right thing. My request for the Chairs to put this on the "re-chartering" list for later on, but to discuss with ADs now so that some of the GRASP or framework work could say something aobut "future work". -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlktp8sACgkQgItw+93Q 3WW+5QgAuQw/yFSTgRt89kgy3MtJXwxbTYwxXjQuAOaei7iWqmtacHD3gx2/jKV4 nKrVhnd2Eo9g9Y7IaJqUETOx1qkLsDGsiiLbSz4dtybfmnTW4QvfycHqux0I7Zp3 xHw+0nk9tsyD4SkI4Dn51NviAy5Grh+caZUAw03cg9LxRJCyN309ZBtiiGMp6gLZ YHYrChN8ziUKFYoCdROQT4xwdwqOoOlmnOLEC6EZebAEZFV9BKYJ/5WMylPgGJTF 7d0JD8YZtx2sle74/yNF70YvMxpyp2LF2heZ1H7DzChq/ek1nfWcaBgUqhhOx+Kn MdMKycbrLlLfkz5ySO2TBHwPEyaSxg== =u4c9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 30 13:30:12 2017 Return-Path: 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 63E21128D19 for ; Tue, 30 May 2017 13:30:10 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAHih82NgLna for ; Tue, 30 May 2017 13:30:09 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 F11C9126CD8 for ; Tue, 30 May 2017 13:30:08 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id m17so82074184pfg.3 for ; Tue, 30 May 2017 13:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2ogn3ne32kaMH89T3/QTpXfCQKXeDVSx7NA5SI057uQ=; b=j1ORlG8Cfiz//z8rvwhRLEgk6QNV9p+9jjJJsm+YINjCPjdA2o8sMs+RyhdQKePFFr dNYqKHqPDVN3U6iEqpgwV8/7PfxE5P3V5ZZLzh+l5JA+hZYNNdca14gDU8VPV+sD1XXL 3G4/epCfPPxVoWWoEHhSnRpFUgbINij0tKKaIVZ4mF4oMPbVb2iO5wkNEZ+ifa39fKaY CIy7HRVmPJi4CxT4pud/KZrXMWF9lS/OmmVZVvPo5L+YLxt2jJ23ZLobCIu/r3EsAlcW fDlbcptAstaR4joXVAf9un8KZkQYyIQcwYoILE6eIrwflmfQGmf/XckbDGxU5pQkywP4 bqhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=2ogn3ne32kaMH89T3/QTpXfCQKXeDVSx7NA5SI057uQ=; b=Pr4tfiSE/kY11z51Whqu+H5aE7N8t48afddi+M1eUHlS2uEBvB87/7f2M1wyd8Q5Pz s42voyyhTgs24Mv8a3SgkQF0vPbls9mhMl2q8KTyx6wH98jtOvzNqOklZz+Vhc9arG+Q AqJGAHrVye80jVmAljM8Hm6wEi84AxoeOSxYQA+mXhNkLx3qLsabvK64aTg0j3vZ4Pkm D/kwlxkcyC+A7m1nyE+ExAN8jxTw7U1y3SSQYQ+84qyqBuwafH/g71czcWol9Segnju2 OwuH9cNFucmCoFuuuEdudeHGtI2dnlvg5E+aHpWg0pdy13tK6dRWTt0/GSdreAG7Nh5g iSvA== X-Gm-Message-State: AODbwcBGs4fn/xgJO46cXVeR2e6T/J25qjO8+JpTsEaa2AHEy28r+Afk b6E+1/0x/UjATL8GKOg= X-Received: by 10.98.160.74 with SMTP id r71mr25656985pfe.16.1496176207465; Tue, 30 May 2017 13:30:07 -0700 (PDT) Received: from ?IPv6:2406:e007:40ba:1:28cc:dc4c:9703:6781? ([2406:e007:40ba:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d6sm23036491pfk.90.2017.05.30.13.30.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 13:30:06 -0700 (PDT) To: Eric Rescorla , Eliot Lear Cc: Anima WG References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> <9fb43c49-3298-7cd7-2cd4-f7db3ab18909@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <365d26f1-d8ec-4f01-9df3-786fbc8d7fed@gmail.com> Date: Wed, 31 May 2017 08:30:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 20:30:10 -0000 Right. I believe that the -12 draft already covers most of Martin Thomson's points, other than what we are still discussing with Eric. Martin Stiemerling's points need to fixed in the future -13 draft. Regards Brian On 31/05/2017 00:52, Eric Rescorla wrote: > Yes. Thanks. > > -Ekr > > > On Tue, May 30, 2017 at 5:49 AM, Eliot Lear wrote: > >> >> >> On 5/30/17 2:29 PM, Eric Rescorla wrote: >> >> >> Martin Stiemerling may or may not have reviewed this document, but I'm >> talking >> about Martin Thomson's review, which can be found at: >> >> -Ekr >> >> >> At..... https://mailarchive.ietf.org/arch/msg/art/tFoac4dniuFvXTk3xX >> tsGkCtUag >> >> ? >> >> > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue May 30 13:33:22 2017 Return-Path: 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 52BF2128D19 for ; Tue, 30 May 2017 13:33:20 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 IHuH77uJHayr for ; Tue, 30 May 2017 13:33:18 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 90B6E126CD8 for ; Tue, 30 May 2017 13:33:18 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id r66so16862033yba.2 for ; Tue, 30 May 2017 13:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b+rMe4H4rQc24p2PF6i3kDv3VYCj1bxtbLahjgGxiio=; b=zPSP/KXl+GUVZ2/eEdRlFnWYGMuyd/UNHggeC+t62wX2pWH1Df4hN7LoXNM5GzSizs 4dcYfULrb64D5E6Zut3QxpQUNAPI/SZVweoUH3yK87IDMBU/TalPUAQ4psN/dat0fHja 8bnyTgx39/VDc1SU/8RK3pVzAMGQfsrhPspXsiY+mXfwDLPW/4/QXYCrukb8wyzjEAMo m8ejuLa9LYvpl+WfvN+6m6mGLW/kb7FHGg90YjZrOVvgB7K3dZmp0ewb3rJJFkT8VrId AKCAC7J14iAJM+5rsNKwmft8jdVBFWyahnH4Zs3kDslKzBTYepg2Yo75lFyQnt0X/k4r smUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b+rMe4H4rQc24p2PF6i3kDv3VYCj1bxtbLahjgGxiio=; b=l2EBpt5mU6WVY481NC/PRH2yH24i1uNn+OBaZ6PcCEOvguyM6jyNdwiyFKV7R3FrM0 JlVXgsBuLw+8zjTlKtm5aOKyoTbUmlHeB8JxwfDtoPlmC4Z8hewNeNVTiXpx+216+gVG lfKZVXsU/EE5faf3MEWn75ABdzB9gLp4mCSOvIpVsGAELs4+e8pREzZ2G5iUgTfSQ0Xq X06yF433pDStIMtDJVeqGzbo2S58IDJqRlPOe8kSJuED5ksVgGrtomjoJLxwvv4RPwOB 3zkHNZUFnwslyljJqM2/MExm1K/n5lUriU9hbQ9lJ6YdI9HzmFGPrKAv8WqpXw/4dzjE t9Xw== X-Gm-Message-State: AODbwcAm3VCiOmTpO9JDSHAURzO0350DI7AVy6pAXLu3UQito7GMGqEB 7T4oOEwV1iV4rndmup6O8Fmv1ANFGhIc X-Received: by 10.37.99.213 with SMTP id x204mr3485381ybb.50.1496176397781; Tue, 30 May 2017 13:33:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Tue, 30 May 2017 13:32:37 -0700 (PDT) In-Reply-To: <365d26f1-d8ec-4f01-9df3-786fbc8d7fed@gmail.com> References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> <9fb43c49-3298-7cd7-2cd4-f7db3ab18909@cisco.com> <365d26f1-d8ec-4f01-9df3-786fbc8d7fed@gmail.com> From: Eric Rescorla Date: Tue, 30 May 2017 13:32:37 -0700 Message-ID: To: Brian E Carpenter Cc: Eliot Lear , Anima WG Content-Type: multipart/alternative; boundary="001a11c15566b6500b0550c3b6db" Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 20:33:20 -0000 --001a11c15566b6500b0550c3b6db Content-Type: text/plain; charset="UTF-8" Yes, I incorporated MT's remaining points into my review. I just wanted to give him credit. -Ekr On Tue, May 30, 2017 at 1:30 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Right. I believe that the -12 draft already covers most of Martin Thomson's > points, other than what we are still discussing with Eric. Martin > Stiemerling's > points need to fixed in the future -13 draft. > > Regards > Brian > > On 31/05/2017 00:52, Eric Rescorla wrote: > > Yes. Thanks. > > > > -Ekr > > > > > > On Tue, May 30, 2017 at 5:49 AM, Eliot Lear wrote: > > > >> > >> > >> On 5/30/17 2:29 PM, Eric Rescorla wrote: > >> > >> > >> Martin Stiemerling may or may not have reviewed this document, but I'm > >> talking > >> about Martin Thomson's review, which can be found at: > >> > >> -Ekr > >> > >> > >> At..... https://mailarchive.ietf.org/arch/msg/art/tFoac4dniuFvXTk3xX > >> tsGkCtUag > >> > >> ? > >> > >> > > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > --001a11c15566b6500b0550c3b6db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I incorporated MT's remaining points into my revi= ew. I just wanted to give
him credit.

-Ekr
=


On Tue, May 30, 2017 at 1:30 PM, Brian E Carpenter <br= ian.e.carpenter@gmail.com> wrote:
Right. I believe that the -12 draft already covers most of Martin Th= omson's
points, other than what we are still discussing with Eric. Martin Stiemerli= ng's
points need to fixed in the future -13 draft.

Regards
=C2=A0 =C2=A0Brian

On 31/05/2017 00:52, Eric Rescorla wrote:
> Yes. Thanks.
>
> -Ekr
>
>
> On Tue, May 30, 2017 at 5:49 AM, Eliot Lear <lear@cisco.com> wrote:
>
>>
>>
>> On 5/30/17 2:29 PM, Eric Rescorla wrote:
>>
>>
>> Martin Stiemerling may or may not have reviewed this document, but= I'm
>> talking
>> about Martin Thomson's review, which can be found at:
>>
>> -Ekr
>>
>>
>> At.....=C2=A0 https://mailarchi= ve.ietf.org/arch/msg/art/tFoac4dniuFvXTk3xX
>> tsGkCtUag
>>
>> ?
>>
>>
>
>
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima=
>

--001a11c15566b6500b0550c3b6db-- From nobody Tue May 30 13:38:03 2017 Return-Path: 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 6AA301293E8; Tue, 30 May 2017 13:38:01 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpQaNxeUnI07; Tue, 30 May 2017 13:38:00 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 2346C126CD8; Tue, 30 May 2017 13:38:00 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id m17so82234505pfg.3; Tue, 30 May 2017 13:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Zfs4J1YFFJevDzOALAyGPRe4wMZS/d8TGanL5OAzCYc=; b=fJOxvZf2W7UP2x4JXyFgtmyUVQinr9oioxrSumA+QwhgaPx/tM5PGbI/M+XrjcKMoO cxCSNlzTzhVH8LHzs1zOGr8Df8/uFpR64Hw8F77K6m2P/HaSbtaRYSkcCYc+RONQOyZc +oPUnWIA2W4q7lRCvnRBMxzl6fqKc3EqD9YYOPgSq74EzBMJPU1xEBGASa9r/7D+QfnS Yx5o/+O+3LdvQ3CFHG2YIxYZ+PgdoZp/QGUvHRX9944sYOiqlDQhCxzQxFjGo9rUeSWc OFPMTuoR0BbCI/AF+5Z5Fl1n8GXgsWl27CCsWQRWbBsR3FTOTWRoNUaXt4klTkRW74Oz KnEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Zfs4J1YFFJevDzOALAyGPRe4wMZS/d8TGanL5OAzCYc=; b=iocvuGSxHiR8ULtj46Yuh8wvzyQn+YOJd4Zi9W1yDy9aeWokLlG4eMAY4VOvM1vF+S Bo9c0KBp0ecR6ycO7xIDwapjrGDTU54niIF76KZT3fr+C49msTX+4zwyvLeFl+FbglfE WluIOcNxLcNYEo+XjzWo+aHTUJq/VXmtWjNhVGvQp4Y+pUnmdaCBxNGR43T69F2Hs8uB M6HtPrs2KQbphIP1wBA37F/mncN4mS/p8cy7oD6OUzRSevJ38AW1YxGkim2yyeKhppgu I2CtgOTvzl0H+iqv5i2nK0FekGLtkjFt0jAfg/D8osLdBB5jZIS/ZJ3WNma4t8pFRmq6 kO8A== X-Gm-Message-State: AODbwcDax/0NtyKxnCWF3Yri806wRQ+h0lzBvWJzHEtzADQl5d3EJKAc SKchMPTNdavDug== X-Received: by 10.98.70.17 with SMTP id t17mr26212898pfa.229.1496176679680; Tue, 30 May 2017 13:37:59 -0700 (PDT) Received: from ?IPv6:2406:e007:40ba:1:28cc:dc4c:9703:6781? ([2406:e007:40ba:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b24sm29563179pfm.17.2017.05.30.13.37.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 13:37:59 -0700 (PDT) To: Michael Richardson , Eric Rescorla Cc: anima-chairs@ietf.org, anima@ietf.org, The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> <3636.1496163751@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <69ab8d4a-8ed2-6b34-9dc9-356f67788d48@gmail.com> Date: Wed, 31 May 2017 08:37:57 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <3636.1496163751@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 20:38:01 -0000 On 31/05/2017 05:02, Michael Richardson wrote: > > Eric Rescorla wrote: > > It's the job of this group of specifications to provide a complete > > security story, so it must either be here or it must be in some other > > document which is normatively referenced from here and which therefore > > one can read to determine if this document achieves the appropriate > > security objectives. Just generally pointing in the direction of TLS is > > not sufficient. You could, of course, say that TLS is not to be used at > > all and you rely entirely on ACP, but the current text doesn't do that > > either. > > The use case for TLS is inter-domain (while the ACP is intra-domain). > I.e. between two ISPs. Such a GRASP instance would be isolated from other > ANIMA GRASP instances, would perhaps not be hop-by-hop. Or might be. > > As that use case is not well understood at all, and I think can (and SHOULD) > be addressed later on, I have argued for simply not mentioning it because we > don't have a story about certificates or identities or validation, etc. (I > suspect that many initial uses will use pinned self-signed certificates, > manually configured). > > Brian has argued to continue to include the reference so that we remember > that use over a secured ACP is not the only use, and that we shouldn't write > some complex interaction that involves many UDP/TCP port combinations that > would be hard to support over TLS. > > Use of GRASP at an Internet Exchange (IX) might be different again, perhaps > using COSE to sign GRASP multicast messages. > > Can anyone suggest a way to keep TLS in mind while not actually saying we know > how to use it? That's the crux of it. We intentionally did not want to bind GRASP irrevocably to the ACP, so that it can be used, for example, to implement dynamic resource management between two ISPs that have a specific trust model between themselves. But clearly that's future work. How can we express that? Brian From nobody Tue May 30 13:41:07 2017 Return-Path: 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 DE35C12943D for ; Tue, 30 May 2017 13:41:06 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGft_we_7fc8 for ; Tue, 30 May 2017 13:41:05 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 B61D7126CD8 for ; Tue, 30 May 2017 13:41:05 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id n23so82378667pfb.2 for ; Tue, 30 May 2017 13:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=STOSuS6ehcb2aG3V1A6fF3BAMGPsrsIZ5kHjJIFFci8=; b=mZ+lQq/GRlUFZHHcGox1e08IMeGOjFZsWHYpiZkeOvP2mFMD3Trte0SdH4sDHRwxwp COVuDgH0LEMahAIZ2+sO0o5ZKeY8PXMQML9yuNVMFmtgLsxHP8NOjMl+fFc+fQQPapzW /DZ/F9nFDZ6rOm4ymadrMLKXcuPtQZaEnKuIinVecDCK5DaSWWtsba8tK7ew8sTBEUfq jel6YE5Nsh3wFJ/ISMr8zD9dSDr9KjzSF/H+rH2rNp/537EczoZo77wQDZOKTtwywszO Kbab3C+Rf7BzfjybFLJTLcu1kO5iWQiijckuv7nPeoZyFDumOPmgJfayKhhUytUCl8XG 2e+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=STOSuS6ehcb2aG3V1A6fF3BAMGPsrsIZ5kHjJIFFci8=; b=TEAboKJ1+2sox9IThkt4GCAAv8ExlmdfHR/6fZHgx8CkestfVhWnK1jYEM8nl7poxd paiJI/goNKNr0cktL0p2ixRt3Ib5DYjKjjnpViTpA0JjN+22ML9u4RbcKjyZPli110CB 1UK4eKiDE2XFF1OUNBJnyToYTNjsQA6IHfrxFTPXxWjOeIppESN3m/B65QHDW5e2BaAt Sb24XnSXRadjkz8194Dx9YcKna3+T1MLZsPoB9C63hCOgK6yGvjtNXM0OGf2ROJjI545 r6QOdv0JJR/pkhCAMkc+WbTzHc5I16CfZc0qZsFmMruBVlO4hIBw/zWXelVNx3u4O9jX Xslw== X-Gm-Message-State: AODbwcB49DXQkfravP21pcWmTwOFEf1dhhAyjFEOJhQi0RJ51AI3eZVz RLpOWzNR8wVqyQ== X-Received: by 10.84.218.134 with SMTP id r6mr33013195pli.190.1496176865328; Tue, 30 May 2017 13:41:05 -0700 (PDT) Received: from ?IPv6:2406:e007:40ba:1:28cc:dc4c:9703:6781? ([2406:e007:40ba:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y9sm8452771pgs.43.2017.05.30.13.41.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 13:41:04 -0700 (PDT) To: Michael Richardson Cc: anima@ietf.org References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> <5785.1496164299@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 31 May 2017 08:41:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5785.1496164299@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] transitive trust in GRASP ASA negotiations X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 20:41:07 -0000 On 31/05/2017 05:11, Michael Richardson wrote: > > ekr> 2. I didn't find the security model very clear. As I understand > ekr> things, basically anyone on the network who has ACP credentials is > ekr> trusted to engage in negotiation with you, so, for instance, if you > ekr> want to get parameter X, then you basically just trust whoever on the > ekr> network offers you X. is that correct? That seems like it needs to be > ekr> very explicitly called out. And if that's not true, then I don't > ekr> understand the spec. > > bc> That is the trust model, but really as an explanatory matter I think it > bc> belongs in draft-ietf-anima-reference-model rather than here. I will > bc> add a few words in the High Level Deployment Model section and/or the > bc> Security Considerations. > > I am increasingly uncomfortable with leaving things like this. It's clearly not the end state, but surely we are on shifting sands until BRSKI and the ACP are stable. > There are a number of things that we could do as GRASP extensions: > > 1a) M_SIGNED: could be container that encapsulates a GRASP message into > a COSESign1 structure to indicate who sent the message. > > 1b) M_MULTISIGNED: a be a container with a COSESign structure in which > every passing node signs as it goes through. > > 2) transport end to end, run it over TLS or something. Might be implied or might > require a M_STARTTLS message. > > 3) hop-by-hop, with some kind of M_TUNNEL message, or using COSE Encrypt > messages with relaying on the outside. > > I think that all of these things could be ASA specific, but I think that ASA > should not have to re-invent the wheel here, but can use the GRASP "kernel" > (aka "libgrasp") to do the right thing. > > My request for the Chairs to put this on the "re-chartering" list for later > on, but to discuss with ADs now so that some of the GRASP or framework work > could say something aobut "future work". Yes, certainly, after we get the basic infrastructure documents out of the door. Brian From nobody Tue May 30 13:48:32 2017 Return-Path: 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 EE398129447 for ; Tue, 30 May 2017 13:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 OEm4y63IT8I8 for ; Tue, 30 May 2017 13:48:29 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 59105126CD8 for ; Tue, 30 May 2017 13:48:29 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id l74so45537662ywe.2 for ; Tue, 30 May 2017 13:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BtN9hTuTTyJceI6P9QR/ZJpexgoTgpma7eIwBWkyKr0=; b=l+r8WClECHvlkzudyqAE4HxZKmNr/3dINwspn70NbaLe71KQbD4TpzTuOlQ8KMGxrJ g66e8D8071xEnbk44xyKPTMvC6CRe6LxEd8tG7T5mtNlFRmO6+1GYUr4AZ5NQurEpnUJ O43ZSeZBgn9l844BZ16QEQ/G+iIRxyK28bQCenYPODbGXx8tbahLGc22c4Tbf2jVC1j7 vUsTekCbfp9rX2nUj2DVGjCbNpWlnOGLlw6esXAyRvHltQRTo5hAUoZpQxQ0Voxbo4n4 l+3Fh1svakpLdac1bZ7Ngw2TUJZmj7jmV6ymk5YBsPavARLryGOfjQREz42c/zStBoZZ ueuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BtN9hTuTTyJceI6P9QR/ZJpexgoTgpma7eIwBWkyKr0=; b=nqWz/oWpO5xLEF8qZwu5HhBAYBqt5y+7Dvxg2jo+m96Tgl3bMPpZ+qe1DMxvZJ4szj 0nsNldUH+9uaf5l3+6VE4JotqWXwfrh5dyFvW78dTX43NWNdY+Iurgid/EIRoQYaEJrz 5l9B7eiE5U1dHJZAGEB25D3XbzyzGG/2NEs13gCXcuj5QHi8CvK7qCPkKEZKeUpiPphx 7kpVskR2gTyuaJpOAMa90WUEZLoUthWqxQhNYkKGpdkC3Ni1SBzP7fjudYSss9cJZBv9 EXaRDFdahasaloVwPMsM6cvbiNPnxpVddaaqIjPEv/UIh7WbmxXfEowVtK8Tuk6I1fb/ 1rtQ== X-Gm-Message-State: AODbwcDlxCbQ8eeasaPWbpp++vKH/ejwa0px6mM2CNfSskv6fgo15xO4 9g4azQ3OEI7KgeoLMKpxi/wnuF9YmdLZ X-Received: by 10.129.57.138 with SMTP id g132mr16760650ywa.312.1496177308653; Tue, 30 May 2017 13:48:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Tue, 30 May 2017 13:47:48 -0700 (PDT) In-Reply-To: <69ab8d4a-8ed2-6b34-9dc9-356f67788d48@gmail.com> References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> <3636.1496163751@obiwan.sandelman.ca> <69ab8d4a-8ed2-6b34-9dc9-356f67788d48@gmail.com> From: Eric Rescorla Date: Tue, 30 May 2017 13:47:48 -0700 Message-ID: To: Brian E Carpenter Cc: Michael Richardson , anima-chairs@ietf.org, Anima WG , The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang Content-Type: multipart/alternative; boundary="001a114c76b401427f0550c3edb2" Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 20:48:31 -0000 --001a114c76b401427f0550c3edb2 Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 1:37 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 31/05/2017 05:02, Michael Richardson wrote: > > > > Eric Rescorla wrote: > > > It's the job of this group of specifications to provide a complete > > > security story, so it must either be here or it must be in some > other > > > document which is normatively referenced from here and which > therefore > > > one can read to determine if this document achieves the appropriate > > > security objectives. Just generally pointing in the direction of > TLS is > > > not sufficient. You could, of course, say that TLS is not to be > used at > > > all and you rely entirely on ACP, but the current text doesn't do > that > > > either. > > > > The use case for TLS is inter-domain (while the ACP is intra-domain). > > I.e. between two ISPs. Such a GRASP instance would be isolated from > other > > ANIMA GRASP instances, would perhaps not be hop-by-hop. Or might be. > > > > As that use case is not well understood at all, and I think can (and > SHOULD) > > be addressed later on, I have argued for simply not mentioning it > because we > > don't have a story about certificates or identities or validation, etc. > (I > > suspect that many initial uses will use pinned self-signed certificates, > > manually configured). > > > > Brian has argued to continue to include the reference so that we remember > > that use over a secured ACP is not the only use, and that we shouldn't > write > > some complex interaction that involves many UDP/TCP port combinations > that > > would be hard to support over TLS. > > > > Use of GRASP at an Internet Exchange (IX) might be different again, > perhaps > > using COSE to sign GRASP multicast messages. > > > > Can anyone suggest a way to keep TLS in mind while not actually saying > we know > > how to use it? > > That's the crux of it. We intentionally did not want to bind GRASP > irrevocably to the ACP, so that it can be used, for example, to implement > dynamic resource management between two ISPs that have a specific trust > model between themselves. But clearly that's future work. How can we > express that? > The usual way is to define things for ACP and then say that future specs may define other protection mechanisms. -Ekr --001a114c76b401427f0550c3edb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 30, 2017 at 1:37 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
On 31/05/2017 05:02, Michael Richa= rdson wrote:
>
> Eric Rescorla <ekr@rtfm.com>= wrote:
>=C2=A0 =C2=A0 =C2=A0> It's the job of this group of specificatio= ns to provide a complete
>=C2=A0 =C2=A0 =C2=A0> security story, so it must either be here or i= t must be in some other
>=C2=A0 =C2=A0 =C2=A0> document which is normatively referenced from = here and which therefore
>=C2=A0 =C2=A0 =C2=A0> one can read to determine if this document ach= ieves the appropriate
>=C2=A0 =C2=A0 =C2=A0> security objectives. Just generally pointing i= n the direction of TLS is
>=C2=A0 =C2=A0 =C2=A0> not sufficient. You could, of course, say that= TLS is not to be used at
>=C2=A0 =C2=A0 =C2=A0> all and you rely entirely on ACP, but the curr= ent text doesn't do that
>=C2=A0 =C2=A0 =C2=A0> either.
>
> The use case for TLS is inter-domain (while the ACP is intra-domain).<= br> > I.e. between two ISPs.=C2=A0 Such a GRASP instance would be isolated f= rom other
> ANIMA GRASP instances, would perhaps not be hop-by-hop.=C2=A0 Or might= be.
>
> As that use case is not well understood at all, and I think can (and S= HOULD)
> be addressed later on, I have argued for simply not mentioning it beca= use we
> don't have a story about certificates or identities or validation,= etc.=C2=A0 (I
> suspect that many initial uses will use pinned self-signed certificate= s,
> manually configured).
>
> Brian has argued to continue to include the reference so that we remem= ber
> that use over a secured ACP is not the only use, and that we shouldn&#= 39;t write
> some complex interaction that involves many UDP/TCP port combinations = that
> would be hard to support over TLS.
>
> Use of GRASP at an Internet Exchange (IX) might be different again, pe= rhaps
> using COSE to sign GRASP multicast messages.
>
> Can anyone suggest a way to keep TLS in mind while not actually saying= we know
> how to use it?

That's the crux of it. We intentionally did not want to bin= d GRASP
irrevocably to the ACP, so that it can be used, for example, to implement dynamic resource management between two ISPs that have a specific trust
model between themselves. But clearly that's future work. How can we express that?

The usual way is to defin= e things for ACP and then say that future specs may
define ot= her protection mechanisms.

-Ekr

--001a114c76b401427f0550c3edb2-- From nobody Tue May 30 13:53:57 2017 Return-Path: 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 B46A7129447 for ; Tue, 30 May 2017 13:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 m46_GmzbV0gY for ; Tue, 30 May 2017 13:53:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2DE126CD8 for ; Tue, 30 May 2017 13:53:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5BED92009E; Tue, 30 May 2017 16:54:14 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D8EEB636BB; Tue, 30 May 2017 16:53:52 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: anima@ietf.org In-Reply-To: References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <1a4b149e-25f0-d4d8-1e31-4d497703129d@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Need WG input: Adam Roach's comment on GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 20:53:56 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > If we ever add not-over-IP =E2=80=9Ctransports=E2=80=9D, there might = be a need for > experiments before we go registering. So I would probably identify a > range of numbers that are strictly reserved for use in experiments. > (This needn=E2=80=99t be very small; say, 65280 to 65535.) =2D1 to -32! =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkt2+AACgkQgItw+93Q 3WWjqwgAnWJo8vu+cV2SQjX08IFJ2mjUGVXIbMVF3AWI1yIUfNwhQcMJR6Qtu3SC 2GC1fA7w7SH1Kz8C5piArozZP6cptgm2lMW0XMF/5IFZ8wTasDoOrFiIdWnruydq 3x50STgNbGiaQAuvD4dkbBgnsEMLcB/LJc0WW0bC+fcgrxC3ztSSe9gSgdE6rgF2 IJX/rh/U2eCcnYHK1WZz8VgJ9VD9QcrbUjOE+PujU4aMC+HQz3ci86IuS4xFQsbR f/do47uALoC9185pIq/+6ifNt7CBIQ8qr49tzLAcLHBoXBnyHcly0XjuYdskuH3Q M0Z1gsKB8tE7dMP+6iP3p2G+4XLXTg== =Qjql -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 30 15:00:43 2017 Return-Path: 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 9C1F3129455; Tue, 30 May 2017 15:00:42 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxXc3q5iSmD4; Tue, 30 May 2017 15:00:41 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 3523A127333; Tue, 30 May 2017 15:00:41 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id e193so84039065pfh.0; Tue, 30 May 2017 15:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ByEKpvNip8cgMTE7woWX6WIQ1WdM1Upfz80vGVDrXWw=; b=cW+HyL8ZLCF+pCDX142TcaVY9VsfetComwr947J2HUkNW6ycvSnT6BuufOjWgMlC1N TMtzhp62vlEqb7YEau2+RxiElV4xGSaP/PClz3yNtqKcL7qIu8SyDUhs5yvPycz91VIm xlEyirQfbnxbn3qMq6E4g0VmBOMkf+Cls8qmMgID+uoYu99aGCdBh+6SMW6V3dgZvGXf cYQpcEfshgfBTRThUXzVhmXpSlyy0vmCkF1Lo7ce71ERahtQoSkmoygxMCxrtGT5latI qKRoTZbkQzb7meXEb5abqJJKxL2QYuGFYjcfn0ErMKOUBe0EfUy97dusXvs5VB734GqL Y3Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ByEKpvNip8cgMTE7woWX6WIQ1WdM1Upfz80vGVDrXWw=; b=Xv9mkm1L3/QzEB7SIFbaCmMdE0otNYZXFYusdBHLvoI/BoC5mb5usVCDFxGGE0V1fY mQO5iG44rgfd8/pk2iezdqnMcd583vLRORuxoLcRmYq+l68CSXgHyFA7rPf4u0+8oKj0 l0Ppe7Ir8n2ZpaQqK99qGhLPpzzspaguVD0u2l1DwAxQ9x58YD1T0o3RiYDILt0NiVm2 EmPnVl0BLfSsVRhc/H4gXeYIjlUCKAUismS+B1vIj31RW0YHAxXGUXCLQaR8bbwd+ooy Rw9V1sWshe1y8M66LzChI7L+rU8erFClCkDGpwk6pW6GOyS2c+Www6/Ekxg4g+OT2zFG Fb0g== X-Gm-Message-State: AODbwcCtbnJIX9+n7RZfNdWW/E10ktq442mhWhxyXNfa2JfV7myVsmPV aw7f6KUs/yzWPVFR X-Received: by 10.99.156.26 with SMTP id f26mr28496164pge.86.1496181640508; Tue, 30 May 2017 15:00:40 -0700 (PDT) Received: from ?IPv6:2406:e007:40ba:1:28cc:dc4c:9703:6781? ([2406:e007:40ba:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 192sm21415565pfb.10.2017.05.30.15.00.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 15:00:40 -0700 (PDT) To: Eric Rescorla Cc: Michael Richardson , anima-chairs@ietf.org, Anima WG , The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> <3636.1496163751@obiwan.sandelman.ca> <69ab8d4a-8ed2-6b34-9dc9-356f67788d48@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <88aa8835-bf5a-86d7-f3cc-861ab51efc73@gmail.com> Date: Wed, 31 May 2017 10:00:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 22:00:43 -0000 On 31/05/2017 08:47, Eric Rescorla wrote: > On Tue, May 30, 2017 at 1:37 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 31/05/2017 05:02, Michael Richardson wrote: >>> >>> Eric Rescorla wrote: >>> > It's the job of this group of specifications to provide a complete >>> > security story, so it must either be here or it must be in some >> other >>> > document which is normatively referenced from here and which >> therefore >>> > one can read to determine if this document achieves the appropriate >>> > security objectives. Just generally pointing in the direction of >> TLS is >>> > not sufficient. You could, of course, say that TLS is not to be >> used at >>> > all and you rely entirely on ACP, but the current text doesn't do >> that >>> > either. >>> >>> The use case for TLS is inter-domain (while the ACP is intra-domain). >>> I.e. between two ISPs. Such a GRASP instance would be isolated from >> other >>> ANIMA GRASP instances, would perhaps not be hop-by-hop. Or might be. >>> >>> As that use case is not well understood at all, and I think can (and >> SHOULD) >>> be addressed later on, I have argued for simply not mentioning it >> because we >>> don't have a story about certificates or identities or validation, etc. >> (I >>> suspect that many initial uses will use pinned self-signed certificates, >>> manually configured). >>> >>> Brian has argued to continue to include the reference so that we remember >>> that use over a secured ACP is not the only use, and that we shouldn't >> write >>> some complex interaction that involves many UDP/TCP port combinations >> that >>> would be hard to support over TLS. >>> >>> Use of GRASP at an Internet Exchange (IX) might be different again, >> perhaps >>> using COSE to sign GRASP multicast messages. >>> >>> Can anyone suggest a way to keep TLS in mind while not actually saying >> we know >>> how to use it? >> >> That's the crux of it. We intentionally did not want to bind GRASP >> irrevocably to the ACP, so that it can be used, for example, to implement >> dynamic resource management between two ISPs that have a specific trust >> model between themselves. But clearly that's future work. How can we >> express that? >> > > The usual way is to define things for ACP and then say that future specs may > define other protection mechanisms. OK, so no spec is better than an incomplete spec. That's easy enough. It also, IMHO, means deleting the "SONN" subsection, 3.5.2.3. Toerless: you invented that, but as I understand it BRSKI does not need it since the registrar-proxy interaction will take place over the ACP. Brian From nobody Tue May 30 16:19:33 2017 Return-Path: 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 B2F551201F8; Tue, 30 May 2017 16:19:26 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el9hApzbGg4S; Tue, 30 May 2017 16:19:25 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 2F6F1120046; Tue, 30 May 2017 16:19:25 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id 9so500528pfj.1; Tue, 30 May 2017 16:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VuvlCV+hpwH4AQ3/B6faRh0g4WDfEB6P2YTZ0j2O5Wg=; b=dDoHMDDkjW3d3kEPOp4aRGXEr0WhPKib3ZVINj1aF0Ea3EOmH0uuccim2zsfisiTbW PqXb/AzuQMXrK/S6Or5FI4xINNUfdHZ2VKEyQ7mZotqkvygQR9k6U6AinsVICCTKmAO4 SoQW9JfTY0S41o5kZF0qh49PySvCmcdEwJK+TX4DukHlOr5ICVKnd47p1KfeMKPWNgNn dmPHZuHNJ8H8tCIwf00jEW743Zmy/OVEzYByfkWlznRrHLbOAqhbuDkIGA9R4aC6sLPt 9x1LESXvNrzoccLGzjqCyIqhfL6B9u7wkOvhqW2phrZj4pt/2+Yh9rHwOrZhJj6Z7Y7A cW4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=VuvlCV+hpwH4AQ3/B6faRh0g4WDfEB6P2YTZ0j2O5Wg=; b=fKhyDqYAMjqzvQgeOdxNUKivCvArxMFnPHRNt8q+vOYNf0pjI8prA8K2MeUB8UiXKg XMclfIiV06yX9vP8gzSmqc00n+ABfCjaRSg1zg8eTMspsc+mtD7wHN6UinkJnNxd4Zn1 0cuHTKYF9JzktKlK4Ki63A17TqDF2q532fHcLiRw5BdOfM1yaI5G4z7ksIGGbIKfojjG VZV0YDQna55kQM01cXmFw8Dt1WxxFxlPPy0H4T90gtiK9hGqLFlFuFi3rSBsG7a3fmTw 3RaCaELOGx0NlPRuHCgPkN+GB3+U9BMU8e3YyyXI12XoRw2xxb7pSKUmlUZQZ0FzSBr6 Ulfw== X-Gm-Message-State: AODbwcDDjsH9vu3r6lcSqUwKPUDCpHqOPHBmWyTJPBO8oh7B9vtx/VJm HZ/O0Pku0TyUqMSR X-Received: by 10.99.166.18 with SMTP id t18mr28324313pge.218.1496186364594; Tue, 30 May 2017 16:19:24 -0700 (PDT) Received: from ?IPv6:2406:e007:40ba:1:28cc:dc4c:9703:6781? ([2406:e007:40ba:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x18sm8387432pge.50.2017.05.30.16.19.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 16:19:23 -0700 (PDT) To: Eric Rescorla Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <93bd9175-77c7-e588-93f9-49a09e12cd66@gmail.com> Date: Wed, 31 May 2017 11:19:21 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 23:19:27 -0000 On some other points that are dangling after previous messages: On 31/05/2017 00:29, Eric Rescorla wrote: > On Mon, May 29, 2017 at 10:14 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Eric, >> >> On 25/05/2017 14:32, Eric Rescorla wrote: >> ... >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- ... >> Finally, I don't >>> understand the security story for the multicast packets. >> >> I think I already typed this a day or two ago, but with an ACP, >> they are secured, because the ACP is a secure virtual overlay >> network. >> > > This document then needs to state which precise properties of > ACP it is relying on for that. A brief skim of ACP suggests that > it relies on other protocols for its actual transport security and > at least some of those protocols (e.g., DTLS) do not support > multicast. Indeed, but as I understand it they will emulate link-local multicast over the secured connections. We don't need wider scope multicast, which is much harder to emulate. We'll try to make this expectation clear. > With no ACP they are of course wide open, unless some new >> magic has been invented that I'm not aware of. Hence the >> restrictions in 3.5.2.2. "Discovery Unsolicited Link-Local" >> > > As above, you need to specify which properties you are relying > on, But in DULL we aren't relying on anything; we're just sending GRASP packets over an interface. I don't see anything that needs specifying. > and how you bridge multicast to unicast. ? We don't do that. >> This is especially relevant for Rapid mode, where you are >>> attaching real work to these multicast packets. >> >> Correct. I think we need to forbid that in the no-ACP case. >> >>> 2. I didn't find the security model very clear. As I understand >>> things, basically anyone on the network who has ACP credentials >>> is trusted to engage in negotiation with you, so, for instance, >>> if you want to get parameter X, then you basically just trust >>> whoever on the network offers you X. is that correct? That seems >>> like it needs to be very explicitly called out. And if that's not >>> true, then I don't understand the spec. >> >> That is the trust model, but really as an explanatory matter I think >> it belongs in draft-ietf-anima-reference-model rather than here. >> I will add a few words in the High Level Deployment Model >> section and/or the Security Considerations. >> >> What we do say already is that authorization of ASAs is out of scope. >> I am certain that it needs to be tackled, but not here. >> > > I don't see how you have a complete protocol without that. The starting position is that we trust all autonomic nodes and therefore the ASAs installed in them. We are in the context of a single operator so this isn't really a stretch. The questions around life cycle management of ASAs, which would certainly involve authorization, were intentionally not in the initial WG charter. I think it's true that you can't have a complete *system* without that, but I disagree that it's a requirement for the protocol. ... >> Finally, I don't see a spec for how you map CBOR onto the wire. Do you >>> just shove them on? Something else? >> >> Yep, CBOR is just a string of bytes. That's CBOR 101 so I don't >> think we need to say anything more. >> > > I don't agree. JSON is just a string of bytes and yet ACME, for instance, > contains > a rather extensive protocol mapping to HTTP. So, you need to at least state > that > you just shove them on the wire. Will do. Brian From nobody Tue May 30 16:30:52 2017 Return-Path: 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 475421200FC for ; Tue, 30 May 2017 16:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 TwL-_Fc6SfQv for ; Tue, 30 May 2017 16:30:49 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 C75D4129479 for ; Tue, 30 May 2017 16:30:47 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id l74so46918145ywe.2 for ; Tue, 30 May 2017 16:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1nXY7hZaz2VJnKPyzIpcBweJShdAoSbBdDNHohO3VfE=; b=EEjnZeaaC+9yWp4YtsxaDbBYBuZrXpD1KEru/5t2g4FkT/t5e+ooE9BqMcxQ2eDE2d IZlwph+uKMoDqUaGRoAwz0C0uQzGX7SN/K1qET78tIq2wzZQJlfckESnrhSRUXujv24Q RAPZMnGYop+sohNIR7kspAykDqlg7w9VOyXE4MUIIYKk5B1QotRY8/v5R9iFVKdf+5dK /ikSWUHzFFwXyoPokALczqtd/JOqTtLATjl8lip6G6cjQ05X/i6J0Qop4lURMvSi12fU h2nl2fGRzjTm4mNFGoJNMe3fC6RPY4cZ27FkUSyI5WL2t0YkSjWgo3Do10Q1xIAUUYkv w9pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1nXY7hZaz2VJnKPyzIpcBweJShdAoSbBdDNHohO3VfE=; b=FSrlPKbt3fvxfLfePvAu6qqi7cmLkXK0siuVjPAMJw5ZSsniwgAcGhCeYriek11rpO GksWNLt5ukCY1YxBHzf3TFWPCrfOzrPkVstr2279I5Eb9LOLF49o8ryddX8Yp3tRio/D L1RvZcJ3/y8+Ej5kteloaQjlUysEuC5dNKlxhzPcL7VTveXKY4qxCwYUMaD2G4WrW5F7 +eGuCbU3yYTNDFFBww2LbrQofnWqCtEPben8uYM9Yz7dyt5JHEYxI2Lu6NWnWZMwMe96 eHcBZW8D+6GqGfQHt28ewqE4+49O6M1PIReqvlvBHXFtr4JgmOBdBP4/HpvQCUzXurWU moww== X-Gm-Message-State: AODbwcBVnQ6WFMP7FMegjXPewGTtpvwYyMxOcEySOiT4F0KFZT5JsVKB 5oDbTbB1gg3mhNYrPkw4fahytLROo/9d X-Received: by 10.13.212.1 with SMTP id w1mr16844050ywd.24.1496187047085; Tue, 30 May 2017 16:30:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Tue, 30 May 2017 16:30:06 -0700 (PDT) In-Reply-To: <93bd9175-77c7-e588-93f9-49a09e12cd66@gmail.com> References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> <93bd9175-77c7-e588-93f9-49a09e12cd66@gmail.com> From: Eric Rescorla Date: Tue, 30 May 2017 16:30:06 -0700 Message-ID: To: Brian E Carpenter Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, Anima WG Content-Type: multipart/alternative; boundary="001a114fb0f675a2f50550c631e7" Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 23:30:50 -0000 --001a114fb0f675a2f50550c631e7 Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 4:19 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On some other points that are dangling after previous messages: > > On 31/05/2017 00:29, Eric Rescorla wrote: > > On Mon, May 29, 2017 at 10:14 PM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> Eric, > >> > >> On 25/05/2017 14:32, Eric Rescorla wrote: > >> ... > >>> ---------------------------------------------------------------------- > >>> DISCUSS: > >>> ---------------------------------------------------------------------- > ... > >> Finally, I don't > >>> understand the security story for the multicast packets. > >> > >> I think I already typed this a day or two ago, but with an ACP, > >> they are secured, because the ACP is a secure virtual overlay > >> network. > >> > > > > This document then needs to state which precise properties of > > ACP it is relying on for that. A brief skim of ACP suggests that > > it relies on other protocols for its actual transport security and > > at least some of those protocols (e.g., DTLS) do not support > > multicast. > > Indeed, but as I understand it they will emulate link-local multicast > over the secured connections. It's not clear to me what that means. You perhaps expect to tie up a connection to every counterparty in the network? > With no ACP they are of course wide open, unless some new > >> magic has been invented that I'm not aware of. Hence the > >> restrictions in 3.5.2.2. "Discovery Unsolicited Link-Local" > >> > > > > As above, you need to specify which properties you are relying > > on, > > But in DULL we aren't relying on anything; we're just sending GRASP > packets over an interface. I don't see anything that needs specifying. > As you indicate, DULL has a whole pile of rules. Why are those rules sufficient? > and how you bridge multicast to unicast. > > ? We don't do that. > Huh? You send out a discovery packet in multicast and then expect someone to connect to you via unicast, no? >> That is the trust model, but really as an explanatory matter I think > >> it belongs in draft-ietf-anima-reference-model rather than here. > >> I will add a few words in the High Level Deployment Model > >> section and/or the Security Considerations. > >> > >> What we do say already is that authorization of ASAs is out of scope. > >> I am certain that it needs to be tackled, but not here. > >> > > > > I don't see how you have a complete protocol without that. > > The starting position is that we trust all autonomic nodes and therefore > the ASAs installed in them. We are in the context of a single operator so this isn't really a stretch. I certainly can see how someone might decide to deploy a system like this, but it seems pretty problematic to have a system that is so brittle to single-point compromise (The term of art here is "distributed single point of failure") > The questions around life cycle > management of ASAs, which would certainly involve authorization, > were intentionally not in the initial WG charter. I think it's true > that you can't have a complete *system* without that, but I disagree > that it's a requirement for the protocol. > At minimum you need to specify that this is your trust model and then work through the implications of compromise of some subset of nodes, as well as of an attacker who can influence which nodes you talk to. -Ekr --001a114fb0f675a2f50550c631e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 30, 2017 at 4:19 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
On some other points that are dangling after previous m= essages:

On 31/05/2017 00:29, Eric Rescorla wrote:
> On Mon, May 29, 2017 at 10:14 PM, Brian E Carpenter <
> brian.e.carpenter@gmail= .com> wrote:
>
>> Eric,
>>
>> On 25/05/2017 14:32, Eric Rescorla wrote:
>> ...
>>> ---------------------------------------------------------= -------------
>>> DISCUSS:
>>> ---------------------------------------------------------= -------------
...
>> Finally, I don't
>>> understand the security story for the multicast packets.
>>
>> I think I already typed this a day or two ago, but with an ACP, >> they are secured, because the ACP is a secure virtual overlay
>> network.
>>
>
> This document then needs to state which precise properties of
> ACP it is relying on for that. A brief skim of ACP suggests that
> it relies on other protocols for its actual transport security and
> at least some of those protocols (e.g., DTLS) do not support
> multicast.

Indeed, but as I understand it they will emulate link-local multicas= t
over the secured connections.

It's not = clear to me what that means. You perhaps expect to tie up
a conne= ction to every counterparty in the network?



> With no ACP they are of course wide open, unless some new
>> magic has been invented that I'm not aware of. Hence the
>> restrictions in 3.5.2.2. "Discovery Unsolicited Link-Local&qu= ot;
>>
>
> As above, you need to specify which properties you are relying
> on,

But in DULL we aren't relying on anything; we're just sendin= g GRASP
packets over an interface. I don't see anything that needs specifying.<= br>

As you indicate, DULL has a whole pile = of rules. Why are those rules
sufficient?


> and how you bridge multicast to unicast.

? We don't do that.

Huh? You= send out a discovery packet in multicast and then expect
someone= to connect to you via unicast, no?


>> That is the trust model, but really as an explanatory matter I thi= nk
>> it belongs in draft-ietf-anima-reference-model rather than he= re.
>> I will add a few words in the High Level Deployment Model
>> section and/or the Security Considerations.
>>
>> What we do say already is that authorization of ASAs is out of sco= pe.
>> I am certain that it needs to be tackled, but not here.
>>
>
> I don't see how you have a complete protocol without that.

The starting position is that we trust all autonomic nodes and there= fore
the ASAs installed in them. We are in the context of a single operator
so this isn't really a stretch.

I certa= inly can see how someone might decide to deploy a system like
thi= s, but it seems pretty problematic to have a system that is so brittle
to single-point compromise (The term of art here is "distributed= single point of failure")
=C2=A0
The questions around life cycle
management of ASAs, which would certainly involve authorization,
were intentionally not in the initial WG charter. I think it's true
that you can't have a complete *system* without that, but I disagree that it's a requirement for the protocol.

At minimum you need to specify that this is your trust model and
then work through the implications of compromise of some subset
of nodes, as well as of an attacker who can influence which nodes
you talk to.

-Ekr

=
=C2=A0
--001a114fb0f675a2f50550c631e7-- From nobody Tue May 30 18:32:35 2017 Return-Path: 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 25D2D126CC4; Tue, 30 May 2017 18:32:34 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5h5cSJe0Z5Z; Tue, 30 May 2017 18:32:32 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 2F3AB1294A3; Tue, 30 May 2017 18:32:32 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id u187so55388pgb.1; Tue, 30 May 2017 18:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1fJY+6lhey67NYxP4mLbildoLE5Uvfkq7fghHtuUc7s=; b=AhXsmmbC9kCG1CYJ+DAHW0kbGzCTLxyERX+udA08VwfwE/LL3xwfP5qYsO1haKz4HV nVI++QOU0LxJBWl0JgaU+FyBWkwbPIr6jGE7h2wbTY/OWj2fltBW7RuOH2d7Vrb8qMLD U61BHVqB6G+2e5+dQRRPi2h37l4J5QRCOSWZilCUIY/HUhb3gluibDR5be7o3sP1Pe0x IXIMe/AUkCrYVuuZebSdjF20jhRTWx3N+8s2wEugkvoz857A9xmYqDQrJ7FWtemB/ypl txr+Vah9USXAD+1ca2KsoggViYhHr6fF1RzH3xfWW8g3kHlH26qF8gMjUcXGv8joLVCF jD2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=1fJY+6lhey67NYxP4mLbildoLE5Uvfkq7fghHtuUc7s=; b=gbvVLU2wEtm3LeegMXfy8WVIqPfrvd5BTBThhfoIhQipggurmu8LKZZxGUqc0Godmn RWNjk25n3BQ22Jv3DVd4BXFar2d6LS6SDeFj1A/hWsoJ1LTg8s5XxrrpQtXsVL1QCbZd Dd2pUidgRbOOQ+ZGzMFKVQUsPUWs0lWrW+JFrL4Eis8uO+pdRr250eLZXbJcYgtGIEG0 3RDYV0obYDOujYEjcP8cQrNhTitX74U/CShu2teVZUWECHUeYgA49sVAbEt5E/yOWFK+ fVxPKYZtyVxtYEGC9jKjRvo1+iIgjQSakkTMwR1fOv/QIzn19xgIq/2xiO83RA/Xik6n SwLQ== X-Gm-Message-State: AODbwcAoLSLDrX/z/rF+sK3nrQk5ERyGcQTJ+733ZCeeOxdQaaQb2Pw6 ji2hKPWdH2dGNJFl X-Received: by 10.99.6.65 with SMTP id 62mr8412423pgg.157.1496194351530; Tue, 30 May 2017 18:32:31 -0700 (PDT) Received: from ?IPv6:2406:e007:40ba:1:28cc:dc4c:9703:6781? ([2406:e007:40ba:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g63sm27146180pgc.59.2017.05.30.18.32.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 18:32:30 -0700 (PDT) To: Eric Rescorla , The IESG Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <2be0192e-2edd-a192-26d2-2a755784dfe5@gmail.com> Date: Wed, 31 May 2017 13:32:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 01:32:34 -0000 Now getting to Eric's COMMENTs: On 25/05/2017 14:32, Eric Rescorla wrote: ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > S 3.5.4.3. > After a GRASP device successfully discovers a locator for a > Discovery > Responder supporting a specific objective, it MUST cache this > information, including the interface index via which it was > discovered. This cache record MAY be used for future negotiation or > synchronization, and the locator SHOULD be passed on when > appropriate > as a Divert option to another Discovery Initiator. > > What's an "interface index" It's a term of art in the socket API: https://tools.ietf.org/html/rfc3493#section-4 Does it need a reference? > S 3.5.4.4. > Since the relay device is unaware of the timeout set by the original > initiator it SHOULD set a timeout at least equal to > GRASP_DEF_TIMEOUT > milliseconds. > > I'm not sure I'm following here. Does the relay instance retransmit > with its own timeout? Yes, but this text was broken anyway (as detected by Bill Atwood testing my code, embarassingly recently). The next version should be clearer, as well as being corrected. > It MUST cache the Session ID > value and initiator address of each relayed Discovery message until > any Discovery Responses have arrived or the discovery process has > timed out. > > How does this behave if the original initiator's timeout is > longer than GRASP_DEF_TIMEOUT? That case works, except that the original initiator waits unnecessarily. But consider what happens if the original initiator's timeout is *shorter* than the timeout on the relayed discovery. It can then happen that the relayed discovery response is returned to the originator after the originator has timed out. That's what Bill discovered :-(. Will fix. > S 3.5.5. > A negotiation procedure concerns one objective and one counterpart. > Both the initiator and the counterpart may take part in simultaneous > negotiations with various other ASAs, or in simultaneous > negotiations > about different objectives. Thus, GRASP is expected to be used in a > multi-threaded mode. Certain negotiation objectives may have > restrictions on multi-threading, for example to avoid > over-allocating > resources. > > "multi-threaded" is an odd word here. I assume you mean that you > are doing multiple stuff at once, but you might actually write > the system using non-multi-threaded techniques. You could, and we need to make sure that the API allows for that. Logically it's always multi-threaded though, even if you use something like an event-loop technique. We can tweak the wording accordingly. > S 3.7. > You seem to be going to a lot of trouble to deal wit session > ID collisions. Why don't you just make session IDs 128-bit > random values and then you won't have to worry about > collisions. Well, yes, the odds would be better with 128 than 32 but that's extra bits on the wire and there'd still be the birthday paradox... > > The Session ID SHOULD have a very low collision rate locally. It > MUST be generated by a pseudo-random algorithm using a locally > generated seed which is unlikely to be used by any other device in > the same network [RFC4086]. > > Why don't you just require a cryptographically secure PRNG? > That will be required to implement the rest of this protocol Well, certainly there will be for the security bootstrap and the ACP. Is there a different reference for that? > S 3.8.2. > You seem to introduce a normative dependency on CDDL here. > I see that it's in your changelog here, but what are > your intentions about this document, given that CDDL seems > to not even be a WG document Resolve at AUTH48. If CDDL advances as planned in the CBOR WG, we're fine. If not, we have a backup plan to add a short appendix defining the subset of CDDL that we use. The text is already drafted in case we need it. > S 3.8.5. > It MUST contain a time-to-live (ttl) for the validity of the > response, given as a positive integer value in milliseconds. > Zero > is treated as the default value GRASP_DEF_TIMEOUT (Section 3.6). > > Why do this, rather than just forbidding 0. This feeds back to the API, so that a lazy ASA programmer doesn't have to provide a value. (Also, I realised when fixing the discovery timeout issue above that this default is low. Will fix.) > S 3.8.6. > If a node receives a Request message for an objective for which no > ASA is currently listening, it MUST immediately close the relevant > socket to indicate this to the initiator. This is to avoid > unnecessary timeouts if, for example, an ASA exits prematurely but > the GRASP core is listening on its behalf. > > This is not secure. You need a secure indication of non-knowledge, > not a transport-level close. I don't see this as a security issue. There would be an alternative, which is to send back an immediate M_DECLINE, but that is quite a bit harder to implement and I don't really see an advantage: the requester will just get back an error code in either case. An ASA must always be ready for an error return. > > S 3.9.5.4. > What are the semantics of a Divert URI? What do I dow ith the > path part? Two things on this: Following Alexy's comment, we are likely to add protocol/port to this type of locator option. Given that, is there anything special about the Divert case? A URI should be valid however you receive it. > S 3.10.4. > The semantics of "dry run" seem pretty unclear. Is it just > "tell me if you would be sad about doing this"? This is explained better in an earlier section: https://tools.ietf.org/html/draft-ietf-anima-grasp-12#section-3.5.5 We will try to clarify this, at least with a cross-reference. Thanks, Brian From nobody Tue May 30 19:00:10 2017 Return-Path: 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 CDAAF127011; Tue, 30 May 2017 19:00:01 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLQDpTkvET6X; Tue, 30 May 2017 19:00:00 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 3DEB0126CC4; Tue, 30 May 2017 19:00:00 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id 9so2870316pfj.1; Tue, 30 May 2017 19:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ODCn8R32+RwdL8VIi2kVymW5yNu1qNaWI5aQOEtybkI=; b=qjd+SVySYcmguqBryz+KgtJYPtrR3WjiyE/pKXqgqxuu4GHb0PKRbUx2Bvy8WHNDPE XFgWdSnM8sAwClltvnIJXIVE6G0CEUwJ+wxSYkGdnP+T9wrCZa+Qz2sxIlMcbckt/vGe uqi0rAcgWlJvrGekkGPGzBnHmd4T4P9ZoTU4/ItXHnaDwTzyMRlwwg95Xn+0X3WM+sog ZoW+d4icIa3VHX5whJo8KnAmi3uW8hjYiqqT4ZrpketB5Kr/ASYNYRlIZTvCSTB06jmv xfjOcvOblB6iNugfftnmg51bKhGREFV6TkB5xvyEQbu+84/agPS1cgrXBkielPKzxmhM AGSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ODCn8R32+RwdL8VIi2kVymW5yNu1qNaWI5aQOEtybkI=; b=OxwB3qnoWelKyO/YxvS7TkOZx9bpxz8Wj1CMYlBigHQFZUwNZnvrK/EtTHd5/YGldN LE/2Fhr7BZUaMJ7JfEKnjpgQpw1M5oGd6mxvUUDCN/bW36al2SNRPangIIfnXRWOtDWv 6Vt2xVGPDzXC3lJiscUv0TBoJoNuzX3YW0N3fFBhn6qTpaVGLigkqvR/hzdmFqFnm7aB 8TiAuMmPtW/O+pafRi5bjeb23CLGCp7nmFNVhZCcjTqnUdTbUz16tlftlk0/rndFReG4 6zpaM5mB6Effs7j/i1nmqL9l+U3pKIa/yN93Vfm7ZrzhIvcwF/ZOoEU6ZLrjKkgpvS2p R3IQ== X-Gm-Message-State: AODbwcANqUINYDWNrzH3/ejkbuDQRZzHUe5W+pNPve5gbtrRYYjZRhvV l18YhM4X+XTKVovs X-Received: by 10.98.214.14 with SMTP id r14mr27071821pfg.156.1496195999591; Tue, 30 May 2017 18:59:59 -0700 (PDT) Received: from ?IPv6:2406:e007:40ba:1:28cc:dc4c:9703:6781? ([2406:e007:40ba:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 6sm25301346pfo.132.2017.05.30.18.59.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 18:59:58 -0700 (PDT) To: Eric Rescorla , Toerless Eckert Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , Anima WG References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> <93bd9175-77c7-e588-93f9-49a09e12cd66@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 31 May 2017 13:59:57 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 02:00:02 -0000 On 31/05/2017 11:30, Eric Rescorla wrote: > On Tue, May 30, 2017 at 4:19 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On some other points that are dangling after previous messages: >> >> On 31/05/2017 00:29, Eric Rescorla wrote: >>> On Mon, May 29, 2017 at 10:14 PM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>>> Eric, >>>> >>>> On 25/05/2017 14:32, Eric Rescorla wrote: >>>> ... >>>>> ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------- >> ... >>>> Finally, I don't >>>>> understand the security story for the multicast packets. >>>> >>>> I think I already typed this a day or two ago, but with an ACP, >>>> they are secured, because the ACP is a secure virtual overlay >>>> network. >>>> >>> >>> This document then needs to state which precise properties of >>> ACP it is relying on for that. A brief skim of ACP suggests that >>> it relies on other protocols for its actual transport security and >>> at least some of those protocols (e.g., DTLS) do not support >>> multicast. >> >> Indeed, but as I understand it they will emulate link-local multicast >> over the secured connections. > > > It's not clear to me what that means. You perhaps expect to tie up > a connection to every counterparty in the network? That is exactly what the ACP does, as I understand it. >> With no ACP they are of course wide open, unless some new >>>> magic has been invented that I'm not aware of. Hence the >>>> restrictions in 3.5.2.2. "Discovery Unsolicited Link-Local" >>>> >>> >>> As above, you need to specify which properties you are relying >>> on, >> >> But in DULL we aren't relying on anything; we're just sending GRASP >> packets over an interface. I don't see anything that needs specifying. >> > > As you indicate, DULL has a whole pile of rules. Why are those rules > sufficient? They are supposed to be self-explanatory. I'm not sure what the issue is. Toerless: please speak up, you wrote that text! >> and how you bridge multicast to unicast. >> >> ? We don't do that. >> > > Huh? You send out a discovery packet in multicast and then expect > someone to connect to you via unicast, no? Yes, but that is elsewhere in the document (I think that came up in Alissa's comments). Nothing new to say in this part. > > >>> That is the trust model, but really as an explanatory matter I think >>>> it belongs in draft-ietf-anima-reference-model rather than here. >>>> I will add a few words in the High Level Deployment Model >>>> section and/or the Security Considerations. >>>> >>>> What we do say already is that authorization of ASAs is out of scope. >>>> I am certain that it needs to be tackled, but not here. >>>> >>> >>> I don't see how you have a complete protocol without that. >> >> The starting position is that we trust all autonomic nodes and therefore >> the ASAs installed in them. We are in the context of a single operator > > so this isn't really a stretch. > > > I certainly can see how someone might decide to deploy a system like > this, but it seems pretty problematic to have a system that is so brittle > to single-point compromise (The term of art here is "distributed single > point of failure") > > >> The questions around life cycle >> management of ASAs, which would certainly involve authorization, >> were intentionally not in the initial WG charter. I think it's true >> that you can't have a complete *system* without that, but I disagree >> that it's a requirement for the protocol. >> > > At minimum you need to specify that this is your trust model and > then work through the implications of compromise of some subset > of nodes, as well as of an attacker who can influence which nodes > you talk to. That really, really belongs in the reference model or the ACP draft; it's in no way specific to GRASP, because nodes could use any protocol they please over the ACP. Brian From nobody Tue May 30 19:18:08 2017 Return-Path: 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 4649E129C3E for ; Tue, 30 May 2017 19:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 LQmGcxil1k-A for ; Tue, 30 May 2017 19:17:58 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 07F30129C53 for ; Tue, 30 May 2017 19:17:58 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id b68so1043323ywe.3 for ; Tue, 30 May 2017 19:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uZO27EceHWCLnjYFq3Hp9K2kisqlrBOfe0JW0vgS9+0=; b=jfXzh5mdYNfg0Zer5KrqjdJjI+XAsVJYkjyACC/bRoIbPjzAz7YHbA1myhtZ0PeWll FzyC2ng1cv0yejAH2+PGIH+m/DuIiWYUrBpVhUn3CIS39AIMVd+C6/phOd/PsMt9dHi5 9Ttja4uv2VUwLvLxvcT0GGlRgNRr8JFsryXILCprKfaFRdPPEe1vO/9k82XQxJfJ16sh 42ixf6Jhk9oxt0TkvPHgCLo5EsdMOf9yvcux7Iw+UQXrDxWW/yzWD8eUEAaenXHFpFIV KSERAyGFJhX4RNy5gw+Pzf/uCYPsSMShEXG52V/Z/PZk09doo8VZBLeUX2GYh8VXEhr/ 83+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uZO27EceHWCLnjYFq3Hp9K2kisqlrBOfe0JW0vgS9+0=; b=nyjlHpXgfCZObldFa18z9nReg35ZvOJ3XWn/GxLQQQ8uKmKSFwbQ01eNzubfCpo4Hf 3o0Qie1P0Z0wzZxpD5YYYL1Nk9A8pW/Orh/WcQSr6T/tYn5/V2BDHt2COSOlAxfZFkLY TtCLhfRsgeuWPdw+MZ1bT8IZ4ZjbCrb7GJi2gryomQKYefliHF567O/KS/gAoFDHdpWl OJVJVScIpYUub2flABYsjVcqOQ5ZZMD9prxkfek6YzEserC1lIquLvbbUXKuLsdPDjLJ I+6sYA7mXRSUMWHRWteSqVXdvjuuMh31sMXilnNW3BEA1OZOxhTYL7CzTEtKoj9F8/sZ izzQ== X-Gm-Message-State: AODbwcC6olCuV2rfoRUHNQntUfWF2JQGjTpjUEMyAUFKhAbDUHDsnXI6 Tc87t2/7H+XpxPb8R3JPxNXiJAAWn+Ej X-Received: by 10.129.104.69 with SMTP id d66mr18050388ywc.74.1496197077329; Tue, 30 May 2017 19:17:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Tue, 30 May 2017 19:17:16 -0700 (PDT) In-Reply-To: <2be0192e-2edd-a192-26d2-2a755784dfe5@gmail.com> References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <2be0192e-2edd-a192-26d2-2a755784dfe5@gmail.com> From: Eric Rescorla Date: Tue, 30 May 2017 19:17:16 -0700 Message-ID: To: Brian E Carpenter Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, Anima WG Content-Type: multipart/alternative; boundary="001a11490b9a4efecf0550c887b5" Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 02:18:00 -0000 --001a11490b9a4efecf0550c887b5 Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 6:32 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Now getting to Eric's COMMENTs: > > On 25/05/2017 14:32, Eric Rescorla wrote: > ... > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > > S 3.5.4.3. > > After a GRASP device successfully discovers a locator for a > > Discovery > > Responder supporting a specific objective, it MUST cache this > > information, including the interface index via which it was > > discovered. This cache record MAY be used for future negotiation or > > synchronization, and the locator SHOULD be passed on when > > appropriate > > as a Divert option to another Discovery Initiator. > > > > What's an "interface index" > > It's a term of art in the socket API: > https://tools.ietf.org/html/rfc3493#section-4 > Does it need a reference? > Yes. > > S 3.7. > > You seem to be going to a lot of trouble to deal wit session > > ID collisions. Why don't you just make session IDs 128-bit > > random values and then you won't have to worry about > > collisions. > > Well, yes, the odds would be better with 128 than 32 but > that's extra bits on the wire and there'd still be the > birthday paradox... Why is this amount of extra bits on the wire significant? As far as birthday paradox, I suspect this protocol is going to break down well before 2^32 endpoints, let alone 2^64. > The Session ID SHOULD have a very low collision rate locally. It > > MUST be generated by a pseudo-random algorithm using a locally > > generated seed which is unlikely to be used by any other device in > > the same network [RFC4086]. > > > > Why don't you just require a cryptographically secure PRNG? > > That will be required to implement the rest of this protocol > > Well, certainly there will be for the security bootstrap > and the ACP. Is there a different reference for that? > I'm not understanding the question here. You basically can't build any cryptographic system without a secure PRNG (in the worst case, if you have a private key you can use that to seed the PRNG). > S 3.8.6. > > If a node receives a Request message for an objective for which no > > ASA is currently listening, it MUST immediately close the relevant > > socket to indicate this to the initiator. This is to avoid > > unnecessary timeouts if, for example, an ASA exits prematurely but > > the GRASP core is listening on its behalf. > > > > This is not secure. You need a secure indication of non-knowledge, > > not a transport-level close. > > I don't see this as a security issue. There would be an alternative, > which is to send back an immediate M_DECLINE, but that is quite > a bit harder to implement and I don't really see an advantage: > the requester will just get back an error code in either case. > An ASA must always be ready for an error return. > If the attacker can force an error when the other side didn't want one then that implicates the security of the system. > > S 3.9.5.4. > > What are the semantics of a Divert URI? What do I dow ith the > > path part? > > Two things on this: > Following Alexy's comment, we are likely to add protocol/port > to this type of locator option. Given that, is there anything special > about the Divert case? A URI should be valid however you receive it. > Again, what do you do with the path section of the URI? > > S 3.10.4. > > The semantics of "dry run" seem pretty unclear. Is it just > > "tell me if you would be sad about doing this"? > > This is explained better in an earlier section: > https://tools.ietf.org/html/draft-ietf-anima-grasp-12#section-3.5.5 This just seems to say "it's up to the ASA" -Ekr > > > We will try to clarify this, at least with a cross-reference. > > Thanks, > Brian > --001a11490b9a4efecf0550c887b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 30, 2017 at 6:32 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
Now getting to Eric's COMMENTs:

On 25/05/2017 14:32, Eric Rescorla wrote:
...
> -----------------------------------------= -----------------------------
> COMMENT:
> ------------------------------------------------------------= ----------
>
>
> S 3.5.4.3.
>=C2=A0 =C2=A0 After a GRASP device successfully discovers a locator for= a
> Discovery
>=C2=A0 =C2=A0 Responder supporting a specific objective, it MUST cache = this
>=C2=A0 =C2=A0 information, including the interface index via which it w= as
>=C2=A0 =C2=A0 discovered.=C2=A0 This cache record MAY be used for futur= e negotiation or
>=C2=A0 =C2=A0 synchronization, and the locator SHOULD be passed on when=
> appropriate
>=C2=A0 =C2=A0 as a Divert option to another Discovery Initiator.
>
> What's an "interface index"

It's a term of art in the socket API:
https://tools.ietf.org/html/rfc3493#section-4<= br> Does it need a reference?

Yes.
=C2=A0
> S 3.7. > You seem to be going to a lot of trouble to deal wit session
> ID collisions. Why don't you just make session IDs 128-bit
> random values and then you won't have to worry about
> collisions.

Well, yes, the odds would be better with 128 than 32 but
that's extra bits on the wire and there'd still be the
birthday paradox...

Why is this amount of e= xtra bits on the wire significant?

As far as birth= day paradox, I suspect this protocol is going to
break down well = before 2^32 endpoints, let alone 2^64.


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> >=C2=A0 =C2=A0The Session ID SHOULD have a very low collision rate local= ly.=C2=A0 It
>=C2=A0 =C2=A0 MUST be generated by a pseudo-random algorithm using a lo= cally
>=C2=A0 =C2=A0 generated seed which is unlikely to be used by any other = device in
>=C2=A0 =C2=A0 the same network [RFC4086].
>
> Why don't you just require a cryptographically secure PRNG?
> That will be required to implement the rest of this protocol

Well, certainly there will be for the security bootstrap
and the ACP. Is there a different reference for that?
=
I'm not understanding the question here. You basically c= an't build any
cryptographic system without a secure PRNG (in= the worst case, if you
have a private key you can use that to se= ed the PRNG).

=C2=A0

> S 3.8.6.
>=C2=A0 =C2=A0 If a node receives a Request message for an objective for= which no
>=C2=A0 =C2=A0 ASA is currently listening, it MUST immediately close the= relevant
>=C2=A0 =C2=A0 socket to indicate this to the initiator.=C2=A0 This is t= o avoid
>=C2=A0 =C2=A0 unnecessary timeouts if, for example, an ASA exits premat= urely but
>=C2=A0 =C2=A0 the GRASP core is listening on its behalf.
>
> This is not secure. You need a secure indication of non-knowledge,
> not a transport-level close.

I don't see this as a security issue. There would be an alternat= ive,
which is to send back an immediate M_DECLINE, but that is quite
a bit harder to implement and I don't really see an advantage:
the requester will just get back an error code in either case.
An ASA must always be ready for an error return.

<= /div>
If the attacker can force an error when the other side didn't= want one then
that implicates the security of the system.
<= div>
=C2=A0
> S 3.9.5.4.
> What are the semantics of a Divert URI? What do I dow ith the
> path part?

Two things on this:
Following Alexy's comment, we are likely to add protocol/port
to this type of locator option. Given that, is there anything special
about the Divert case? A URI should be valid however you receive it.

Again, what do you do with the path section o= f the URI?


> S 3.10.4.
> The semantics of "dry run" seem pretty unclear. Is it just > "tell me if you would be sad about doing this"?

This is explained better in an earlier section:
https://tools.ietf.org/html/= draft-ietf-anima-grasp-12#section-3.5.5

This just seems to say "it's up to the ASA"
<= br>
-Ekr
=C2=A0

We will try to clarify this, at least with a cross-reference.

Thanks,
=C2=A0 =C2=A0 =C2=A0Brian

--001a11490b9a4efecf0550c887b5-- From nobody Tue May 30 23:56:24 2017 Return-Path: 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 97C7E12EA42 for ; Tue, 30 May 2017 23:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 28Jy2jr9sS9o for ; Tue, 30 May 2017 23:56:20 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 1FCB612E870 for ; Tue, 30 May 2017 23:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v4V6uHCS020082; Wed, 31 May 2017 08:56:17 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wd1Tr6GCwzDHnT; Wed, 31 May 2017 08:56:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <25240.1496177632@obiwan.sandelman.ca> Date: Wed, 31 May 2017 08:56:16 +0200 Cc: anima@ietf.org X-Mao-Original-Outgoing-Id: 517906576.309438-ce423633e59c39664bf7e3475550f9b0 Content-Transfer-Encoding: quoted-printable Message-Id: <9C702B81-E02E-4341-BF0B-BE3FEBBFFE49@tzi.org> References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <1a4b149e-25f0-d4d8-1e31-4d497703129d@gmail.com> <25240.1496177632@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Anima] Need WG input: Adam Roach's comment on GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 06:56:23 -0000 Ah. 3.9.5.1 currently does not have a =E2=80=9C.within=E2=80=9D clause = giving an expectation as to how the type "transport-proto=E2=80=9D is = going to grow as the protocol evolves. Foolishly, my brain inserted = =E2=80=9Cuint=E2=80=9D as the most obvious envelope type. Allowing negative values for transport-proto certainly would be = possible. As a design pattern, I try to reserve broad ranges like this for the = indication of differences that a receiver can act upon without = understanding the details, such as the difference between base = attributes and other attributes in SenML. So I still would favor sticking with uint for now and carving out a = range of that for experimental. Gr=C3=BC=C3=9Fe, Carsten > On May 30, 2017, at 22:53, Michael Richardson = wrote: >=20 >=20 > Carsten Bormann wrote: >> If we ever add not-over-IP =E2=80=9Ctransports=E2=80=9D, there might = be a need for >> experiments before we go registering. So I would probably identify a >> range of numbers that are strictly reserved for use in experiments. >> (This needn=E2=80=99t be very small; say, 65280 to 65535.) >=20 > -1 to -32! >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed May 31 06:00:33 2017 Return-Path: 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 6B35C127275 for ; Wed, 31 May 2017 06:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 uCBZLinHMN0x for ; Wed, 31 May 2017 06:00:30 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 3CDCA128D2E for ; Wed, 31 May 2017 06:00:29 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id p73so6100210ywp.0 for ; Wed, 31 May 2017 06:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gST5uAUgGYderRr5F/2JmupxxmrEDE6JKw7QeHa+kK0=; b=a3+g8aNCV55T9n0g7zamYyX4cVUdKo8MlT/FDFf+b4Kasi1YQrmILSH8vALdBTWAYO RMcO1EhUDqtDF+zpIfaokiypdEO9GmOwz/tQIyxAVcmGFGSzrM1ndr31c+2T9Q+NjIcG 7TtjsdDXyjPzO2S76SMxJp0yJMOCEpdnDL/EK6cY2mWzH6Y/lxw2JjdrRuHT1Taagqfx 8YEYFJPT+msx7nFl0GOeeohdeyu/bjsg5doYeu9gAf87MH3KOz352egA7QFeDTW0uhyT 8N9vBDMtB5nBee63e5BgkVhRviJfQ7h2DMGHbuBK7t9ADte/11/zozG5xpmdgsM4KMCt B7Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gST5uAUgGYderRr5F/2JmupxxmrEDE6JKw7QeHa+kK0=; b=aU79JnPfY+2yNb1Iox5IQSgwbi5sc2KJnWkyB0nfy8uxf345JMxO9DXoPcQcEwO1ud dF8aSC5r580QdODzZ+5P3GoeuAypav/ruk3uC5WBJa4V3eEDt5vM9gL/WipX9f3acgrd F2SWPtqig1ICDYZPwlce6uff7ZsjSyTZJSUFSaoCOKs0YNC5mXfz/vaj7S+4KeF6gIsK 5l3y70ukQj+7z25N+01TrNS6AWSJwDpQ7agSnw6YgAwn7aRArPZWoSWgh9w+1iwf+23K bX9k23wXQQZbnDtMBeDztZex3JXPVoBKfB5+gIBhIMCNXe7VUXc6Of9kdmCwvHzfeuc9 qM0Q== X-Gm-Message-State: AODbwcBFrSCrG/PyeQT+zv721Zz0Ax7DNhXCcEWFPHKltCtnJWumZzDw Yxk/4k+qJZT0WQP0hAp918+RXC5wx4r0 X-Received: by 10.129.57.138 with SMTP id g132mr19142050ywa.312.1496235627958; Wed, 31 May 2017 06:00:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Wed, 31 May 2017 05:59:47 -0700 (PDT) In-Reply-To: References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> <93bd9175-77c7-e588-93f9-49a09e12cd66@gmail.com> From: Eric Rescorla Date: Wed, 31 May 2017 05:59:47 -0700 Message-ID: To: Brian E Carpenter Cc: Toerless Eckert , The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , Anima WG Content-Type: multipart/alternative; boundary="001a114c76b41b02ea0550d181db" Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 13:00:31 -0000 --001a114c76b41b02ea0550d181db Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 6:59 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 31/05/2017 11:30, Eric Rescorla wrote: > > On Tue, May 30, 2017 at 4:19 PM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> On some other points that are dangling after previous messages: > >> > >> On 31/05/2017 00:29, Eric Rescorla wrote: > >>> On Mon, May 29, 2017 at 10:14 PM, Brian E Carpenter < > >>> brian.e.carpenter@gmail.com> wrote: > >>> > >>>> Eric, > >>>> > >>>> On 25/05/2017 14:32, Eric Rescorla wrote: > >>>> ... > >>>>> ------------------------------------------------------------ > ---------- > >>>>> DISCUSS: > >>>>> ------------------------------------------------------------ > ---------- > >> ... > >>>> Finally, I don't > >>>>> understand the security story for the multicast packets. > >>>> > >>>> I think I already typed this a day or two ago, but with an ACP, > >>>> they are secured, because the ACP is a secure virtual overlay > >>>> network. > >>>> > >>> > >>> This document then needs to state which precise properties of > >>> ACP it is relying on for that. A brief skim of ACP suggests that > >>> it relies on other protocols for its actual transport security and > >>> at least some of those protocols (e.g., DTLS) do not support > >>> multicast. > >> > >> Indeed, but as I understand it they will emulate link-local multicast > >> over the secured connections. > > > > > > It's not clear to me what that means. You perhaps expect to tie up > > a connection to every counterparty in the network? > > That is exactly what the ACP does, as I understand it. That's not what I got from 5.4.3, which says: GRASP discovery and flooding messages are designed for use over link- local multicast UDP. They MUST NOT be fragmented, and therefore MUST NOT exceed the link MTU size. Perhaps a ladder diagram of how this works would help, both here and in the document. >>> That is the trust model, but really as an explanatory matter I think > >>>> it belongs in draft-ietf-anima-reference-model rather than here. > >>>> I will add a few words in the High Level Deployment Model > >>>> section and/or the Security Considerations. > >>>> > >>>> What we do say already is that authorization of ASAs is out of scope. > >>>> I am certain that it needs to be tackled, but not here. > >>>> > >>> > >>> I don't see how you have a complete protocol without that. > >> > >> The starting position is that we trust all autonomic nodes and therefore > >> the ASAs installed in them. We are in the context of a single operator > > > > so this isn't really a stretch. > > > > > > I certainly can see how someone might decide to deploy a system like > > this, but it seems pretty problematic to have a system that is so brittle > > to single-point compromise (The term of art here is "distributed single > > point of failure") > > > > > >> The questions around life cycle > >> management of ASAs, which would certainly involve authorization, > >> were intentionally not in the initial WG charter. I think it's true > >> that you can't have a complete *system* without that, but I disagree > >> that it's a requirement for the protocol. > >> > > > > At minimum you need to specify that this is your trust model and > > then work through the implications of compromise of some subset > > of nodes, as well as of an attacker who can influence which nodes > > you talk to. > > That really, really belongs in the reference model or the ACP draft; > it's in no way specific to GRASP, because nodes could use any protocol > they please over the ACP. > It's a WG decision which document it goes in, but it's something that needs to exist, because otherwise it is not possible to assess the security of this document. -Ekr > Brian > --001a114c76b41b02ea0550d181db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 30, 2017 at 6:59 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
On = 31/05/2017 11:30, Eric Rescorla wrote:
> On Tue, May 30, 2017 at 4:19 PM, Brian E Carpenter <
> brian.e.carpenter@gmail= .com> wrote:
>
>> On some other points that are dangling after previous messages: >>
>> On 31/05/2017 00:29, Eric Rescorla wrote:
>>> On Mon, May 29, 2017 at 10:14 PM, Brian E Carpenter <
>>> brian.e.carpent= er@gmail.com> wrote:
>>>
>>>> Eric,
>>>>
>>>> On 25/05/2017 14:32, Eric Rescorla wrote:
>>>> ...
>>>>> -------------------------------------------------= ---------------------
>>>>> DISCUSS:
>>>>> -------------------------------------------------= ---------------------
>> ...
>>>> Finally, I don't
>>>>> understand the security story for the multicast packet= s.
>>>>
>>>> I think I already typed this a day or two ago, but with an= ACP,
>>>> they are secured, because the ACP is a secure virtual over= lay
>>>> network.
>>>>
>>>
>>> This document then needs to state which precise properties of<= br> >>> ACP it is relying on for that. A brief skim of ACP suggests th= at
>>> it relies on other protocols for its actual transport security= and
>>> at least some of those protocols (e.g., DTLS) do not support >>> multicast.
>>
>> Indeed, but as I understand it they will emulate link-local multic= ast
>> over the secured connections.
>
>
> It's not clear to me what that means. You perhaps expect to tie up=
> a connection to every counterparty in the network?

That is exactly what the ACP does, as I understand it.

That's not what I got from 5.4.3, which says:

=C2=A0 =C2=A0GRASP discovery and flooding messages = are designed for use over link-
=C2=A0 =C2=A0local multicast UDP.= =C2=A0 They MUST NOT be fragmented, and therefore MUST
=C2=A0 =C2= =A0NOT exceed the link MTU size.


Perhaps a ladder diagram of how this works would help, both he= re
and in the document.

>>> That is th= e trust model, but really as an explanatory matter I think
>>>> it belongs in draft-ietf-anima-reference-model rather= than here.
>>>> I will add a few words in the High Level Deployment Model<= br> >>>> section and/or the Security Considerations.
>>>>
>>>> What we do say already is that authorization of ASAs is ou= t of scope.
>>>> I am certain that it needs to be tackled, but not here. >>>>
>>>
>>> I don't see how you have a complete protocol without that.=
>>
>> The starting position is that we trust all autonomic nodes and the= refore
>> the ASAs installed in them. We are in the context of a single oper= ator
>
> so this isn't really a stretch.
>
>
> I certainly can see how someone might decide to deploy a system like > this, but it seems pretty problematic to have a system that is so brit= tle
> to single-point compromise (The term of art here is "distributed = single
> point of failure")
>
>
>> The questions around life cycle
>> management of ASAs, which would certainly involve authorization, >> were intentionally not in the initial WG charter. I think it's= true
>> that you can't have a complete *system* without that, but I di= sagree
>> that it's a requirement for the protocol.
>>
>
> At minimum you need to specify that this is your trust model and
> then work through the implications of compromise of some subset
> of nodes, as well as of an attacker who can influence which nodes
> you talk to.

That really, really belongs in the reference model or the ACP draft;=
it's in no way specific to GRASP, because nodes could use any protocol<= br> they please over the ACP.

It's a WG= decision which document it goes in, but it's something
that = needs to exist, because otherwise it is not possible to assess the
security of this document.

-Ekr


=C2=A0 =C2=A0 Brian

--001a114c76b41b02ea0550d181db-- From nobody Wed May 31 13:37:06 2017 Return-Path: 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 BAC94129BA2; Wed, 31 May 2017 13:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62k1EOp_a1eG; Wed, 31 May 2017 13:37:02 -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 00F2E129B9B; Wed, 31 May 2017 13:37:01 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4VKasP1019334 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 31 May 2017 15:36:54 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <5905c0d9-f664-1207-aa28-d4d45d5d8528@gmail.com> Date: Wed, 31 May 2017 15:36:53 -0500 Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1D91D354-0A23-471F-A854-7256D8D2BA52@nostrum.com> References: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> <5905c0d9-f664-1207-aa28-d4d45d5d8528@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 20:37:04 -0000 Hi, thanks for the responses. Further comments below. I deleted = sections that seem resolved. Thanks! Ben. > On May 28, 2017, at 11:16 PM, Brian E Carpenter = wrote: >=20 > Comments on some more of Ben's comments: >=20 > On 23/05/2017 13:25, Ben Campbell wrote: >>=20 [=E2=80=A6] >> -5, Privacy and Confidentiality: Did people consider IP Addresses and >> other potentially persistent identifiers as impacting privacy? >=20 > Here we are dealing with the addresses of network elements, not user > devices, so there don't seem to to be personal privacy issues. >=20 Did I miss something that indicated that these network elements = can=E2=80=99t/won=E2=80=99t ever be end-user devices? Now, I don=E2=80=99t necessarily think that would change the privacy = considerations=E2=80=94I was mainly questioning the assertion the =E2=80=9C= no personal information=E2=80=9D assertion. >> -7, Grasp Message and Options table: Why "Standards Action"? Would = you >> expect some harm to be done if this were only Spec Required? >=20 > I have asked the WG's opinion. Okay, I will follow that separately. >=20 >> Editorial: >>=20 >> - Is section 2 expected to be useful to implementers once this is >> published as an RFC? Unless there's a reason otherwise, I would = suggest >> moving this to an appendix, or even removing it entirely. As it is, = you >> have to wade through an unusual amount of front material before you = get >> to the meat of the protocol. >=20 > I have asked the WG's opinion. Okay. >=20 >> - Along the lines of the previous comment, I found the organization a = bit >> hard to follow. I didn't find actual protocol details until around = page >> 21. Procedures are split (and sometimes repeated) between the = procedure >> sections and the message format sections. I think that will make this >> more difficult and error prone than necessary for implementors to = read >> and reference. I fear readers will read one section and think they >> understand the procedures, and miss a requirement in the other. >=20 > I understand the problem but I don't have a solution; there is an = attempt > to give an overview before getting into message formats, but that = leads > to some repetition as well. On reflection, it=E2=80=99s probably not worth trying to reorganize = things this late in the process. Other reviewers seem to have followed = things just fine, so maybe it=E2=80=99s me :-) [=E2=80=A6]= From nobody Wed May 31 13:39:49 2017 Return-Path: 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 919F8129B9B; Wed, 31 May 2017 13:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxN3JrzBDmbf; Wed, 31 May 2017 13:39:46 -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 6E89C1241FC; Wed, 31 May 2017 13:39:46 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4VKdMas019560 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 31 May 2017 15:39:22 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <19f8e94f-fe08-f1e8-53f5-6852953690e3@gmail.com> Date: Wed, 31 May 2017 15:39:22 -0500 Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> <19f8e94f-fe08-f1e8-53f5-6852953690e3@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Anima] WG input needed: Ben Campbell's question on GRASP (2) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 20:39:48 -0000 > On May 28, 2017, at 11:02 PM, Brian E Carpenter = wrote: >=20 > On 23/05/2017 13:25, Ben Campbell wrote: > ... >> - Is section 2 [Requirements] expected to be useful to implementers = once this is> published as an RFC? Unless there's a reason otherwise, I = would suggest >> moving this to an appendix, or even removing it entirely. As it is, = you >> have to wade through an unusual amount of front material before you = get >> to the meat of the protocol. >=20 > I'm open to that, and you are not the only reader with that comment. > But we'd need WG consent=E2=80=A6 Understood. I=E2=80=99m not going to stand in the way if the WG wants to = keep things as is. But I do think that moving/removing the section would = make the document more friendly to it=E2=80=99s post-publication target = audience. Thanks! Ben.= From nobody Wed May 31 13:55:25 2017 Return-Path: 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 8D819129BA2; Wed, 31 May 2017 13:55:17 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2CovFSS5Ull; Wed, 31 May 2017 13:55:15 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 5FF30124B0A; Wed, 31 May 2017 13:55:15 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id w69so4171659pfk.1; Wed, 31 May 2017 13:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lFIeeqTok/8OHf6b8+HWFzfxqqyZ2XX/usowHo48dr8=; b=uqTjhFGbl6+3a1yCCVdN2C1ZgMvTkl5hmVTYoBHNxUA9LKuOX/jbx78JSNj4iTdtpM m8wgV031qhLh1F4wHWihmu/UtaRbEI9gJjQWHT77LiODBIxjjoTlE0GC67qD4Lvjpvd4 ADqUwr4v4QAPO86IAbiOZKvJc6w5h1IRgUFKyIoGdi3YJ6MSOUwe8zqWAEvss5Zv67yt kFl6+GQlIyn8Y3n/F4X0vUGNz4kCgGmtR2dOUIxJ3UGpLKwy1egybVofkTDhcT2wUfrh yxzkW5hlvluEriq7rFn6Hn2XiNYDCFsL/okyG+Dy2GATGWQj488sPVmkuo5L916bmsUF AOTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=lFIeeqTok/8OHf6b8+HWFzfxqqyZ2XX/usowHo48dr8=; b=FzEIBm6a3RW8Y0oNvKMwINlLUKo2oIyVaiMFyRVt93VN5WblPWjoIz/3uPFG+x6fuV +AFPHtXdVMrhrW7k9F/wI9pW5N8ELse+zSv/exN7fd+B2lJZzoByFMVKfW7F2FyNGEO4 HvqRwFBUFlfXRStFUeHeSOsMDXxx1R2R4GLGaVYdaKILQreuHgus+dO5upOtPa5vtRC3 Abu0coa8wmgxTVCdP82RuPxrypgDjVgE2O0jUvzRm9xtRoe4oFFE7UGv3iO9Rw/peL8+ +F8m6056DEAAuFOet9BzH/R8m7saBcQYoN7nIuAHg4g7ZT0Y2rmHs0D7bPo+mY8JTzGL K6UA== X-Gm-Message-State: AODbwcDUhc+l2C+I8UDakrI4k0IcCAqci0bUzCbCdl1STROdJtkGsd9s yTuuE38P5RZrRMiN X-Received: by 10.99.149.14 with SMTP id p14mr29747603pgd.148.1496264114456; Wed, 31 May 2017 13:55:14 -0700 (PDT) Received: from ?IPv6:2406:e001:5618:1:28cc:dc4c:9703:6781? ([2406:e001:5618:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a87sm34402597pfj.50.2017.05.31.13.55.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 13:55:13 -0700 (PDT) To: Eric Rescorla Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, Anima WG References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <2be0192e-2edd-a192-26d2-2a755784dfe5@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <604b04b5-9e6d-c740-4805-ea0674cd640a@gmail.com> Date: Thu, 1 Jun 2017 08:55:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 20:55:18 -0000 On 31/05/2017 14:17, Eric Rescorla wrote: > On Tue, May 30, 2017 at 6:32 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Now getting to Eric's COMMENTs: >> >> On 25/05/2017 14:32, Eric Rescorla wrote: >> ... >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> S 3.5.4.3. >>> After a GRASP device successfully discovers a locator for a >>> Discovery >>> Responder supporting a specific objective, it MUST cache this >>> information, including the interface index via which it was >>> discovered. This cache record MAY be used for future negotiation or >>> synchronization, and the locator SHOULD be passed on when >>> appropriate >>> as a Divert option to another Discovery Initiator. >>> >>> What's an "interface index" >> >> It's a term of art in the socket API: >> https://tools.ietf.org/html/rfc3493#section-4 >> Does it need a reference? >> > > Yes. Will fix. > >>> S 3.7. >>> You seem to be going to a lot of trouble to deal wit session >>> ID collisions. Why don't you just make session IDs 128-bit >>> random values and then you won't have to worry about >>> collisions. >> >> Well, yes, the odds would be better with 128 than 32 but >> that's extra bits on the wire and there'd still be the >> birthday paradox... > > > Why is this amount of extra bits on the wire significant? We do have people in Anima who care about every extra byte, in case this stuff does end up in constrained devices. > As far as birthday paradox, I suspect this protocol is going to > break down well before 2^32 endpoints, let alone 2^64. Of course, but it's the number of overlapping sessions that would be relevant for the birthday paradox. However, my point is that regardless of the odds, the implementer needs to check for a collision; that's just correct programming. >> The Session ID SHOULD have a very low collision rate locally. It >>> MUST be generated by a pseudo-random algorithm using a locally >>> generated seed which is unlikely to be used by any other device in >>> the same network [RFC4086]. >>> >>> Why don't you just require a cryptographically secure PRNG? >>> That will be required to implement the rest of this protocol >> >> Well, certainly there will be for the security bootstrap >> and the ACP. Is there a different reference for that? >> > > I'm not understanding the question here. You basically can't build any > cryptographic system without a secure PRNG (in the worst case, if you > have a private key you can use that to seed the PRNG). Sure. I just meant is that covered by RFC4086? Now I have to go look... yes, I guess it is. OK, will fix. > > > >> S 3.8.6. >>> If a node receives a Request message for an objective for which no >>> ASA is currently listening, it MUST immediately close the relevant >>> socket to indicate this to the initiator. This is to avoid >>> unnecessary timeouts if, for example, an ASA exits prematurely but >>> the GRASP core is listening on its behalf. >>> >>> This is not secure. You need a secure indication of non-knowledge, >>> not a transport-level close. >> >> I don't see this as a security issue. There would be an alternative, >> which is to send back an immediate M_DECLINE, but that is quite >> a bit harder to implement and I don't really see an advantage: >> the requester will just get back an error code in either case. >> An ASA must always be ready for an error return. >> > > If the attacker can force an error when the other side didn't want one then > that implicates the security of the system. True, but I don't think your suggestion helps. Let me explain: Suppose that we add a new use of the M_DECLINE message for this case. Then the ASA which is currently not accepting Request messages will send an M_DECLINE followed by a TCP FIN. The initiator receives an M_DECLINE, closes its socket and returns an error code to the API. If it receives an unexpected FIN (or RST) it closes its socket and returns an error code to the API anyway. It has to; there's nothing else it can do. As far as the ASA involved is concerned, it's a failure in any case. If it's an attacker, or some other random event, that causes the failure, it really looks no different than a failure caused by the remote ASA. (OK, one possible difference: the error code in the API might be 18 #"Socket error sending negotiation request" instead of 23 #"Negotiation peer not listening", depending on the exact timing.) But this doesn't affect what the ASA does in any way: it shrugs its shoulders, probably waits for a few seconds, and tries again. Inserting the M_DECLINE really makes no difference. >>> S 3.9.5.4. >>> What are the semantics of a Divert URI? What do I dow ith the >>> path part? >> >> Two things on this: >> Following Alexy's comment, we are likely to add protocol/port >> to this type of locator option. Given that, is there anything special >> about the Divert case? A URI should be valid however you receive it. >> > > Again, what do you do with the path section of the URI? Note 2: Normal GRASP operations are not expected to use this option. It is intended for special purposes such as discovering external services. Therefore its use is not further described in this specification. GRASP is just the carrier so is completely agnostic about your question. >>> S 3.10.4. >>> The semantics of "dry run" seem pretty unclear. Is it just >>> "tell me if you would be sad about doing this"? >> >> This is explained better in an earlier section: >> https://tools.ietf.org/html/draft-ietf-anima-grasp-12#section-3.5.5 > > > This just seems to say "it's up to the ASA" Yes. FYI, draft-carpenter-anima-asa-guidelines, "Guidelines for Autonomic Service Agents" will hopefully be filling in a number of gaps in future. (I think one the issues here is that GRASP is just part of a complete system, which happens to have reached the IESG first.) Rgds Brian >> >> We will try to clarify this, at least with a cross-reference. >> >> Thanks, >> Brian >> > From nobody Wed May 31 14:09:53 2017 Return-Path: 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 B0D74129BB2 for ; Wed, 31 May 2017 14:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 H22VXFPzley0 for ; Wed, 31 May 2017 14:09:48 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 B116A129B9A for ; Wed, 31 May 2017 14:09:48 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id p73so12151789ywp.0 for ; Wed, 31 May 2017 14:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Djeqzr+z5juIwgOP4upvP25eDnviIYHr2b6N4OSgaow=; b=qZWoZt/53+vJIqPrlXztKNKEbHYPnVRN3WaJc4m4vs/mMal1hrUoHWJl8Hcav9h3Pl nON+DfsMwaIHlZGg2aSwp7JtK+RxlK5+5BsckwLbfzDos5+/AMnCziZKwlOLpHRdGeF0 rk246lvnBhENBuGOQAYmMDAgU0vnocjLq1sl5lZectRAXV/8m27pu3/tkYnBAoO8uVFr 8LpCb5eGf+IPbgk5b85fCsFQmpoOvAS2HdbY0J/lKA+cAfo5ZKc/lvmFRbL4jn7gN/c2 /eRufFy6raLtEAwLxS9oX1cnuk7nxbBS4+ikQRfOE66So7e+57eXgPo8+O/Ngk7hMPze aJ+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Djeqzr+z5juIwgOP4upvP25eDnviIYHr2b6N4OSgaow=; b=C6rUWiKfB14R6wWMxQzu9CGCMeugNaQhNxzcW1Njgnwo6z+NyLgB237HKUJdjJQMZL IT4k9Zgx6RtsGMMTmiSromvQJOzlvqjPaYPVbQWNAa2VI+S2nD6wmFxA6s2euEne1rp3 S5jzE1FOl5aWEilppAFbNtI42k6t9dLq5xoNiqC5HWdh4BHrlsnYTPXfCe/XHbEmCws8 HyM1FrcgkvuYwDi9pBtialQbKrFNGQAqxhR7WbOxEDY3xzu9vmzCLxn7ukzU9jJhjNhJ 40/jRGLX8ZcYguYQ9fA0wwP9Ur8NXaIumSg8oNnOuvg4bgCE4REzVh2++yfyCptCQqaa egWQ== X-Gm-Message-State: AODbwcDXcoexYSf4I6r4yq3wGdLX1/ZYo5f2AeZRXOB2JY3FWfnbTTuP dpLgPRklk6pYoQKIp4+0rrhHgdVwcsr3 X-Received: by 10.129.104.69 with SMTP id d66mr21403133ywc.74.1496264987969; Wed, 31 May 2017 14:09:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Wed, 31 May 2017 14:09:07 -0700 (PDT) In-Reply-To: <604b04b5-9e6d-c740-4805-ea0674cd640a@gmail.com> References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <2be0192e-2edd-a192-26d2-2a755784dfe5@gmail.com> <604b04b5-9e6d-c740-4805-ea0674cd640a@gmail.com> From: Eric Rescorla Date: Wed, 31 May 2017 14:09:07 -0700 Message-ID: To: Brian E Carpenter Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, Anima WG Content-Type: multipart/alternative; boundary="001a11490b9a199b130550d857ee" Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 21:09:51 -0000 --001a11490b9a199b130550d857ee Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 1:55 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 31/05/2017 14:17, Eric Rescorla wrote: > > On Tue, May 30, 2017 at 6:32 PM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> Now getting to Eric's COMMENTs: > >> > >> On 25/05/2017 14:32, Eric Rescorla wrote: > >> ... > >>> ---------------------------------------------------------------------- > >>> COMMENT: > >>> ---------------------------------------------------------------------- > >>> > >>> > >>> S 3.5.4.3. > >>> After a GRASP device successfully discovers a locator for a > >>> Discovery > >>> Responder supporting a specific objective, it MUST cache this > >>> information, including the interface index via which it was > >>> discovered. This cache record MAY be used for future negotiation or > >>> synchronization, and the locator SHOULD be passed on when > >>> appropriate > >>> as a Divert option to another Discovery Initiator. > >>> > >>> What's an "interface index" > >> > >> It's a term of art in the socket API: > >> https://tools.ietf.org/html/rfc3493#section-4 > >> Does it need a reference? > >> > > > > Yes. > > Will fix. > > > > >>> S 3.7. > >>> You seem to be going to a lot of trouble to deal wit session > >>> ID collisions. Why don't you just make session IDs 128-bit > >>> random values and then you won't have to worry about > >>> collisions. > >> > >> Well, yes, the odds would be better with 128 than 32 but > >> that's extra bits on the wire and there'd still be the > >> birthday paradox... > > > > > > Why is this amount of extra bits on the wire significant? > > We do have people in Anima who care about every extra byte, in > case this stuff does end up in constrained devices. > Yeah, I hear this stuff a lot, but I'd want to see some real analysis of whether this is an issue. > As far as birthday paradox, I suspect this protocol is going to > > break down well before 2^32 endpoints, let alone 2^64. > > Of course, but it's the number of overlapping sessions that would > be relevant for the birthday paradox. You think you're going to have anywhere near 2^64 sessions? > However, my point is that regardless of the odds, the implementer needs to check for a collision; > that's just correct programming. > No, I don't agree with this. Once collisions are sufficiently statistically unlikely, you can assume they will not happen. Note that we routinely assume this in situations where the results of collisions are far more severe (e.g., generating cryptographic keys). > > >> S 3.8.6. > >>> If a node receives a Request message for an objective for which no > >>> ASA is currently listening, it MUST immediately close the relevant > >>> socket to indicate this to the initiator. This is to avoid > >>> unnecessary timeouts if, for example, an ASA exits prematurely but > >>> the GRASP core is listening on its behalf. > >>> > >>> This is not secure. You need a secure indication of non-knowledge, > >>> not a transport-level close. > >> > >> I don't see this as a security issue. There would be an alternative, > >> which is to send back an immediate M_DECLINE, but that is quite > >> a bit harder to implement and I don't really see an advantage: > >> the requester will just get back an error code in either case. > >> An ASA must always be ready for an error return. > >> > > > > If the attacker can force an error when the other side didn't want one > then > > that implicates the security of the system. > > True, but I don't think your suggestion helps. Let me explain: > > Suppose that we add a new use of the M_DECLINE message for this case. > Then the ASA which is currently not accepting Request messages will > send an M_DECLINE followed by a TCP FIN. The initiator receives > an M_DECLINE, closes its socket and returns an error code to the API. > > If it receives an unexpected FIN (or RST) it closes its socket and returns > an error code to the API anyway. It has to; there's nothing else it can > do. As far as the ASA involved is concerned, it's a failure in any case. > Not necessarily. You might, for instance, log an error and do something when you believe that your network is under attack/broken. > >>> S 3.9.5.4. > >>> What are the semantics of a Divert URI? What do I dow ith the > >>> path part? > >> > >> Two things on this: > >> Following Alexy's comment, we are likely to add protocol/port > >> to this type of locator option. Given that, is there anything special > >> about the Divert case? A URI should be valid however you receive it. > >> > > > > Again, what do you do with the path section of the URI? > > Note 2: Normal GRASP operations are not expected to use this option. > It is intended for special purposes such as discovering external > services. Therefore its use is not further described in this > specification. > > GRASP is just the carrier so is completely agnostic about your > question. > Yeah, I'm not generally a big fan of "here is some placeholder we have no idea what we're going to do with" -Ekr > >> > >> We will try to clarify this, at least with a cross-reference. > >> > >> Thanks, > >> Brian > >> > > > --001a11490b9a199b130550d857ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 31, 2017 at 1:55 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
On 31/05/2017 14:17, Eric Rescorla wrote:
> On Tue, May 30, 2017 at 6:32 PM, Brian E Carpenter <
> brian.e.carpenter@gmail= .com> wrote:
>
>> Now getting to Eric's COMMENTs:
>>
>> On 25/05/2017 14:32, Eric Rescorla wrote:
>> ...
>>> ---------------------------------------------------------= -------------
>>> COMMENT:
>>> ---------------------------------------------------------= -------------
>>>
>>>
>>> S 3.5.4.3.
>>>=C2=A0 =C2=A0 After a GRASP device successfully discovers a loc= ator for a
>>> Discovery
>>>=C2=A0 =C2=A0 Responder supporting a specific objective, it MUS= T cache this
>>>=C2=A0 =C2=A0 information, including the interface index via wh= ich it was
>>>=C2=A0 =C2=A0 discovered.=C2=A0 This cache record MAY be used f= or future negotiation or
>>>=C2=A0 =C2=A0 synchronization, and the locator SHOULD be passed= on when
>>> appropriate
>>>=C2=A0 =C2=A0 as a Divert option to another Discovery Initiator= .
>>>
>>> What's an "interface index"
>>
>> It's a term of art in the socket API:
>> https://tools.ietf.org/html/rfc3493#secti= on-4
>> Does it need a reference?
>>
>
> Yes.

Will fix.

>
>>> S 3.7.
>>> You seem to be going to a lot of trouble to deal wit session >>> ID collisions. Why don't you just make session IDs 128-bit=
>>> random values and then you won't have to worry about
>>> collisions.
>>
>> Well, yes, the odds would be better with 128 than 32 but
>> that's extra bits on the wire and there'd still be the
>> birthday paradox...
>
>
> Why is this amount of extra bits on the wire significant?

We do have people in Anima who care about every extra byte, in
case this stuff does end up in constrained devices.
Yeah, I hear this stuff a lot, but I'd want to see some re= al analysis of whether
this is an issue.


> As far as birthday paradox, I suspect this protocol is going to
> break down well before 2^32 endpoints, let alone 2^64.

Of course, but it's the number of overlapping sessions that woul= d
be relevant for the birthday paradox.

You t= hink you're going to have anywhere near 2^64 sessions?

=C2=A0
However, my point is th= at
regardless of the odds, the implementer needs to check for a collision;
that's just correct programming.

No= , I don't agree with this. Once collisions are sufficiently statistical= ly
unlikely, you can assume they will not happen. Note that we ro= utinely
assume this in situations where the results of collisions= are far more
severe (e.g., generating cryptographic keys).
=

=C2=A0

>> S 3.8.6.
>>>=C2=A0 =C2=A0 If a node receives a Request message for an objec= tive for which no
>>>=C2=A0 =C2=A0 ASA is currently listening, it MUST immediately c= lose the relevant
>>>=C2=A0 =C2=A0 socket to indicate this to the initiator.=C2=A0 T= his is to avoid
>>>=C2=A0 =C2=A0 unnecessary timeouts if, for example, an ASA exit= s prematurely but
>>>=C2=A0 =C2=A0 the GRASP core is listening on its behalf.
>>>
>>> This is not secure. You need a secure indication of non-knowle= dge,
>>> not a transport-level close.
>>
>> I don't see this as a security issue. There would be an altern= ative,
>> which is to send back an immediate M_DECLINE, but that is quite >> a bit harder to implement and I don't really see an advantage:=
>> the requester will just get back an error code in either case.
>> An ASA must always be ready for an error return.
>>
>
> If the attacker can force an error when the other side didn't want= one then
> that implicates the security of the system.

True, but I don't think your suggestion helps. Let me explain:
Suppose that we add a new use of the M_DECLINE message for this case.
Then the ASA which is currently not accepting Request messages will
send an M_DECLINE followed by a TCP FIN. The initiator receives
an M_DECLINE, closes its socket and returns an error code to the API.

If it receives an unexpected FIN (or RST) it closes its socket and returns<= br> an error code to the API anyway. It has to; there's nothing else it can=
do. As far as the ASA involved is concerned, it's a failure in any case= .

Not necessarily. You might, for insta= nce, log an error and do something
when you believe that your net= work is under attack/broken.=C2=A0


>>> S 3.9.5.4.
>>> What are the semantics of a Divert URI? What do I dow ith the<= br> >>> path part?
>>
>> Two things on this:
>> Following Alexy's comment, we are likely to add protocol/port<= br> >> to this type of locator option. Given that, is there anything spec= ial
>> about the Divert case? A URI should be valid however you receive i= t.
>>
>
> Again, what do you do with the path section of the URI?

=C2=A0 =C2=A0Note 2: Normal GRASP operations are not expected to use= this option.
=C2=A0 =C2=A0It is intended for special purposes such as discovering extern= al
=C2=A0 =C2=A0services.=C2=A0 Therefore its use is not further described in = this
=C2=A0 =C2=A0specification.

GRASP is just the carrier so is completely agnostic about your
question.

Yeah, I'm not generally a= big fan of "here is some placeholder we have
no idea what w= e're going to do with"

-Ekr

>>
>> We will try to clarify this, at least with a cross-reference.
>>
>> Thanks,
>>=C2=A0 =C2=A0 =C2=A0 Brian
>>
>

--001a11490b9a199b130550d857ee-- From nobody Wed May 31 16:18:03 2017 Return-Path: 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 3E23E127333; Wed, 31 May 2017 16:18:02 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kohbMrJ10COl; Wed, 31 May 2017 16:18:01 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 305BB1271DF; Wed, 31 May 2017 16:18:01 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id e193so20321507pfh.0; Wed, 31 May 2017 16:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OiW3woHgxOvxCGKYzjkm7oOj4iUk553bUFlvVlKKoBA=; b=bV6NxH5trk5I5jF2Bo13Xsfj4fTgmihsijoV+pcLR6DS/47LK3axpoBaG9Tk2lv6DK 2Zz7YKn1odbNR4rJJ/Q9rQW24wpjv2o302p56S4611In5+L0DhXobgUspOGXGDAcyLGX 1zi4Wv2pV9PEU5Lv05KbYKdciGxzy6Zwp4iQLEK9KwkqjlNUYoIPXN40cGUfoTtUCLUx bWH05/ACkkUZU/aQhS+16+q06MlHm4OdUgR0EzQLSvo8kLkSEslPgc/3pGQeYqvjs8w/ LeE8VL5eVpxo5c4VkLj4xBKq0PhG14pyj2oAPcZS0/Effdyfzo85muhfLnWQ5tW2ADfo l2mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=OiW3woHgxOvxCGKYzjkm7oOj4iUk553bUFlvVlKKoBA=; b=bN7PFzolJfhvTQpHmMll5TMcDqcDdi5hcsrkBlegmhb/I9UGwQtToX3vqvtOgA5oSl qh4KK1NcZPwjD7M5ufTLiIfD2z4x5whCNcZ1vfupHk57/tdcziFipSKW70fifoAZHNYd iCfSlRUym7qogmBaCpjqSe6twninjtLXJK4i607os2ruWXoy1JQosw0zuZVOA2bj21BA +W8oa98mECIXrzUNVk8Bx7EXXgptM0dpzIJm7z+2zgQaJ6F15yST9WoS2NIEiGgK8oHk CEPaOjEGWYT6/6BAy+Vzy5VSfrKOjfsoZisPTL4iZLRjmym1w4kUqe/0Ozs2jclWUVPK JusQ== X-Gm-Message-State: AODbwcDXJvEdxKa3NvibCK3Xo+GmnXgV00dxkCTHuGLRfCPLYoUS6XQ8 8v1uFSNDvUX+zTE0 X-Received: by 10.84.193.3 with SMTP id e3mr8406254pld.178.1496272680434; Wed, 31 May 2017 16:18:00 -0700 (PDT) Received: from ?IPv6:2406:e001:5618:1:28cc:dc4c:9703:6781? ([2406:e001:5618:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j82sm31833767pfj.69.2017.05.31.16.17.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 16:17:59 -0700 (PDT) To: Ben Campbell Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> <5905c0d9-f664-1207-aa28-d4d45d5d8528@gmail.com> <1D91D354-0A23-471F-A854-7256D8D2BA52@nostrum.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <77e6c45d-bdbf-2823-5432-1a1388003d36@gmail.com> Date: Thu, 1 Jun 2017 11:18:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1D91D354-0A23-471F-A854-7256D8D2BA52@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-grasp-12: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 23:18:02 -0000 On 01/06/2017 08:36, Ben Campbell wrote: > Hi, thanks for the responses. Further comments below. I deleted sectio= ns that seem resolved. >=20 > Thanks! >=20 > Ben. >=20 >> On May 28, 2017, at 11:16 PM, Brian E Carpenter wrote: >> >> Comments on some more of Ben's comments: >> >> On 23/05/2017 13:25, Ben Campbell wrote: >>> >=20 > [=E2=80=A6] >=20 >>> -5, Privacy and Confidentiality: Did people consider IP Addresses and= >>> other potentially persistent identifiers as impacting privacy? >> >> Here we are dealing with the addresses of network elements, not user >> devices, so there don't seem to to be personal privacy issues. >> >=20 > Did I miss something that indicated that these network elements can=E2=80= =99t/won=E2=80=99t ever be end-user devices? >=20 > Now, I don=E2=80=99t necessarily think that would change the privacy co= nsiderations=E2=80=94I was mainly questioning the assertion the =E2=80=9C= no personal information=E2=80=9D assertion. No, I don't think you missed anything, because we can't reasonably assert= that. People can install what they want where they want. We will qualify the text accordingly; it only strengthens the case for encryption. =20 >>> -7, Grasp Message and Options table: Why "Standards Action"? Would yo= u >>> expect some harm to be done if this were only Spec Required? >> >> I have asked the WG's opinion. >=20 > Okay, I will follow that separately. >=20 >> >>> Editorial: >>> >>> - Is section 2 expected to be useful to implementers once this is >>> published as an RFC? Unless there's a reason otherwise, I would sugge= st >>> moving this to an appendix, or even removing it entirely. As it is, y= ou >>> have to wade through an unusual amount of front material before you g= et >>> to the meat of the protocol. >> >> I have asked the WG's opinion. >=20 > Okay. >=20 >> >>> - Along the lines of the previous comment, I found the organization a= bit >>> hard to follow. I didn't find actual protocol details until around pa= ge >>> 21. Procedures are split (and sometimes repeated) between the procedu= re >>> sections and the message format sections. I think that will make this= >>> more difficult and error prone than necessary for implementors to rea= d >>> and reference. I fear readers will read one section and think they >>> understand the procedures, and miss a requirement in the other. >> >> I understand the problem but I don't have a solution; there is an atte= mpt >> to give an overview before getting into message formats, but that lead= s >> to some repetition as well. >=20 > On reflection, it=E2=80=99s probably not worth trying to reorganize thi= ngs this late in the process. Other reviewers seem to have followed thing= s just fine, so maybe it=E2=80=99s me :-) No, it's complicated. I have exactly the same problem - both in updating the draft and in chasing bugs through the prototype code. I just don't think it can be fixed by reorganising the text, because to some extent you have to understand everything before you can understand anything. Thanks Brian From nobody Wed May 31 16:41:51 2017 Return-Path: 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 AD276129476; Wed, 31 May 2017 16:41:50 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fepXXIbKaOT; Wed, 31 May 2017 16:41:49 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 176AC1201F2; Wed, 31 May 2017 16:41:49 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id e193so20738344pfh.0; Wed, 31 May 2017 16:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=v3flmkemEeq1hCgZpqUOquMUkYsgyX4koZ1Q+EuNJpA=; b=poWckPf4/ZYmQNiN/x8h2/WEWMfZQFvbK3hgm4ao/PQKjVmV7rBHaEIqCTHVnCE9j+ gJL0rgcbR6MuSY+20rjuzk/JCvctqu9asRgJd2nBbZ+7zuYsD3C6MlddiQDbVoW5pB2x k71/BatGElOBtHVZUzw5WDXmbJhACv2h81K5ES78Ar/w1F2AF4fKuRcLqmlImQLpEoi8 qP0VnfjToFNbbF43BSrgTBu4EWySG7d6TVWzv0kVY3UPcxdDNlOcM/zR5YWYBimO+3b1 J93+SUj6XcmSVK2xTI4BU8m2BdrMJYrnvTl8jAZ5wbNx7tdLr0cCNUkQOev70UbjuDeo 5oTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=v3flmkemEeq1hCgZpqUOquMUkYsgyX4koZ1Q+EuNJpA=; b=ZR/SLsKY2GIw3qwoAuehrF8e0HI4V4mzlKqq28+p7Jb0qwJwF26FP6TqDXt2enc15l pqvJmJaLmOhrjoxZeiYLpKNUCXjkswXu8nBCm71CFFarXOS7rDtmlWx3ciW4w8lCZsqC 9+FjroWFo9+nAwdxr2Y1zxUXnnNOLmo7vM7pIAKFWyZt2wpc08++Xubd8D3MuxCdw5eu nqTv4mfrUUIZOaNOLh57h4Dek71kX6t6yVlM5ipjCf/3432nw/Pcfr6QyLB/kmY/iW1Y UT0SlVObnTU0ms18i/M7cMlvevw03Jt5uFoI1PCyVuInS6qfgikuNdCdhhp18fsAfgXg CvqQ== X-Gm-Message-State: AODbwcDGtKW6K1Mdgm6T9X+/Zyoq0xpTXB0+2S8bkGwLi0q2+hNyO1CI lnQBN1OxVZTgwg== X-Received: by 10.84.204.133 with SMTP id b5mr93569662ple.56.1496274108623; Wed, 31 May 2017 16:41:48 -0700 (PDT) Received: from ?IPv6:2406:e001:5618:1:28cc:dc4c:9703:6781? ([2406:e001:5618:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o89sm31649115pfj.88.2017.05.31.16.41.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 16:41:47 -0700 (PDT) To: Eric Rescorla Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, Anima WG References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <2be0192e-2edd-a192-26d2-2a755784dfe5@gmail.com> <604b04b5-9e6d-c740-4805-ea0674cd640a@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 1 Jun 2017 11:41:50 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 23:41:50 -0000 Eric, On 01/06/2017 09:09, Eric Rescorla wrote: > > > On Wed, May 31, 2017 at 1:55 PM, Brian E Carpenter > wrote: > > On 31/05/2017 14:17, Eric Rescorla wrote: > > On Tue, May 30, 2017 at 6:32 PM, Brian E Carpenter < > > brian.e.carpenter@gmail.com > wrote: > > > >> Now getting to Eric's COMMENTs: > >> > >> On 25/05/2017 14:32, Eric Rescorla wrote: > >> ... > >>> ---------------------------------------------------------------------- > >>> COMMENT: > >>> ---------------------------------------------------------------------- > >>> > >>> > >>> S 3.5.4.3. > >>> After a GRASP device successfully discovers a locator for a > >>> Discovery > >>> Responder supporting a specific objective, it MUST cache this > >>> information, including the interface index via which it was > >>> discovered. This cache record MAY be used for future negotiation or > >>> synchronization, and the locator SHOULD be passed on when > >>> appropriate > >>> as a Divert option to another Discovery Initiator. > >>> > >>> What's an "interface index" > >> > >> It's a term of art in the socket API: > >> https://tools.ietf.org/html/rfc3493#section-4 > >> Does it need a reference? > >> > > > > Yes. > > Will fix. > > > > >>> S 3.7. > >>> You seem to be going to a lot of trouble to deal wit session > >>> ID collisions. Why don't you just make session IDs 128-bit > >>> random values and then you won't have to worry about > >>> collisions. > >> > >> Well, yes, the odds would be better with 128 than 32 but > >> that's extra bits on the wire and there'd still be the > >> birthday paradox... > > > > > > Why is this amount of extra bits on the wire significant? > > We do have people in Anima who care about every extra byte, in > case this stuff does end up in constrained devices. > > > Yeah, I hear this stuff a lot, but I'd want to see some real analysis of whether > this is an issue. Well, I read the published RFC on constrained systems at the beginning of Anima, so it isn't clear in my mind today, but I think the people working in that area really do care about every byte. But it's a side issue really. The main point is that afaik it's still a lot easier to manipulate 32 bit numbers than say 128 bit numbers, and 2^32 seems plenty big enough for this particular (non-cryptographic) purpose. > > As far as birthday paradox, I suspect this protocol is going to > > break down well before 2^32 endpoints, let alone 2^64. > > Of course, but it's the number of overlapping sessions that would > be relevant for the birthday paradox. > > > You think you're going to have anywhere near 2^64 sessions? Not likely, even 2^32 is a lot. > However, my point is that > > regardless of the odds, the implementer needs to check for a collision; > that's just correct programming. > > > No, I don't agree with this. Once collisions are sufficiently statistically > unlikely, you can assume they will not happen. Note that we routinely > assume this in situations where the results of collisions are far more > severe (e.g., generating cryptographic keys). This only adds one uint32 test in the code if clash.id_source == session_inst.id_source: which will almost never test true. So I think we'd better agree to differ. > > >> S 3.8.6. > >>> If a node receives a Request message for an objective for which no > >>> ASA is currently listening, it MUST immediately close the relevant > >>> socket to indicate this to the initiator. This is to avoid > >>> unnecessary timeouts if, for example, an ASA exits prematurely but > >>> the GRASP core is listening on its behalf. > >>> > >>> This is not secure. You need a secure indication of non-knowledge, > >>> not a transport-level close. > >> > >> I don't see this as a security issue. There would be an alternative, > >> which is to send back an immediate M_DECLINE, but that is quite > >> a bit harder to implement and I don't really see an advantage: > >> the requester will just get back an error code in either case. > >> An ASA must always be ready for an error return. > >> > > > > If the attacker can force an error when the other side didn't want one then > > that implicates the security of the system. > > True, but I don't think your suggestion helps. Let me explain: > > Suppose that we add a new use of the M_DECLINE message for this case. > Then the ASA which is currently not accepting Request messages will > send an M_DECLINE followed by a TCP FIN. The initiator receives > an M_DECLINE, closes its socket and returns an error code to the API. > > If it receives an unexpected FIN (or RST) it closes its socket and returns > an error code to the API anyway. It has to; there's nothing else it can > do. As far as the ASA involved is concerned, it's a failure in any case. > > > Not necessarily. You might, for instance, log an error and do something > when you believe that your network is under attack/broken. We can do that anyway. "Negotiation peer not listening" is not a normal situation anyway; if it persists it should be logged and investigated. (This is not just thoughtware - when I've run test ASAs with full diagnostic logging, this is in fact one of the errors I've used for debugging.) Note, I'm not saying it's unreasonable to add the M_DECLINED message in this case; it easily passes my test of "can I code this?" But I'd need a clear message from the WG to be convinced. > > >>> S 3.9.5.4. > >>> What are the semantics of a Divert URI? What do I dow ith the > >>> path part? > >> > >> Two things on this: > >> Following Alexy's comment, we are likely to add protocol/port > >> to this type of locator option. Given that, is there anything special > >> about the Divert case? A URI should be valid however you receive it. > >> > > > > Again, what do you do with the path section of the URI? > > Note 2: Normal GRASP operations are not expected to use this option. > It is intended for special purposes such as discovering external > services. Therefore its use is not further described in this > specification. > > GRASP is just the carrier so is completely agnostic about your > question. > > > Yeah, I'm not generally a big fan of "here is some placeholder we have > no idea what we're going to do with" It's not really a placeholder IMHO. It's something that GRASP, as an infrastructure component, provides for app (the ASA) to use as it needs. Brian > > -Ekr > > > >> > >> We will try to clarify this, at least with a cross-reference. > >> > >> Thanks, > >> Brian > >> > > > > From nobody Wed May 31 16:50:43 2017 Return-Path: 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 8C6C712E037 for ; Wed, 31 May 2017 16:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 rmncybKqe2qX for ; Wed, 31 May 2017 16:50:38 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 195E4128BB7 for ; Wed, 31 May 2017 16:50:38 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id 130so7377058ybl.3 for ; Wed, 31 May 2017 16:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I42rbiivfJPCr1qllpP653Xz6sO0bfRXlqU6YTBhFxs=; b=OhDGvO4xtgSNmUPng9Th8DOMy8LS7mKC8GcYcb9j5acEsUVRqZlqx4PyhjQOvM2HjR iwdtvskVEeY362bcRQMF4FNFcZlnOST/O50SIHLSteGnnu79mJIsNUwXZ5tYFG7ESmtb arv9or3ydLMsLEST1sWrpXX/xK4RROLaZ/yX33X3QlK6O9WXXPvSg9MYu6x3PUqSSMgg DN08yChIycyYZr4euY/lCNSyxTDRAZHy06wL+0HSzOzZ3FvmQ78gL+vrCvyYP1KH07mz llSS/o2LIk73bFLC4SWGe003c1k78GqzKzpTbV2Gmxk4y6LjJ49mGDdn0DXfg9InmdWE dTVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I42rbiivfJPCr1qllpP653Xz6sO0bfRXlqU6YTBhFxs=; b=QHX/jnNEIiZwihDc+fc4iTG/KC4dvIkB1XSsZqXVYrhUz346C8Iwn7qr9utKDlpz0q Ms49aDXwy6YdI+KrXE7R608ycod5ZRKvtQxdkHu5BeFgEc77ly5xinU8SlBhV/Tcp7xg fV7ZEpuo6Gg3xgqrpZ4D6AL552jODxinwoPIharTGdjVVsYn1bai5MNtczmwy1tXyEAx HfzbQw2kSzFeFT8KBeeKRQQL2Z66Sib47uwcebebJP4BQ9Mw7mKQ5yKtaZj9+AhgEW5x MdWvFiIR5xKo7jD3b1pSAu4w9sP8cHAeHrj8V+uk2P7y7qOWm0celJvy1aA6vnGRtVY4 Iu6g== X-Gm-Message-State: AODbwcBGgP6MHhL1nUKPRFO0R5X4KLHsVx/rJ5BCaDLcijNxdVj9l7nt /yxY4Cn90wOOQTtusBJGYRr/3ch5K9F/ X-Received: by 10.37.99.213 with SMTP id x204mr8479302ybb.50.1496274637306; Wed, 31 May 2017 16:50:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Wed, 31 May 2017 16:49:56 -0700 (PDT) In-Reply-To: References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <2be0192e-2edd-a192-26d2-2a755784dfe5@gmail.com> <604b04b5-9e6d-c740-4805-ea0674cd640a@gmail.com> From: Eric Rescorla Date: Wed, 31 May 2017 16:49:56 -0700 Message-ID: To: Brian E Carpenter Cc: The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, Anima WG Content-Type: multipart/alternative; boundary="001a11c155663e69390550da96a2" Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 23:50:41 -0000 --001a11c155663e69390550da96a2 Content-Type: text/plain; charset="UTF-8" On Wed, May 31, 2017 at 4:41 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Eric, > > On 01/06/2017 09:09, Eric Rescorla wrote: > > > > > > On Wed, May 31, 2017 at 1:55 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > > > > On 31/05/2017 14:17, Eric Rescorla wrote: > > > On Tue, May 30, 2017 at 6:32 PM, Brian E Carpenter < > > > brian.e.carpenter@gmail.com > > wrote: > > > > > >> Now getting to Eric's COMMENTs: > > >> > > >> On 25/05/2017 14:32, Eric Rescorla wrote: > > >> ... > > >>> ------------------------------------------------------------ > ---------- > > >>> COMMENT: > > >>> ------------------------------------------------------------ > ---------- > > >>> > > >>> > > >>> S 3.5.4.3. > > >>> After a GRASP device successfully discovers a locator for a > > >>> Discovery > > >>> Responder supporting a specific objective, it MUST cache this > > >>> information, including the interface index via which it was > > >>> discovered. This cache record MAY be used for future > negotiation or > > >>> synchronization, and the locator SHOULD be passed on when > > >>> appropriate > > >>> as a Divert option to another Discovery Initiator. > > >>> > > >>> What's an "interface index" > > >> > > >> It's a term of art in the socket API: > > >> https://tools.ietf.org/html/rfc3493#section-4 < > https://tools.ietf.org/html/rfc3493#section-4> > > >> Does it need a reference? > > >> > > > > > > Yes. > > > > Will fix. > > > > > > > >>> S 3.7. > > >>> You seem to be going to a lot of trouble to deal wit session > > >>> ID collisions. Why don't you just make session IDs 128-bit > > >>> random values and then you won't have to worry about > > >>> collisions. > > >> > > >> Well, yes, the odds would be better with 128 than 32 but > > >> that's extra bits on the wire and there'd still be the > > >> birthday paradox... > > > > > > > > > Why is this amount of extra bits on the wire significant? > > > > We do have people in Anima who care about every extra byte, in > > case this stuff does end up in constrained devices. > > > > > > Yeah, I hear this stuff a lot, but I'd want to see some real analysis of > whether > > this is an issue. > > Well, I read the published RFC on constrained systems at the beginning > of Anima, so it isn't clear in my mind today, but I think the people > working > in that area really do care about every byte. But it's a side issue really. > The main point is that afaik it's still a lot easier to manipulate 32 bit > numbers than say 128 bit numbers, and 2^32 seems plenty big enough for > this particular (non-cryptographic) purpose. > Sure, it doesn't need to be cryptographic, just statistically unique. And as you say, 2^{32} *isn't* large enough for that, but 2^{128} is. > However, my point is that > > > > regardless of the odds, the implementer needs to check for a > collision; > > that's just correct programming. > > > > > > No, I don't agree with this. Once collisions are sufficiently > statistically > > unlikely, you can assume they will not happen. Note that we routinely > > assume this in situations where the results of collisions are far more > > severe (e.g., generating cryptographic keys). > > This only adds one uint32 test in the code > if clash.id_source == session_inst.id_source: > which will almost never test true. That's not good, it's bad. It means it's a code path which is likely not to be tested correctly. So I think we'd better agree to differ. Yes, I agree that this is within WG discretion. > > > If the attacker can force an error when the other side didn't want > one then > > > that implicates the security of the system. > > > > True, but I don't think your suggestion helps. Let me explain: > > > > Suppose that we add a new use of the M_DECLINE message for this case. > > Then the ASA which is currently not accepting Request messages will > > send an M_DECLINE followed by a TCP FIN. The initiator receives > > an M_DECLINE, closes its socket and returns an error code to the API. > > > > If it receives an unexpected FIN (or RST) it closes its socket and > returns > > an error code to the API anyway. It has to; there's nothing else it > can > > do. As far as the ASA involved is concerned, it's a failure in any > case. > > > > > > Not necessarily. You might, for instance, log an error and do something > > when you believe that your network is under attack/broken. > > We can do that anyway. "Negotiation peer not listening" is not a normal > situation anyway; if it persists it should be logged and investigated. > (This is not just thoughtware - when I've run test ASAs with full > diagnostic > logging, this is in fact one of the errors I've used for debugging.) > > Note, I'm not saying it's unreasonable to add the M_DECLINED message in > this > case; it easily passes my test of "can I code this?" But I'd need a clear > message from the WG to be convinced. > If you opt not to change it, you need to call it out in the security considerations, because truncation attacks are a real thing. > GRASP is just the carrier so is completely agnostic about your > > question. > > > > > > Yeah, I'm not generally a big fan of "here is some placeholder we have > > no idea what we're going to do with" > > It's not really a placeholder IMHO. It's something that GRASP, as an > infrastructure component, provides for app (the ASA) to use as it needs. > This seems like a distinction without a difference. -Ekr --001a11c155663e69390550da96a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 31, 2017 at 4:41 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
Eric,

On 01/06/2017 09:09, Eric Rescorla wrote:
>
>
> On Wed, May 31, 2017 at 1:55 PM, Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:= brian.e.carpenter@gmail= .com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 31/05/2017 14:17, Eric Rescorla wrote:
>=C2=A0 =C2=A0 =C2=A0> On Tue, May 30, 2017 at 6:32 PM, Brian E Carpe= nter <
>=C2=A0 =C2=A0 =C2=A0> brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> Now getting to Eric's COMMENTs:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On 25/05/2017 14:32, Eric Rescorla wrote:<= br> >=C2=A0 =C2=A0 =C2=A0>> ...
>=C2=A0 =C2=A0 =C2=A0>>> ---------------------------------= -------------------------------------
>=C2=A0 =C2=A0 =C2=A0>>> COMMENT:
>=C2=A0 =C2=A0 =C2=A0>>> ---------------------------------= -------------------------------------
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> S 3.5.4.3.
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 After a GRASP device succ= essfully discovers a locator for a
>=C2=A0 =C2=A0 =C2=A0>>> Discovery
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 Responder supporting a sp= ecific objective, it MUST cache this
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 information, including th= e interface index via which it was
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 discovered.=C2=A0 This ca= che record MAY be used for future negotiation or
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 synchronization, and the = locator SHOULD be passed on when
>=C2=A0 =C2=A0 =C2=A0>>> appropriate
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 as a Divert option to ano= ther Discovery Initiator.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> What's an "interface index&qu= ot;
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> It's a term of art in the socket API:<= br> >=C2=A0 =C2=A0 =C2=A0>> https://tools.i= etf.org/html/rfc3493#section-4 <https://too= ls.ietf.org/html/rfc3493#section-4>
>=C2=A0 =C2=A0 =C2=A0>> Does it need a reference?=
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Yes.
>
>=C2=A0 =C2=A0 =C2=A0Will fix.
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>>> S 3.7.
>=C2=A0 =C2=A0 =C2=A0>>> You seem to be going to a lot of troub= le to deal wit session
>=C2=A0 =C2=A0 =C2=A0>>> ID collisions. Why don't you just = make session IDs 128-bit
>=C2=A0 =C2=A0 =C2=A0>>> random values and then you won't h= ave to worry about
>=C2=A0 =C2=A0 =C2=A0>>> collisions.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Well, yes, the odds would be better with 1= 28 than 32 but
>=C2=A0 =C2=A0 =C2=A0>> that's extra bits on the wire and ther= e'd still be the
>=C2=A0 =C2=A0 =C2=A0>> birthday paradox...
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Why is this amount of extra bits on the wire s= ignificant?
>
>=C2=A0 =C2=A0 =C2=A0We do have people in Anima who care about every ext= ra byte, in
>=C2=A0 =C2=A0 =C2=A0case this stuff does end up in constrained devices.=
>
>
> Yeah, I hear this stuff a lot, but I'd want to see some real analy= sis of whether
> this is an issue.

Well, I read the published RFC on constrained systems at the beginni= ng
of Anima, so it isn't clear in my mind today, but I think the people wo= rking
in that area really do care about every byte. But it's a side issue rea= lly.
The main point is that afaik it's still a lot easier to manipulate 32 b= it
numbers than say 128 bit numbers, and 2^32 seems plenty big enough for
this particular (non-cryptographic) purpose.

Sure, it doesn't need to be cryptographic, just statistically uni= que. And as you say,
2^{32} *isn't* large enough for that, bu= t 2^{128} is.


>=C2=A0 =C2=A0 =C2=A0However, my point is that
>
>=C2=A0 =C2=A0 =C2=A0regardless of the odds, the implementer needs to ch= eck for a collision;
>=C2=A0 =C2=A0 =C2=A0that's just correct programming.
>
>
> No, I don't agree with this. Once collisions are sufficiently stat= istically
> unlikely, you can assume they will not happen. Note that we routinely<= br> > assume this in situations where the results of collisions are far more=
> severe (e.g., generating cryptographic keys).

This only adds one uint32 test in the code
=C2=A0 =C2=A0 if clash.id_source =3D=3D session_inst.id_source:
which will almost never test true.

That'= ;s not good, it's bad. It means it's a code path which is likely no= t to
be tested correctly.


So I think we'd better agree to differ.

Yes, I agree that this is within WG discretion= .



>=C2=A0 =C2=A0 =C2=A0> If the attacker can force an error when the ot= her side didn't want one then
>=C2=A0 =C2=A0 =C2=A0> that implicates the security of the system. >
>=C2=A0 =C2=A0 =C2=A0True, but I don't think your suggestion helps. = Let me explain:
>
>=C2=A0 =C2=A0 =C2=A0Suppose that we add a new use of the M_DECLINE mess= age for this case.
>=C2=A0 =C2=A0 =C2=A0Then the ASA which is currently not accepting Reque= st messages will
>=C2=A0 =C2=A0 =C2=A0send an M_DECLINE followed by a TCP FIN. The initia= tor receives
>=C2=A0 =C2=A0 =C2=A0an M_DECLINE, closes its socket and returns an erro= r code to the API.
>
>=C2=A0 =C2=A0 =C2=A0If it receives an unexpected FIN (or RST) it closes= its socket and returns
>=C2=A0 =C2=A0 =C2=A0an error code to the API anyway. It has to; there&#= 39;s nothing else it can
>=C2=A0 =C2=A0 =C2=A0do. As far as the ASA involved is concerned, it'= ;s a failure in any case.
>
>
> Not necessarily. You might, for instance, log an error and do somethin= g
> when you believe that your network is under attack/broken.

We can do that anyway. "Negotiation peer not listening&quo= t; is not a normal
situation anyway; if it persists it should be logged and investigated.
(This is not just thoughtware - when I've run test ASAs with full diagn= ostic
logging, this is in fact one of the errors I've used for debugging.)
Note, I'm not saying it's unreasonable to add the M_DECLINED messag= e in this
case; it easily passes my test of "can I code this?" But I'd = need a clear
message from the WG to be convinced.

If= you opt not to change it, you need to call it out in the security consider= ations,
because truncation attacks are a real thing.

>=C2=A0 =C2=A0 =C2=A0GRASP is just the carrier so is completely agnostic= about your
>=C2=A0 =C2=A0 =C2=A0question.
>
>
> Yeah, I'm not generally a big fan of "here is some placeholde= r we have
> no idea what we're going to do with"

It's not really a placeholder IMHO. It's something that GRAS= P, as an
infrastructure component, provides for app (the ASA) to use as it needs.

This seems like a distinction without a d= ifference.

-Ekr

--001a11c155663e69390550da96a2-- From nobody Wed May 31 16:57:04 2017 Return-Path: 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 05D9912EA58; Wed, 31 May 2017 16:57:00 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sonogw818m5T; Wed, 31 May 2017 16:56:58 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 616CB12EA57; Wed, 31 May 2017 16:56:58 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id 9so20958912pfj.1; Wed, 31 May 2017 16:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FQafuVD5eTmSG05sxdTdmEJkcO6/xljoCZx8i07ZnO0=; b=Z+PqZQEOeFdxSLhk7Lpe+pgDqkH2wjpazT4ZuokobRBKJt5OW4I48FrcQTNIo4YNTI FSiW60l9BVLfg/+t6H7WZ77+5xhAtZyhbkc4/76ALwkw8hKom5Nju+4wIJH/ccTo+xF7 q73NLwrkmVOopFJdB4ZxBt5Vx78OM2s39SZEpzX0q4pnkUY32Z95at/CjCI3Xwbyv0Hx 6Ju+0eDtpEJDx9ZxH/UUAGfa06THRa1dYzLKHxMwd9Tt7T3i0I3LKv7GTwrRVMfBHa6P 5olrs+zXGAvhl7THi4yck81ZzgjKlpZZJau1ZQbhjYxQW4gkwJMw0sfPviK3ThOznTac 2BrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=FQafuVD5eTmSG05sxdTdmEJkcO6/xljoCZx8i07ZnO0=; b=EofR5Kyp5VRkm78rUgIKbg4XXBsmtFFDr+A7ME0JOfPyLbBN+iZSSOmE66i8cluL3X rmdLXjooP8jE0V8vbErBc5zOJCzNp/kJpbTSCRCX+PSN5nj24vg2d0P+JemM4ZHKiXbo 25l/bKtBJxe4XCpYgvsuYk60CBOf8S7MkQqtPZR4MDbT0CixLUcEfqF7FOfXJfvZjvy3 cZE30duoqRIZyu0+98luj7s4NIxwxgC3hqLUh9p+BbhgNFY8qRUr0qfkiqqv5wcPXewF kxKMnPJ1wxZFhrL9ZV5OgKJcZ07KzfiAa2AuLdXw5VdIUvC0xaY6+Nbq3KNNbdrQTUnT +bag== X-Gm-Message-State: AODbwcC3ywl/+hW8gMIzchgmIFfJB6MmzyBvqIqMYGHsVAk6SZPu0TxR nqjkZ5Y1lefWXg== X-Received: by 10.84.225.130 with SMTP id u2mr91225346plj.91.1496275017798; Wed, 31 May 2017 16:56:57 -0700 (PDT) Received: from ?IPv6:2406:e001:5618:1:28cc:dc4c:9703:6781? ([2406:e001:5618:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f1sm25066275pgc.8.2017.05.31.16.56.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 16:56:57 -0700 (PDT) To: Eric Rescorla Cc: Toerless Eckert , The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , Anima WG References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> <93bd9175-77c7-e588-93f9-49a09e12cd66@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 1 Jun 2017 11:56:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 23:57:00 -0000 On 01/06/2017 00:59, Eric Rescorla wrote: > > > On Tue, May 30, 2017 at 6:59 PM, Brian E Carpenter > wrote: > > On 31/05/2017 11:30, Eric Rescorla wrote: > > On Tue, May 30, 2017 at 4:19 PM, Brian E Carpenter < > > brian.e.carpenter@gmail.com > wrote: > > > >> On some other points that are dangling after previous messages: > >> > >> On 31/05/2017 00:29, Eric Rescorla wrote: > >>> On Mon, May 29, 2017 at 10:14 PM, Brian E Carpenter < > >>> brian.e.carpenter@gmail.com > wrote: > >>> > >>>> Eric, > >>>> > >>>> On 25/05/2017 14:32, Eric Rescorla wrote: > >>>> ... > >>>>> ---------------------------------------------------------------------- > >>>>> DISCUSS: > >>>>> ---------------------------------------------------------------------- > >> ... > >>>> Finally, I don't > >>>>> understand the security story for the multicast packets. > >>>> > >>>> I think I already typed this a day or two ago, but with an ACP, > >>>> they are secured, because the ACP is a secure virtual overlay > >>>> network. > >>>> > >>> > >>> This document then needs to state which precise properties of > >>> ACP it is relying on for that. A brief skim of ACP suggests that > >>> it relies on other protocols for its actual transport security and > >>> at least some of those protocols (e.g., DTLS) do not support > >>> multicast. > >> > >> Indeed, but as I understand it they will emulate link-local multicast > >> over the secured connections. > > > > > > It's not clear to me what that means. You perhaps expect to tie up > > a connection to every counterparty in the network? > > That is exactly what the ACP does, as I understand it. > > > That's not what I got from 5.4.3, which says: > > GRASP discovery and flooding messages are designed for use over link- > local multicast UDP. They MUST NOT be fragmented, and therefore MUST > NOT exceed the link MTU size. > > Perhaps a ladder diagram of how this works would help, both here > and in the document. Regardless of that, we will try to ensure that the next draft makes this clear without too much repetition. By the time the reader gets to 5.4.3, it should be clear that multicast UDP is via the ACP just like unicast TCP. I'll try a diagram but not right now as I have to run. > > >>> That is the trust model, but really as an explanatory matter I think > >>>> it belongs in draft-ietf-anima-reference-model rather than here. > >>>> I will add a few words in the High Level Deployment Model > >>>> section and/or the Security Considerations. > >>>> > >>>> What we do say already is that authorization of ASAs is out of scope. > >>>> I am certain that it needs to be tackled, but not here. > >>>> > >>> > >>> I don't see how you have a complete protocol without that. > >> > >> The starting position is that we trust all autonomic nodes and therefore > >> the ASAs installed in them. We are in the context of a single operator > > > > so this isn't really a stretch. > > > > > > I certainly can see how someone might decide to deploy a system like > > this, but it seems pretty problematic to have a system that is so brittle > > to single-point compromise (The term of art here is "distributed single > > point of failure") > > > > > >> The questions around life cycle > >> management of ASAs, which would certainly involve authorization, > >> were intentionally not in the initial WG charter. I think it's true > >> that you can't have a complete *system* without that, but I disagree > >> that it's a requirement for the protocol. > >> > > > > At minimum you need to specify that this is your trust model and > > then work through the implications of compromise of some subset > > of nodes, as well as of an attacker who can influence which nodes > > you talk to. > > That really, really belongs in the reference model or the ACP draft; > it's in no way specific to GRASP, because nodes could use any protocol > they please over the ACP. > > > It's a WG decision which document it goes in, but it's something > that needs to exist, because otherwise it is not possible to assess the > security of this document. Then it had better be the ACP, which is normative. (!Toerless again!) Brian From nobody Wed May 31 18:29:50 2017 Return-Path: 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 2F6DF129498 for ; Wed, 31 May 2017 18:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 bRySxpLjfd26 for ; Wed, 31 May 2017 18:29:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CE01292CE for ; Wed, 31 May 2017 18:29:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0687CE204; Wed, 31 May 2017 21:30:13 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 760B2636BB; Wed, 31 May 2017 21:29:47 -0400 (EDT) From: Michael Richardson To: "Max Pritikin \(pritikin\)" cc: Kent Watsen , "anima\@ietf.org" In-Reply-To: <2BCEB682-357B-43E5-9794-3B84F69E3C71@cisco.com> References: <4F1BE153-1A2E-4DC2-9E51-520A8538B84E@juniper.net> <2BCEB682-357B-43E5-9794-3B84F69E3C71@cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [Anima-bootstrap] Voucher signing method X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 01:29:50 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Max Pritikin (pritikin) wrote: > (libjwt) didn=E2=80=99t support it. After looking at the code more cl= osely I=E2=80=99m > not sure a jwt abstraction layer is really even needed; JWS is pretty > simple to use directly. I=E2=80=99ve forked libjwt and will upload my= diff to > github tomorrow so you can see what i mean. Max, can you indicate what your current thinking is in the movement From=20PKIX signed custom JSON to ... a) JWS signed custom JSON? b) JWT, with standard claims? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkvbgsACgkQgItw+93Q 3WUktQf+NQrUXPEHcnLavM2HKdZBXoln77+IwSoAJK7dawnqtgwuVTuxfqUaK9E5 lya2Kh9REuOnEZILbkJ6Kw93nCI2odMjmEFqyN99yj2Yhm+JguvZCOCk2es6XEgr 0sFAyyCWDDKua7YOExVXgmOAwXAUQ0PjYs2yWzW/F3D0ji/ydOtS3xsvTJaP7zyq o89Iag0a4CFu9qEZepQ0ztnPOkUzuLGtj1wIDfKy3jlGNwEh4GOSrvT+uj0hyY5n TDr1WpGDDjzgQmyZ6ew8jRJKiglXtODbPmJTd/sdVM6Z6n1uhRItxmNSMv/mkz/i A0uI+rJR2Vl13ZDfwrP3P+NXzQsRnQ== =zKdF -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 31 18:56:07 2017 Return-Path: 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 89CF1129B07 for ; Wed, 31 May 2017 18:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, 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 5DxGBDeO-cRP for ; Wed, 31 May 2017 18:56:04 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id B5171129B13 for ; Wed, 31 May 2017 18:56:04 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id v511u2xE023032; Wed, 31 May 2017 21:56:02 -0400 To: anima@ietf.org From: William Atwood Organization: Concordia University, Montreal Message-ID: <76bde93b-4883-8440-a9ff-1f29f55da3f7@concordia.ca> Date: Wed, 31 May 2017 21:56:08 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2017-05-31 21:56:02 EDT Archived-At: Subject: [Anima] Testing ASA Negotiation via GRASP over two hops X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 01:56:07 -0000 Brian Carpenter and I are pleased to report that we have successfully tested communication between two ASAs that are not sharing a link. ASA Gray ASA Briggs GRASP ------X------ GRASP ------X------ GRASP (Gingko) (Ritchie) (Iverson) Gingko, Richie, and Iverson are three Linux processors. ASA Briggs is installed on Iverson, and offers a variety of products. ASA Gray is installed on Gingko, and seeks to discover a source for these products. GRASP is installed on all three machines, and provides the necessary discovery forwarding. In the absence of an ACP, I have manually assigned IPv6 Unique Local Addresses (ULAs) to each interface, and manually installed the necessary routes. (These tasks would be part of the functionality of an ACP, once one gets developed.) Once this is done, ASA Gray is able to discover (through GRASP) that ASA Briggs is offering the necessary products, and then negotiate directly with ASA Briggs (i.e., using ASA Briggs' IPv6 ULA) to acquire these products. In the process, some small errors in the specification of GRASP have been found, and resolved in the latest Internet Draft. For those interested in the (python) code, it may be found at https://www.cs.auckland.ac.nz/~brian/graspy/ . Bill Atwood and Brian Carpenter -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Wed May 31 20:22:32 2017 Return-Path: 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 94743129456 for ; Wed, 31 May 2017 20:22:30 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpihgWhtBmJD for ; Wed, 31 May 2017 20:22:29 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 ECB07127011 for ; Wed, 31 May 2017 20:22:28 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id n23so24871041pfb.2 for ; Wed, 31 May 2017 20:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ntKRhhOY40X3P5ivQq8d84TMaE0HwE9sL4co7qf9zyQ=; b=gBVwW12muuDdW2H8TcFrUG+7eMMj+ONStyGMSQCiuvkgkBBHJMq9RqH6ugPbwpwLgn G+wMzGCs11MrykaMuowLiGpk+GEjZjG3auKHfg2Vsf4tKT5HF2++dyCu4TpO1bQZiOu7 YThD1SZh/Wi2MjfBdbGph2ktyifGjxAAZPO9r+ESamATBJPZwKi+UWvXeRUPRIKVQJRB l12hSma6yTW2TI1a/dAIbsCkrUTHdz08Nb6AmHdnLNva6beN/aMU1O69MvNHAggwJysO ETTd6uN1bbuiyfM/kxYXR+ZJr/jxNqN0H/wfMUNFx8YrKFUAeBWYVx7i34ZhGARDtNmR KSmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ntKRhhOY40X3P5ivQq8d84TMaE0HwE9sL4co7qf9zyQ=; b=AJIXzhuSG3T2xGYPvf75OxjZOD26D7S5xOBS3h4h3QOtQAWagon/qRMGAQCYFRmtpB PI+Ra4jZutvvY+ocDFOznlprdU+4tS/AP/EWMv9kV/nx6DOtS+nCgTValXLiN/bp3u0S ngTr4tMiiuOui3x+qmeTjLzt80XYdHTqriNrQV+1T0XEaEinfecH4IUquQlFwDcc5uDm NinrNCuqL69du1ch74ayNfJ39XZY8G/uYcW598aIKqK1+Sq725g4zEuMvEYZVZS8dnfM XxvMBbeDm1oadicsnLgFyAKZvew1SSihVPBR2v6xFDVQqge/xLdEVBkn2RfzWd9CBVa4 36sQ== X-Gm-Message-State: AODbwcCIpkUvGH+E952PF1No+SuZrSUkBomJA8lbRv1T4FmlJk0vmyds IFEsfp/swhO2LgWY X-Received: by 10.99.44.9 with SMTP id s9mr37293186pgs.72.1496287348430; Wed, 31 May 2017 20:22:28 -0700 (PDT) Received: from ?IPv6:2406:e001:5618:1:28cc:dc4c:9703:6781? ([2406:e001:5618:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 74sm26673235pga.58.2017.05.31.20.22.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 20:22:27 -0700 (PDT) To: Michael Richardson Cc: Anima WG References: <05b21e01-d856-ded5-87ec-da9d0f983310@gmail.com> <26917.1496083744@obiwan.sandelman.ca> <21a266aa-5650-d6bd-5a2d-a02bfc60eedc@gmail.com> <30412.1496162228@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 1 Jun 2017 15:22:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <30412.1496162228@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Need WG input: Alexy Melnikov's suggestion on GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 03:22:31 -0000 On 31/05/2017 04:37, Michael Richardson wrote: > Brian E Carpenter wrote: > > >> Brian E Carpenter wrote: > I have > >> started the process of going through IESG comments on the GRASP > > >> draft. Where something is editorial or obviously non-controversial, I > >> > will not ask for input. But I do need input on some things, and here > >> is > the first. Please answer quickly; no answer will be taken to > >> mean that > you don't care... > >> > >> > Alexy wrote: >>> uri-locator = [O_URI_LOCATOR, text] > >> >>> > >> >>> I suggest inclusion of optional transport protocol here to match > >> >>> other locators and to follow best practices for not encoding >>> > >> transport information in URIs. > >> > >> > That would become uri-locator = [O_URI_LOCATOR, text, > >> transport-proto, > port-number] > >> > >> > Opinions? Objections? > >> > >> If the resource is really at https://example.com:9943/my/path > >> > >> what would text, transport-proto be? > > > "https://example.com:9943/my/path", Null, Null perhaps. > > > Also of course see the thread on Adam Roach's comment. > > okay, then give me an example where it wouldn't be null and null? funnyschema:funny.stuff Who knows what proto and port might be appropriate? I'll buy Alexy's suggestion, because it really costs nothing. Brian From nobody Wed May 31 20:48:46 2017 Return-Path: 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 D41131294D4 for ; Wed, 31 May 2017 20:48:44 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEUBLpjSclSl for ; Wed, 31 May 2017 20:48:43 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 E85B01294CF for ; Wed, 31 May 2017 20:48:42 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id n23so25376150pfb.2 for ; Wed, 31 May 2017 20:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=J29Oa9GFBPl+x+ygghS3xHjlNzo5FL0056rz1zNTAl4=; b=k1Sld7njeeMrWghVa3sJ7h/arnG7V0cQ5GTUbY21tbjTvKDkv2hWZJwcF+O4QSsrnB 8so8xnBFP1UfbdxdfPwI4xVIIAMjxqHgfFblBiB+dSSnWSPj3WYB0A6s35Lqk75a2W4r MLgLTCtwC2Mxy3POJCMmEZEPRI1YKNmf6as2aKrpDSKVBjfKuCodAPyzHc7w+T2XWBtZ 8cWqejknubRsq0IfGSkdTKf2XIvJszGLH5c676Ww8EbmI0IOuFuGjUKrlntJ8fTX0QPv js3Ml3iNQBKUxJBmu6f9D/N7/47uIiITOFS62wPnOj76h0733bnlAEqChuC9UxWG2ftk z/0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=J29Oa9GFBPl+x+ygghS3xHjlNzo5FL0056rz1zNTAl4=; b=QNkeJBOy4/+/XUD51F0+TMu4hF1B0F7XDl+KC+f7esBrfDYlxnc95TcFW2OB+jf6cr Ra129vi/JNeY+vZfWnq3lDJ5Py9UWZzi42qU7P+e4u5LxftKS5ZQw+lROw+dZnPVwxH6 GGTTsfejYTg3GjtXYBOcets7J5YAUBi9H3BOEYuyayH9OyF5xwPAawH50VTUmzj0J1HY IAmyW7792dhIkho1DVtDoPvaNUXxsx2jzOCXwSlJ1Z0akyLNA648kmxEC42bn5hB+fVa lUKRaLTaH/fhslJb1mVrgmHBAkGovpkLrcXi3IZL3HBzNs4l+9jU6UV3Gj4Fg0/o3F4f HAhA== X-Gm-Message-State: AODbwcAqpT1r16xfRtcd9KQl83POhx+SWd3ZzMGJdiPbpOwWGCuAhvvg Cg5RIw51+RZj6BdD X-Received: by 10.99.175.19 with SMTP id w19mr11951203pge.67.1496288922416; Wed, 31 May 2017 20:48:42 -0700 (PDT) Received: from ?IPv6:2406:e001:5618:1:28cc:dc4c:9703:6781? ([2406:e001:5618:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q24sm36478017pfj.3.2017.05.31.20.48.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 20:48:41 -0700 (PDT) To: anima@ietf.org References: <149549285151.31698.4933027087319976975.idtracker@ietfa.amsl.com> <1a4b149e-25f0-d4d8-1e31-4d497703129d@gmail.com> <25240.1496177632@obiwan.sandelman.ca> <9C702B81-E02E-4341-BF0B-BE3FEBBFFE49@tzi.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 1 Jun 2017 15:48:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <9C702B81-E02E-4341-BF0B-BE3FEBBFFE49@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Need WG input: Adam Roach's comment on GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 03:48:45 -0000 We can do that, when we need it. To get the draft out of the door, I'll d= o what was previously suggested: > Proposal: Note in the text that the current values are taken from the > existing Protocol Numbers registry. Also note that if values are requir= ed > in future that are not in that registry, a new registry for values >255= > will be created. So IANA doesn't have to do anything now. Brian On 31/05/2017 18:56, Carsten Bormann wrote: > Ah. 3.9.5.1 currently does not have a =E2=80=9C.within=E2=80=9D clause= giving an expectation as to how the type "transport-proto=E2=80=9D is go= ing to grow as the protocol evolves. Foolishly, my brain inserted =E2=80= =9Cuint=E2=80=9D as the most obvious envelope type. >=20 > Allowing negative values for transport-proto certainly would be possibl= e. > As a design pattern, I try to reserve broad ranges like this for the in= dication of differences that a receiver can act upon without understandin= g the details, such as the difference between base attributes and other a= ttributes in SenML. >=20 > So I still would favor sticking with uint for now and carving out a ran= ge of that for experimental. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On May 30, 2017, at 22:53, Michael Richardson = wrote: >> >> >> Carsten Bormann wrote: >>> If we ever add not-over-IP =E2=80=9Ctransports=E2=80=9D, there might = be a need for >>> experiments before we go registering. So I would probably identify a= >>> range of numbers that are strictly reserved for use in experiments. >>> (This needn=E2=80=99t be very small; say, 65280 to 65535.) >> >> -1 to -32! >> >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Wed May 31 20:52:20 2017 Return-Path: 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 97AC81294D4; Wed, 31 May 2017 20:52:17 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikX5Noc9mPTk; Wed, 31 May 2017 20:52:16 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 7F5561294CF; Wed, 31 May 2017 20:52:16 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id n23so6049301pfb.3; Wed, 31 May 2017 20:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HmSwiUAo4hTvdHUP75gdgjDX/3hQZPbo4yksbro++9Y=; b=UH2PapQAIA+cxSeqBkLrMwxIi6zGPDhlZ8427eYMTHjE/HpPssgr5oQzxgcmTVl5U5 RDV9BRD7W8oGPpw4Vmv0XLnKYDz0Y+O9cBEpkUjHrFWes+OuY6dOByrfvx6v6Di1dD7g aIv7azcThUCwJaL1XpxpQkwJidrn00UNYh744ejsUptggVWXTqIn/4G8KsFZf4tMsm85 y/KWUEGFkLKzESLh9Ba9W22YTSACmeJyXk6FEqHB63Ds2dQgbcN32M3nOKye8MxemWWW rzMikaOZghwlrwOsOLmnO0ooWR6aky4VmcHca0Kg40L6AxA3vD33kML6OIMhOXQLZell 7hGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=HmSwiUAo4hTvdHUP75gdgjDX/3hQZPbo4yksbro++9Y=; b=hE9D2ym+Uzx7vYkScj3t/NDqjVSdiPqk0SbZaBbhP+et3zY+JFtEc/y0cPIxeVRfM8 8Yh82uxU9XEDyhU3lxeG8Hlj47KKX8YlotxO4QN/Vwa3ixtEVDUY5Mnpzxir2bKNdiP/ FgL29lSjCh57J2mbdp914VZCx4GRmR6OqFrcFbvZsKBbn3jXTv1LJfA3bfkeRBkTorNk LaMSv3Us6IXjMtXuz+UWL8ImfOd6Ke0O7F9+tt3A+uA+0NSk/o45MYo4A+e8AI384lGG KForQa1fmlya0WNuJr4lhz2He/Hb0uN+XnxS8Pk1yjs4PxQpwE9UY36Qzh2rjjOT2Vpq kxmA== X-Gm-Message-State: AODbwcCpDteksh5pNakrg3TPDf48kxlVHtUFj2HEBzn5WhIaVFzwTu4V 5Dj4B+GAz/QStwq4 X-Received: by 10.84.171.193 with SMTP id l59mr91851224plb.139.1496289135957; Wed, 31 May 2017 20:52:15 -0700 (PDT) Received: from ?IPv6:2406:e001:5618:1:28cc:dc4c:9703:6781? ([2406:e001:5618:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t13sm34474012pfa.126.2017.05.31.20.52.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 20:52:15 -0700 (PDT) To: Michael Richardson Cc: Ben Campbell , anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-grasp@ietf.org References: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> <27508.1496083908@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 1 Jun 2017 15:52:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <27508.1496083908@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] WG input needed: Ben Campbell's question on GRASP (1) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 03:52:18 -0000 On 30/05/2017 06:51, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> -7, Grasp Message and Options table: Why "Standards Action"? Would you > >> expect some harm to be done if this were only Spec Required? > > > Personal opinion: I see potential for harm. I could imagine that if > > GRASP is a success, then with experience we might be more relaxed about > > it, but for now I tend to be conservative about it. Of course, the WG > > may disagree... > > Is it easier to raise the bar or lower it? I think lowering is easier. > I could live with "Spec Required" or even FCFS for M_* values >65536, btw. Probably, but it's definitely impossible to squeeze toothpaste back in the tube, so IMHO lowering the bar later is the safer approach. Brian > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Wed May 31 20:54:14 2017 Return-Path: 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 3D8F6129C5C; Wed, 31 May 2017 20:54:13 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J42qw5gTZ9VM; Wed, 31 May 2017 20:54:11 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 C867C1294CF; Wed, 31 May 2017 20:54:07 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id f27so6094756pfe.0; Wed, 31 May 2017 20:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=c6MO5F7s0x7LMFejKKuDCIhJ7PNvu850/LXK8X/v/Lo=; b=uSOmcRdJ0/JCHIyEVJivvWQjkRXf8feGTebbnW2KOBUUslqwmR0d/4/CV8BLg2k1gi w8PiUKQHn1x2sRLVC0Lo0CEdq2buZ+c4fACc9VPTIwpf7MMftRA6dWfJZocQAXOc9LQl RRPVhpVmLGssyl4XcfxdsRrdoEtean13vEZtaiHEWbN8aD5hVUp4ShL8+Kq+LjksJjwW ZQlW1Hm8BaohYysvrDf9LfOMT7ou1n/4l6g6CC+hA9By0L8EiIGHvFTcnOmzTzrK00R5 QihwqsaW0YX2upLFOvZdyBNCryoB8CVHttuw+kSXZPkZpmmMJAJTuQiehhN8r/oSFlLl dyeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=c6MO5F7s0x7LMFejKKuDCIhJ7PNvu850/LXK8X/v/Lo=; b=TWcgxuXqX0PqiRGvGqdH4RJNufMU7ZpAJzehsvhGB94C8R1L6pH00C77oj4JRw46FM h/bMLyTZhDsAy37VQsj4KK76EzrdCvz/PpbgPfTKk97zpQfen9iDUI/fxHbBEsJeKKP/ H6XHyhxiQU9nThfVKVvLHQsUvtilmkw6pqRQSBzsJffNFEhkQkBfZT4WkYfZyurCtSUW L4YncpmfENmaAEgDJOlGMIfeR2U5K5yvuYKg3Zy1ge+JRmpNsOFPmD1hqvbGEWqmPGsB lMKKEHzbH1fkIy+b3OT1vEWNSzJNZMWgMNdeYdMmbtYF74ELXe5RqotIm4v8tDXml18k sdEA== X-Gm-Message-State: AODbwcCulAwszf569BxpYXsIdC7AUG9baSGbl6EXvr/VfVe1wS0QAxX1 awuKYUFuHLvZ0p/3 X-Received: by 10.98.59.212 with SMTP id w81mr1021181pfj.107.1496289247279; Wed, 31 May 2017 20:54:07 -0700 (PDT) Received: from ?IPv6:2406:e001:5618:1:28cc:dc4c:9703:6781? ([2406:e001:5618:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m80sm31712750pfg.107.2017.05.31.20.54.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 20:54:06 -0700 (PDT) To: Ben Campbell Cc: draft-ietf-anima-grasp@ietf.org, Sheng Jiang , anima-chairs@ietf.org, anima@ietf.org References: <149550272234.507.6666100470577050600.idtracker@ietfa.amsl.com> <19f8e94f-fe08-f1e8-53f5-6852953690e3@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 1 Jun 2017 15:54:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <19f8e94f-fe08-f1e8-53f5-6852953690e3@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] WG input needed: Ben Campbell's question on GRASP (2) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 03:54:13 -0000 On 29/05/2017 16:02, Brian E Carpenter wrote: > On 23/05/2017 13:25, Ben Campbell wrote: > ... >> - Is section 2 [Requirements] expected to be useful to implementers once this is> published as an RFC? Unless there's a reason otherwise, I would suggest >> moving this to an appendix, or even removing it entirely. As it is, you >> have to wade through an unusual amount of front material before you get >> to the meat of the protocol. > > I'm open to that, and you are not the only reader with that comment. > But we'd need WG consent... I'm not hearing much from the WG but since several new readers have made this comment, my proposal is to move the requirements into an Appendix. If we don't like the look of it when done, we can always move them back again. Brian