From nobody Sun Oct 8 22:08:45 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 355DE132F8F; Sun, 8 Oct 2017 22:08:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Thomson To: Cc: mile@ietf.org, ietf@ietf.org, draft-ietf-mile-rolie.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150752570618.18384.5615358468704377459@ietfa.amsl.com> Date: Sun, 08 Oct 2017 22:08:26 -0700 Archived-At: Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 05:08:26 -0000 Reviewer: Martin Thomson Review result: Almost Ready I have reviewed this document, and - despite what appears to be a lengthy list of issues - I think that it is in pretty good shape. It's clear, readable, and addresses the requirements well. Most of my comments should be trivial to resolve. Major: The decision to define a .well-known URI without a discovery story is - in my opinion - inadvisable. Such a registration is usually appropriate if you design a protocol that depends on discovery by hostname and port. As such, this does not use that at all. A configuration system can (and should) accept a complete URI for the service endpoint. It would be better to defer creation of yet another .well-known URI registration until the working group is certain that discovery requires it. The same comment applies to the .well-known resource for the category document. Given that this sort of document is readily discoverable via the service document, I would say that the need for a .well-known resource is less well-justified than the service document. The requirements in Section 5.3 on TLS use are unnecessarily strict. It's great to recommend the use of TLS 1.2, but given that the document has no real requirement on any particular version of TLS, the use of "MUST" here is not needed. Similarly, the prohibition on the use of 0-RTT is groundless. The lengthy list of requirements around certificate validation only risk creating a conflict with advice in other RFCs. Many, if not all, of these requirements are transitively included by way of referencing HTTPS documents. I would prefer to see this entire section reduced to a simple RFC 7525 reference. User authentication is under-specified. * Section 5.3 mandates the use of TLS cipher suites that support client authentication using certificates, but offers no further advice. Aside from being an unnecessary requirement - cipher suites that support certificate-based authentication of servers all allow for client authentication - this sort of requirement is rarely sufficient for interoperation. For instance, you need to specify how a server will request a certificate such that clients can select the correct certificate. If a client and server have agreed to share information on terms that rely on authentication of clients, it is better for those peers to arrange the terms on which they will authenticate. * Section 5.4 uses "SHOULD" regarding client authentication using federation, but offers no hints about what this entails. It also uses "SHOULD" regarding authorization checks, which isn't an interoperability requirement. It's more of a "don't be silly" type of requirement, which doesn't need to be written down in an RFC. Section 5.5 prohibits the use of GET on "/". This prohibits use of the resource for other purposes. It seems reasonable to accept POST messages as defined in RFC 6546, but this requirement is overly strict (and further entrenches the violation of RFC 7320). If, for instance, the server operator wishes to provide HTML in response to a GET request to "/", this would prohibit that. The requirement to return 404 if RFC 6546 is not supported is worse; not supporting RFC 6546 might be a choice that a deployment makes to avoid the need to reserve "/" for that protocol. In Section 6.2.3, what is the advantage of "rolie:format" over having a well-defined media type? Media types can take advantage of content negotiation, existing support in link relations, and other existing tools. This rolie:format element has namespace, format, and schema; these are not useful to anyone that is ignorant of their contents. The only advantage I see is that syntax might be validated, but semantics can't be extracted. There's a lot of implied work in adding this element, but that doesn't seem to be justified by that advantage. (I see that RFC 7970 doesn't define a media type, but it seems like it would be easier to correct that than to define an element like this.) Section 6.2.4 defines a generic key-value mechanism. But that is something that XML is actually good at. Why can't users that require additional metadata use additional metadata as originally defined by Atom? That is, replace with something like 12345. The final paragraph of the section recognizes this possibility. Minor: Section 5.1.1 recommends the use of workspaces to separate "private" and "public" information. But workspaces don't really contain enough information to signal their status to a consumer of the information. I would suggest mentioning this, removing the recommendation, or expanding on the manner in which the status of information is signaled. Section 6.1.1 says "zero or more atom:category elements", but this contradicts the text and amendment to the schema in Section 6.1. Section 6.1.3 requires updating the "atom:updated" element when the representation changes. I don't think that this is what was intended. I think that the element needs to be updated when the contents of the feed change in any way. Question: it's fairly widely accepted that use of IRIs in Atom has been less than successful. Do you want to mandate use of URIs instead? This would apply to both link relations and the "src" attribute. In Section 7.1, the definition of the namespace prefix "urn:ietf:params:rolie:category:local" seems unnecessary. Namespace URIs are cheap and it seems reasonable to experiment with feeds that produce non-ROLIE information by omitting the "urn:ietf:params:rolie:category:information-type" category, even if that feed might comply with the requirements of ROLIE. The other way to experiment would be to use the category, but define a way to identify "term" attributes that are for use in private or experimental contexts. In Section 7.4, how is "...:rolie:property:content-author-name" superior to "atom:author"? In Section 8.4, is there a uniqueness requirement on "name"? I understand this to be the thing that being registered. Assuming that, what purpose does the "index" serve? This statement from Section 9, "As described in the discovery section, DNS SRV Records are a possible secure solution to discovery." is false without further qualification. SRV with DNSSEC might be secure, but a lot depends on the input to the discovery process and its provenance. In Section 10, the following statement is false (all of the described privacy violations are available to a client or server, not third parties): "Proper usage of TLS as described in Section 5.3 will in many cases aid in the mitigation of these issues." I think that you can strike this statement (most of the reason for use of TLS is justified by the security considerations anyway). Nits: Is it "Feed" or "feed"? RFC 4287 uses the latter, but this document seems to prefer the Proper Noun form. Section 6.2 should say what changed in the schema. It's hard to eyeball the schema to discover that "atomContent" is no longer optional. The two new elements are easy to spot and might cause the first change to be missed. Section 6.2.1 is the same. It should explicitly say that it only permits the atomOutOfLineContent formulation. I found the formulation of Section 7.1.1 confusing. It includes a list that seems to be authoritative, then disclaims any attempt to register these terms. Maybe this is because the statement "This document does not specify any information types." appears too late. Some reordering might help. The formatting of the table in Section 8.3 makes most of the columns unreadable. I would recommend a simple nested list. In section 9, the use of the term "well-known" to refer to information that is either public or widely available risks misinterpretation. FWIW, I would reword this entire paragraph to say simply "Access control to information published using ROLIE should use mechanisms that are appropriate to the sensitivity of the information. Primitive authentication mechanisms like HTTP Basic Authentication [RFC7617] are rarely appropriate for sensitive information." I didn't find the remainder of the text on authentication especially helpful. The text seems to equivocate on the subject of federation, where it would be easier to say nothing. Also in Section 9, the use of the term "message" is used in the context of using additional security controls. I think that the word "representation" is what was intended here. From nobody Sun Oct 8 22:08:49 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 65CC41342E1; Sun, 8 Oct 2017 22:08:26 -0700 (PDT) X-Original-To: draft-ietf-mile-rolie.all@ietf.org Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 355DE132F8F; Sun, 8 Oct 2017 22:08:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Thomson To: Cc: mile@ietf.org, ietf@ietf.org, draft-ietf-mile-rolie.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150752570618.18384.5615358468704377459@ietfa.amsl.com> Date: Sun, 08 Oct 2017 22:08:26 -0700 Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171009050826.65CC41342E1@ietfa.amsl.com> Resent-Date: Sun, 8 Oct 2017 22:08:26 -0700 (PDT) Archived-At: Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 05:08:26 -0000 Reviewer: Martin Thomson Review result: Almost Ready I have reviewed this document, and - despite what appears to be a lengthy list of issues - I think that it is in pretty good shape. It's clear, readable, and addresses the requirements well. Most of my comments should be trivial to resolve. Major: The decision to define a .well-known URI without a discovery story is - in my opinion - inadvisable. Such a registration is usually appropriate if you design a protocol that depends on discovery by hostname and port. As such, this does not use that at all. A configuration system can (and should) accept a complete URI for the service endpoint. It would be better to defer creation of yet another .well-known URI registration until the working group is certain that discovery requires it. The same comment applies to the .well-known resource for the category document. Given that this sort of document is readily discoverable via the service document, I would say that the need for a .well-known resource is less well-justified than the service document. The requirements in Section 5.3 on TLS use are unnecessarily strict. It's great to recommend the use of TLS 1.2, but given that the document has no real requirement on any particular version of TLS, the use of "MUST" here is not needed. Similarly, the prohibition on the use of 0-RTT is groundless. The lengthy list of requirements around certificate validation only risk creating a conflict with advice in other RFCs. Many, if not all, of these requirements are transitively included by way of referencing HTTPS documents. I would prefer to see this entire section reduced to a simple RFC 7525 reference. User authentication is under-specified. * Section 5.3 mandates the use of TLS cipher suites that support client authentication using certificates, but offers no further advice. Aside from being an unnecessary requirement - cipher suites that support certificate-based authentication of servers all allow for client authentication - this sort of requirement is rarely sufficient for interoperation. For instance, you need to specify how a server will request a certificate such that clients can select the correct certificate. If a client and server have agreed to share information on terms that rely on authentication of clients, it is better for those peers to arrange the terms on which they will authenticate. * Section 5.4 uses "SHOULD" regarding client authentication using federation, but offers no hints about what this entails. It also uses "SHOULD" regarding authorization checks, which isn't an interoperability requirement. It's more of a "don't be silly" type of requirement, which doesn't need to be written down in an RFC. Section 5.5 prohibits the use of GET on "/". This prohibits use of the resource for other purposes. It seems reasonable to accept POST messages as defined in RFC 6546, but this requirement is overly strict (and further entrenches the violation of RFC 7320). If, for instance, the server operator wishes to provide HTML in response to a GET request to "/", this would prohibit that. The requirement to return 404 if RFC 6546 is not supported is worse; not supporting RFC 6546 might be a choice that a deployment makes to avoid the need to reserve "/" for that protocol. In Section 6.2.3, what is the advantage of "rolie:format" over having a well-defined media type? Media types can take advantage of content negotiation, existing support in link relations, and other existing tools. This rolie:format element has namespace, format, and schema; these are not useful to anyone that is ignorant of their contents. The only advantage I see is that syntax might be validated, but semantics can't be extracted. There's a lot of implied work in adding this element, but that doesn't seem to be justified by that advantage. (I see that RFC 7970 doesn't define a media type, but it seems like it would be easier to correct that than to define an element like this.) Section 6.2.4 defines a generic key-value mechanism. But that is something that XML is actually good at. Why can't users that require additional metadata use additional metadata as originally defined by Atom? That is, replace with something like 12345. The final paragraph of the section recognizes this possibility. Minor: Section 5.1.1 recommends the use of workspaces to separate "private" and "public" information. But workspaces don't really contain enough information to signal their status to a consumer of the information. I would suggest mentioning this, removing the recommendation, or expanding on the manner in which the status of information is signaled. Section 6.1.1 says "zero or more atom:category elements", but this contradicts the text and amendment to the schema in Section 6.1. Section 6.1.3 requires updating the "atom:updated" element when the representation changes. I don't think that this is what was intended. I think that the element needs to be updated when the contents of the feed change in any way. Question: it's fairly widely accepted that use of IRIs in Atom has been less than successful. Do you want to mandate use of URIs instead? This would apply to both link relations and the "src" attribute. In Section 7.1, the definition of the namespace prefix "urn:ietf:params:rolie:category:local" seems unnecessary. Namespace URIs are cheap and it seems reasonable to experiment with feeds that produce non-ROLIE information by omitting the "urn:ietf:params:rolie:category:information-type" category, even if that feed might comply with the requirements of ROLIE. The other way to experiment would be to use the category, but define a way to identify "term" attributes that are for use in private or experimental contexts. In Section 7.4, how is "...:rolie:property:content-author-name" superior to "atom:author"? In Section 8.4, is there a uniqueness requirement on "name"? I understand this to be the thing that being registered. Assuming that, what purpose does the "index" serve? This statement from Section 9, "As described in the discovery section, DNS SRV Records are a possible secure solution to discovery." is false without further qualification. SRV with DNSSEC might be secure, but a lot depends on the input to the discovery process and its provenance. In Section 10, the following statement is false (all of the described privacy violations are available to a client or server, not third parties): "Proper usage of TLS as described in Section 5.3 will in many cases aid in the mitigation of these issues." I think that you can strike this statement (most of the reason for use of TLS is justified by the security considerations anyway). Nits: Is it "Feed" or "feed"? RFC 4287 uses the latter, but this document seems to prefer the Proper Noun form. Section 6.2 should say what changed in the schema. It's hard to eyeball the schema to discover that "atomContent" is no longer optional. The two new elements are easy to spot and might cause the first change to be missed. Section 6.2.1 is the same. It should explicitly say that it only permits the atomOutOfLineContent formulation. I found the formulation of Section 7.1.1 confusing. It includes a list that seems to be authoritative, then disclaims any attempt to register these terms. Maybe this is because the statement "This document does not specify any information types." appears too late. Some reordering might help. The formatting of the table in Section 8.3 makes most of the columns unreadable. I would recommend a simple nested list. In section 9, the use of the term "well-known" to refer to information that is either public or widely available risks misinterpretation. FWIW, I would reword this entire paragraph to say simply "Access control to information published using ROLIE should use mechanisms that are appropriate to the sensitivity of the information. Primitive authentication mechanisms like HTTP Basic Authentication [RFC7617] are rarely appropriate for sensitive information." I didn't find the remainder of the text on authentication especially helpful. The text seems to equivocate on the subject of federation, where it would be easier to say nothing. Also in Section 9, the use of the term "message" is used in the context of using additional security controls. I think that the word "representation" is what was intended here. From nobody Mon Oct 9 09:19:03 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851B713456C; Mon, 9 Oct 2017 09:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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=mnot.net header.b=T9ujnNDV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FsX3WZab 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 Zj2A5lEeIgcQ; Mon, 9 Oct 2017 09:18:53 -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 2495F13465C; Mon, 9 Oct 2017 09:18:53 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7D89F20DA6; Mon, 9 Oct 2017 12:18:52 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 09 Oct 2017 12:18:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; 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=vvkwI/mlKI0khE1aoV dvA4ZiKqv0KOSg1GnG+t8bgG8=; b=T9ujnNDVTtkI8DpV5M/anSy9UeEs55LV4Y w4EKKU2fvcS1QWfI4xORR47cIcGZil8C9QlzeRie4ZY9OEUrJk9oubPYzQZm7x2X EUWA39piYhW4NEDh6QcUF5RQSqQv0BoWTnHm2SOmSOGcLouXh6wqJtrQyK2tkJU+ qmkNPMUfv53xM4/cz0SL+70z0Yiikjo4sZQSUMM4Un9bHooa+IGa+RB8qO2xz2fh HLOfYlExNmmv5z+4hB8ozncwEayITP3kNMEAbl1YT95MwLsyY7wlFQJO3Ehopna+ iP1zzLZOTZuDdI/hTGF8uTOKeRoG1KRd6UwapGBAGPrZWsaLBRlQ== 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=vvkwI/mlKI0khE1aoVdvA4ZiKqv0KOSg1GnG+t8bgG8=; b=FsX3WZab gDycx7T2Ho5pp3CHSheGpJpVgdKXKlAkKNrnFTZJtRxhGP4N2ebEQrZFm8G265oQ cXEq2u21pqtm/y5+SzYpLqSBT1Zve5lsoIA5BCR9ym68iCltcrFINWIRr6wBo3gp xet/RoV8CFpk+hVygHzlH1ErnKdrL4ttIvYYHPXd+pISBun1WZa3x6oxr0xbqTAx vfvgkc4O2j83WP2PK+cS5r8y+O3lQEP0eopWL50vPO1ncicpGxF8gnv15/8GuuAd iM4A7K/bdeQXEOdQdH7/qS+gVLzP9mfXEFh+3OZxiQBH9SyrNupPYzKHTT8F9LcF kPj3iaNkG565kw== X-ME-Sender: X-Sasl-enc: UJ1nunGy0ofHQVWk9eKtshY7NegoDsltz1SLET1BMZuS 1507565932 Received: from [10.100.20.97] (unknown [8.18.217.202]) by mail.messagingengine.com (Postfix) with ESMTPA id CB16D2413F; Mon, 9 Oct 2017 12:18:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Mark Nottingham In-Reply-To: <150752570618.18384.5615358468704377459@ietfa.amsl.com> Date: Mon, 9 Oct 2017 09:18:50 -0700 Cc: art@ietf.org, mile@ietf.org, ietf@ietf.org, draft-ietf-mile-rolie.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [mile] [art] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 16:18:55 -0000 On 8 Oct 2017, at 10:08 pm, Martin Thomson = wrote: >=20 > The decision to define a .well-known URI without a discovery story is = - in my > opinion - inadvisable. Such a registration is usually appropriate if = you > design a protocol that depends on discovery by hostname and port. As = such, > this does not use that at all. A configuration system can (and = should) accept > a complete URI for the service endpoint. It would be better to defer = creation > of yet another .well-known URI registration until the working group is = certain > that discovery requires it. I'll second this.=20 Generally, you only want to register a .well-known when there's a good = story for why using a URL isn't possible. Typically, this is when you = genuinely need to convey policy or metadata applicable to the whole = origin.=20 =46rom 5785: """ well-known URIs are not intended for general information retrieval or = establishment of large URI namespaces on the Web. Rather, they are = designed to facilitate discovery of information on a site when it isn't = practical to use other mechanisms; for example, when discovering policy = that needs to be evaluated before a resource is accessed, or when using = multiple round-trips is judged detrimental to performance. As such, the well-known URI space was created with the expectation that = it will be used to make site-wide policy information and other metadata = available directly (if sufficiently concise), or provide references to = other URIs that provide such metadata. """ Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Oct 9 09:19:13 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B8D4B13465C; Mon, 9 Oct 2017 09:18:55 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851B713456C; Mon, 9 Oct 2017 09:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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=mnot.net header.b=T9ujnNDV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FsX3WZab 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 Zj2A5lEeIgcQ; Mon, 9 Oct 2017 09:18:53 -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 2495F13465C; Mon, 9 Oct 2017 09:18:53 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7D89F20DA6; Mon, 9 Oct 2017 12:18:52 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 09 Oct 2017 12:18:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; 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=vvkwI/mlKI0khE1aoV dvA4ZiKqv0KOSg1GnG+t8bgG8=; b=T9ujnNDVTtkI8DpV5M/anSy9UeEs55LV4Y w4EKKU2fvcS1QWfI4xORR47cIcGZil8C9QlzeRie4ZY9OEUrJk9oubPYzQZm7x2X EUWA39piYhW4NEDh6QcUF5RQSqQv0BoWTnHm2SOmSOGcLouXh6wqJtrQyK2tkJU+ qmkNPMUfv53xM4/cz0SL+70z0Yiikjo4sZQSUMM4Un9bHooa+IGa+RB8qO2xz2fh HLOfYlExNmmv5z+4hB8ozncwEayITP3kNMEAbl1YT95MwLsyY7wlFQJO3Ehopna+ iP1zzLZOTZuDdI/hTGF8uTOKeRoG1KRd6UwapGBAGPrZWsaLBRlQ== 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=vvkwI/mlKI0khE1aoVdvA4ZiKqv0KOSg1GnG+t8bgG8=; b=FsX3WZab gDycx7T2Ho5pp3CHSheGpJpVgdKXKlAkKNrnFTZJtRxhGP4N2ebEQrZFm8G265oQ cXEq2u21pqtm/y5+SzYpLqSBT1Zve5lsoIA5BCR9ym68iCltcrFINWIRr6wBo3gp xet/RoV8CFpk+hVygHzlH1ErnKdrL4ttIvYYHPXd+pISBun1WZa3x6oxr0xbqTAx vfvgkc4O2j83WP2PK+cS5r8y+O3lQEP0eopWL50vPO1ncicpGxF8gnv15/8GuuAd iM4A7K/bdeQXEOdQdH7/qS+gVLzP9mfXEFh+3OZxiQBH9SyrNupPYzKHTT8F9LcF kPj3iaNkG565kw== X-ME-Sender: X-Sasl-enc: UJ1nunGy0ofHQVWk9eKtshY7NegoDsltz1SLET1BMZuS 1507565932 Received: from [10.100.20.97] (unknown [8.18.217.202]) by mail.messagingengine.com (Postfix) with ESMTPA id CB16D2413F; Mon, 9 Oct 2017 12:18:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Mark Nottingham In-Reply-To: <150752570618.18384.5615358468704377459@ietfa.amsl.com> Date: Mon, 9 Oct 2017 09:18:50 -0700 Cc: art@ietf.org, mile@ietf.org, ietf@ietf.org, draft-ietf-mile-rolie.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.1.7) Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171009161855.B8D4B13465C@ietfa.amsl.com> Resent-Date: Mon, 9 Oct 2017 09:18:55 -0700 (PDT) Archived-At: Subject: Re: [mile] [art] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 16:18:56 -0000 On 8 Oct 2017, at 10:08 pm, Martin Thomson = wrote: >=20 > The decision to define a .well-known URI without a discovery story is = - in my > opinion - inadvisable. Such a registration is usually appropriate if = you > design a protocol that depends on discovery by hostname and port. As = such, > this does not use that at all. A configuration system can (and = should) accept > a complete URI for the service endpoint. It would be better to defer = creation > of yet another .well-known URI registration until the working group is = certain > that discovery requires it. I'll second this.=20 Generally, you only want to register a .well-known when there's a good = story for why using a URL isn't possible. Typically, this is when you = genuinely need to convey policy or metadata applicable to the whole = origin.=20 =46rom 5785: """ well-known URIs are not intended for general information retrieval or = establishment of large URI namespaces on the Web. Rather, they are = designed to facilitate discovery of information on a site when it isn't = practical to use other mechanisms; for example, when discovering policy = that needs to be evaluated before a resource is accessed, or when using = multiple round-trips is judged detrimental to performance. As such, the well-known URI space was created with the expectation that = it will be used to make site-wide policy information and other metadata = available directly (if sufficiently concise), or provide references to = other URIs that provide such metadata. """ Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Oct 9 16:57:39 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250E31270AB; Mon, 9 Oct 2017 16:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 uTrp0yXobhIK; Mon, 9 Oct 2017 16:57:24 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 9CF06120720; Mon, 9 Oct 2017 16:57:23 -0700 (PDT) X-AuditID: 1209190e-823ff7000000797d-18-59dc0ce29c97 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id E8.4E.31101.2EC0CD95; Mon, 9 Oct 2017 19:57:22 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v99NvLDx011267; Mon, 9 Oct 2017 19:57:21 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v99NvHCE015911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Oct 2017 19:57:19 -0400 Date: Mon, 9 Oct 2017 18:57:17 -0500 From: Benjamin Kaduk To: Martin Thomson Cc: art@ietf.org, mile@ietf.org, ietf@ietf.org, draft-ietf-mile-rolie.all@ietf.org Message-ID: <20171009235717.GN96685@kduck.kaduk.org> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150752570618.18384.5615358468704377459@ietfa.amsl.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrPuI506kwa7jKhYr7npY/L/zl93i 2cb5LBbXzvxjtNjzv4/JgdVj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4s/Aic8EBzoo9 878wNjCeY+9i5OSQEDCR+H/sIROILSSwmEli++rYLkYuIHsDo8TlDdcZIZwrTBIPF11jBqli EVCR2LrkJ1g3G5Dd0H0ZLC4ioCux6OwDsDizQLTEwp6JbCC2sICDxPYfTWA1vEDbjs04wNrF yAE01Fni/GFpiLCgxMmZT1ggWrUkbvx7yQRSwiwgLbH8HwdImFPAReL4zjZGEFtUQFli3r5V bBMYBWYh6Z6FpHsWQvcCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFusZ6uZkleqkppZsYweEr ybeDcVKD9yFGAQ5GJR7eBZNvRwqxJpYVV+YeYpTkYFIS5b3CfSdSiC8pP6UyI7E4I76oNCe1 +BCjBAezkgiv832gct6UxMqq1KJ8mJQ0B4uSOO+2oF2RQgLpiSWp2ampBalFMFkZDg4lCd7X IEMFi1LTUyvSMnNKENJMHJwgw3mAhm8BqeEtLkjMLc5Mh8ifYlSUEuc1AEkIgCQySvPgekHp RSJ7f80rRnGgV4R5+0GqeICpCa77FdBgJqDBjMU3QAaXJCKkpBoYt9+O+t2x0CnDzkaTb5fE yg0TVixieXXT/znLz/pSx9L0N5e3vbrywmDGOi7j41EMmrKbbHie1iaEvIud/iHixvwZWqyG axddeXSV+dSZr1/2iLkVtu3yX+oibKeQHnZ6bUHgrLt5Btk3c9Q+1c6bcFmP6V5ahhPXxrme 61nO7JD9Gj9h9uvHi5VYijMSDbWYi4oTARfoVwgKAwAA Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 23:57:25 -0000 On Sun, Oct 08, 2017 at 10:08:26PM -0700, Martin Thomson wrote: > > The requirements in Section 5.3 on TLS use are unnecessarily strict. It's > great to recommend the use of TLS 1.2, but given that the document has no real > requirement on any particular version of TLS, the use of "MUST" here is not I think that one could make the case that using TLS 1.2 (or higher) greatly facilitates having a secure system, and so it could plausibly be required by a consuming protocol. > needed. Similarly, the prohibition on the use of 0-RTT is groundless. The I am a little surprised to hear you say that this prohibition is "groundless". Given that we require consumers of TLS 1.3 0-RTT data to explictly specify an application profile for how it may be used, with the intent to induce a careful analysis of the security considerations for sending early data messages, it seems quite reasonable to me that a protocol author might wish to defer such a painstaking analysis and take the easy choice of prohibiting early data. -Ben > lengthy list of requirements around certificate validation only risk creating a > conflict with advice in other RFCs. Many, if not all, of these requirements From nobody Mon Oct 9 16:57:47 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 743FE120720; Mon, 9 Oct 2017 16:57:25 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250E31270AB; Mon, 9 Oct 2017 16:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 uTrp0yXobhIK; Mon, 9 Oct 2017 16:57:24 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 9CF06120720; Mon, 9 Oct 2017 16:57:23 -0700 (PDT) X-AuditID: 1209190e-823ff7000000797d-18-59dc0ce29c97 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id E8.4E.31101.2EC0CD95; Mon, 9 Oct 2017 19:57:22 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v99NvLDx011267; Mon, 9 Oct 2017 19:57:21 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v99NvHCE015911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Oct 2017 19:57:19 -0400 Date: Mon, 9 Oct 2017 18:57:17 -0500 From: Benjamin Kaduk To: Martin Thomson Cc: art@ietf.org, mile@ietf.org, ietf@ietf.org, draft-ietf-mile-rolie.all@ietf.org Message-ID: <20171009235717.GN96685@kduck.kaduk.org> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150752570618.18384.5615358468704377459@ietfa.amsl.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrPuI506kwa7jKhYr7npY/L/zl93i 2cb5LBbXzvxjtNjzv4/JgdVj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4s/Aic8EBzoo9 878wNjCeY+9i5OSQEDCR+H/sIROILSSwmEli++rYLkYuIHsDo8TlDdcZIZwrTBIPF11jBqli EVCR2LrkJ1g3G5Dd0H0ZLC4ioCux6OwDsDizQLTEwp6JbCC2sICDxPYfTWA1vEDbjs04wNrF yAE01Fni/GFpiLCgxMmZT1ggWrUkbvx7yQRSwiwgLbH8HwdImFPAReL4zjZGEFtUQFli3r5V bBMYBWYh6Z6FpHsWQvcCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFusZ6uZkleqkppZsYweEr ybeDcVKD9yFGAQ5GJR7eBZNvRwqxJpYVV+YeYpTkYFIS5b3CfSdSiC8pP6UyI7E4I76oNCe1 +BCjBAezkgiv832gct6UxMqq1KJ8mJQ0B4uSOO+2oF2RQgLpiSWp2ampBalFMFkZDg4lCd7X IEMFi1LTUyvSMnNKENJMHJwgw3mAhm8BqeEtLkjMLc5Mh8ifYlSUEuc1AEkIgCQySvPgekHp RSJ7f80rRnGgV4R5+0GqeICpCa77FdBgJqDBjMU3QAaXJCKkpBoYt9+O+t2x0CnDzkaTb5fE yg0TVixieXXT/znLz/pSx9L0N5e3vbrywmDGOi7j41EMmrKbbHie1iaEvIud/iHixvwZWqyG axddeXSV+dSZr1/2iLkVtu3yX+oibKeQHnZ6bUHgrLt5Btk3c9Q+1c6bcFmP6V5ahhPXxrme 61nO7JD9Gj9h9uvHi5VYijMSDbWYi4oTARfoVwgKAwAA Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171009235725.743FE120720@ietfa.amsl.com> Resent-Date: Mon, 9 Oct 2017 16:57:25 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 23:57:25 -0000 On Sun, Oct 08, 2017 at 10:08:26PM -0700, Martin Thomson wrote: > > The requirements in Section 5.3 on TLS use are unnecessarily strict. It's > great to recommend the use of TLS 1.2, but given that the document has no real > requirement on any particular version of TLS, the use of "MUST" here is not I think that one could make the case that using TLS 1.2 (or higher) greatly facilitates having a secure system, and so it could plausibly be required by a consuming protocol. > needed. Similarly, the prohibition on the use of 0-RTT is groundless. The I am a little surprised to hear you say that this prohibition is "groundless". Given that we require consumers of TLS 1.3 0-RTT data to explictly specify an application profile for how it may be used, with the intent to induce a careful analysis of the security considerations for sending early data messages, it seems quite reasonable to me that a protocol author might wish to defer such a painstaking analysis and take the easy choice of prohibiting early data. -Ben > lengthy list of requirements around certificate validation only risk creating a > conflict with advice in other RFCs. Many, if not all, of these requirements From nobody Mon Oct 9 18:11:39 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A53134323; Mon, 9 Oct 2017 18:11:27 -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 AhlsbGx76X-2; Mon, 9 Oct 2017 18:11:26 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 10F5413239C; Mon, 9 Oct 2017 18:11:26 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id v132so23292267oie.1; Mon, 09 Oct 2017 18:11:26 -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=q4Eq1jDPoG6fhlfjvLM+/r13zvpZimaEHBa7Od1rm4M=; b=GctBaEpSmbLOh5jg1J6I6d3FHZg31S7XkkFW1DlFDHVVi0Jnp0ZEXr2c5fzPcOZMGe +J9FZeAX1ZhPbvrgJvd+OwfOcaO19L6WfHZ2lLyT/g7J9iAlC5AmSOfO2mKC3DHLGmxr /VVmhYSnhY2HPfa7VY4KWwqJNGqVGZR7vUfoubq9XsjTBnEwiW+G6VEA6d2v4Z4Ywhwa xn/AS5rv8KesVYYjG/q6bJDYbKH/5ENp7JRagUfUhK+wwXPbzmKl9cxyIoeym55BLaNC H8461G5kXMiYXaEtTtpHWiIswETXwevLJNjiHjFRmvJ20E9V9kq7NQQTGbTYOs98evK5 uvwQ== 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=q4Eq1jDPoG6fhlfjvLM+/r13zvpZimaEHBa7Od1rm4M=; b=CM6p9/w24NiWAjmmtTOrYVBX7/EyOmAaCh4++W/ww5nD5kBe/NptYaikAk+w7SHBWZ QXg9XPbc43HUDLrH0bLXLrgowjJc50M0wPbOgj3GA3V9M9WVCOUv2hkQEqjcFs5CC7DF NFSNd3dweBB1XSzWUHqTuYi0YeZA6GUnR/9Pdfmq4c1lHWEj9neSf/GQQMdGDTEnm7d/ qj2eDmuIqcrbjbVtwDrIGxpcHKO6AU5mRhp8qlXMwCIi4ASpTOBPJWbl++hmpCRTNX9H qtn0xuFoLKAG3HwHnIz20uOZJmftI36cmgsFEeJA9Io0bqsak90Ac7TRHyRN2Zs/dY8A /BWQ== X-Gm-Message-State: AMCzsaWV5HcpFbCM7UBc6ngIPJy55QgOionHrv2Zy+7wDgBEsP4k5TH0 iLbuW3OSzDJgCZ6+juH90o4dHaTPXmbw9iM7PkA= X-Google-Smtp-Source: AOwi7QA3JHBN/5yc/M5T5LK5P11PXSxKTlJn3bbXmM/zlmRhTUEzSu7jCRFEZA1Ix6Y/GUHaZTXTVSaF+qRsWbJwxlI= X-Received: by 10.202.166.141 with SMTP id t13mr6412585oij.392.1507597885358; Mon, 09 Oct 2017 18:11:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Mon, 9 Oct 2017 18:11:24 -0700 (PDT) In-Reply-To: <20171009235717.GN96685@kduck.kaduk.org> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> From: Martin Thomson Date: Tue, 10 Oct 2017 12:11:24 +1100 Message-ID: To: Benjamin Kaduk Cc: ART Area , mile@ietf.org, "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 01:11:27 -0000 On Tue, Oct 10, 2017 at 10:57 AM, Benjamin Kaduk wrote: > I think that one could make the case that using TLS 1.2 (or higher) greatly > facilitates having a secure system, and so it could plausibly be required > by a consuming protocol. The problem here is that the protocol is actually HTTP. And that protocol has requirements already. A recommendation to use TLS 1.2 is fine, but that is already part of RFC 7525. >> needed. Similarly, the prohibition on the use of 0-RTT is groundless. The > > I am a little surprised to hear you say that this prohibition is "groundless". > Given that we require consumers of TLS 1.3 0-RTT data to explictly specify > an application profile for how it may be used, with the intent to induce > a careful analysis of the security considerations for sending early data > messages, it seems quite reasonable to me that a protocol author might > wish to defer such a painstaking analysis and take the easy choice of > prohibiting early data. This is quite explicitly using HTTP, which has a profile (work in progress). If that profile is somehow inadequate, then a case should be made in the draft explaining why (hence the choice of the word). A reference to TLS 1.3 also has the unfortunate effect of delaying publication of this draft. From nobody Mon Oct 9 18:11:46 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 841B613239C; Mon, 9 Oct 2017 18:11:27 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A53134323; Mon, 9 Oct 2017 18:11:27 -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 AhlsbGx76X-2; Mon, 9 Oct 2017 18:11:26 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 10F5413239C; Mon, 9 Oct 2017 18:11:26 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id v132so23292267oie.1; Mon, 09 Oct 2017 18:11:26 -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=q4Eq1jDPoG6fhlfjvLM+/r13zvpZimaEHBa7Od1rm4M=; b=GctBaEpSmbLOh5jg1J6I6d3FHZg31S7XkkFW1DlFDHVVi0Jnp0ZEXr2c5fzPcOZMGe +J9FZeAX1ZhPbvrgJvd+OwfOcaO19L6WfHZ2lLyT/g7J9iAlC5AmSOfO2mKC3DHLGmxr /VVmhYSnhY2HPfa7VY4KWwqJNGqVGZR7vUfoubq9XsjTBnEwiW+G6VEA6d2v4Z4Ywhwa xn/AS5rv8KesVYYjG/q6bJDYbKH/5ENp7JRagUfUhK+wwXPbzmKl9cxyIoeym55BLaNC H8461G5kXMiYXaEtTtpHWiIswETXwevLJNjiHjFRmvJ20E9V9kq7NQQTGbTYOs98evK5 uvwQ== 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=q4Eq1jDPoG6fhlfjvLM+/r13zvpZimaEHBa7Od1rm4M=; b=CM6p9/w24NiWAjmmtTOrYVBX7/EyOmAaCh4++W/ww5nD5kBe/NptYaikAk+w7SHBWZ QXg9XPbc43HUDLrH0bLXLrgowjJc50M0wPbOgj3GA3V9M9WVCOUv2hkQEqjcFs5CC7DF NFSNd3dweBB1XSzWUHqTuYi0YeZA6GUnR/9Pdfmq4c1lHWEj9neSf/GQQMdGDTEnm7d/ qj2eDmuIqcrbjbVtwDrIGxpcHKO6AU5mRhp8qlXMwCIi4ASpTOBPJWbl++hmpCRTNX9H qtn0xuFoLKAG3HwHnIz20uOZJmftI36cmgsFEeJA9Io0bqsak90Ac7TRHyRN2Zs/dY8A /BWQ== X-Gm-Message-State: AMCzsaWV5HcpFbCM7UBc6ngIPJy55QgOionHrv2Zy+7wDgBEsP4k5TH0 iLbuW3OSzDJgCZ6+juH90o4dHaTPXmbw9iM7PkA= X-Google-Smtp-Source: AOwi7QA3JHBN/5yc/M5T5LK5P11PXSxKTlJn3bbXmM/zlmRhTUEzSu7jCRFEZA1Ix6Y/GUHaZTXTVSaF+qRsWbJwxlI= X-Received: by 10.202.166.141 with SMTP id t13mr6412585oij.392.1507597885358; Mon, 09 Oct 2017 18:11:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Mon, 9 Oct 2017 18:11:24 -0700 (PDT) In-Reply-To: <20171009235717.GN96685@kduck.kaduk.org> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> From: Martin Thomson Date: Tue, 10 Oct 2017 12:11:24 +1100 Message-ID: To: Benjamin Kaduk Cc: ART Area , mile@ietf.org, "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171010011127.841B613239C@ietfa.amsl.com> Resent-Date: Mon, 9 Oct 2017 18:11:27 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 01:11:27 -0000 On Tue, Oct 10, 2017 at 10:57 AM, Benjamin Kaduk wrote: > I think that one could make the case that using TLS 1.2 (or higher) greatly > facilitates having a secure system, and so it could plausibly be required > by a consuming protocol. The problem here is that the protocol is actually HTTP. And that protocol has requirements already. A recommendation to use TLS 1.2 is fine, but that is already part of RFC 7525. >> needed. Similarly, the prohibition on the use of 0-RTT is groundless. The > > I am a little surprised to hear you say that this prohibition is "groundless". > Given that we require consumers of TLS 1.3 0-RTT data to explictly specify > an application profile for how it may be used, with the intent to induce > a careful analysis of the security considerations for sending early data > messages, it seems quite reasonable to me that a protocol author might > wish to defer such a painstaking analysis and take the easy choice of > prohibiting early data. This is quite explicitly using HTTP, which has a profile (work in progress). If that profile is somehow inadequate, then a case should be made in the draft explaining why (hence the choice of the word). A reference to TLS 1.3 also has the unfortunate effect of delaying publication of this draft. From nobody Mon Oct 9 18:23:52 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293DD134460; Mon, 9 Oct 2017 18:23:36 -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 vg-Uxlv5Apr8; Mon, 9 Oct 2017 18:23:34 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 D25BC1342E6; Mon, 9 Oct 2017 18:23:34 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id x7so5236424pfa.1; Mon, 09 Oct 2017 18:23:34 -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=+cwGECz2Zewz7vzKsz0xC0QZoBKScFC71kLn7OYbhl4=; b=ZkafJ6AXRlHlWmiJ5FE3SFH6pXyV84GlRNnhnr3HNdbpuITRdipzIXTYDnMbvIbWRZ NeZ/gkSGLNuVyCZEqMey8uLxABgLWMgIHZDrL3M7hVOYHw/abjGSBPEk6Uu7qKP4x6zk gHPmFIYqxne6c7NOm0g52z6hJs/c/uIOQ/QxMKDbCv9IkoraE6+/bxvvu+3HJn9xocNJ pIlLBIfQU5GFGKdOKB+gdzWtkRmPsRSuJUTUL3XInAvyzQ8VM2BWjWGYr/rxEuE/n+h5 Pdah/F5SWbuw9rx0sAACG7oXsebLD/2yIXcosPQ2TQPeZ3Ts6sWZAY3pVaV1MQBEGyCp ZUEw== 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=+cwGECz2Zewz7vzKsz0xC0QZoBKScFC71kLn7OYbhl4=; b=K1R/eZgQMxhq8jWCYcATV7bxVl7Y0GRtmdJq3RNG/mhltSKwEK8QeTr4rnP2Cap2HT mYAZp5V8YGtLr1my3O28XqsfOQ2BzbneHoIdfSbX3G3Ue2sfgt8ozOOVgxZPxeOki14Q jmSJ7AdmvmZ7W9E5s0o/Id/+jfm6KlBMsZPNmutjbzrEhDuNhYSMFR2Oz8WnERweRUuL kWE+nEwJhpokEfZkDxY5NCx6HnDn6srU+WC6ADY86P6F7PfCi6CY588up2tOZ7TAsPpG e58X8kmzh8F4zxIJCDrMKTnjtn968jhwwHnLO9WUoOSnCgL7pLG9AAuUauPMJyR/mqCU sr+g== X-Gm-Message-State: AMCzsaVGCVzzgrA+R8JQzExFoMOchOFuY0N5B11EHoD/8g80LbDyL+sR /AwbwEQMwzjZUYgOpf+QFlNB6na+YfE2h8mOLwc= X-Google-Smtp-Source: AOwi7QC7LFUH+TeEYcHhSL69MpNxhqjwhZfgro+msbntCYP4OqbKNKoFsWI/Y6w/YVt/esTiMqL3zuiTXPzt4KCAjy0= X-Received: by 10.159.244.23 with SMTP id x23mr4494575plr.64.1507598614371; Mon, 09 Oct 2017 18:23:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.151.131 with HTTP; Mon, 9 Oct 2017 18:22:53 -0700 (PDT) In-Reply-To: <20171009235717.GN96685@kduck.kaduk.org> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> From: Kathleen Moriarty Date: Mon, 9 Oct 2017 21:22:53 -0400 Message-ID: To: Benjamin Kaduk Cc: Martin Thomson , "gen-art@ietf.org" , MILE IETF , IETF , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 01:23:36 -0000 On Mon, Oct 9, 2017 at 7:57 PM, Benjamin Kaduk wrote: > On Sun, Oct 08, 2017 at 10:08:26PM -0700, Martin Thomson wrote: >> >> The requirements in Section 5.3 on TLS use are unnecessarily strict. It's >> great to recommend the use of TLS 1.2, but given that the document has no real >> requirement on any particular version of TLS, the use of "MUST" here is not > > I think that one could make the case that using TLS 1.2 (or higher) greatly > facilitates having a secure system, and so it could plausibly be required > by a consuming protocol. +1 and this has pretty much been standard practice on all protocols using TLS for at least the last 3 years. RFC7525 has been a requirement on most protocols using TLS since it was published. This is a protocol that will carry sensitive data and strict requirements are necessary. Examples of data that might be exchanged with this protocol include threat actor information or indicators of compromise. Strict security is necessary and completely expected by those deploying this protocol. > >> needed. Similarly, the prohibition on the use of 0-RTT is groundless. The > > I am a little surprised to hear you say that this prohibition is "groundless". > Given that we require consumers of TLS 1.3 0-RTT data to explictly specify > an application profile for how it may be used, with the intent to induce > a careful analysis of the security considerations for sending early data > messages, it seems quite reasonable to me that a protocol author might > wish to defer such a painstaking analysis and take the easy choice of > prohibiting early data. +1. In the case of this protocol, there is no tolerance for replay attacks. Many other protocols use TLS and will have similar requirements. This is likely to be a theme. The performance gain isn't worth the tradeoffs - of defining a profile, risking configuration mistakes, the careful analysis, and weighing the security considerations. The 0-RTT decision in the TLS WG has a big impact on other protocols using it. Kathleen > > -Ben > >> lengthy list of requirements around certificate validation only risk creating a >> conflict with advice in other RFCs. Many, if not all, of these requirements -- Best regards, Kathleen From nobody Mon Oct 9 18:23:56 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5B2151342E6; Mon, 9 Oct 2017 18:23:36 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293DD134460; Mon, 9 Oct 2017 18:23:36 -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 vg-Uxlv5Apr8; Mon, 9 Oct 2017 18:23:34 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 D25BC1342E6; Mon, 9 Oct 2017 18:23:34 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id x7so5236424pfa.1; Mon, 09 Oct 2017 18:23:34 -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=+cwGECz2Zewz7vzKsz0xC0QZoBKScFC71kLn7OYbhl4=; b=ZkafJ6AXRlHlWmiJ5FE3SFH6pXyV84GlRNnhnr3HNdbpuITRdipzIXTYDnMbvIbWRZ NeZ/gkSGLNuVyCZEqMey8uLxABgLWMgIHZDrL3M7hVOYHw/abjGSBPEk6Uu7qKP4x6zk gHPmFIYqxne6c7NOm0g52z6hJs/c/uIOQ/QxMKDbCv9IkoraE6+/bxvvu+3HJn9xocNJ pIlLBIfQU5GFGKdOKB+gdzWtkRmPsRSuJUTUL3XInAvyzQ8VM2BWjWGYr/rxEuE/n+h5 Pdah/F5SWbuw9rx0sAACG7oXsebLD/2yIXcosPQ2TQPeZ3Ts6sWZAY3pVaV1MQBEGyCp ZUEw== 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=+cwGECz2Zewz7vzKsz0xC0QZoBKScFC71kLn7OYbhl4=; b=K1R/eZgQMxhq8jWCYcATV7bxVl7Y0GRtmdJq3RNG/mhltSKwEK8QeTr4rnP2Cap2HT mYAZp5V8YGtLr1my3O28XqsfOQ2BzbneHoIdfSbX3G3Ue2sfgt8ozOOVgxZPxeOki14Q jmSJ7AdmvmZ7W9E5s0o/Id/+jfm6KlBMsZPNmutjbzrEhDuNhYSMFR2Oz8WnERweRUuL kWE+nEwJhpokEfZkDxY5NCx6HnDn6srU+WC6ADY86P6F7PfCi6CY588up2tOZ7TAsPpG e58X8kmzh8F4zxIJCDrMKTnjtn968jhwwHnLO9WUoOSnCgL7pLG9AAuUauPMJyR/mqCU sr+g== X-Gm-Message-State: AMCzsaVGCVzzgrA+R8JQzExFoMOchOFuY0N5B11EHoD/8g80LbDyL+sR /AwbwEQMwzjZUYgOpf+QFlNB6na+YfE2h8mOLwc= X-Google-Smtp-Source: AOwi7QC7LFUH+TeEYcHhSL69MpNxhqjwhZfgro+msbntCYP4OqbKNKoFsWI/Y6w/YVt/esTiMqL3zuiTXPzt4KCAjy0= X-Received: by 10.159.244.23 with SMTP id x23mr4494575plr.64.1507598614371; Mon, 09 Oct 2017 18:23:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.151.131 with HTTP; Mon, 9 Oct 2017 18:22:53 -0700 (PDT) In-Reply-To: <20171009235717.GN96685@kduck.kaduk.org> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> From: Kathleen Moriarty Date: Mon, 9 Oct 2017 21:22:53 -0400 Message-ID: To: Benjamin Kaduk Cc: Martin Thomson , "gen-art@ietf.org" , MILE IETF , IETF , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171010012336.5B2151342E6@ietfa.amsl.com> Resent-Date: Mon, 9 Oct 2017 18:23:36 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 01:23:36 -0000 On Mon, Oct 9, 2017 at 7:57 PM, Benjamin Kaduk wrote: > On Sun, Oct 08, 2017 at 10:08:26PM -0700, Martin Thomson wrote: >> >> The requirements in Section 5.3 on TLS use are unnecessarily strict. It's >> great to recommend the use of TLS 1.2, but given that the document has no real >> requirement on any particular version of TLS, the use of "MUST" here is not > > I think that one could make the case that using TLS 1.2 (or higher) greatly > facilitates having a secure system, and so it could plausibly be required > by a consuming protocol. +1 and this has pretty much been standard practice on all protocols using TLS for at least the last 3 years. RFC7525 has been a requirement on most protocols using TLS since it was published. This is a protocol that will carry sensitive data and strict requirements are necessary. Examples of data that might be exchanged with this protocol include threat actor information or indicators of compromise. Strict security is necessary and completely expected by those deploying this protocol. > >> needed. Similarly, the prohibition on the use of 0-RTT is groundless. The > > I am a little surprised to hear you say that this prohibition is "groundless". > Given that we require consumers of TLS 1.3 0-RTT data to explictly specify > an application profile for how it may be used, with the intent to induce > a careful analysis of the security considerations for sending early data > messages, it seems quite reasonable to me that a protocol author might > wish to defer such a painstaking analysis and take the easy choice of > prohibiting early data. +1. In the case of this protocol, there is no tolerance for replay attacks. Many other protocols use TLS and will have similar requirements. This is likely to be a theme. The performance gain isn't worth the tradeoffs - of defining a profile, risking configuration mistakes, the careful analysis, and weighing the security considerations. The 0-RTT decision in the TLS WG has a big impact on other protocols using it. Kathleen > > -Ben > >> lengthy list of requirements around certificate validation only risk creating a >> conflict with advice in other RFCs. Many, if not all, of these requirements -- Best regards, Kathleen From nobody Mon Oct 9 18:33:20 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73656133073; Mon, 9 Oct 2017 18:33:05 -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 L5ixnntTmmMS; Mon, 9 Oct 2017 18:33:04 -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 3F8241320D8; Mon, 9 Oct 2017 18:33:04 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id n73so8876833pfg.10; Mon, 09 Oct 2017 18:33:04 -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=lxPaFcwotAe8FJLtX+D/Z0yQd0C4i4xGtiNOF+8VQ0E=; b=WSMEn23r9MoeeCWwMYfVW9yyyvXPLmOnCMzyVcQ9ru9bLgFSnUowq40Yh4vqOb4lbK k3jK6I+OS/MDWOt/ZvgaQOcR7LSD1FjBGu+Bru23Pv2z5GZg4FOQwVN3Eepb+5UjsuQz lE+EnfH/UU/mjK4HdRIlUABq5eQtNAbOwKvZri9CZFTDPnSUQd7pOnU0SK1Y8uH3xcch YN/ap6E12oN5zRaARMZwXayT76z13vi/hHwXT99IjfBwXajTh4WYnR7qzhzrQ3s3UXH1 tqstp1U1aVxT4oCXJgdt036LDmOExmTBezy6OQS4IWlP2r1lvn4zlRCTveiFUyTAcnbQ TDgw== 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=lxPaFcwotAe8FJLtX+D/Z0yQd0C4i4xGtiNOF+8VQ0E=; b=WWDT3vjDZlJipUgdm7HElDu5Wrgo/SFt+fGv3WbsyRGWKAvGKxIc+ClzSFrZ6sipHN nSYRZlSon+MhH/OI2k8olikB2Awem9FQ7cXy/8Rt9dAG5/3T5Tv9fuMPejiAKzoVCVE8 tTetXfUivwIXBjsMTmbduajtvkwgPuk88OhXXzZ4yxgcjgyeSTwkfFnwVBL6GWiM5RWK rzdH42iuq2JDgyIFnzgfdt6LO1n7YeJrs/mNkkwySZV3vzUEOa2F6UWXivL5ho5N5IN7 PfEnjYPTZuWDhFUU/4fRP7MzOORDwh3kwdgeG6Pnb0cYu3YHUnk8jMKjMAocRoOTh7aB FHmA== X-Gm-Message-State: AMCzsaV9nadAyRJmdiGF82jngisRsTKPpiGxmUSKfTQmIrqk0cymxCm7 EXe4wRSUPKV1WlcA1coWSXpvnnVsQ6jeuKPMflg= X-Google-Smtp-Source: AOwi7QBeFzTpkWPhBxy1IfbDFu5XWEaln8qqjx7pnl/Rqy2P19ErSmXcGE9R8eq1l0bdK29CRDidgMlliR3RQRnPbto= X-Received: by 10.98.194.8 with SMTP id l8mr11750823pfg.253.1507599183904; Mon, 09 Oct 2017 18:33:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.151.131 with HTTP; Mon, 9 Oct 2017 18:32:23 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> From: Kathleen Moriarty Date: Mon, 9 Oct 2017 21:32:23 -0400 Message-ID: To: Martin Thomson Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 01:33:05 -0000 On Mon, Oct 9, 2017 at 9:11 PM, Martin Thomson wrote: > On Tue, Oct 10, 2017 at 10:57 AM, Benjamin Kaduk wrote: >> I think that one could make the case that using TLS 1.2 (or higher) greatly >> facilitates having a secure system, and so it could plausibly be required >> by a consuming protocol. > > The problem here is that the protocol is actually HTTP. And that > protocol has requirements already. A recommendation to use TLS 1.2 is > fine, but that is already part of RFC 7525. > >>> needed. Similarly, the prohibition on the use of 0-RTT is groundless. The >> >> I am a little surprised to hear you say that this prohibition is "groundless". >> Given that we require consumers of TLS 1.3 0-RTT data to explictly specify >> an application profile for how it may be used, with the intent to induce >> a careful analysis of the security considerations for sending early data >> messages, it seems quite reasonable to me that a protocol author might >> wish to defer such a painstaking analysis and take the easy choice of >> prohibiting early data. > > This is quite explicitly using HTTP, which has a profile (work in > progress). If that profile is somehow inadequate, then a case should > be made in the draft explaining why (hence the choice of the word). A > reference to TLS 1.3 also has the unfortunate effect of delaying > publication of this draft. Can you provide a pointer? The profile is likely inadequate for this and many other uses of HTTP/TLS if early data is permitted. 0RTT has a large impact across many protocols including those that use HTTP/TLS. If there is no normative language, then it can continue on to be published with the draft for TLS 1.3 being used. This is an application where security is very important, so decisions like this that can be made now should be prior to implementers testing TLS 1.3. Best, Kathleen -- Best regards, Kathleen From nobody Mon Oct 9 18:33:26 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A4A561320D8; Mon, 9 Oct 2017 18:33:05 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73656133073; Mon, 9 Oct 2017 18:33:05 -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 L5ixnntTmmMS; Mon, 9 Oct 2017 18:33:04 -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 3F8241320D8; Mon, 9 Oct 2017 18:33:04 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id n73so8876833pfg.10; Mon, 09 Oct 2017 18:33:04 -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=lxPaFcwotAe8FJLtX+D/Z0yQd0C4i4xGtiNOF+8VQ0E=; b=WSMEn23r9MoeeCWwMYfVW9yyyvXPLmOnCMzyVcQ9ru9bLgFSnUowq40Yh4vqOb4lbK k3jK6I+OS/MDWOt/ZvgaQOcR7LSD1FjBGu+Bru23Pv2z5GZg4FOQwVN3Eepb+5UjsuQz lE+EnfH/UU/mjK4HdRIlUABq5eQtNAbOwKvZri9CZFTDPnSUQd7pOnU0SK1Y8uH3xcch YN/ap6E12oN5zRaARMZwXayT76z13vi/hHwXT99IjfBwXajTh4WYnR7qzhzrQ3s3UXH1 tqstp1U1aVxT4oCXJgdt036LDmOExmTBezy6OQS4IWlP2r1lvn4zlRCTveiFUyTAcnbQ TDgw== 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=lxPaFcwotAe8FJLtX+D/Z0yQd0C4i4xGtiNOF+8VQ0E=; b=WWDT3vjDZlJipUgdm7HElDu5Wrgo/SFt+fGv3WbsyRGWKAvGKxIc+ClzSFrZ6sipHN nSYRZlSon+MhH/OI2k8olikB2Awem9FQ7cXy/8Rt9dAG5/3T5Tv9fuMPejiAKzoVCVE8 tTetXfUivwIXBjsMTmbduajtvkwgPuk88OhXXzZ4yxgcjgyeSTwkfFnwVBL6GWiM5RWK rzdH42iuq2JDgyIFnzgfdt6LO1n7YeJrs/mNkkwySZV3vzUEOa2F6UWXivL5ho5N5IN7 PfEnjYPTZuWDhFUU/4fRP7MzOORDwh3kwdgeG6Pnb0cYu3YHUnk8jMKjMAocRoOTh7aB FHmA== X-Gm-Message-State: AMCzsaV9nadAyRJmdiGF82jngisRsTKPpiGxmUSKfTQmIrqk0cymxCm7 EXe4wRSUPKV1WlcA1coWSXpvnnVsQ6jeuKPMflg= X-Google-Smtp-Source: AOwi7QBeFzTpkWPhBxy1IfbDFu5XWEaln8qqjx7pnl/Rqy2P19ErSmXcGE9R8eq1l0bdK29CRDidgMlliR3RQRnPbto= X-Received: by 10.98.194.8 with SMTP id l8mr11750823pfg.253.1507599183904; Mon, 09 Oct 2017 18:33:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.151.131 with HTTP; Mon, 9 Oct 2017 18:32:23 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> From: Kathleen Moriarty Date: Mon, 9 Oct 2017 21:32:23 -0400 Message-ID: To: Martin Thomson Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171010013305.A4A561320D8@ietfa.amsl.com> Resent-Date: Mon, 9 Oct 2017 18:33:05 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 01:33:05 -0000 On Mon, Oct 9, 2017 at 9:11 PM, Martin Thomson wrote: > On Tue, Oct 10, 2017 at 10:57 AM, Benjamin Kaduk wrote: >> I think that one could make the case that using TLS 1.2 (or higher) greatly >> facilitates having a secure system, and so it could plausibly be required >> by a consuming protocol. > > The problem here is that the protocol is actually HTTP. And that > protocol has requirements already. A recommendation to use TLS 1.2 is > fine, but that is already part of RFC 7525. > >>> needed. Similarly, the prohibition on the use of 0-RTT is groundless. The >> >> I am a little surprised to hear you say that this prohibition is "groundless". >> Given that we require consumers of TLS 1.3 0-RTT data to explictly specify >> an application profile for how it may be used, with the intent to induce >> a careful analysis of the security considerations for sending early data >> messages, it seems quite reasonable to me that a protocol author might >> wish to defer such a painstaking analysis and take the easy choice of >> prohibiting early data. > > This is quite explicitly using HTTP, which has a profile (work in > progress). If that profile is somehow inadequate, then a case should > be made in the draft explaining why (hence the choice of the word). A > reference to TLS 1.3 also has the unfortunate effect of delaying > publication of this draft. Can you provide a pointer? The profile is likely inadequate for this and many other uses of HTTP/TLS if early data is permitted. 0RTT has a large impact across many protocols including those that use HTTP/TLS. If there is no normative language, then it can continue on to be published with the draft for TLS 1.3 being used. This is an application where security is very important, so decisions like this that can be made now should be prior to implementers testing TLS 1.3. Best, Kathleen -- Best regards, Kathleen From nobody Mon Oct 9 18:56:17 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75EF133221; Mon, 9 Oct 2017 18:56:11 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 lGUJbG9Efl0a; Mon, 9 Oct 2017 18:56:09 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 90B061342E6; Mon, 9 Oct 2017 18:55:55 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id w197so38188343oif.6; Mon, 09 Oct 2017 18:55:55 -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=tqwLXpPx+1ogVGN6/nJv2z6hUOALnPEXYFHQdIKXsYg=; b=Tb9q2oX54MnHKUcr3vHh4HL29RSwq/L+FltyLPYec/1yrl40k4RQVWPE0J7F5NkUcZ eawDcgFYpgnMIb8+S8814uI7WQFDLtg3Fs5X/5dhktpkQa72yfm/UNfBtRyHUH28d5Sl 2ZakFuHgNvyvgDnGn3htiFRnWdFjE/MRy7HeOpTtgsJeHVoOkKZx0qyNaHDYAH01tARA GVUIoNJeqGjoOiRu+TViMlUkQo/TH0hl3G9INp4R2JWDvttiUcK/r/Pm8E/pfn/WRb/n FYNFOxUqPalofpRWWFe1MMtdqqkFjhtvsTQmUfnrqaDlAOT74974fpXmmeVrZG0uAELn xYKA== 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=tqwLXpPx+1ogVGN6/nJv2z6hUOALnPEXYFHQdIKXsYg=; b=d/QbNIOKdOHmi/Xv3j3HojJZIBVj+Tmvbpk6TG3oGeaefbc9GkRUOymisoFodSX1RX t0SrF76+tbMw8vUcC5bTeL4+S+Wz/G+VEWOUhNRjruv4zPDLyu234Jq2L4IzyqiooBtN JkrK8TNLzx8trRW1J6HkS6BRroBR3exBewZSvZYBZIzacuW1zVIlQ1MhQ4nEMIF3bpZS XCdOs7AsF+uEPkQcDNJKenJgBBi8beuCgkHUR8ZIpTCIqGgNb5Ay/PRbTvFLitFocYpg ZZ5Gejg9Kion3JAaencpmIl0J1CKMgG5YbrpTvcYcZbq/SBxox1Kc7fq3SXA8yz5h0UN xGoA== X-Gm-Message-State: AMCzsaXMLgH6kWLml6aW3LZTUrj8q9/pHkZq6GdZ6w7ff6FCi3fQz2d4 jOCYbHQynNnrR2vbU1ETtEm1kAja4CG0i78qThI= X-Google-Smtp-Source: AOwi7QCC+J4gGidHZ+zlvg91ga3CBP99fIN8Vhw3EvxNUN8wpRGgnZOzyXX4cjsx2XCTEvC1iviZ4uVzwXf8vKg2hQo= X-Received: by 10.157.37.90 with SMTP id j26mr746772otd.401.1507600554870; Mon, 09 Oct 2017 18:55:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Mon, 9 Oct 2017 18:55:54 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> From: Martin Thomson Date: Tue, 10 Oct 2017 12:55:54 +1100 Message-ID: To: Kathleen Moriarty Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 01:56:12 -0000 On Tue, Oct 10, 2017 at 12:32 PM, Kathleen Moriarty wrote: >> This is quite explicitly using HTTP, which has a profile (work in >> progress). If that profile is somehow inadequate, then a case should >> be made in the draft explaining why (hence the choice of the word). A >> reference to TLS 1.3 also has the unfortunate effect of delaying >> publication of this draft. > > Can you provide a pointer? The profile is likely inadequate for this > and many other uses of HTTP/TLS if early data is permitted. 0RTT has > a large impact across many protocols including those that use > HTTP/TLS. https://datatracker.ietf.org/doc/draft-ietf-httpbis-replay/ Editor's copy (with a number of changes): http://httpwg.org/http-extensions/replay.html > If there is no normative language, then it can continue on to be > published with the draft for TLS 1.3 being used. This is an > application where security is very important, so decisions like this > that can be made now should be prior to implementers testing TLS 1.3. Currently there is normative language, and it wouldn't make sense to make any sort of statement with respect to 0-RTT without making that statement normative. However, I think that it would be wiser to rely on HTTP doing the right thing here. I would of course encourage you and the document authors to review the draft above to see if we're making completely unsuitable recommendations. I realize that security is very important here, but I don't think that it is so significantly special that a whole new application profile of HTTP is needed. HTTP can be very secure with the right configuration. Strong recommendations about good practices for both configuration and operation are appropriate. RFC 7525 is what I would use for that. RFC 7525 covers all that the draft does and more. From nobody Mon Oct 9 18:56:35 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1676D134450; Mon, 9 Oct 2017 18:56:12 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75EF133221; Mon, 9 Oct 2017 18:56:11 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 lGUJbG9Efl0a; Mon, 9 Oct 2017 18:56:09 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 90B061342E6; Mon, 9 Oct 2017 18:55:55 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id w197so38188343oif.6; Mon, 09 Oct 2017 18:55:55 -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=tqwLXpPx+1ogVGN6/nJv2z6hUOALnPEXYFHQdIKXsYg=; b=Tb9q2oX54MnHKUcr3vHh4HL29RSwq/L+FltyLPYec/1yrl40k4RQVWPE0J7F5NkUcZ eawDcgFYpgnMIb8+S8814uI7WQFDLtg3Fs5X/5dhktpkQa72yfm/UNfBtRyHUH28d5Sl 2ZakFuHgNvyvgDnGn3htiFRnWdFjE/MRy7HeOpTtgsJeHVoOkKZx0qyNaHDYAH01tARA GVUIoNJeqGjoOiRu+TViMlUkQo/TH0hl3G9INp4R2JWDvttiUcK/r/Pm8E/pfn/WRb/n FYNFOxUqPalofpRWWFe1MMtdqqkFjhtvsTQmUfnrqaDlAOT74974fpXmmeVrZG0uAELn xYKA== 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=tqwLXpPx+1ogVGN6/nJv2z6hUOALnPEXYFHQdIKXsYg=; b=d/QbNIOKdOHmi/Xv3j3HojJZIBVj+Tmvbpk6TG3oGeaefbc9GkRUOymisoFodSX1RX t0SrF76+tbMw8vUcC5bTeL4+S+Wz/G+VEWOUhNRjruv4zPDLyu234Jq2L4IzyqiooBtN JkrK8TNLzx8trRW1J6HkS6BRroBR3exBewZSvZYBZIzacuW1zVIlQ1MhQ4nEMIF3bpZS XCdOs7AsF+uEPkQcDNJKenJgBBi8beuCgkHUR8ZIpTCIqGgNb5Ay/PRbTvFLitFocYpg ZZ5Gejg9Kion3JAaencpmIl0J1CKMgG5YbrpTvcYcZbq/SBxox1Kc7fq3SXA8yz5h0UN xGoA== X-Gm-Message-State: AMCzsaXMLgH6kWLml6aW3LZTUrj8q9/pHkZq6GdZ6w7ff6FCi3fQz2d4 jOCYbHQynNnrR2vbU1ETtEm1kAja4CG0i78qThI= X-Google-Smtp-Source: AOwi7QCC+J4gGidHZ+zlvg91ga3CBP99fIN8Vhw3EvxNUN8wpRGgnZOzyXX4cjsx2XCTEvC1iviZ4uVzwXf8vKg2hQo= X-Received: by 10.157.37.90 with SMTP id j26mr746772otd.401.1507600554870; Mon, 09 Oct 2017 18:55:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Mon, 9 Oct 2017 18:55:54 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> From: Martin Thomson Date: Tue, 10 Oct 2017 12:55:54 +1100 Message-ID: To: Kathleen Moriarty Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171010015612.1676D134450@ietfa.amsl.com> Resent-Date: Mon, 9 Oct 2017 18:56:12 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 01:56:12 -0000 On Tue, Oct 10, 2017 at 12:32 PM, Kathleen Moriarty wrote: >> This is quite explicitly using HTTP, which has a profile (work in >> progress). If that profile is somehow inadequate, then a case should >> be made in the draft explaining why (hence the choice of the word). A >> reference to TLS 1.3 also has the unfortunate effect of delaying >> publication of this draft. > > Can you provide a pointer? The profile is likely inadequate for this > and many other uses of HTTP/TLS if early data is permitted. 0RTT has > a large impact across many protocols including those that use > HTTP/TLS. https://datatracker.ietf.org/doc/draft-ietf-httpbis-replay/ Editor's copy (with a number of changes): http://httpwg.org/http-extensions/replay.html > If there is no normative language, then it can continue on to be > published with the draft for TLS 1.3 being used. This is an > application where security is very important, so decisions like this > that can be made now should be prior to implementers testing TLS 1.3. Currently there is normative language, and it wouldn't make sense to make any sort of statement with respect to 0-RTT without making that statement normative. However, I think that it would be wiser to rely on HTTP doing the right thing here. I would of course encourage you and the document authors to review the draft above to see if we're making completely unsuitable recommendations. I realize that security is very important here, but I don't think that it is so significantly special that a whole new application profile of HTTP is needed. HTTP can be very secure with the right configuration. Strong recommendations about good practices for both configuration and operation are appropriate. RFC 7525 is what I would use for that. RFC 7525 covers all that the draft does and more. From nobody Mon Oct 9 20:06:11 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5DF13431D; Mon, 9 Oct 2017 20:05:59 -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 6k5615ee3IV7; Mon, 9 Oct 2017 20:05:57 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 64ADF1323B4; Mon, 9 Oct 2017 20:05:57 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id q4so47407772qtq.8; Mon, 09 Oct 2017 20:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pPNso3UHrRR1l5704Hozpp4yXMwx0f/qKXq03DR27ic=; b=YfOhzwM0+CDrTAtmm4oKcbnLmHZUv1Wb7S+5yRyDlp+sch1qLtq4dnMXweUBUiIbY+ 4spH1Rmf5rfpaqeghAbP8LFDNOvhzmtQJnkkpNNzwZUh8xWrA2lfLNfJ3D3iTTfFtRCJ plg0RwrSd+fFtqVo4O6cTL7omH7KIZQ5PB3GR9FOqmNvoPSTjmm5urAEr3+EilSiorty zkmnMv9KcN3C0AueFVyor2pjPes11MYOQBTQerSzthcJzrstMq2zELwFGXhxbyAYaNPI 6X0dlio7KqHPglUujetPtfigWy/JkGRp5tjlFLfPtxISv14mzQ0NQ9hAHOMaIH9Dvq/9 Lwsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pPNso3UHrRR1l5704Hozpp4yXMwx0f/qKXq03DR27ic=; b=sNb2Jcpqnb/89fHBflsZQxyrSWhx4p+7hjvghfEVRl4/ljeRe4vQoC/ugZ79PnGbMJ jT8oEJGCIGs6CvVlS6t5WoPrxq7VNpQ/euQQOuYgIPOH0st1aw9nadllGgWHUicwDaYj Yd3gXMb42zs9TFPvNwxANktthZmvQablafb8Yo4vAbg8pg5x8DoU6XRVwtwTqKPzQFFF C+Us0xZYkmBqRspHjwLjvFrKm0kAq7kB4fPNlaIPlI02HWeX6yd5rxQac5/C7b/70bbS 9a1lk7G1sJ2SUN2x54Hqo2U7p5WVKdmyt1gkzGJdy8PV2K6GIRgEi4+6/2rrgENdklFy dajQ== X-Gm-Message-State: AMCzsaXPwpiCeh9Y7nO0aA0ezjK3eyH2BdLJqdQkE0M6P385Vu2ts4+A sN9lyXW/ejQ/asgyeOfCYZg= X-Google-Smtp-Source: AOwi7QDQwiTaErKRdgFINE0id3LKPUWwSvNVGk+WnTV8JZ2xjo8Ebj0ZPnj5D6mAQ4AJ9dZmVa1fsQ== X-Received: by 10.55.126.2 with SMTP id z2mr12631313qkc.39.1507604756549; Mon, 09 Oct 2017 20:05:56 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.s3530.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id n4sm5650376qkf.49.2017.10.09.20.05.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Oct 2017 20:05:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Mon, 9 Oct 2017 23:05:53 -0400 Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> To: Martin Thomson Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 03:05:59 -0000 Sent from my iPhone > On Oct 9, 2017, at 9:55 PM, Martin Thomson wrot= e: >=20 > On Tue, Oct 10, 2017 at 12:32 PM, Kathleen Moriarty > wrote: >>> This is quite explicitly using HTTP, which has a profile (work in >>> progress). If that profile is somehow inadequate, then a case should >>> be made in the draft explaining why (hence the choice of the word). A >>> reference to TLS 1.3 also has the unfortunate effect of delaying >>> publication of this draft. >>=20 >> Can you provide a pointer? The profile is likely inadequate for this >> and many other uses of HTTP/TLS if early data is permitted. 0RTT has >> a large impact across many protocols including those that use >> HTTP/TLS. >=20 > https://datatracker.ietf.org/doc/draft-ietf-httpbis-replay/ > Editor's copy (with a number of changes): > http://httpwg.org/http-extensions/replay.html >=20 >> If there is no normative language, then it can continue on to be >> published with the draft for TLS 1.3 being used. This is an >> application where security is very important, so decisions like this >> that can be made now should be prior to implementers testing TLS 1.3. >=20 > Currently there is normative language, and it wouldn't make sense to > make any sort of statement with respect to 0-RTT without making that > statement normative. However, I think that it would be wiser to rely > on HTTP doing the right thing here. I would of course encourage you > and the document authors to review the draft above to see if we're > making completely unsuitable recommendations. >=20 I'll review and see if the WG participants can as well. I think there will b= e many applications to follow with high security requirements and no toleran= ce for replay attacks. > I realize that security is very important here, but I don't think that > it is so significantly special that a whole new application profile of > HTTP is needed. HTTP can be very secure with the right configuration. Configuration mistakes happen and lead to big problems. > Strong recommendations about good practices for both configuration and > operation are appropriate. RFC 7525 is what I would use for that. > RFC 7525 covers all that the draft does and more. Yes, I had pointed that out in my review. Best, Kathleen=20= From nobody Mon Oct 9 20:06:16 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 640341323B4; Mon, 9 Oct 2017 20:05:59 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5DF13431D; Mon, 9 Oct 2017 20:05:59 -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 6k5615ee3IV7; Mon, 9 Oct 2017 20:05:57 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 64ADF1323B4; Mon, 9 Oct 2017 20:05:57 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id q4so47407772qtq.8; Mon, 09 Oct 2017 20:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pPNso3UHrRR1l5704Hozpp4yXMwx0f/qKXq03DR27ic=; b=YfOhzwM0+CDrTAtmm4oKcbnLmHZUv1Wb7S+5yRyDlp+sch1qLtq4dnMXweUBUiIbY+ 4spH1Rmf5rfpaqeghAbP8LFDNOvhzmtQJnkkpNNzwZUh8xWrA2lfLNfJ3D3iTTfFtRCJ plg0RwrSd+fFtqVo4O6cTL7omH7KIZQ5PB3GR9FOqmNvoPSTjmm5urAEr3+EilSiorty zkmnMv9KcN3C0AueFVyor2pjPes11MYOQBTQerSzthcJzrstMq2zELwFGXhxbyAYaNPI 6X0dlio7KqHPglUujetPtfigWy/JkGRp5tjlFLfPtxISv14mzQ0NQ9hAHOMaIH9Dvq/9 Lwsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pPNso3UHrRR1l5704Hozpp4yXMwx0f/qKXq03DR27ic=; b=sNb2Jcpqnb/89fHBflsZQxyrSWhx4p+7hjvghfEVRl4/ljeRe4vQoC/ugZ79PnGbMJ jT8oEJGCIGs6CvVlS6t5WoPrxq7VNpQ/euQQOuYgIPOH0st1aw9nadllGgWHUicwDaYj Yd3gXMb42zs9TFPvNwxANktthZmvQablafb8Yo4vAbg8pg5x8DoU6XRVwtwTqKPzQFFF C+Us0xZYkmBqRspHjwLjvFrKm0kAq7kB4fPNlaIPlI02HWeX6yd5rxQac5/C7b/70bbS 9a1lk7G1sJ2SUN2x54Hqo2U7p5WVKdmyt1gkzGJdy8PV2K6GIRgEi4+6/2rrgENdklFy dajQ== X-Gm-Message-State: AMCzsaXPwpiCeh9Y7nO0aA0ezjK3eyH2BdLJqdQkE0M6P385Vu2ts4+A sN9lyXW/ejQ/asgyeOfCYZg= X-Google-Smtp-Source: AOwi7QDQwiTaErKRdgFINE0id3LKPUWwSvNVGk+WnTV8JZ2xjo8Ebj0ZPnj5D6mAQ4AJ9dZmVa1fsQ== X-Received: by 10.55.126.2 with SMTP id z2mr12631313qkc.39.1507604756549; Mon, 09 Oct 2017 20:05:56 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.s3530.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id n4sm5650376qkf.49.2017.10.09.20.05.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Oct 2017 20:05:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Mon, 9 Oct 2017 23:05:53 -0400 Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> To: Martin Thomson Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 03:05:59 -0000 Sent from my iPhone > On Oct 9, 2017, at 9:55 PM, Martin Thomson wrot= e: >=20 > On Tue, Oct 10, 2017 at 12:32 PM, Kathleen Moriarty > wrote: >>> This is quite explicitly using HTTP, which has a profile (work in >>> progress). If that profile is somehow inadequate, then a case should >>> be made in the draft explaining why (hence the choice of the word). A >>> reference to TLS 1.3 also has the unfortunate effect of delaying >>> publication of this draft. >>=20 >> Can you provide a pointer? The profile is likely inadequate for this >> and many other uses of HTTP/TLS if early data is permitted. 0RTT has >> a large impact across many protocols including those that use >> HTTP/TLS. >=20 > https://datatracker.ietf.org/doc/draft-ietf-httpbis-replay/ > Editor's copy (with a number of changes): > http://httpwg.org/http-extensions/replay.html >=20 >> If there is no normative language, then it can continue on to be >> published with the draft for TLS 1.3 being used. This is an >> application where security is very important, so decisions like this >> that can be made now should be prior to implementers testing TLS 1.3. >=20 > Currently there is normative language, and it wouldn't make sense to > make any sort of statement with respect to 0-RTT without making that > statement normative. However, I think that it would be wiser to rely > on HTTP doing the right thing here. I would of course encourage you > and the document authors to review the draft above to see if we're > making completely unsuitable recommendations. >=20 I'll review and see if the WG participants can as well. I think there will b= e many applications to follow with high security requirements and no toleran= ce for replay attacks. > I realize that security is very important here, but I don't think that > it is so significantly special that a whole new application profile of > HTTP is needed. HTTP can be very secure with the right configuration. Configuration mistakes happen and lead to big problems. > Strong recommendations about good practices for both configuration and > operation are appropriate. RFC 7525 is what I would use for that. > RFC 7525 covers all that the draft does and more. Yes, I had pointed that out in my review. Best, Kathleen=20= From nobody Mon Oct 9 20:46:08 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866E9120724; Mon, 9 Oct 2017 20:45:53 -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 LCjj1zwaMB6T; Mon, 9 Oct 2017 20:45:52 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 5C7C2132F3F; Mon, 9 Oct 2017 20:45:52 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id u130so43081945oib.11; Mon, 09 Oct 2017 20:45:52 -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=6z19sJx3lmC8z1rr9CiF77kCoEfnrTkfkXaBssBIbFA=; b=OW19ZklbLc4UaB33lFbyU68DVo9zbU0zOcAXZRn1TVo2K+Gmdb9U7SEYo7oZqLREvD 22IGOnyU7WeAi5JEkJPh6jEzd+n/NnFWVG8mbAbSW+t1KO5ii4tvIUqC4OuFsAi/92YP PHeEAsg3u7wEPT2WLHSVna9pq+BsoH4UcrYSD2CmDs4k+q3gwzfXBaz/iW1FmlwUraz7 6cbmie7U03CiSlgm50HQJFO+RL6lb5FSQzQpJOoOEmUZapnYXzFtHHKPj+rmsBU45Mhj MXdDz/WyAl9F96PhfYuIs+IfLoth3VKlmn7X1vpYSwuCLqDowUVdznPm0vxIwm14eCat wzJA== 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=6z19sJx3lmC8z1rr9CiF77kCoEfnrTkfkXaBssBIbFA=; b=WlgbDc3rmSbTlYsnmllu4gMQ571TKjflXESJLmcMSiPyIsCdsuNKwTW+8kb18VJkzb VmtcexKIhlVyEcg3ydVkE5LsbyA3NdqljY/gzOXfynkIMeLiIUi0/yX2eLqiwIxcNE0a 9Mrf7N4Nved48dZsGR7RqI5ruqJxnmSWD5FQG9v4OmkFMsHO+HLEkp4fQ/8Ugqto+GWv siTH979QXQ84zM3xKYih4nAGh8Rojg91oGl/Un4bGv2apDD77NhzcglAgSGBCdxSrlWT F1uN8mbOJWOpkDnNUGk+Xg05iJ4sOkwX+6A4u8zSe9R0UBy2k+B9XXJZeWyH1ZP7jEOA GYXw== X-Gm-Message-State: AMCzsaWGH7Z0DCfF8Abz7afgKfoEUGbSDaWNpzDG5HMPOuTXenT1Ct7v ZFvDMNZwqaBqwueqNXlfv8G6BoYWq6KWG8Bzhvo= X-Google-Smtp-Source: AOwi7QDFlnwbIzSKGpA7c2DhiakBucXCeB2QnBvzLMbhxpJa52JN9V/VnwwQTh9qz+XTCVMBSipMlH3bqRluZW3avKs= X-Received: by 10.202.102.39 with SMTP id a39mr5488399oic.83.1507607151655; Mon, 09 Oct 2017 20:45:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Mon, 9 Oct 2017 20:45:51 -0700 (PDT) In-Reply-To: <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> From: Martin Thomson Date: Tue, 10 Oct 2017 14:45:51 +1100 Message-ID: To: Kathleen Moriarty Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 03:45:53 -0000 On Tue, Oct 10, 2017 at 2:05 PM, Kathleen Moriarty wrote: > I'll review and see if the WG participants can as well. I think there will be many applications to follow with high security requirements and no tolerance for replay attacks. That is true, but it's not clear to me that this is a protocol that is intolerant of replay. AtomPub follows a pattern that limits exposure fairly well. The primary thing to safeguard in ROLIE is the confidentiality of the content, and replay won't generally compromise that. The sorts of things you might see is duplicate resource creation (we recommend against POST in early data for that reason; we also recommend against PUT), and the sort of traffic analysis and timing side channel information that reveals if resources exist or have been updated (which shouldn't be an issue here). From nobody Mon Oct 9 20:46:13 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B4947132F3F; Mon, 9 Oct 2017 20:45:53 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866E9120724; Mon, 9 Oct 2017 20:45:53 -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 LCjj1zwaMB6T; Mon, 9 Oct 2017 20:45:52 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 5C7C2132F3F; Mon, 9 Oct 2017 20:45:52 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id u130so43081945oib.11; Mon, 09 Oct 2017 20:45:52 -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=6z19sJx3lmC8z1rr9CiF77kCoEfnrTkfkXaBssBIbFA=; b=OW19ZklbLc4UaB33lFbyU68DVo9zbU0zOcAXZRn1TVo2K+Gmdb9U7SEYo7oZqLREvD 22IGOnyU7WeAi5JEkJPh6jEzd+n/NnFWVG8mbAbSW+t1KO5ii4tvIUqC4OuFsAi/92YP PHeEAsg3u7wEPT2WLHSVna9pq+BsoH4UcrYSD2CmDs4k+q3gwzfXBaz/iW1FmlwUraz7 6cbmie7U03CiSlgm50HQJFO+RL6lb5FSQzQpJOoOEmUZapnYXzFtHHKPj+rmsBU45Mhj MXdDz/WyAl9F96PhfYuIs+IfLoth3VKlmn7X1vpYSwuCLqDowUVdznPm0vxIwm14eCat wzJA== 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=6z19sJx3lmC8z1rr9CiF77kCoEfnrTkfkXaBssBIbFA=; b=WlgbDc3rmSbTlYsnmllu4gMQ571TKjflXESJLmcMSiPyIsCdsuNKwTW+8kb18VJkzb VmtcexKIhlVyEcg3ydVkE5LsbyA3NdqljY/gzOXfynkIMeLiIUi0/yX2eLqiwIxcNE0a 9Mrf7N4Nved48dZsGR7RqI5ruqJxnmSWD5FQG9v4OmkFMsHO+HLEkp4fQ/8Ugqto+GWv siTH979QXQ84zM3xKYih4nAGh8Rojg91oGl/Un4bGv2apDD77NhzcglAgSGBCdxSrlWT F1uN8mbOJWOpkDnNUGk+Xg05iJ4sOkwX+6A4u8zSe9R0UBy2k+B9XXJZeWyH1ZP7jEOA GYXw== X-Gm-Message-State: AMCzsaWGH7Z0DCfF8Abz7afgKfoEUGbSDaWNpzDG5HMPOuTXenT1Ct7v ZFvDMNZwqaBqwueqNXlfv8G6BoYWq6KWG8Bzhvo= X-Google-Smtp-Source: AOwi7QDFlnwbIzSKGpA7c2DhiakBucXCeB2QnBvzLMbhxpJa52JN9V/VnwwQTh9qz+XTCVMBSipMlH3bqRluZW3avKs= X-Received: by 10.202.102.39 with SMTP id a39mr5488399oic.83.1507607151655; Mon, 09 Oct 2017 20:45:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Mon, 9 Oct 2017 20:45:51 -0700 (PDT) In-Reply-To: <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> From: Martin Thomson Date: Tue, 10 Oct 2017 14:45:51 +1100 Message-ID: To: Kathleen Moriarty Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171010034553.B4947132F3F@ietfa.amsl.com> Resent-Date: Mon, 9 Oct 2017 20:45:53 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 03:45:53 -0000 On Tue, Oct 10, 2017 at 2:05 PM, Kathleen Moriarty wrote: > I'll review and see if the WG participants can as well. I think there will be many applications to follow with high security requirements and no tolerance for replay attacks. That is true, but it's not clear to me that this is a protocol that is intolerant of replay. AtomPub follows a pattern that limits exposure fairly well. The primary thing to safeguard in ROLIE is the confidentiality of the content, and replay won't generally compromise that. The sorts of things you might see is duplicate resource creation (we recommend against POST in early data for that reason; we also recommend against PUT), and the sort of traffic analysis and timing side channel information that reveals if resources exist or have been updated (which shouldn't be an issue here). From nobody Thu Oct 12 11:41:28 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2957127005; Thu, 12 Oct 2017 11:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.185 X-Spam-Level: X-Spam-Status: No, score=-5.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RDNS_NONE=0.793, 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 MYHLGkWWzlYL; Thu, 12 Oct 2017 11:26:16 -0700 (PDT) Received: from smtp01.icann.org (unknown [192.0.46.81]) (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 EDDAC13202D; Thu, 12 Oct 2017 11:26:15 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 1A499E3661; Thu, 12 Oct 2017 18:26:15 +0000 (UTC) Received: by request3.lax.icann.org (Postfix, from userid 48) id CFCF1C2060E; Thu, 12 Oct 2017 18:26:14 +0000 (UTC) RT-Owner: sabrina.tanamal From: "Sabrina Tanamal via RT" Reply-To: drafts-lastcall@iana.org In-Reply-To: <150670057250.14181.17753271478518577817.idtracker@ietfa.amsl.com> References: <150670057250.14181.17753271478518577817.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #983750 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: sabrina.tanamal@icann.org CC: iesg@ietf.org, jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 12 Oct 2017 18:26:14 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 12 Oct 2017 11:41:22 -0700 Subject: [mile] [IANA #983750] Last Call: (Resource-Oriented Lightweight Information Exchange) to Proposed Standard X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 18:26:18 -0000 (BEGIN IANA COMMENTS) IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-mile-rolie-10. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there are seven actions which we must complete. First, in the ns registry on the IETF XML registry page located at: https://www.iana.org/assignments/xml-registry/ a new namespace will be registered as follows: ID: rolie-1.0 URI: urn:ietf:params:xml:ns:rolie-1.0 Filename: [ TBD-at-registration ] Reference: [ RFC-to-be ] Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC. Second, in the schema registry also on the IETF XML registry page located at: https://www.iana.org/assignments/xml-registry/ a new schema will be registered as follows: ID: rolie-1.0 URI: urn:ietf:params:xml:ns:rolie-1.0 Filename: [ TBD-at-registration ] Reference: [ RFC-to-be ] Because this registry also requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC. Third, in the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers registry on the Uniform Resource Name (URN) Namespace for IETF Use registry page located at: https://www.iana.org/assignments/params/ a new parameter identifier will be registered as follows: Registered Parameter Identifier: rolie Reference: [ RFC-to-be ] IANA Registry Reference: [ TBD-at-Registration ] Fourth, a new, top-level registry page will be created called "Resource Oriented Lightweight Information Exchange (ROLIE) Parameters" on the IANA Matrix at: https://www.iana.org/protocols On this new registry page, a new registry is to be created called the ROLIE URN Parameters registry. The new registry will be managed via Specification Required as defined in [ RFC 8126 ]. There are initial registrations in the new registry as follows: Name: category:information-type Extension IRI: urn:ietf:params:rolie:category:information-type Reference: [ RFC-to-be Section 8.4 ] Sub-Registry: None Name: Extension IRI: urn:ietf:params:rolie: Reference: [ RFC-to-be ] Sub-Registry: https://www.iana.org/assignments/rolie/category/information-type Name: property:local Extension IRI: urn:ietf:params:rolie:property:local Reference: [ RFC-to-be Section 7.4 ] Sub-Registry: None Name: category:local Extension IRI: urn:ietf:params:rolie:category:local Reference: [ RFC-to-be Section 7.1 ] Sub-Registry: None Name: property:content-author-name Extension IRI: urn:ietf:params:rolie:property:content-author-name Reference: [ RFC-to-be Section 7.4 ] Sub-Registry: None Name: property:content-id Extension IRI: urn:ietf:params:rolie:property:content-id Reference: [ RFC-to-be Section 7.4 ] Sub-Registry: None Name: property:content-published-date Extension IRI: urn:ietf:params:rolie:property:content-published-date Reference: [ RFC-to-be Section 7.4 ] Sub-Registry: None Name: property:content-updated-date Extension IRI: urn:ietf:params:rolie:property:content-updated-date Reference: [ RFC-to-be Section 7.4 ] Sub-Registry: None Fifth, a new registry is to be created called the ROLIE Information Types registry. We note that the authors request that the registry be created in the following, specific location: https://www.iana.org/assignments/rolie/category/information-type The registry is to be located on the Registry Page created in step four above. The registry is to be managed via Specification Required as defined in [ RFC 8126 ]. We understand that there are no initial registrations in the new registry. Sixth, in the Well-Known URIs registry located at: https://www.iana.org/assignments/well-known-uris/ a new URI is to be registered as follows: URI Suffix: rolie/servicedocument Change Controller: IETF Reference: [ RFC-to-be ] Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC. Seventh, also in the Well-Known URIs registry located at: https://www.iana.org/assignments/well-known-uris/ a new URI is to be registered as follows: URI Suffix: rolie/categorydocument Change Controller: IETF Reference: [ RFC-to-be ] Because this registry also requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC. The IANA Services Operator understands that these seven actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Services Specialist (END IANA COMMENTS) From nobody Thu Oct 12 12:05:10 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD2F13456F; Thu, 12 Oct 2017 12:05:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , "Nancy Cam-Winget" X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150783510878.25752.3812632916411721086.idtracker@ietfa.amsl.com> Date: Thu, 12 Oct 2017 12:05:08 -0700 From: IETF Secretariat Archived-At: Subject: [mile] Datatracker State Update Notice: X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 19:05:09 -0000 IANA review state changed to "IANA - Not OK" Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/ From nobody Fri Oct 13 00:15:33 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B73513292F; Fri, 13 Oct 2017 00:15:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , , "Nancy Cam-Winget" Cc: iesg-secretary@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150787893243.4884.6558955736831150455.idtracker@ietfa.amsl.com> Date: Fri, 13 Oct 2017 00:15:32 -0700 Archived-At: Subject: [mile] Last Call Expired: X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 07:15:32 -0000 Please DO NOT reply to this email. I-D: Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Fri Oct 13 07:21:12 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B511320C9; Fri, 13 Oct 2017 07:21:05 -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 f__3lQf2T95D; Fri, 13 Oct 2017 07:21:04 -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 463EA120720; Fri, 13 Oct 2017 07:21:04 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id l188so10435190pfc.6; Fri, 13 Oct 2017 07:21:04 -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=71cgjs9Yt2MqZcSaV5HJSutli3rMlIiG6jtDQWbNGSQ=; b=sI0R2R25ZLgqxlnkvsVOj3cUEQJlDJMjvHrPiJJhdFmaTcor/P/mbJF33MlhJtkU0D jz6b1KEe3gG+9m/kyniRP+4pLasNn3FnZqVfverwE1oAmR0eJ9GQWP8opjlzxstjhzHE PcEr0bwg9n0GpS8bbyqzzTrwMPEduPioHqzbgSngT9x8k/preXx3t7H+iWi4Kfxgr4Zz +IFUlehMgZZtnKgLjUA8ZHzglNYs7IB8PZZ+PziRmFTKAojmoe0DhdNNy0Z2lQNWjx9E Fyns6Fb7RhhjNtgEOhLzTGLJRj1old+h56/3/YEgL8HLGlPe4vl522ap39Nb3e0dHlII fxUA== 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=71cgjs9Yt2MqZcSaV5HJSutli3rMlIiG6jtDQWbNGSQ=; b=Fq42EVeYl6MDfuXtGS669MOlKTAaGw03otBF12AN5SFQceQgJuaCOgiz5SB2wzfmQZ ZJ0nItl/BAU9nL13dIrHOZEG5V6Qqw+FRE0Ek9K1Xka2BY5nnj7B5gO7iMbKm708WxEk cvdG57vZ+5AU7LHuNd7ZbwYjW7qMDAEeoWkQP8j8kK9KsAhF0oShZCQwfYAPnrfz/tMS ItgLCGVbtXCa4KCtJVm3MVhRaLOssHaX6+JS3MZRVHJ0GmwuQrukvErumWZNbE85OAAZ Czqi0ZcczLWrceknuJLCukqK/bymDT1f81eAv8dLZd5mJ4rRGD9ZadJ6MRMxE0O2u8G+ uI/Q== X-Gm-Message-State: AMCzsaUYC8BAd2YsveacDIVnGK9oRKxBhsIKBH3Pe6PJm9FKeD6HXdGI 0lSxl17lbpmuvZ5x71utYnMyhnEYUXriXEbzKws= X-Google-Smtp-Source: AOwi7QAXF5iZCwosIRCer0YIDh/8hPLrKycPws4yc47QdQ2BbEq7TATycBWK+/hmLKtbUQp7WGDEdIOXQHBMA7pKFyE= X-Received: by 10.101.83.12 with SMTP id m12mr1450021pgq.153.1507904463823; Fri, 13 Oct 2017 07:21:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Fri, 13 Oct 2017 07:20:23 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> From: Kathleen Moriarty Date: Fri, 13 Oct 2017 10:20:23 -0400 Message-ID: To: Martin Thomson Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 14:21:06 -0000 The telechat prep delayed my response. Inline. On Mon, Oct 9, 2017 at 11:45 PM, Martin Thomson wrote: > On Tue, Oct 10, 2017 at 2:05 PM, Kathleen Moriarty > wrote: >> I'll review and see if the WG participants can as well. I think there will be many applications to follow with high security requirements and no tolerance for replay attacks. > > That is true, but it's not clear to me that this is a protocol that is > intolerant of replay. AtomPub follows a pattern that limits exposure > fairly well. The primary thing to safeguard in ROLIE is the > confidentiality of the content, and replay won't generally compromise > that. The sorts of things you might see is duplicate resource > creation (we recommend against POST in early data for that reason; we > also recommend against PUT), and the sort of traffic analysis and > timing side channel information that reveals if resources exist or > have been updated (which shouldn't be an issue here). I see what you are saying and that makes sense, but you also lose forward secrecy with 0RTT and that is a problem. I think we need to accept that there will be uses of HTTP that will not allow for 0RTT. In the draft you mentioned in the HTTP working group, section 3 even starts out with, "When a server enables early data", meaning it won't always be appropriate. I do think that draft should be more clear on the risks, with a pointer back to Section 2.3 of TLS 1.3. I think there will also be cases where HTTP is used and the profile isn't a fit. Since some implementations of TLS 1.3 keep the streams separate (0RTT and full negotiation), just using the full negotiation stream will reduce configuration problems for implementers. Lots of security problems are the result of configuration mistakes and if we can avoid them in places where it matters, we should. The systems running ROLIE will be ones that enterprises will regard as high value assets. Replay attack and lack of forward secrecy aren't acceptable. The same will be true of many other HTTP enabled services. A performance gain isn't worth the trade off. Even with the profile you've created, the server has the option to not enable early data, although that's not as clear as I think it should be in the draft and is something that would be good to improve, If developers implementing the HTTP profile only look at this draft, they have to have enough context to understand the implications that they must in turn ensure implementors of their code/applications using code have the information to make appropriate decisions for their environment. I hope that's helpful enough for an update of your profile draft. My opinion is that for ROLIE, there is no need for 0RTT. I'm not sure a slight delay in publication would matter much since TLS 1.3 is getting closer to publication. If it is, we could also play with the language so it's an informational reference if there is a rush. Thanks for your thoughtful review. -- Best regards, Kathleen From nobody Fri Oct 13 07:21:39 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id F0342120720; Fri, 13 Oct 2017 07:21:05 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B511320C9; Fri, 13 Oct 2017 07:21:05 -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 f__3lQf2T95D; Fri, 13 Oct 2017 07:21:04 -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 463EA120720; Fri, 13 Oct 2017 07:21:04 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id l188so10435190pfc.6; Fri, 13 Oct 2017 07:21:04 -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=71cgjs9Yt2MqZcSaV5HJSutli3rMlIiG6jtDQWbNGSQ=; b=sI0R2R25ZLgqxlnkvsVOj3cUEQJlDJMjvHrPiJJhdFmaTcor/P/mbJF33MlhJtkU0D jz6b1KEe3gG+9m/kyniRP+4pLasNn3FnZqVfverwE1oAmR0eJ9GQWP8opjlzxstjhzHE PcEr0bwg9n0GpS8bbyqzzTrwMPEduPioHqzbgSngT9x8k/preXx3t7H+iWi4Kfxgr4Zz +IFUlehMgZZtnKgLjUA8ZHzglNYs7IB8PZZ+PziRmFTKAojmoe0DhdNNy0Z2lQNWjx9E Fyns6Fb7RhhjNtgEOhLzTGLJRj1old+h56/3/YEgL8HLGlPe4vl522ap39Nb3e0dHlII fxUA== 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=71cgjs9Yt2MqZcSaV5HJSutli3rMlIiG6jtDQWbNGSQ=; b=Fq42EVeYl6MDfuXtGS669MOlKTAaGw03otBF12AN5SFQceQgJuaCOgiz5SB2wzfmQZ ZJ0nItl/BAU9nL13dIrHOZEG5V6Qqw+FRE0Ek9K1Xka2BY5nnj7B5gO7iMbKm708WxEk cvdG57vZ+5AU7LHuNd7ZbwYjW7qMDAEeoWkQP8j8kK9KsAhF0oShZCQwfYAPnrfz/tMS ItgLCGVbtXCa4KCtJVm3MVhRaLOssHaX6+JS3MZRVHJ0GmwuQrukvErumWZNbE85OAAZ Czqi0ZcczLWrceknuJLCukqK/bymDT1f81eAv8dLZd5mJ4rRGD9ZadJ6MRMxE0O2u8G+ uI/Q== X-Gm-Message-State: AMCzsaUYC8BAd2YsveacDIVnGK9oRKxBhsIKBH3Pe6PJm9FKeD6HXdGI 0lSxl17lbpmuvZ5x71utYnMyhnEYUXriXEbzKws= X-Google-Smtp-Source: AOwi7QAXF5iZCwosIRCer0YIDh/8hPLrKycPws4yc47QdQ2BbEq7TATycBWK+/hmLKtbUQp7WGDEdIOXQHBMA7pKFyE= X-Received: by 10.101.83.12 with SMTP id m12mr1450021pgq.153.1507904463823; Fri, 13 Oct 2017 07:21:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Fri, 13 Oct 2017 07:20:23 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> From: Kathleen Moriarty Date: Fri, 13 Oct 2017 10:20:23 -0400 Message-ID: To: Martin Thomson Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171013142105.F0342120720@ietfa.amsl.com> Resent-Date: Fri, 13 Oct 2017 07:21:05 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 14:21:06 -0000 The telechat prep delayed my response. Inline. On Mon, Oct 9, 2017 at 11:45 PM, Martin Thomson wrote: > On Tue, Oct 10, 2017 at 2:05 PM, Kathleen Moriarty > wrote: >> I'll review and see if the WG participants can as well. I think there will be many applications to follow with high security requirements and no tolerance for replay attacks. > > That is true, but it's not clear to me that this is a protocol that is > intolerant of replay. AtomPub follows a pattern that limits exposure > fairly well. The primary thing to safeguard in ROLIE is the > confidentiality of the content, and replay won't generally compromise > that. The sorts of things you might see is duplicate resource > creation (we recommend against POST in early data for that reason; we > also recommend against PUT), and the sort of traffic analysis and > timing side channel information that reveals if resources exist or > have been updated (which shouldn't be an issue here). I see what you are saying and that makes sense, but you also lose forward secrecy with 0RTT and that is a problem. I think we need to accept that there will be uses of HTTP that will not allow for 0RTT. In the draft you mentioned in the HTTP working group, section 3 even starts out with, "When a server enables early data", meaning it won't always be appropriate. I do think that draft should be more clear on the risks, with a pointer back to Section 2.3 of TLS 1.3. I think there will also be cases where HTTP is used and the profile isn't a fit. Since some implementations of TLS 1.3 keep the streams separate (0RTT and full negotiation), just using the full negotiation stream will reduce configuration problems for implementers. Lots of security problems are the result of configuration mistakes and if we can avoid them in places where it matters, we should. The systems running ROLIE will be ones that enterprises will regard as high value assets. Replay attack and lack of forward secrecy aren't acceptable. The same will be true of many other HTTP enabled services. A performance gain isn't worth the trade off. Even with the profile you've created, the server has the option to not enable early data, although that's not as clear as I think it should be in the draft and is something that would be good to improve, If developers implementing the HTTP profile only look at this draft, they have to have enough context to understand the implications that they must in turn ensure implementors of their code/applications using code have the information to make appropriate decisions for their environment. I hope that's helpful enough for an update of your profile draft. My opinion is that for ROLIE, there is no need for 0RTT. I'm not sure a slight delay in publication would matter much since TLS 1.3 is getting closer to publication. If it is, we could also play with the language so it's an informational reference if there is a rush. Thanks for your thoughtful review. -- Best regards, Kathleen From nobody Fri Oct 13 13:55:18 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB98133011; Fri, 13 Oct 2017 13:55:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , "Nancy Cam-Winget" X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150792811104.23771.17041038154310617393.idtracker@ietfa.amsl.com> Date: Fri, 13 Oct 2017 13:55:11 -0700 From: IETF Secretariat Archived-At: Subject: [mile] Datatracker State Update Notice: X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 20:55:11 -0000 IESG state changed: New State: IESG Evaluation (The previous state was Waiting for AD Go-Ahead) Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/ From nobody Fri Oct 13 14:39:36 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id AF1621321D8; Fri, 13 Oct 2017 14:39:34 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A866133011 for ; Fri, 13 Oct 2017 14:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twZDBhCofyi5 for ; Fri, 13 Oct 2017 14:39:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3051321D8 for ; Fri, 13 Oct 2017 14:39:30 -0700 (PDT) Received: from usplmg20.ericsson.net ([198.24.6.45]:46128) by zinfandel.tools.ietf.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1e37fU-0007AN-Ci for draft-ietf-mile-rolie.all@tools.ietf.org; Fri, 13 Oct 2017 14:39:30 -0700 X-AuditID: c618062d-f51209c000004f0a-62-59e14b7a1ac6 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 75.EE.20234.A7B41E95; Sat, 14 Oct 2017 01:25:46 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0352.000; Fri, 13 Oct 2017 17:38:46 -0400 From: Meral Shirazipour To: "draft-ietf-mile-rolie.all@tools.ietf.org" , "gen-art@ietf.org" Thread-Topic: Gen-ART Telechat Call review of draft-ietf-mile-rolie-10 Thread-Index: AdNEa3cfCku/gXinQFWk7Mmf+XTcIw== Date: Fri, 13 Oct 2017 21:38:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_ABCAA4EF18F17B4FB619EA93DEF7939A4F6047A6eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXRPiG6V98NIg4vrLSwaP5xgsrj66jOL A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJXRuvs/Y8Fc9YreuRNYGxgvKHUxcnJICJhI 7F16jq2LkYtDSOAoo8Sxl6+gnOWMEm+P3WAHqWITsJDY/vs5K0hCRKCFUaJjykJWkISwgKPE n41vWEBsEQE3ieuPdrJD2HoSM3qegMVZBFQleo59AIvzCvhKPNizECzOKCAm8f3UGiYQm1lA XOLWk/lMECcJSCzZc54ZwhaVePn4HyuErSixr386O0R9vsS5iasZIWYKSpyc+YRlAqPgLCSj ZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9i5CgtLsjJTTcy2MQIDPxjEmy6 OxjvT/c8xCjAwajEw8ti9zBSiDWxrLgy9xCjBAezkghvjgFQiDclsbIqtSg/vqg0J7X4EKM0 B4uSOO+E8xcihATSE0tSs1NTC1KLYLJMHJxSDYzMRXq5ex5Fv98XzLbz+QQxnpQJL2R+awsf qFpydsLiouV8iicLt4duFH/ixZxy78zeTclinQvf6UvuvhAjtPaFc8i/w9dfalt1vpiafDPo 52MJo189p6TreD7JMmbe+NBwIetrZfKFiK7afUvd532ZHDjd95S75KP1CVVR2XOOB5bLJC58 5+yhxFKckWioxVxUnAgA8CYREHgCAAA= X-SA-Exim-Connect-IP: 198.24.6.45 X-SA-Exim-Rcpt-To: draft-ietf-mile-rolie.all@tools.ietf.org X-SA-Exim-Mail-From: meral.shirazipour@ericsson.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-To: draft-ietf-mile-rolie.all@ietf.org Resent-Message-Id: <20171013213930.CD3051321D8@ietfa.amsl.com> Resent-Date: Fri, 13 Oct 2017 14:39:30 -0700 (PDT) Resent-From: meral.shirazipour@ericsson.com Archived-At: Subject: [mile] Gen-ART Telechat Call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 21:39:35 -0000 --_000_ABCAA4EF18F17B4FB619EA93DEF7939A4F6047A6eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 t= he 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-mile-rolie-10 Reviewer: Meral Shirazipour Review Date: 2017-10-13 IETF LC End Date: 2017-10-13 IESG Telechat date: 2017-10-26 Summary: This draft is ready to be published as Standards RFC . Major issues: Minor issues: Nits/editorial comments: -[Page 13], "handling of collections ealier "--->"handling of collections e= arlier " -Please spell out IRI (Internationalized Resource Identifiers) at first use Best Regards, Meral --- Meral Shirazipour Ericsson Research www.ericsson.com --_000_ABCAA4EF18F17B4FB619EA93DEF7939A4F6047A6eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am the assigned Gen-ART reviewer for this draft. T= he General Area Review Team (Gen-ART) reviews all IETF documents being proc= essed by the IESG for the IETF Chair. Please wait for direction from your d= ocument shepherd or AD before posting a new version of the draft.

 

For more information, please see the FAQ at <http= ://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

 

Document: draft-ietf-mile-rolie-10

Reviewer: Meral Shirazipour

Review Date: 2017-10-13

IETF LC End Date: 2017-10-13   =

IESG Telechat date: 2017-10-26

 

Summary: This draft is ready to be published as Stan= dards RFC .

 

Major issues:

Minor issues:

Nits/editorial comments:

-[Page 13], "handling of collections ealier &qu= ot;--->"handling of collections earlier "

-Please spell out IRI (Internationalized Resource Id= entifiers) at first use

 

 

 

Best Regards,

Meral

---

Meral Shirazipour

Ericsson Research

www.ericsson.com

 

--_000_ABCAA4EF18F17B4FB619EA93DEF7939A4F6047A6eusaamb107erics_-- From nobody Sun Oct 15 17:46:04 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E8D1332D4; Sun, 15 Oct 2017 17:46:02 -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 i9G13exjYFbK; Sun, 15 Oct 2017 17:46:01 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 F2FF11321A4; Sun, 15 Oct 2017 17:46:00 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id c77so22552556oig.0; Sun, 15 Oct 2017 17:46:00 -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=Q0tGNwqGIwnQjYbYltOIcifuQmb8I7/BcIytxvpnU1I=; b=sLzsNn++IwhX3r92s4rlJrfjSX9RMYx9Su6zRyqsKBOGx1QN3l2gSzYbcG7766I5YC KGxLONbgYY4BrGt1Qm1OyCGV/pAhAM4gK6doNjFHSK3TFmKnoNmjVM9H6ItlAhZ6Dsxd oiprNsLOP1MPjToiOWxpLMT9mwHMTkotbEYYewbYv0f/Y9kzQ+xg0eo0vRvMYAKaSwHm Cwz2kbOpQrTE+6NPuqvWp6TWLQz+KzgtCZEo+BDj3lDzb2KQ4hWQDIsN06gA53dzmhLQ O1+/g8/2JIZ9GdRCqshYCe39lSJfgAT/OcIw9v/MrH2h4I9PjHHf6Z4Ll03DqWtLVBPG mOrw== 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=Q0tGNwqGIwnQjYbYltOIcifuQmb8I7/BcIytxvpnU1I=; b=F9e9EaWqw3U8o5w8DWUfFts4sM7Se0mapE+Lt5ELRifhE97/3zpNyRi8fVBmaTkBCL NGD1m5N8ywHcfEpL/yrL3CM+83xcvSFxPuffRq7RdDDMYMDWCwXcd8bZFID7fjZXvVHH In6ixh8YIjiy46bR870keb0fndoPu7ue+3ZNyA4jUDNp/tfblvKwyjmoFTKosmWZSADQ 3kIavwAwEsoYV8M7lKMVvi+41ztf8u2xQQSEZ9Dkuu3KIoRTaUAjzwMKEC57wbOz7KvR R6+c4WTDI2ULylgKslC1+mBaN1m1ZLjP0lZnOV0ogJH+I5ryXjJVwJSzMrwzjpu+ZwKe CVhg== X-Gm-Message-State: AMCzsaWzMD0yD3J4JeJ2kufV2RPvp/RnPoEgjmj7qnecOSUF29+aY7sj AepipArSSdxnEJJErhE0NuD52fW2+K8EQ+LLn/c= X-Google-Smtp-Source: ABhQp+R+nsaXB6wXT7UXf53FTH8UvyE9ceffNHzXtg3FCa2wanZRvG9KinR4McP+SvcrmwsumkXDp3dqr8fuTg8KMt8= X-Received: by 10.157.53.17 with SMTP id o17mr2687144otc.35.1508114760103; Sun, 15 Oct 2017 17:46:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Sun, 15 Oct 2017 17:45:59 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> From: Martin Thomson Date: Mon, 16 Oct 2017 11:45:59 +1100 Message-ID: To: Kathleen Moriarty Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 00:46:03 -0000 On Sat, Oct 14, 2017 at 1:20 AM, Kathleen Moriarty wrote: > The systems running ROLIE will be ones that enterprises will regard as > high value assets. Replay attack and lack of forward secrecy aren't > acceptable. The same will be true of many other HTTP enabled > services. A performance gain isn't worth the trade off. My point isn't to reject this sort of analysis, which is possibly correct, but to point out that this analysis is one that a deployment makes based on the circumstances Everyone thinks that their thing is a special snowflake, and that's OK, but you are asking for a levy on all implementations that would prevent use of 0-RTT in all deployments. I think that is inappropriate. I don't want to see every draft that the IETF ever published making its own assessment and a policy statement regarding this particular feature. (We don't mandate a particular authentication mechanism here either.) Note that TLS 1.3 permits resumption without forward secrecy. It's not widely implemented that way, but it is possible. If you care about forward secrecy (I'm not sure that it's especially critical in this context given the time-sensitive nature of the information you are talking about), then you have to make statements about that as well. But again, I would not on the same grounds: the purpose of this work is to define what interoperability looks like, not to legislate deployment configuration. Explain the trade-off and let the operational teams do their work. From nobody Sun Oct 15 17:46:22 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 448AE1321A4; Sun, 15 Oct 2017 17:46:03 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E8D1332D4; Sun, 15 Oct 2017 17:46:02 -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 i9G13exjYFbK; Sun, 15 Oct 2017 17:46:01 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 F2FF11321A4; Sun, 15 Oct 2017 17:46:00 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id c77so22552556oig.0; Sun, 15 Oct 2017 17:46:00 -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=Q0tGNwqGIwnQjYbYltOIcifuQmb8I7/BcIytxvpnU1I=; b=sLzsNn++IwhX3r92s4rlJrfjSX9RMYx9Su6zRyqsKBOGx1QN3l2gSzYbcG7766I5YC KGxLONbgYY4BrGt1Qm1OyCGV/pAhAM4gK6doNjFHSK3TFmKnoNmjVM9H6ItlAhZ6Dsxd oiprNsLOP1MPjToiOWxpLMT9mwHMTkotbEYYewbYv0f/Y9kzQ+xg0eo0vRvMYAKaSwHm Cwz2kbOpQrTE+6NPuqvWp6TWLQz+KzgtCZEo+BDj3lDzb2KQ4hWQDIsN06gA53dzmhLQ O1+/g8/2JIZ9GdRCqshYCe39lSJfgAT/OcIw9v/MrH2h4I9PjHHf6Z4Ll03DqWtLVBPG mOrw== 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=Q0tGNwqGIwnQjYbYltOIcifuQmb8I7/BcIytxvpnU1I=; b=F9e9EaWqw3U8o5w8DWUfFts4sM7Se0mapE+Lt5ELRifhE97/3zpNyRi8fVBmaTkBCL NGD1m5N8ywHcfEpL/yrL3CM+83xcvSFxPuffRq7RdDDMYMDWCwXcd8bZFID7fjZXvVHH In6ixh8YIjiy46bR870keb0fndoPu7ue+3ZNyA4jUDNp/tfblvKwyjmoFTKosmWZSADQ 3kIavwAwEsoYV8M7lKMVvi+41ztf8u2xQQSEZ9Dkuu3KIoRTaUAjzwMKEC57wbOz7KvR R6+c4WTDI2ULylgKslC1+mBaN1m1ZLjP0lZnOV0ogJH+I5ryXjJVwJSzMrwzjpu+ZwKe CVhg== X-Gm-Message-State: AMCzsaWzMD0yD3J4JeJ2kufV2RPvp/RnPoEgjmj7qnecOSUF29+aY7sj AepipArSSdxnEJJErhE0NuD52fW2+K8EQ+LLn/c= X-Google-Smtp-Source: ABhQp+R+nsaXB6wXT7UXf53FTH8UvyE9ceffNHzXtg3FCa2wanZRvG9KinR4McP+SvcrmwsumkXDp3dqr8fuTg8KMt8= X-Received: by 10.157.53.17 with SMTP id o17mr2687144otc.35.1508114760103; Sun, 15 Oct 2017 17:46:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Sun, 15 Oct 2017 17:45:59 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> From: Martin Thomson Date: Mon, 16 Oct 2017 11:45:59 +1100 Message-ID: To: Kathleen Moriarty Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171016004603.448AE1321A4@ietfa.amsl.com> Resent-Date: Sun, 15 Oct 2017 17:46:03 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 00:46:03 -0000 On Sat, Oct 14, 2017 at 1:20 AM, Kathleen Moriarty wrote: > The systems running ROLIE will be ones that enterprises will regard as > high value assets. Replay attack and lack of forward secrecy aren't > acceptable. The same will be true of many other HTTP enabled > services. A performance gain isn't worth the trade off. My point isn't to reject this sort of analysis, which is possibly correct, but to point out that this analysis is one that a deployment makes based on the circumstances Everyone thinks that their thing is a special snowflake, and that's OK, but you are asking for a levy on all implementations that would prevent use of 0-RTT in all deployments. I think that is inappropriate. I don't want to see every draft that the IETF ever published making its own assessment and a policy statement regarding this particular feature. (We don't mandate a particular authentication mechanism here either.) Note that TLS 1.3 permits resumption without forward secrecy. It's not widely implemented that way, but it is possible. If you care about forward secrecy (I'm not sure that it's especially critical in this context given the time-sensitive nature of the information you are talking about), then you have to make statements about that as well. But again, I would not on the same grounds: the purpose of this work is to define what interoperability looks like, not to legislate deployment configuration. Explain the trade-off and let the operational teams do their work. From nobody Sun Oct 15 18:43:21 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEF41332DA; Sun, 15 Oct 2017 18:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 auoN8ggvMH8W; Sun, 15 Oct 2017 18:43:06 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 B68F812895E; Sun, 15 Oct 2017 18:43:05 -0700 (PDT) X-AuditID: 12074424-8a5ff70000004fa7-d2-59e40ea61300 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 45.E4.20391.7AE04E95; Sun, 15 Oct 2017 21:43:03 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v9G1h1NZ009738; Sun, 15 Oct 2017 21:43:01 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9G1guMP002994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Oct 2017 21:42:59 -0400 Date: Sun, 15 Oct 2017 20:42:57 -0500 From: Benjamin Kaduk To: Martin Thomson Cc: Kathleen Moriarty , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Message-ID: <20171016014256.GK96685@kduck.kaduk.org> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixCmqrbuc70mkwasnyhYr7npY/L/zl93i 2cb5LBYNO/Mtrp35x2ix538fkwObx85Zd9k9liz5yRTAFMVlk5Kak1mWWqRvl8CV8fuWa8Fh iYpJcw+yNzBeF+5i5OSQEDCRaH5zhLWLkYtDSGAxk8TaxQ8ZIZyNjBJH7j9kB6kSErjKJPFn UQyIzSKgKrF9TwNYnE1ARaKh+zIziC0ioCux6OwDdpBmZoHDjBJrz58HKxIWcJDY/qMJrIgX aN3xX++hNpxmkTh4chEbREJQ4uTMJywgNrOAlsSNfy+Zuhg5gGxpieX/OEDCnAKBEruvXQYr ERVQlpi3bxXbBEaBWUi6ZyHpnoXQvYCReRWjbEpulW5uYmZOcWqybnFyYl5eapGuuV5uZole akrpJkZQKLO7qOxg7O7xPsQowMGoxMO74tzjSCHWxLLiytxDjJIcTEqivOdaH0YK8SXlp1Rm JBZnxBeV5qQWH2KU4GBWEuHdy/skUog3JbGyKrUoHyYlzcGiJM67LWhXpJBAemJJanZqakFq EUxWhoNDSYJ3FUijYFFqempFWmZOCUKaiYMTZDgP0PAesOHFBYm5xZnpEPlTjIpS4rySIAkB kERGaR5cLyjVSGTvr3nFKA70ijDvdpAqHmCagut+BTSYCWjwu4gHIINLEhFSUg2MK6NKy6LX Of9w+ul4umZXUO6sBaJNZnbXF7zdfeW2nULSkbd7zRrbuDd3PGz46/92QdOXQruy+rfqvj+/ hE/TkbjO6ujkM7f+aPKB3Ng/tzqZrmWfVv/uJpDc/3C1zaM/HLMvLk9t/7IwPuhtt6Fj/+XT Fz9snuCXpz/5Q9eVEN6dH2+2B+0PUWIpzkg01GIuKk4EAMPnNXcQAwAA Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 01:43:08 -0000 Sorry for the slow response to this thread; I wanted to have a closer read of the ROLIE document itself (and not just the cherry-picked TLS-specific bits). On Mon, Oct 16, 2017 at 11:45:59AM +1100, Martin Thomson wrote: > On Sat, Oct 14, 2017 at 1:20 AM, Kathleen Moriarty > wrote: > > The systems running ROLIE will be ones that enterprises will regard as > > high value assets. Replay attack and lack of forward secrecy aren't > > acceptable. The same will be true of many other HTTP enabled > > services. A performance gain isn't worth the trade off. > > My point isn't to reject this sort of analysis, which is possibly > correct, but to point out that this analysis is one that a deployment > makes based on the circumstances > > Everyone thinks that their thing is a special snowflake, and that's > OK, but you are asking for a levy on all implementations that would > prevent use of 0-RTT in all deployments. I think that is > inappropriate. I don't want to see every draft that the IETF ever > published making its own assessment and a policy statement regarding > this particular feature. (We don't mandate a particular > authentication mechanism here either.) Every draft doesn't have to; in the absense of an explicit statement it is assumed that 0-RTT should not be used. But, for protocols built on top of HTTP, perhaps things are not as clear cut. > Note that TLS 1.3 permits resumption without forward secrecy. It's > not widely implemented that way, but it is possible. If you care > about forward secrecy (I'm not sure that it's especially critical in > this context given the time-sensitive nature of the information you > are talking about), then you have to make statements about that as > well. But again, I would not on the same grounds: the purpose of this > work is to define what interoperability looks like, not to legislate > deployment configuration. Explain the trade-off and let the > operational teams do their work. My main consideration is that the ROLIE document we're talking about is a framework, and does not define any information types itself. So, you are asking the operational teams to know and anlayze not just what events they are currently handling but also all types that might be handled in the future, which seems like an intractable analysis for them to perform. But yes, you are right that a statement about forward secrecy as a requirement would be appropriate. I'm also quite reluctant to provide a general recommendation to send client-authenticated requests in 0-RTT, as it still seems too risky to me. I also don't see how preventing the use of 0-RTT is supposed to be a "levy on all implementations". It seems to only require *not* adding additional code/logic to handle 0-RTT. I could perhaps see calling it a "levy on deployments" that are unable to take advantage of the performance benefits, but given the large number of unknowns in what will be conveyed via ROLIE, it seems to me an unwarranted risk to try to take advantage of those benefits in general. -Ben From nobody Sun Oct 15 18:43:27 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 49E0F1332E1; Sun, 15 Oct 2017 18:43:08 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEF41332DA; Sun, 15 Oct 2017 18:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 auoN8ggvMH8W; Sun, 15 Oct 2017 18:43:06 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 B68F812895E; Sun, 15 Oct 2017 18:43:05 -0700 (PDT) X-AuditID: 12074424-8a5ff70000004fa7-d2-59e40ea61300 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 45.E4.20391.7AE04E95; Sun, 15 Oct 2017 21:43:03 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v9G1h1NZ009738; Sun, 15 Oct 2017 21:43:01 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9G1guMP002994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Oct 2017 21:42:59 -0400 Date: Sun, 15 Oct 2017 20:42:57 -0500 From: Benjamin Kaduk To: Martin Thomson Cc: Kathleen Moriarty , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Message-ID: <20171016014256.GK96685@kduck.kaduk.org> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixCmqrbuc70mkwasnyhYr7npY/L/zl93i 2cb5LBYNO/Mtrp35x2ix538fkwObx85Zd9k9liz5yRTAFMVlk5Kak1mWWqRvl8CV8fuWa8Fh iYpJcw+yNzBeF+5i5OSQEDCRaH5zhLWLkYtDSGAxk8TaxQ8ZIZyNjBJH7j9kB6kSErjKJPFn UQyIzSKgKrF9TwNYnE1ARaKh+zIziC0ioCux6OwDdpBmZoHDjBJrz58HKxIWcJDY/qMJrIgX aN3xX++hNpxmkTh4chEbREJQ4uTMJywgNrOAlsSNfy+Zuhg5gGxpieX/OEDCnAKBEruvXQYr ERVQlpi3bxXbBEaBWUi6ZyHpnoXQvYCReRWjbEpulW5uYmZOcWqybnFyYl5eapGuuV5uZole akrpJkZQKLO7qOxg7O7xPsQowMGoxMO74tzjSCHWxLLiytxDjJIcTEqivOdaH0YK8SXlp1Rm JBZnxBeV5qQWH2KU4GBWEuHdy/skUog3JbGyKrUoHyYlzcGiJM67LWhXpJBAemJJanZqakFq EUxWhoNDSYJ3FUijYFFqempFWmZOCUKaiYMTZDgP0PAesOHFBYm5xZnpEPlTjIpS4rySIAkB kERGaR5cLyjVSGTvr3nFKA70ijDvdpAqHmCagut+BTSYCWjwu4gHIINLEhFSUg2MK6NKy6LX Of9w+ul4umZXUO6sBaJNZnbXF7zdfeW2nULSkbd7zRrbuDd3PGz46/92QdOXQruy+rfqvj+/ hE/TkbjO6ujkM7f+aPKB3Ng/tzqZrmWfVv/uJpDc/3C1zaM/HLMvLk9t/7IwPuhtt6Fj/+XT Fz9snuCXpz/5Q9eVEN6dH2+2B+0PUWIpzkg01GIuKk4EAMPnNXcQAwAA Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171016014308.49E0F1332E1@ietfa.amsl.com> Resent-Date: Sun, 15 Oct 2017 18:43:08 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 01:43:08 -0000 Sorry for the slow response to this thread; I wanted to have a closer read of the ROLIE document itself (and not just the cherry-picked TLS-specific bits). On Mon, Oct 16, 2017 at 11:45:59AM +1100, Martin Thomson wrote: > On Sat, Oct 14, 2017 at 1:20 AM, Kathleen Moriarty > wrote: > > The systems running ROLIE will be ones that enterprises will regard as > > high value assets. Replay attack and lack of forward secrecy aren't > > acceptable. The same will be true of many other HTTP enabled > > services. A performance gain isn't worth the trade off. > > My point isn't to reject this sort of analysis, which is possibly > correct, but to point out that this analysis is one that a deployment > makes based on the circumstances > > Everyone thinks that their thing is a special snowflake, and that's > OK, but you are asking for a levy on all implementations that would > prevent use of 0-RTT in all deployments. I think that is > inappropriate. I don't want to see every draft that the IETF ever > published making its own assessment and a policy statement regarding > this particular feature. (We don't mandate a particular > authentication mechanism here either.) Every draft doesn't have to; in the absense of an explicit statement it is assumed that 0-RTT should not be used. But, for protocols built on top of HTTP, perhaps things are not as clear cut. > Note that TLS 1.3 permits resumption without forward secrecy. It's > not widely implemented that way, but it is possible. If you care > about forward secrecy (I'm not sure that it's especially critical in > this context given the time-sensitive nature of the information you > are talking about), then you have to make statements about that as > well. But again, I would not on the same grounds: the purpose of this > work is to define what interoperability looks like, not to legislate > deployment configuration. Explain the trade-off and let the > operational teams do their work. My main consideration is that the ROLIE document we're talking about is a framework, and does not define any information types itself. So, you are asking the operational teams to know and anlayze not just what events they are currently handling but also all types that might be handled in the future, which seems like an intractable analysis for them to perform. But yes, you are right that a statement about forward secrecy as a requirement would be appropriate. I'm also quite reluctant to provide a general recommendation to send client-authenticated requests in 0-RTT, as it still seems too risky to me. I also don't see how preventing the use of 0-RTT is supposed to be a "levy on all implementations". It seems to only require *not* adding additional code/logic to handle 0-RTT. I could perhaps see calling it a "levy on deployments" that are unable to take advantage of the performance benefits, but given the large number of unknowns in what will be conveyed via ROLIE, it seems to me an unwarranted risk to try to take advantage of those benefits in general. -Ben From nobody Mon Oct 16 12:42:23 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC7E134555 for ; Mon, 16 Oct 2017 12:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 OH-HMeh9e5cP for ; Mon, 16 Oct 2017 12:42:20 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 E5215132355 for ; Mon, 16 Oct 2017 12:42:19 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 27AE6E01DC; Mon, 16 Oct 2017 19:42:19 +0000 (UTC) Received: by request3.lax.icann.org (Postfix, from userid 48) id E0050C20611; Mon, 16 Oct 2017 19:42:18 +0000 (UTC) RT-Owner: sabrina.tanamal From: "Sabrina Tanamal via RT" Reply-To: drafts-expert-review@iana.org In-Reply-To: References: Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #985228 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: sabrina.tanamal@icann.org CC: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 16 Oct 2017 19:42:18 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [mile] [IANA #985228] expert review for draft-ietf-mile-rolie (well-known-uris) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 19:42:21 -0000 Dear Authors/Chairs/ADs: Please see the comments from the designated expert below. Thank you, Sabrina Tanamal IANA Services Specialist --- This draft proposes registration of a well-known URI, "rolie/servicedocument". That syntax does not conform to the requirements of RFC5785, Section 3: """ Registered names MUST conform to the segment-nz production in[RFC3986]. """ I'd suggest registering just "rolie" and specifying that "/servicedocument" under it is used for this purpose, and that other paths under "rolie" can be reserved using other standards-track documents. However, it is not clear why such a well-known URI is needed. RFC5785 states: """ [W]ell-known URIs are not intended for general information retrieval or establishment of large URI namespaces on the Web. Rather, they are designed to facilitate discovery of information on a site when it isn't practical to use other mechanisms; for example, when discovering policy that needs to be evaluated before a resource is accessed, or when using multiple round-trips is judged detrimental to performance. As such, the well-known URI space was created with the expectation that it will be used to make site-wide policy information and other metadata available directly (if sufficiently concise), or provide references to other URIs that provide such metadata. """ This draft doesn't explain why using a URL to locate a service document isn't sufficient; in other words, why is it necessary to reserve name space on every Web server existent for this function? The draft does mention: """ A mechanism to determine which host and port to use is not specified in this document. Use of a mechanism such as DNS SRV Records [RFC2782] can provide a secure and reliable discovery mechanism for determining a specific host and port to use for retrieving a Service Document for a given DNS domain. """ ... but it does not specify how to use DNS SRV to achieve this goal, leading me to believe that this is underspecified and not a strong motivation for the well-known URI. Is there some context about this proposed use that I've overlooked? ---8<--- From nobody Tue Oct 17 09:19:00 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643EE13303F; Tue, 17 Oct 2017 09:18:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 9B8LQMlJZ6-G; Tue, 17 Oct 2017 09:18:45 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0096.outbound.protection.outlook.com [23.103.200.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B514613303A; Tue, 17 Oct 2017 09:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=a6CWE8WdepRFBt5RUnfrCLipNFza/3XI2pyemx2RKUA=; b=ZuZWXbKIirXJjukkIRBS+Ba1oLuD5Gz38+4Mab2oF4Ns+WHY4gDzodNTsQod4CNq3/fD+AqDzc4pMLqEYWCGfttDunOmVNfOP0kpsu0e6fSgsos2ftwpdVSN24DLF855mh+/2INWE2Xp29RnphbUpusiGlwpWt6/ch+TV0cHLPM= Received: from DM5PR09MB1307.namprd09.prod.outlook.com (10.172.34.141) by DM5PR09MB1306.namprd09.prod.outlook.com (10.172.34.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 17 Oct 2017 16:18:44 +0000 Received: from DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) by DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) with mapi id 15.20.0077.022; Tue, 17 Oct 2017 16:18:44 +0000 From: "Banghart, Stephen A. (Fed)" To: Martin Thomson , "art@ietf.org" CC: "mile@ietf.org" , "ietf@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Thread-Topic: [mile] Artart last call review of draft-ietf-mile-rolie-10 Thread-Index: AQHTQLy5EiZhxIKVNkSNg/Bn547ThKLoNUig Date: Tue, 17 Oct 2017 16:18:43 +0000 Message-ID: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> In-Reply-To: <150752570618.18384.5615358468704377459@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.251.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR09MB1306; 6:dkd+O0N5w+qf3GTS+sYsq2EkaTpimjDipPCA8fig60zWodhqO0TyJdu34Q/v6509QBKS88zkVEWAK95keN8DbJ54nUCokOPhIPoUW6uqMasY+8DmjppotYj9fFP9x/f863EmwAsNjBP3PtTSCYMKGfdHiZP12VNl5tFfvOnSiOAcgdxxk0IOmxmtsRrR0O+cuK7rqwBem9cfenAZFJh2c8g2GQwlm4db+/rdP9eDf7gZ8sOASM9QI2h4Iq7OuiP1Z+8kYxK4OH9FKt8Kwr1tIaMxLY3k3W+kzpWXOxCp4El/ckuZyLWFKToE+/xpAwEWTgQBBTw66NTNNu6AAgEMEA==; 5:tDlekDwNF64zk24+NiNF2//HE+OWJZgV+30ZK4VVUyqEesoF5HN3nwmWGqXugkNIqT1sz+/8tsDh+nGPd52Wt72aTxHW4prAYrop91dD1HAhcB6Ea6Ip78xJca2cWmvGYXcL5ibDnsBYzERubdSJ3A==; 24:s3Z2iIqGwjo/w8mbyaAw/zagSIzG7GJZWEnbOM9Q9ghtBPLLDu8MwCQqRMEnKYsfOVh8Dc9GZIFLt12vh9nweiTALDjqFs2aeCfpvwlG5qY=; 7:Sh2kTrhVSsnetIrCTXB+2FbATGcsUzMX7v2IYqjZZ1ci5JAYEtakrDhVRoDDcxtZl5FZ/zjCoiyQIshHLMjDlkGHBLcKyNdnVNJr+RipxEc2kLG/URADvxLB/xsIAiupfhid/O5XYwn3/EsW8JZaCMo3unorU1PO1kNpkOGk5C/8OKDqVsAz9sk5yolVxCH3rUJYiciCf4giRguMtoNIw4u6uG8y6UehMtxlxJzIXIE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 757d0b2b-5c4f-40e7-aeb4-08d5157abcc8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR09MB1306; x-ms-traffictypediagnostic: DM5PR09MB1306: x-exchange-antispam-report-test: UriScan:(43050042349365)(158342451672863)(192374486261705)(189930954265078)(131327999870524)(150554046322364)(788757137089)(219752817060721); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR09MB1306; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR09MB1306; x-forefront-prvs: 04631F8F77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(199003)(55674003)(51444003)(189002)(3905003)(51914003)(13464003)(377454003)(43784003)(4326008)(316002)(25786009)(9686003)(7736002)(106356001)(74316002)(6246003)(105586002)(6306002)(99286003)(68736007)(55016002)(14454004)(76176999)(3846002)(6116002)(39060400002)(2906002)(305945005)(33656002)(53936002)(66066001)(102836003)(101416001)(54356999)(50986999)(97736004)(77096006)(81166006)(230783001)(229853002)(3660700001)(966005)(2900100001)(54906003)(110136005)(8936002)(189998001)(478600001)(2950100002)(2501003)(6506006)(6436002)(86362001)(8676002)(45080400002)(53546010)(7696004)(5660300001)(3280700002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1306; H:DM5PR09MB1307.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 16:18:43.8593 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1306 Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 16:18:48 -0000 Martin, Thanks for the great review. We've been working through your comments and p= reparing a -11 version. I'll have a full response to your comments out to t= he list once we've completed addressing them all, but wanted to open a disc= ussion on a few points in the meantime. The .well-known registration for /servicedocument has a use case/discovery = story that we feel is important enough for registration, or at least for st= andardization. In the case where there is no standardized location template= for the service document, a vendor/company/site that wants to stand up a R= OLIE repository and provide regular syndicated information must provide a l= ink to the service document somewhere on their regular site, or otherwise d= istribute the URL. While this potentially provides a means for humans to fi= nd the repository (although the link would likely be hidden in some strange= place), it doesn't help automated tools locate the repository. As a user of ROLIE, I'd like to be able to provide a tool with the hostname= :port of a vendor whose syndicated information I'd like to receive, and hav= e the tool return the status of any repository that is or in not hosted by = that top level site. For example, I'd like to give a tool "www.microsoft.co= m" and have it provide me all the ROLIE (and non-ROLIE AtomPub if provided = in the same ServDoc) Collections provided by that host. Without a .well-kno= wn registration, the standard would have to provide a defined non-/.well-kn= own URL template location, which we felt was bad practice. Its likely that the standard doesn't provide enough context around the /.we= ll-known registration, and that adding more explanatory text around our dis= covery story would help make the need for a URL template more clear. If the issue is with the use of /.well-known, and not with the standardized= URL template, we could simply remove the .well-known registration and inst= ead provide a non-registered requirement for a {host}/rolie/servicedocument= URL template. We agree that the discovery story for /categorydocument is decidedly weaker= , as any out-of-line category documents would be linked to from the Service= Document. We would open to dropping this registration/requirement outright= as you suggest. Thanks again for the thorough review, Stephen Banghart > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Monday, October 09, 2017 1:08 AM > To: art@ietf.org > Cc: mile@ietf.org; ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org > Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 >=20 > Reviewer: Martin Thomson > Review result: Almost Ready >=20 > I have reviewed this document, and - despite what appears to be a lengthy > list of issues - I think that it is in pretty good shape. It's clear, re= adable, and > addresses the requirements well. Most of my comments should be trivial t= o > resolve. >=20 > Major: >=20 > The decision to define a .well-known URI without a discovery story is - i= n my > opinion - inadvisable. Such a registration is usually appropriate if you= design a > protocol that depends on discovery by hostname and port. As such, this > does not use that at all. A configuration system can (and should) accept= a > complete URI for the service endpoint. It would be better to defer creat= ion > of yet another .well-known URI registration until the working group is ce= rtain > that discovery requires it. >=20 > The same comment applies to the .well-known resource for the category > document. > Given that this sort of document is readily discoverable via the service > document, I would say that the need for a .well-known resource is less we= ll- > justified than the service document. >=20 > The requirements in Section 5.3 on TLS use are unnecessarily strict. It'= s great > to recommend the use of TLS 1.2, but given that the document has no real > requirement on any particular version of TLS, the use of "MUST" here is n= ot > needed. Similarly, the prohibition on the use of 0-RTT is groundless. T= he > lengthy list of requirements around certificate validation only risk crea= ting a > conflict with advice in other RFCs. Many, if not all, of these requireme= nts are > transitively included by way of referencing HTTPS documents. I would pre= fer > to see this entire section reduced to a simple RFC 7525 reference. >=20 > User authentication is under-specified. >=20 > * Section 5.3 mandates the use of TLS cipher suites that support client > authentication using certificates, but offers no further advice. Aside f= rom > being an unnecessary requirement - cipher suites that support certificate= - > based authentication of servers all allow for client authentication - thi= s sort of > requirement is rarely sufficient for interoperation. For instance, you n= eed to > specify how a server will request a certificate such that clients can sel= ect the > correct certificate. If a client and server have agreed to share informa= tion on > terms that rely on authentication of clients, it is better for those peer= s to > arrange the terms on which they will authenticate. >=20 > * Section 5.4 uses "SHOULD" regarding client authentication using federat= ion, > but offers no hints about what this entails. It also uses "SHOULD" regar= ding > authorization checks, which isn't an interoperability requirement. It's = more > of a "don't be silly" type of requirement, which doesn't need to be writt= en > down in an RFC. >=20 > Section 5.5 prohibits the use of GET on "/". This prohibits use of the r= esource > for other purposes. It seems reasonable to accept POST messages as > defined in RFC 6546, but this requirement is overly strict (and further > entrenches the violation of RFC 7320). If, for instance, the server oper= ator > wishes to provide HTML in response to a GET request to "/", this would > prohibit that. The requirement to return 404 if RFC 6546 is not supporte= d is > worse; not supporting RFC 6546 might be a choice that a deployment makes > to avoid the need to reserve "/" for that protocol. >=20 > In Section 6.2.3, what is the advantage of "rolie:format" over having a w= ell- > defined media type? Media types can take advantage of content > negotiation, existing support in link relations, and other existing tools= . > This rolie:format element has namespace, format, and schema; these are no= t > useful to anyone that is ignorant of their contents. The only advantage = I see > is that syntax might be validated, but semantics can't be extracted. The= re's a > lot of implied work in adding this element, but that doesn't seem to be > justified by that advantage. (I see that RFC 7970 doesn't define a media= type, > but it seems like it would be easier to correct that than to define an el= ement > like this.) >=20 > Section 6.2.4 defines a generic key-value mechanism. But that is somethi= ng > that XML is actually good at. Why can't users that require additional > metadata use additional metadata as originally defined by Atom? That is, > replace value=3D"12345"/> with something like > 12345. The final paragraph = of the > section recognizes this possibility. >=20 > Minor: >=20 > Section 5.1.1 recommends the use of workspaces to separate "private" and > "public" information. But workspaces don't really contain enough > information to signal their status to a consumer of the information. I w= ould > suggest mentioning this, removing the recommendation, or expanding on > the manner in which the status of information is signaled. >=20 > Section 6.1.1 says "zero or more atom:category elements", but this > contradicts the text and amendment to the schema in Section 6.1. >=20 > Section 6.1.3 requires updating the "atom:updated" element when the > representation changes. I don't think that this is what was intended. I= think > that the element needs to be updated when the contents of the feed > change in any way. >=20 > Question: it's fairly widely accepted that use of IRIs in Atom has been l= ess > than successful. Do you want to mandate use of URIs instead? This would > apply to both link relations and the "src" attribute. >=20 > In Section 7.1, the definition of the namespace prefix > "urn:ietf:params:rolie:category:local" seems unnecessary. Namespace URIs > are cheap and it seems reasonable to experiment with feeds that produce > non-ROLIE information by omitting the > "urn:ietf:params:rolie:category:information-type" > category, even if that feed might comply with the requirements of ROLIE. > The other way to experiment would be to use the category, but define a wa= y > to identify "term" attributes that are for use in private or experimental > contexts. >=20 > In Section 7.4, how is "...:rolie:property:content-author-name" superior = to > "atom:author"? >=20 > In Section 8.4, is there a uniqueness requirement on "name"? I understa= nd > this to be the thing that being registered. Assuming that, what purpose > does > the "index" serve? >=20 > This statement from Section 9, "As described in the discovery section, DN= S > SRV Records are a possible secure solution to discovery." is false withou= t > further qualification. SRV with DNSSEC might be secure, but a lot depend= s on > the input to the discovery process and its provenance. >=20 > In Section 10, the following statement is false (all of the described pri= vacy > violations are available to a client or server, not third parties): "Prop= er usage > of TLS as described in Section 5.3 will in many cases aid in the mitigati= on of > these issues." I think that you can strike this statement (most of the r= eason > for use of TLS is justified by the security considerations anyway). >=20 > Nits: >=20 > Is it "Feed" or "feed"? RFC 4287 uses the latter, but this document seem= s to > prefer the Proper Noun form. >=20 > Section 6.2 should say what changed in the schema. It's hard to eyeball = the > schema to discover that "atomContent" is no longer optional. The two new > elements are easy to spot and might cause the first change to be missed. >=20 > Section 6.2.1 is the same. It should explicitly say that it only permits= the > atomOutOfLineContent formulation. >=20 > I found the formulation of Section 7.1.1 confusing. It includes a list t= hat > seems to be authoritative, then disclaims any attempt to register these > terms. > Maybe this is because the statement "This document does not specify any > information types." appears too late. Some reordering might help. >=20 > The formatting of the table in Section 8.3 makes most of the columns > unreadable. I would recommend a simple nested list. >=20 > In section 9, the use of the term "well-known" to refer to information th= at is > either public or widely available risks misinterpretation. >=20 > FWIW, I would reword this entire paragraph to say simply "Access control = to > information published using ROLIE should use mechanisms that are > appropriate to the sensitivity of the information. Primitive authenticat= ion > mechanisms like HTTP Basic Authentication [RFC7617] are rarely appropriat= e > for sensitive information." I didn't find the remainder of the text on > authentication especially helpful. The text seems to equivocate on the > subject of federation, where it would be easier to say nothing. >=20 > Also in Section 9, the use of the term "message" is used in the context o= f > using additional security controls. I think that the word "representatio= n" is > what was intended here. >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fmile&data=3D02%7C01%7Cstephen.banghar > t%40nist.gov%7Caf3af91a1c684592007d08d50ed3d401%7C2ab5d82fd8fa4797 > a93e054655c61dec%7C1%7C0%7C636431225322845891&sdata=3DSykEasQlo1e > MarYmKXSA5HsOUpTLyjd9rslyvZPpxak%3D&reserved=3D0 From nobody Tue Oct 17 09:19:12 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8E13413303A; Tue, 17 Oct 2017 09:18:48 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643EE13303F; Tue, 17 Oct 2017 09:18:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 9B8LQMlJZ6-G; Tue, 17 Oct 2017 09:18:45 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0096.outbound.protection.outlook.com [23.103.200.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B514613303A; Tue, 17 Oct 2017 09:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=a6CWE8WdepRFBt5RUnfrCLipNFza/3XI2pyemx2RKUA=; b=ZuZWXbKIirXJjukkIRBS+Ba1oLuD5Gz38+4Mab2oF4Ns+WHY4gDzodNTsQod4CNq3/fD+AqDzc4pMLqEYWCGfttDunOmVNfOP0kpsu0e6fSgsos2ftwpdVSN24DLF855mh+/2INWE2Xp29RnphbUpusiGlwpWt6/ch+TV0cHLPM= Received: from DM5PR09MB1307.namprd09.prod.outlook.com (10.172.34.141) by DM5PR09MB1306.namprd09.prod.outlook.com (10.172.34.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 17 Oct 2017 16:18:44 +0000 Received: from DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) by DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) with mapi id 15.20.0077.022; Tue, 17 Oct 2017 16:18:44 +0000 From: "Banghart, Stephen A. (Fed)" To: Martin Thomson , "art@ietf.org" CC: "mile@ietf.org" , "ietf@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Thread-Topic: [mile] Artart last call review of draft-ietf-mile-rolie-10 Thread-Index: AQHTQLy5EiZhxIKVNkSNg/Bn547ThKLoNUig Date: Tue, 17 Oct 2017 16:18:43 +0000 Message-ID: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> In-Reply-To: <150752570618.18384.5615358468704377459@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.251.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR09MB1306; 6:dkd+O0N5w+qf3GTS+sYsq2EkaTpimjDipPCA8fig60zWodhqO0TyJdu34Q/v6509QBKS88zkVEWAK95keN8DbJ54nUCokOPhIPoUW6uqMasY+8DmjppotYj9fFP9x/f863EmwAsNjBP3PtTSCYMKGfdHiZP12VNl5tFfvOnSiOAcgdxxk0IOmxmtsRrR0O+cuK7rqwBem9cfenAZFJh2c8g2GQwlm4db+/rdP9eDf7gZ8sOASM9QI2h4Iq7OuiP1Z+8kYxK4OH9FKt8Kwr1tIaMxLY3k3W+kzpWXOxCp4El/ckuZyLWFKToE+/xpAwEWTgQBBTw66NTNNu6AAgEMEA==; 5:tDlekDwNF64zk24+NiNF2//HE+OWJZgV+30ZK4VVUyqEesoF5HN3nwmWGqXugkNIqT1sz+/8tsDh+nGPd52Wt72aTxHW4prAYrop91dD1HAhcB6Ea6Ip78xJca2cWmvGYXcL5ibDnsBYzERubdSJ3A==; 24:s3Z2iIqGwjo/w8mbyaAw/zagSIzG7GJZWEnbOM9Q9ghtBPLLDu8MwCQqRMEnKYsfOVh8Dc9GZIFLt12vh9nweiTALDjqFs2aeCfpvwlG5qY=; 7:Sh2kTrhVSsnetIrCTXB+2FbATGcsUzMX7v2IYqjZZ1ci5JAYEtakrDhVRoDDcxtZl5FZ/zjCoiyQIshHLMjDlkGHBLcKyNdnVNJr+RipxEc2kLG/URADvxLB/xsIAiupfhid/O5XYwn3/EsW8JZaCMo3unorU1PO1kNpkOGk5C/8OKDqVsAz9sk5yolVxCH3rUJYiciCf4giRguMtoNIw4u6uG8y6UehMtxlxJzIXIE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 757d0b2b-5c4f-40e7-aeb4-08d5157abcc8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR09MB1306; x-ms-traffictypediagnostic: DM5PR09MB1306: x-exchange-antispam-report-test: UriScan:(43050042349365)(158342451672863)(192374486261705)(189930954265078)(131327999870524)(150554046322364)(788757137089)(219752817060721); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR09MB1306; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR09MB1306; x-forefront-prvs: 04631F8F77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(199003)(55674003)(51444003)(189002)(3905003)(51914003)(13464003)(377454003)(43784003)(4326008)(316002)(25786009)(9686003)(7736002)(106356001)(74316002)(6246003)(105586002)(6306002)(99286003)(68736007)(55016002)(14454004)(76176999)(3846002)(6116002)(39060400002)(2906002)(305945005)(33656002)(53936002)(66066001)(102836003)(101416001)(54356999)(50986999)(97736004)(77096006)(81166006)(230783001)(229853002)(3660700001)(966005)(2900100001)(54906003)(110136005)(8936002)(189998001)(478600001)(2950100002)(2501003)(6506006)(6436002)(86362001)(8676002)(45080400002)(53546010)(7696004)(5660300001)(3280700002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1306; H:DM5PR09MB1307.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 16:18:43.8593 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1306 Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171017161848.8E13413303A@ietfa.amsl.com> Resent-Date: Tue, 17 Oct 2017 09:18:48 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 16:18:48 -0000 Martin, Thanks for the great review. We've been working through your comments and p= reparing a -11 version. I'll have a full response to your comments out to t= he list once we've completed addressing them all, but wanted to open a disc= ussion on a few points in the meantime. The .well-known registration for /servicedocument has a use case/discovery = story that we feel is important enough for registration, or at least for st= andardization. In the case where there is no standardized location template= for the service document, a vendor/company/site that wants to stand up a R= OLIE repository and provide regular syndicated information must provide a l= ink to the service document somewhere on their regular site, or otherwise d= istribute the URL. While this potentially provides a means for humans to fi= nd the repository (although the link would likely be hidden in some strange= place), it doesn't help automated tools locate the repository. As a user of ROLIE, I'd like to be able to provide a tool with the hostname= :port of a vendor whose syndicated information I'd like to receive, and hav= e the tool return the status of any repository that is or in not hosted by = that top level site. For example, I'd like to give a tool "www.microsoft.co= m" and have it provide me all the ROLIE (and non-ROLIE AtomPub if provided = in the same ServDoc) Collections provided by that host. Without a .well-kno= wn registration, the standard would have to provide a defined non-/.well-kn= own URL template location, which we felt was bad practice. Its likely that the standard doesn't provide enough context around the /.we= ll-known registration, and that adding more explanatory text around our dis= covery story would help make the need for a URL template more clear. If the issue is with the use of /.well-known, and not with the standardized= URL template, we could simply remove the .well-known registration and inst= ead provide a non-registered requirement for a {host}/rolie/servicedocument= URL template. We agree that the discovery story for /categorydocument is decidedly weaker= , as any out-of-line category documents would be linked to from the Service= Document. We would open to dropping this registration/requirement outright= as you suggest. Thanks again for the thorough review, Stephen Banghart > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Monday, October 09, 2017 1:08 AM > To: art@ietf.org > Cc: mile@ietf.org; ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org > Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 >=20 > Reviewer: Martin Thomson > Review result: Almost Ready >=20 > I have reviewed this document, and - despite what appears to be a lengthy > list of issues - I think that it is in pretty good shape. It's clear, re= adable, and > addresses the requirements well. Most of my comments should be trivial t= o > resolve. >=20 > Major: >=20 > The decision to define a .well-known URI without a discovery story is - i= n my > opinion - inadvisable. Such a registration is usually appropriate if you= design a > protocol that depends on discovery by hostname and port. As such, this > does not use that at all. A configuration system can (and should) accept= a > complete URI for the service endpoint. It would be better to defer creat= ion > of yet another .well-known URI registration until the working group is ce= rtain > that discovery requires it. >=20 > The same comment applies to the .well-known resource for the category > document. > Given that this sort of document is readily discoverable via the service > document, I would say that the need for a .well-known resource is less we= ll- > justified than the service document. >=20 > The requirements in Section 5.3 on TLS use are unnecessarily strict. It'= s great > to recommend the use of TLS 1.2, but given that the document has no real > requirement on any particular version of TLS, the use of "MUST" here is n= ot > needed. Similarly, the prohibition on the use of 0-RTT is groundless. T= he > lengthy list of requirements around certificate validation only risk crea= ting a > conflict with advice in other RFCs. Many, if not all, of these requireme= nts are > transitively included by way of referencing HTTPS documents. I would pre= fer > to see this entire section reduced to a simple RFC 7525 reference. >=20 > User authentication is under-specified. >=20 > * Section 5.3 mandates the use of TLS cipher suites that support client > authentication using certificates, but offers no further advice. Aside f= rom > being an unnecessary requirement - cipher suites that support certificate= - > based authentication of servers all allow for client authentication - thi= s sort of > requirement is rarely sufficient for interoperation. For instance, you n= eed to > specify how a server will request a certificate such that clients can sel= ect the > correct certificate. If a client and server have agreed to share informa= tion on > terms that rely on authentication of clients, it is better for those peer= s to > arrange the terms on which they will authenticate. >=20 > * Section 5.4 uses "SHOULD" regarding client authentication using federat= ion, > but offers no hints about what this entails. It also uses "SHOULD" regar= ding > authorization checks, which isn't an interoperability requirement. It's = more > of a "don't be silly" type of requirement, which doesn't need to be writt= en > down in an RFC. >=20 > Section 5.5 prohibits the use of GET on "/". This prohibits use of the r= esource > for other purposes. It seems reasonable to accept POST messages as > defined in RFC 6546, but this requirement is overly strict (and further > entrenches the violation of RFC 7320). If, for instance, the server oper= ator > wishes to provide HTML in response to a GET request to "/", this would > prohibit that. The requirement to return 404 if RFC 6546 is not supporte= d is > worse; not supporting RFC 6546 might be a choice that a deployment makes > to avoid the need to reserve "/" for that protocol. >=20 > In Section 6.2.3, what is the advantage of "rolie:format" over having a w= ell- > defined media type? Media types can take advantage of content > negotiation, existing support in link relations, and other existing tools= From nobody Tue Oct 17 22:03:34 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E77133074; Tue, 17 Oct 2017 22:03:31 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 VQGtBBMUj0lh; Tue, 17 Oct 2017 22:03:29 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 CF75D133044; Tue, 17 Oct 2017 22:03:28 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id n82so6956456oig.3; Tue, 17 Oct 2017 22:03:28 -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:content-transfer-encoding; bh=AD3+97SbTTSVc/XNXbplIoKTQyLB/ly+0q05Ih5IoGg=; b=IUbo7iam+mRyMqlmDZljuyILI/IBTPTidADwRxh7BA+jxQeYgSmK05WmgD3DuT1882 36ZF81XcDNAJBQgB2tSTrNo4KfHAwkPePu6OxAMfDGzosYSTOwpzgvHy3oV9N+ZiMyj4 y3+dAmpYcPddU0HA4mslNbtxGZtOdvz8fPqlOesX35pzSicPG3RJZlcCjblebXowbm2a 34H0yVq1dDLGJW3XOPpvMnZ+dPS0dcLeVvEg1AqSZG2/WWmO1l1vtuLMo8MHAD6Y6faL ds1HiXvyiZyIiFmugseRYdyIXcSB8aPoQI+zkdHsfu/h0C2NdDaZwJDMxdrw2c3VTlQk vSsg== 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:content-transfer-encoding; bh=AD3+97SbTTSVc/XNXbplIoKTQyLB/ly+0q05Ih5IoGg=; b=hBuTUA6VTJeIza1OjWo5dyVH+IAr543UVzzSqD8V/drrRt2SdggwopUzrge4sPQeei iu/dnNuL2DDuL8kXTRHv0yrwJm8LCAeOpGTmPZPOqw9Z2ofrI0SVKcc2qzSyVn+aAkyW rE6Hr89+WFlEfFoxc3CSmJ6ytFX+YYTAOc/nNRfhuRLTI75o3Y5hmto95nIkaMi8RZC8 r5KEo/XXZ/7SvlyjZkZS/lubUxlVGe2vVt71xypvmEMgnUhxKHGiKyl7eMDkqL0WKLMa gWPqTHo7rJvybZXMBYz2UALLnbSY8Bm15FzfmrsUu2QSBkEUie9gA9m0sM9pte7p1oFE qBiw== X-Gm-Message-State: AMCzsaVMDawM7u5Z0h+Ns0/Y4DOFRlxVTpiHe9CodZMU3RUOyWx8soC0 zubh5UQCGwre1r8gAm1av8DAZisdLioh0E9QIgQ= X-Google-Smtp-Source: ABhQp+SPo05ruzixfwla0ivjJlgHQAPfye9Q9T2gjgtkf45ZsB1nkZIFnAPgaxm/141U3jY15+O9Sd+cIoEdB+/Q4No= X-Received: by 10.157.51.146 with SMTP id u18mr3261825otc.98.1508303007689; Tue, 17 Oct 2017 22:03:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Tue, 17 Oct 2017 22:03:27 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> From: Martin Thomson Date: Wed, 18 Oct 2017 16:03:27 +1100 Message-ID: To: "Banghart, Stephen A. (Fed)" Cc: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 05:03:32 -0000 (-ietf@ and art@ to save those inboxes) Hi Stephen, Thanks for the explanation. I somewhat expected that this would be the use case, but I couldn't reconcile that with the long list of requirements for client authentication. Can you go into some more detail about that as well? Happy to hash that out here (I'm not subscribed to mile@ though). If the intent is to have the information for a web site (as opposed to the organization) accessible in a location that can be readily found, then I think that you have justification for using .well-known for the service document. The category document can be linked from the service document, so I think it would be best if you did remove that .well-known registration. You might also consider using simply .well-known/rolie once you have just one resource. On Wed, Oct 18, 2017 at 3:18 AM, Banghart, Stephen A. (Fed) wrote: > Martin, > > Thanks for the great review. We've been working through your comments and= preparing a -11 version. I'll have a full response to your comments out to= the list once we've completed addressing them all, but wanted to open a di= scussion on a few points in the meantime. > > The .well-known registration for /servicedocument has a use case/discover= y story that we feel is important enough for registration, or at least for = standardization. In the case where there is no standardized location templa= te for the service document, a vendor/company/site that wants to stand up a= ROLIE repository and provide regular syndicated information must provide a= link to the service document somewhere on their regular site, or otherwise= distribute the URL. While this potentially provides a means for humans to = find the repository (although the link would likely be hidden in some stran= ge place), it doesn't help automated tools locate the repository. > > As a user of ROLIE, I'd like to be able to provide a tool with the hostna= me:port of a vendor whose syndicated information I'd like to receive, and h= ave the tool return the status of any repository that is or in not hosted b= y that top level site. For example, I'd like to give a tool "www.microsoft.= com" and have it provide me all the ROLIE (and non-ROLIE AtomPub if provide= d in the same ServDoc) Collections provided by that host. Without a .well-k= nown registration, the standard would have to provide a defined non-/.well-= known URL template location, which we felt was bad practice. > > Its likely that the standard doesn't provide enough context around the /.= well-known registration, and that adding more explanatory text around our d= iscovery story would help make the need for a URL template more clear. > > If the issue is with the use of /.well-known, and not with the standardiz= ed URL template, we could simply remove the .well-known registration and in= stead provide a non-registered requirement for a {host}/rolie/servicedocume= nt URL template. > > We agree that the discovery story for /categorydocument is decidedly weak= er, as any out-of-line category documents would be linked to from the Servi= ce Document. We would open to dropping this registration/requirement outrig= ht as you suggest. > > Thanks again for the thorough review, > Stephen Banghart > >> -----Original Message----- >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin Thomson >> Sent: Monday, October 09, 2017 1:08 AM >> To: art@ietf.org >> Cc: mile@ietf.org; ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org >> Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 >> >> Reviewer: Martin Thomson >> Review result: Almost Ready >> >> I have reviewed this document, and - despite what appears to be a length= y >> list of issues - I think that it is in pretty good shape. It's clear, r= eadable, and >> addresses the requirements well. Most of my comments should be trivial = to >> resolve. >> >> Major: >> >> The decision to define a .well-known URI without a discovery story is - = in my >> opinion - inadvisable. Such a registration is usually appropriate if yo= u design a >> protocol that depends on discovery by hostname and port. As such, this >> does not use that at all. A configuration system can (and should) accep= t a >> complete URI for the service endpoint. It would be better to defer crea= tion >> of yet another .well-known URI registration until the working group is c= ertain >> that discovery requires it. >> >> The same comment applies to the .well-known resource for the category >> document. >> Given that this sort of document is readily discoverable via the servic= e >> document, I would say that the need for a .well-known resource is less w= ell- >> justified than the service document. >> >> The requirements in Section 5.3 on TLS use are unnecessarily strict. It= 's great >> to recommend the use of TLS 1.2, but given that the document has no real >> requirement on any particular version of TLS, the use of "MUST" here is = not >> needed. Similarly, the prohibition on the use of 0-RTT is groundless. = The >> lengthy list of requirements around certificate validation only risk cre= ating a >> conflict with advice in other RFCs. Many, if not all, of these requirem= ents are >> transitively included by way of referencing HTTPS documents. I would pr= efer >> to see this entire section reduced to a simple RFC 7525 reference. >> >> User authentication is under-specified. >> >> * Section 5.3 mandates the use of TLS cipher suites that support client >> authentication using certificates, but offers no further advice. Aside = from >> being an unnecessary requirement - cipher suites that support certificat= e- >> based authentication of servers all allow for client authentication - th= is sort of >> requirement is rarely sufficient for interoperation. For instance, you = need to >> specify how a server will request a certificate such that clients can se= lect the >> correct certificate. If a client and server have agreed to share inform= ation on >> terms that rely on authentication of clients, it is better for those pee= rs to >> arrange the terms on which they will authenticate. >> >> * Section 5.4 uses "SHOULD" regarding client authentication using federa= tion, >> but offers no hints about what this entails. It also uses "SHOULD" rega= rding >> authorization checks, which isn't an interoperability requirement. It's= more >> of a "don't be silly" type of requirement, which doesn't need to be writ= ten >> down in an RFC. >> >> Section 5.5 prohibits the use of GET on "/". This prohibits use of the = resource >> for other purposes. It seems reasonable to accept POST messages as >> defined in RFC 6546, but this requirement is overly strict (and further >> entrenches the violation of RFC 7320). If, for instance, the server ope= rator >> wishes to provide HTML in response to a GET request to "/", this would >> prohibit that. The requirement to return 404 if RFC 6546 is not support= ed is >> worse; not supporting RFC 6546 might be a choice that a deployment makes >> to avoid the need to reserve "/" for that protocol. >> >> In Section 6.2.3, what is the advantage of "rolie:format" over having a = well- >> defined media type? Media types can take advantage of content >> negotiation, existing support in link relations, and other existing tool= s. >> This rolie:format element has namespace, format, and schema; these are n= ot >> useful to anyone that is ignorant of their contents. The only advantage= I see >> is that syntax might be validated, but semantics can't be extracted. Th= ere's a >> lot of implied work in adding this element, but that doesn't seem to be >> justified by that advantage. (I see that RFC 7970 doesn't define a medi= a type, >> but it seems like it would be easier to correct that than to define an e= lement >> like this.) >> >> Section 6.2.4 defines a generic key-value mechanism. But that is someth= ing >> that XML is actually good at. Why can't users that require additional >> metadata use additional metadata as originally defined by Atom? That is= , >> replace > value=3D"12345"/> with something like >> 12345. The final paragraph= of the >> section recognizes this possibility. >> >> Minor: >> >> Section 5.1.1 recommends the use of workspaces to separate "private" and >> "public" information. But workspaces don't really contain enough >> information to signal their status to a consumer of the information. I = would >> suggest mentioning this, removing the recommendation, or expanding on >> the manner in which the status of information is signaled. >> >> Section 6.1.1 says "zero or more atom:category elements", but this >> contradicts the text and amendment to the schema in Section 6.1. >> >> Section 6.1.3 requires updating the "atom:updated" element when the >> representation changes. I don't think that this is what was intended. = I think >> that the element needs to be updated when the contents of the feed >> change in any way. >> >> Question: it's fairly widely accepted that use of IRIs in Atom has been = less >> than successful. Do you want to mandate use of URIs instead? This woul= d >> apply to both link relations and the "src" attribute. >> >> In Section 7.1, the definition of the namespace prefix >> "urn:ietf:params:rolie:category:local" seems unnecessary. Namespace URI= s >> are cheap and it seems reasonable to experiment with feeds that produce >> non-ROLIE information by omitting the >> "urn:ietf:params:rolie:category:information-type" >> category, even if that feed might comply with the requirements of ROLIE. >> The other way to experiment would be to use the category, but define a w= ay >> to identify "term" attributes that are for use in private or experimenta= l >> contexts. >> >> In Section 7.4, how is "...:rolie:property:content-author-name" superior= to >> "atom:author"? >> >> In Section 8.4, is there a uniqueness requirement on "name"? I underst= and >> this to be the thing that being registered. Assuming that, what purpos= e >> does >> the "index" serve? >> >> This statement from Section 9, "As described in the discovery section, D= NS >> SRV Records are a possible secure solution to discovery." is false witho= ut >> further qualification. SRV with DNSSEC might be secure, but a lot depen= ds on >> the input to the discovery process and its provenance. >> >> In Section 10, the following statement is false (all of the described pr= ivacy >> violations are available to a client or server, not third parties): "Pro= per usage >> of TLS as described in Section 5.3 will in many cases aid in the mitigat= ion of >> these issues." I think that you can strike this statement (most of the = reason >> for use of TLS is justified by the security considerations anyway). >> >> Nits: >> >> Is it "Feed" or "feed"? RFC 4287 uses the latter, but this document see= ms to >> prefer the Proper Noun form. >> >> Section 6.2 should say what changed in the schema. It's hard to eyeball= the >> schema to discover that "atomContent" is no longer optional. The two ne= w >> elements are easy to spot and might cause the first change to be missed. >> >> Section 6.2.1 is the same. It should explicitly say that it only permit= s the >> atomOutOfLineContent formulation. >> >> I found the formulation of Section 7.1.1 confusing. It includes a list = that >> seems to be authoritative, then disclaims any attempt to register these >> terms. >> Maybe this is because the statement "This document does not specify any >> information types." appears too late. Some reordering might help. >> >> The formatting of the table in Section 8.3 makes most of the columns >> unreadable. I would recommend a simple nested list. >> >> In section 9, the use of the term "well-known" to refer to information t= hat is >> either public or widely available risks misinterpretation. >> >> FWIW, I would reword this entire paragraph to say simply "Access control= to >> information published using ROLIE should use mechanisms that are >> appropriate to the sensitivity of the information. Primitive authentica= tion >> mechanisms like HTTP Basic Authentication [RFC7617] are rarely appropria= te >> for sensitive information." I didn't find the remainder of the text on >> authentication especially helpful. The text seems to equivocate on the >> subject of federation, where it would be easier to say nothing. >> >> Also in Section 9, the use of the term "message" is used in the context = of >> using additional security controls. I think that the word "representati= on" is >> what was intended here. >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i >> etf.org%2Fmailman%2Flistinfo%2Fmile&data=3D02%7C01%7Cstephen.banghar >> t%40nist.gov%7Caf3af91a1c684592007d08d50ed3d401%7C2ab5d82fd8fa4797 >> a93e054655c61dec%7C1%7C0%7C636431225322845891&sdata=3DSykEasQlo1e >> MarYmKXSA5HsOUpTLyjd9rslyvZPpxak%3D&reserved=3D0 From nobody Tue Oct 17 22:03:40 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0303D133044; Tue, 17 Oct 2017 22:03:31 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E77133074; Tue, 17 Oct 2017 22:03:31 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 VQGtBBMUj0lh; Tue, 17 Oct 2017 22:03:29 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 CF75D133044; Tue, 17 Oct 2017 22:03:28 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id n82so6956456oig.3; Tue, 17 Oct 2017 22:03:28 -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:content-transfer-encoding; bh=AD3+97SbTTSVc/XNXbplIoKTQyLB/ly+0q05Ih5IoGg=; b=IUbo7iam+mRyMqlmDZljuyILI/IBTPTidADwRxh7BA+jxQeYgSmK05WmgD3DuT1882 36ZF81XcDNAJBQgB2tSTrNo4KfHAwkPePu6OxAMfDGzosYSTOwpzgvHy3oV9N+ZiMyj4 y3+dAmpYcPddU0HA4mslNbtxGZtOdvz8fPqlOesX35pzSicPG3RJZlcCjblebXowbm2a 34H0yVq1dDLGJW3XOPpvMnZ+dPS0dcLeVvEg1AqSZG2/WWmO1l1vtuLMo8MHAD6Y6faL ds1HiXvyiZyIiFmugseRYdyIXcSB8aPoQI+zkdHsfu/h0C2NdDaZwJDMxdrw2c3VTlQk vSsg== 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:content-transfer-encoding; bh=AD3+97SbTTSVc/XNXbplIoKTQyLB/ly+0q05Ih5IoGg=; b=hBuTUA6VTJeIza1OjWo5dyVH+IAr543UVzzSqD8V/drrRt2SdggwopUzrge4sPQeei iu/dnNuL2DDuL8kXTRHv0yrwJm8LCAeOpGTmPZPOqw9Z2ofrI0SVKcc2qzSyVn+aAkyW rE6Hr89+WFlEfFoxc3CSmJ6ytFX+YYTAOc/nNRfhuRLTI75o3Y5hmto95nIkaMi8RZC8 r5KEo/XXZ/7SvlyjZkZS/lubUxlVGe2vVt71xypvmEMgnUhxKHGiKyl7eMDkqL0WKLMa gWPqTHo7rJvybZXMBYz2UALLnbSY8Bm15FzfmrsUu2QSBkEUie9gA9m0sM9pte7p1oFE qBiw== X-Gm-Message-State: AMCzsaVMDawM7u5Z0h+Ns0/Y4DOFRlxVTpiHe9CodZMU3RUOyWx8soC0 zubh5UQCGwre1r8gAm1av8DAZisdLioh0E9QIgQ= X-Google-Smtp-Source: ABhQp+SPo05ruzixfwla0ivjJlgHQAPfye9Q9T2gjgtkf45ZsB1nkZIFnAPgaxm/141U3jY15+O9Sd+cIoEdB+/Q4No= X-Received: by 10.157.51.146 with SMTP id u18mr3261825otc.98.1508303007689; Tue, 17 Oct 2017 22:03:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Tue, 17 Oct 2017 22:03:27 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> From: Martin Thomson Date: Wed, 18 Oct 2017 16:03:27 +1100 Message-ID: To: "Banghart, Stephen A. (Fed)" Cc: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171018050332.0303D133044@ietfa.amsl.com> Resent-Date: Tue, 17 Oct 2017 22:03:31 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 05:03:32 -0000 (-ietf@ and art@ to save those inboxes) Hi Stephen, Thanks for the explanation. I somewhat expected that this would be the use case, but I couldn't reconcile that with the long list of requirements for client authentication. Can you go into some more detail about that as well? Happy to hash that out here (I'm not subscribed to mile@ though). If the intent is to have the information for a web site (as opposed to the organization) accessible in a location that can be readily found, then I think that you have justification for using .well-known for the service document. The category document can be linked from the service document, so I think it would be best if you did remove that .well-known registration. You might also consider using simply .well-known/rolie once you have just one resource. On Wed, Oct 18, 2017 at 3:18 AM, Banghart, Stephen A. (Fed) wrote: > Martin, > > Thanks for the great review. We've been working through your comments and= preparing a -11 version. I'll have a full response to your comments out to= the list once we've completed addressing them all, but wanted to open a di= scussion on a few points in the meantime. > > The .well-known registration for /servicedocument has a use case/discover= y story that we feel is important enough for registration, or at least for = standardization. In the case where there is no standardized location templa= te for the service document, a vendor/company/site that wants to stand up a= ROLIE repository and provide regular syndicated information must provide a= link to the service document somewhere on their regular site, or otherwise= distribute the URL. While this potentially provides a means for humans to = find the repository (although the link would likely be hidden in some stran= ge place), it doesn't help automated tools locate the repository. > > As a user of ROLIE, I'd like to be able to provide a tool with the hostna= me:port of a vendor whose syndicated information I'd like to receive, and h= ave the tool return the status of any repository that is or in not hosted b= y that top level site. For example, I'd like to give a tool "www.microsoft.= com" and have it provide me all the ROLIE (and non-ROLIE AtomPub if provide= d in the same ServDoc) Collections provided by that host. Without a .well-k= nown registration, the standard would have to provide a defined non-/.well-= known URL template location, which we felt was bad practice. > > Its likely that the standard doesn't provide enough context around the /.= well-known registration, and that adding more explanatory text around our d= iscovery story would help make the need for a URL template more clear. > > If the issue is with the use of /.well-known, and not with the standardiz= ed URL template, we could simply remove the .well-known registration and in= stead provide a non-registered requirement for a {host}/rolie/servicedocume= nt URL template. > > We agree that the discovery story for /categorydocument is decidedly weak= er, as any out-of-line category documents would be linked to from the Servi= ce Document. We would open to dropping this registration/requirement outrig= ht as you suggest. > > Thanks again for the thorough review, > Stephen Banghart > >> -----Original Message----- >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin Thomson >> Sent: Monday, October 09, 2017 1:08 AM >> To: art@ietf.org >> Cc: mile@ietf.org; ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org >> Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 >> >> Reviewer: Martin Thomson >> Review result: Almost Ready >> >> I have reviewed this document, and - despite what appears to be a length= y >> list of issues - I think that it is in pretty good shape. It's clear, r= eadable, and >> addresses the requirements well. Most of my comments should be trivial = to >> resolve. >> >> Major: >> >> The decision to define a .well-known URI without a discovery story is - = in my >> opinion - inadvisable. Such a registration is usually appropriate if yo= u design a >> protocol that depends on discovery by hostname and port. As such, this >> does not use that at all. A configuration system can (and should) accep= t a >> complete URI for the service endpoint. It would be better to defer crea= tion >> of yet another .well-known URI registration until the working group is c= ertain >> that discovery requires it. >> >> The same comment applies to the .well-known resource for the category >> document. >> Given that this sort of document is readily discoverable via the servic= e >> document, I would say that the need for a .well-known resource is less w= ell- >> justified than the service document. >> >> The requirements in Section 5.3 on TLS use are unnecessarily strict. It= 's great >> to recommend the use of TLS 1.2, but given that the document has no real >> requirement on any particular version of TLS, the use of "MUST" here is = not >> needed. Similarly, the prohibition on the use of 0-RTT is groundless. = The >> lengthy list of requirements around certificate validation only risk cre= ating a >> conflict with advice in other RFCs. Many, if not all, of these requirem= ents are >> transitively included by way of referencing HTTPS documents. I would pr= efer >> to see this entire section reduced to a simple RFC 7525 reference. >> >> User authentication is under-specified. >> >> * Section 5.3 mandates the use of TLS cipher suites that support client >> authentication using certificates, but offers no further advice. Aside = from >> being an unnecessary requirement - cipher suites that support certificat= e- >> based authentication of servers all allow for client authentication - th= is sort of >> requirement is rarely sufficient for interoperation. For instance, you = need to >> specify how a server will request a certificate such that clients can se= lect the >> correct certificate. If a client and server have agreed to share inform= ation on >> terms that rely on authentication of clients, it is better for those pee= rs to >> arrange the terms on which they will authenticate. >> >> * Section 5.4 uses "SHOULD" regarding client authentication using federa= tion, >> but offers no hints about what this entails. It also uses "SHOULD" rega= rding >> authorization checks, which isn't an interoperability requirement. It's= more >> of a "don't be silly" type of requirement, which doesn't need to be writ= ten >> down in an RFC. >> >> Section 5.5 prohibits the use of GET on "/". This prohibits use of the = resource >> for other purposes. It seems reasonable to accept POST messages as >> defined in RFC 6546, but this requirement is overly strict (and further >> entrenches the violation of RFC 7320). If, for instance, the server ope= rator >> wishes to provide HTML in response to a GET request to "/", this would >> prohibit that. The requirement to return 404 if RFC 6546 is not support= ed is >> worse; not supporting RFC 6546 might be a choice that a deployment makes >> to avoid the need to reserve "/" for that protocol. >> >> In Section 6.2.3, what is the advantage of "rolie:format" over having a = well- >> defined media type? Media types can take advantage of content >> negotiation, existing support in link relations, and other existing tool= s. >> This rolie:format element has namespace, format, and schema; these are n= ot >> useful to anyone that is ignorant of their contents. The only advantage= I see >> is that syntax might be validated, but semantics can't be extracted. Th= ere's a >> lot of implied work in adding this element, but that doesn't seem to be >> justified by that advantage. (I see that RFC 7970 doesn't define a medi= a type, >> but it seems like it would be easier to correct that than to define an e= lement >> like this.) >> >> Section 6.2.4 defines a generic key-value mechanism. But that is someth= ing >> that XML is actually good at. Why can't users that require additional >> metadata use additional metadata as originally defined by Atom? That is= , >> replace > value=3D"12345"/> with something like >> 12345. The final paragraph= of the >> section recognizes this possibility. >> >> Minor: >> >> Section 5.1.1 recommends the use of workspaces to separate "private" and >> "public" information. But workspaces don't really contain enough >> information to signal their status to a consumer of the information. I = would >> suggest mentioning this, removing the recommendation, or expanding on >> the manner in which the status of information is signaled. >> >> Section 6.1.1 says "zero or more atom:category elements", but this >> contradicts the text and amendment to the schema in Section 6.1. >> >> Section 6.1.3 requires updating the "atom:updated" element when the >> representation changes. I don't think that this is what was intended. = I think >> that the element needs to be updated when the contents of the feed >> change in any way. >> >> Question: it's fairly widely accepted that use of IRIs in Atom has been = less >> than successful. Do you want to mandate use of URIs instead? This woul= d >> apply to both link relations and the "src" attribute. >> >> In Section 7.1, the definition of the namespace prefix >> "urn:ietf:params:rolie:category:local" seems unnecessary. Namespace URI= s >> are cheap and it seems reasonable to experiment with feeds that produce >> non-ROLIE information by omitting the >> "urn:ietf:params:rolie:category:information-type" >> category, even if that feed might comply with the requirements of ROLIE. >> The other way to experiment would be to use the category, but define a w= ay >> to identify "term" attributes that are for use in private or experimenta= l >> contexts. >> >> In Section 7.4, how is "...:rolie:property:content-author-name" superior= to >> "atom:author"? >> >> In Section 8.4, is there a uniqueness requirement on "name"? I underst= and >> this to be the thing that being registered. Assuming that, what purpos= e >> does >> the "index" serve? >> >> This statement from Section 9, "As described in the discovery section, D= NS >> SRV Records are a possible secure solution to discovery." is false witho= ut >> further qualification. SRV with DNSSEC might be secure, but a lot depen= ds on >> the input to the discovery process and its provenance. >> >> In Section 10, the following statement is false (all of the described pr= ivacy >> violations are available to a client or server, not third parties): "Pro= per usage >> of TLS as described in Section 5.3 will in many cases aid in the mitigat= ion of >> these issues." I think that you can strike this statement (most of the = reason >> for use of TLS is justified by the security considerations anyway). >> >> Nits: >> >> Is it "Feed" or "feed"? RFC 4287 uses the latter, but this document see= ms to >> prefer the Proper Noun form. >> >> Section 6.2 should say what changed in the schema. It's hard to eyeball= the >> schema to discover that "atomContent" is no longer optional. The two ne= w >> elements are easy to spot and might cause the first change to be missed. >> >> Section 6.2.1 is the same. It should explicitly say that it only permit= s the >> atomOutOfLineContent formulation. >> >> I found the formulation of Section 7.1.1 confusing. It includes a list = that >> seems to be authoritative, then disclaims any attempt to register these >> terms. >> Maybe this is because the statement "This document does not specify any >> information types." appears too late. Some reordering might help. >> >> The formatting of the table in Section 8.3 makes most of the columns >> unreadable. I would recommend a simple nested list. >> >> In section 9, the use of the term "well-known" to refer to information t= hat is >> either public or widely available risks misinterpretation. >> >> FWIW, I would reword this entire paragraph to say simply "Access control= to >> information published using ROLIE should use mechanisms that are >> appropriate to the sensitivity of the information. Primitive authentica= tion >> mechanisms like HTTP Basic Authentication [RFC7617] are rarely appropria= te >> for sensitive information." I didn't find the remainder of the text on >> authentication especially helpful. The text seems to equivocate on the >> subject of federation, where it would be easier to say nothing. >> >> Also in Section 9, the use of the term "message" is used in the context = of >> using additional security controls. I think that the word "representati= on" is >> what was intended here. >> >> _______________________________________________ >> mile mailing list >> mile@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i >> etf.org%2Fmailman%2Flistinfo%2Fmile&data=3D02%7C01%7Cstephen.banghar >> t%40nist.gov%7Caf3af91a1c684592007d08d50ed3d401%7C2ab5d82fd8fa4797 >> a93e054655c61dec%7C1%7C0%7C636431225322845891&sdata=3DSykEasQlo1e >> MarYmKXSA5HsOUpTLyjd9rslyvZPpxak%3D&reserved=3D0 From nobody Wed Oct 18 07:52:04 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08151321BB; Wed, 18 Oct 2017 07:52:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=nistgov.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 ud9Ko61u9oWO; Wed, 18 Oct 2017 07:51:59 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0130.outbound.protection.outlook.com [23.103.201.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13808132CE7; Wed, 18 Oct 2017 07:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Fc0Z8Os1gmsXFzeBcvG+37kxbDZbP8FLvCx4glT9/Ng=; b=EBLGp9oYuDtj62UTVV2hLJ1kHY9AgixhJxpdRyI49yUzqxUtpUVPciemFbXgUtBWsFCp3nf4rGmmqyyJBBpyL2L3IjTtXnC3VEbQuGcFH6n6rEy+lQfei3piRd6rCdBAmOyfgnps3y5PU+DgJHVsUxHqhpLxI+e73Am5+0mVjmM= Received: from DM5PR09MB1307.namprd09.prod.outlook.com (10.172.34.141) by DM5PR09MB1307.namprd09.prod.outlook.com (10.172.34.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 18 Oct 2017 14:51:57 +0000 Received: from DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) by DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) with mapi id 15.20.0077.022; Wed, 18 Oct 2017 14:51:56 +0000 From: "Banghart, Stephen A. (Fed)" To: Martin Thomson CC: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Thread-Topic: [mile] Artart last call review of draft-ietf-mile-rolie-10 Thread-Index: AQHTQLy5EiZhxIKVNkSNg/Bn547ThKLoNUiggADmG4CAAJ+WMA== Date: Wed, 18 Oct 2017 14:51:56 +0000 Message-ID: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.220.117] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR09MB1307; 6:d5V8iCnu2+Hi82wqMflkoZmt5TDqYTwyS/WvHXD6yhROi5hg6RpiPSDdJHtIJcF/iHVBJi+VCl3t2X60NVnfqLdvEfk8jNWizyh8WvOiJGXJXZDmoPvWk49Z6Vxw+iXc6btJQzRw4q0leGCxcbMjYUv76e5g6ViRgiUM2WzM0bOzvGOHOSOBS5VqsW9MdYZ6/jA5WjP04698z5EZ6DoM01/OwQPxfPZO9gAP6f1n0RuypZIDfhw9/Ij4PsT3gpaacWebqcnhhMaQyTT1W4yIygF/YodC19LmND7mH95knsQoJ7/w/VrqezOPASZGMlwvIFwY9QM8I9CvQ48su9eyog==; 5:oadVTxAWacZmYPYjb9pE23cDDuyDHvwRppIfR8qs3P7Vyk4w1//ddQy8V/jp4MSER6Mszl8T0/uTL4YVNTENBpuRhHh6YZinG+PlmrKfeYNmW+YKohp6KownNSWHM7tFCsHSVOLYKoY1uV7xegL63Q==; 24:qsA/ModDL8bmcKSH178MkOSJBHWBNaOJEh/8gyMC+ohieV7XhadjD7/yMCWt7XuLFhRpyo6VX/saqLE+lA4MhRVjtUJuulGtsPOUM+id214=; 7:D5nrNKOOof3nR3iVR79ybnDB4Z1P6RDlBlv/y2O69XQItNvEd6LagROhSOchSwE7yFJ1jYGKs9bSUosZnfyLlUgEz57vGBIjZeIoVeT2Ral6ul8Fdg9QJYNfGahk9V8GHYjakoXsuVco9+snwaRhUdsp3NgSWOg7ou1Ny9MV6m+lx+Vnn6ttFSl0LoTQbADy723fRqe6URej3jmatFrKE5tWhUB7flyvrn2ez2Cqjyo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e6816c17-b849-4b2a-ad65-08d51637c78a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR09MB1307; x-ms-traffictypediagnostic: DM5PR09MB1307: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(192374486261705)(189930954265078)(131327999870524)(150554046322364)(788757137089)(219752817060721); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR09MB1307; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR09MB1307; x-forefront-prvs: 0464DBBBC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(43784003)(3905003)(51914003)(55674003)(51444003)(24454002)(13464003)(199003)(189002)(377454003)(5660300001)(50986999)(76176999)(54356999)(105586002)(106356001)(74316002)(2906002)(229853002)(230783001)(6506006)(2950100002)(8676002)(3660700001)(316002)(81166006)(54906003)(3280700002)(8936002)(305945005)(77096006)(6916009)(81156014)(101416001)(7736002)(14454004)(33656002)(53546010)(6306002)(9686003)(3846002)(53936002)(53946003)(102836003)(99286003)(6116002)(7696004)(966005)(189998001)(66066001)(25786009)(2900100001)(86362001)(4326008)(478600001)(6436002)(6246003)(39060400002)(55016002)(68736007)(97736004)(45080400002)(575784001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1307; H:DM5PR09MB1307.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2017 14:51:56.6591 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1307 Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 14:52:03 -0000 TWFydGluLA0KDQpUaGFua3MgZm9yIHRydW5jYXRpbmcgdGhlIGV4dHJhIG1haWxpbmcgbGlzdHMu DQoNClRoZSBjbGllbnQgYXV0aG9yaXphdGlvbiByZXF1aXJlbWVudHMgaW4gUk9MSUUgYXJlIGlu dGVuZGVkIHRvIGJlIGltcGxlbWVudGF0aW9uIHJlcXVpcmVtZW50cyBhbmQgbm90IHVzZSByZXF1 aXJlbWVudHMsIHdoaWNoIEkgdGhpbmsgaXMgY2F1c2luZyBzb21lIG9mIHRoZSBjb25mdXNpb24u DQoNClVsdGltYXRlbHksIFJPTElFIHdpbGwgYmUgd2VhcmluZyBvbmUgb2YgdHdvIGhhdHMgaW4g dGhlIHdpbGQsIGEgc2VjdXJlIHNlY3VyaXR5IGluZm9ybWF0aW9uIGV4Y2hhbmdlIGZvciBDU0lS VHMgYW5kIHNoYXJpbmcgY29uc29ydGl1bXMsIGFuZCBhIHB1YmxpYyBmYWNpbmcgc2VjdXJpdHkg aW5mb3JtYXRpb24gZXhjaGFuZ2UgZm9yIHB1YmxpYyBkaXNjbG9zdXJlLiBJbiBvcmRlciBmb3Ig YSBnaXZlbiBpbXBsZW1lbnRhdGlvbiB0byBzdXBwb3J0IGJvdGggb2YgdGhlc2UgdXNlIGNhc2Vz IHN0cm9uZyB1c2VyIGF1dGhlbnRpY2F0aW9uIG5lZWRzIHRvIGJlIHN1cHBvcnRlZC9pbXBsZW1l bnRlZCwgYnV0IGluIG9yZGVyIHRvIHN1cHBvcnQgdGhlIHB1YmxpYyBmYWNpbmcgdXNlIGNhc2Us IHRoZXNlIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyBjYW4ndCBiZSByZXF1aXJlZCB0byBi ZSB0dXJuZWQgb24uDQoNCk91ciBnb2FsIHdhcyB0byBhdHRlbXB0IHRvIHN1cHBvcnQgYm90aCB1 c2UgY2FzZXMgaW4gYSB3YXkgdGhhdCAoaG9wZWZ1bGx5KSBkb2Vzbid0IGNvbXByb21pc2UgdGhl IGNvcmUgdXNhZ2Ugb2YgdGhlIG90aGVyIHVzZSBjYXNlLiBXZSB0cmllZCB0byBhbGxvdyB0aGUg cmVxdWlyZW1lbnRzIHRvIGJlIGFkanVkaWNhdGVkIG9uIGEgd29ya3NwYWNlIGJ5IHdvcmtzcGFj ZSBiYXNpcyBzbyBhIHNpbmdsZSBzaXRlIGNvdWxkIGJlIHRha2luZyBhZHZhbnRhZ2Ugb2YgYm90 aCB1c2UgY2FzZXMgc2ltdWx0YW5lb3VzbHkuDQoNCkkndmUgdGFrZW4geW91ciBzdWdnZXN0aW9u IHRvIGNsZWFuIHVwIHRoZSBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgc2VjdGlvbiBhbmQgcGFy dHMgb2YgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gYnkgcmVtb3Zpbmcgb3Vy IHJlaW52ZW50aW9uIG9mIHRoZSB3aGVlbCBhbmQgbGVhbmluZyBtb3JlIGhlYXZpbHkgb24gcmVm ZXJlbmNpbmcgb3RoZXIgUkZDcyBmb3IgYmVzdCBwcmFjdGljZXMsIGl0J3MgcG9zc2libGUgdGhh dCB0aGUgY2xlYW5lZCB1cCB0ZXh0IGNvbnRyYWRpY3RzIGl0c2VsZiBsZXNzIGFuZCBtaXRpZ2F0 ZXMgdGhlIGlzc3VlLiBQZXJoYXBzIG1vcmUgZXhwbGFuYXRvcnkgdGV4dCBhcm91bmQgdGhlc2Ug dHdvIGNvcmUgdXNlIGNhc2VzIGluIHRoZSBhdXRoZW50aWNhdGlvbiBzZWN0aW9uIHdvdWxkIGhl bHAgdG9vPw0KDQpUaGFua3MsDQpTdGVwaGVuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5j b21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxOCwgMjAxNyAxOjAzIEFNDQo+IFRvOiBC YW5naGFydCwgU3RlcGhlbiBBLiAoRmVkKSA8c3RlcGhlbi5iYW5naGFydEBuaXN0Lmdvdj4NCj4g Q2M6IG1pbGVAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbWlsZS1yb2xpZS5hbGxAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFttaWxlXSBBcnRhcnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRm LW1pbGUtcm9saWUtMTANCj4gDQo+ICgtaWV0ZkAgYW5kIGFydEAgdG8gc2F2ZSB0aG9zZSBpbmJv eGVzKQ0KPiANCj4gSGkgU3RlcGhlbiwNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0aW9u LiAgSSBzb21ld2hhdCBleHBlY3RlZCB0aGF0IHRoaXMgd291bGQgYmUgdGhlIHVzZQ0KPiBjYXNl LCBidXQgSSBjb3VsZG4ndCByZWNvbmNpbGUgdGhhdCB3aXRoIHRoZSBsb25nIGxpc3Qgb2YgcmVx dWlyZW1lbnRzIGZvciBjbGllbnQNCj4gYXV0aGVudGljYXRpb24uICBDYW4geW91IGdvIGludG8g c29tZSBtb3JlIGRldGFpbCBhYm91dCB0aGF0IGFzIHdlbGw/ICBIYXBweQ0KPiB0byBoYXNoIHRo YXQgb3V0IGhlcmUgKEknbSBub3Qgc3Vic2NyaWJlZCB0byBtaWxlQCB0aG91Z2gpLg0KPiANCj4g SWYgdGhlIGludGVudCBpcyB0byBoYXZlIHRoZSBpbmZvcm1hdGlvbiBmb3IgYSB3ZWIgc2l0ZSAo YXMgb3Bwb3NlZCB0byB0aGUNCj4gb3JnYW5pemF0aW9uKSBhY2Nlc3NpYmxlIGluIGEgbG9jYXRp b24gdGhhdCBjYW4gYmUgcmVhZGlseSBmb3VuZCwgdGhlbiBJIHRoaW5rDQo+IHRoYXQgeW91IGhh dmUganVzdGlmaWNhdGlvbiBmb3IgdXNpbmcgLndlbGwta25vd24gZm9yIHRoZSBzZXJ2aWNlIGRv Y3VtZW50Lg0KPiBUaGUgY2F0ZWdvcnkgZG9jdW1lbnQgY2FuIGJlIGxpbmtlZCBmcm9tIHRoZSBz ZXJ2aWNlIGRvY3VtZW50LCBzbyBJIHRoaW5rIGl0DQo+IHdvdWxkIGJlIGJlc3QgaWYgeW91IGRp ZCByZW1vdmUgdGhhdCAud2VsbC1rbm93biByZWdpc3RyYXRpb24uICBZb3UgbWlnaHQNCj4gYWxz byBjb25zaWRlciB1c2luZyBzaW1wbHkgLndlbGwta25vd24vcm9saWUgb25jZSB5b3UgaGF2ZSBq dXN0IG9uZQ0KPiByZXNvdXJjZS4NCj4gDQo+IE9uIFdlZCwgT2N0IDE4LCAyMDE3IGF0IDM6MTgg QU0sIEJhbmdoYXJ0LCBTdGVwaGVuIEEuIChGZWQpDQo+IDxzdGVwaGVuLmJhbmdoYXJ0QG5pc3Qu Z292PiB3cm90ZToNCj4gPiBNYXJ0aW4sDQo+ID4NCj4gPiBUaGFua3MgZm9yIHRoZSBncmVhdCBy ZXZpZXcuIFdlJ3ZlIGJlZW4gd29ya2luZyB0aHJvdWdoIHlvdXIgY29tbWVudHMNCj4gYW5kIHBy ZXBhcmluZyBhIC0xMSB2ZXJzaW9uLiBJJ2xsIGhhdmUgYSBmdWxsIHJlc3BvbnNlIHRvIHlvdXIg Y29tbWVudHMgb3V0IHRvDQo+IHRoZSBsaXN0IG9uY2Ugd2UndmUgY29tcGxldGVkIGFkZHJlc3Np bmcgdGhlbSBhbGwsIGJ1dCB3YW50ZWQgdG8gb3BlbiBhDQo+IGRpc2N1c3Npb24gb24gYSBmZXcg cG9pbnRzIGluIHRoZSBtZWFudGltZS4NCj4gPg0KPiA+IFRoZSAud2VsbC1rbm93biByZWdpc3Ry YXRpb24gZm9yIC9zZXJ2aWNlZG9jdW1lbnQgaGFzIGEgdXNlDQo+IGNhc2UvZGlzY292ZXJ5IHN0 b3J5IHRoYXQgd2UgZmVlbCBpcyBpbXBvcnRhbnQgZW5vdWdoIGZvciByZWdpc3RyYXRpb24sIG9y IGF0DQo+IGxlYXN0IGZvciBzdGFuZGFyZGl6YXRpb24uIEluIHRoZSBjYXNlIHdoZXJlIHRoZXJl IGlzIG5vIHN0YW5kYXJkaXplZCBsb2NhdGlvbg0KPiB0ZW1wbGF0ZSBmb3IgdGhlIHNlcnZpY2Ug ZG9jdW1lbnQsIGEgdmVuZG9yL2NvbXBhbnkvc2l0ZSB0aGF0IHdhbnRzIHRvDQo+IHN0YW5kIHVw IGEgUk9MSUUgcmVwb3NpdG9yeSBhbmQgcHJvdmlkZSByZWd1bGFyIHN5bmRpY2F0ZWQgaW5mb3Jt YXRpb24gbXVzdA0KPiBwcm92aWRlIGEgbGluayB0byB0aGUgc2VydmljZSBkb2N1bWVudCBzb21l d2hlcmUgb24gdGhlaXIgcmVndWxhciBzaXRlLCBvcg0KPiBvdGhlcndpc2UgZGlzdHJpYnV0ZSB0 aGUgVVJMLiBXaGlsZSB0aGlzIHBvdGVudGlhbGx5IHByb3ZpZGVzIGEgbWVhbnMgZm9yDQo+IGh1 bWFucyB0byBmaW5kIHRoZSByZXBvc2l0b3J5IChhbHRob3VnaCB0aGUgbGluayB3b3VsZCBsaWtl bHkgYmUgaGlkZGVuIGluDQo+IHNvbWUgc3RyYW5nZSBwbGFjZSksIGl0IGRvZXNuJ3QgaGVscCBh dXRvbWF0ZWQgdG9vbHMgbG9jYXRlIHRoZSByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gQXMgYSB1c2Vy IG9mIFJPTElFLCBJJ2QgbGlrZSB0byBiZSBhYmxlIHRvIHByb3ZpZGUgYSB0b29sIHdpdGggdGhl DQo+IGhvc3RuYW1lOnBvcnQgb2YgYSB2ZW5kb3Igd2hvc2Ugc3luZGljYXRlZCBpbmZvcm1hdGlv biBJJ2QgbGlrZSB0byByZWNlaXZlLA0KPiBhbmQgaGF2ZSB0aGUgdG9vbCByZXR1cm4gdGhlIHN0 YXR1cyBvZiBhbnkgcmVwb3NpdG9yeSB0aGF0IGlzIG9yIGluIG5vdCBob3N0ZWQNCj4gYnkgdGhh dCB0b3AgbGV2ZWwgc2l0ZS4gRm9yIGV4YW1wbGUsIEknZCBsaWtlIHRvIGdpdmUgYSB0b29sDQo+ ICJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD13d3cu bWljcm9zb2Z0LmNvbSZkDQo+IGF0YT0wMiU3QzAxJTdDc3RlcGhlbi5iYW5naGFydCU0MG5pc3Qu Z292JTdDYmE0NmFhZmViZTczNGIzZjY4MDUwDQo+IDhkNTE1ZTU5MjQ2JTdDMmFiNWQ4MmZkOGZh NDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjQzODkNCj4gOTgxMDc2MDczMzcmc2Rh dGE9V00weHNyc1BIY0w1Mm9VODJDOFZsRmxWS1lIZVRkWm9tVER4NldRZ0pZcyUNCj4gM0QmcmVz ZXJ2ZWQ9MCIgYW5kIGhhdmUgaXQgcHJvdmlkZSBtZSBhbGwgdGhlIFJPTElFIChhbmQgbm9uLVJP TElFDQo+IEF0b21QdWIgaWYgcHJvdmlkZWQgaW4gdGhlIHNhbWUgU2VydkRvYykgQ29sbGVjdGlv bnMgcHJvdmlkZWQgYnkgdGhhdCBob3N0Lg0KPiBXaXRob3V0IGEgLndlbGwta25vd24gcmVnaXN0 cmF0aW9uLCB0aGUgc3RhbmRhcmQgd291bGQgaGF2ZSB0byBwcm92aWRlIGENCj4gZGVmaW5lZCBu b24tLy53ZWxsLWtub3duIFVSTCB0ZW1wbGF0ZSBsb2NhdGlvbiwgd2hpY2ggd2UgZmVsdCB3YXMg YmFkDQo+IHByYWN0aWNlLg0KPiA+DQo+ID4gSXRzIGxpa2VseSB0aGF0IHRoZSBzdGFuZGFyZCBk b2Vzbid0IHByb3ZpZGUgZW5vdWdoIGNvbnRleHQgYXJvdW5kIHRoZQ0KPiAvLndlbGwta25vd24g cmVnaXN0cmF0aW9uLCBhbmQgdGhhdCBhZGRpbmcgbW9yZSBleHBsYW5hdG9yeSB0ZXh0IGFyb3Vu ZCBvdXINCj4gZGlzY292ZXJ5IHN0b3J5IHdvdWxkIGhlbHAgbWFrZSB0aGUgbmVlZCBmb3IgYSBV UkwgdGVtcGxhdGUgbW9yZSBjbGVhci4NCj4gPg0KPiA+IElmIHRoZSBpc3N1ZSBpcyB3aXRoIHRo ZSB1c2Ugb2YgLy53ZWxsLWtub3duLCBhbmQgbm90IHdpdGggdGhlIHN0YW5kYXJkaXplZA0KPiBV UkwgdGVtcGxhdGUsIHdlIGNvdWxkIHNpbXBseSByZW1vdmUgdGhlIC53ZWxsLWtub3duIHJlZ2lz dHJhdGlvbiBhbmQNCj4gaW5zdGVhZCBwcm92aWRlIGEgbm9uLXJlZ2lzdGVyZWQgcmVxdWlyZW1l bnQgZm9yIGENCj4ge2hvc3R9L3JvbGllL3NlcnZpY2Vkb2N1bWVudCBVUkwgdGVtcGxhdGUuDQo+ ID4NCj4gPiBXZSBhZ3JlZSB0aGF0IHRoZSBkaXNjb3Zlcnkgc3RvcnkgZm9yIC9jYXRlZ29yeWRv Y3VtZW50IGlzIGRlY2lkZWRseQ0KPiB3ZWFrZXIsIGFzIGFueSBvdXQtb2YtbGluZSBjYXRlZ29y eSBkb2N1bWVudHMgd291bGQgYmUgbGlua2VkIHRvIGZyb20gdGhlDQo+IFNlcnZpY2UgRG9jdW1l bnQuIFdlIHdvdWxkIG9wZW4gdG8gZHJvcHBpbmcgdGhpcw0KPiByZWdpc3RyYXRpb24vcmVxdWly ZW1lbnQgb3V0cmlnaHQgYXMgeW91IHN1Z2dlc3QuDQo+ID4NCj4gPiBUaGFua3MgYWdhaW4gZm9y IHRoZSB0aG9yb3VnaCByZXZpZXcsDQo+ID4gU3RlcGhlbiBCYW5naGFydA0KPiA+DQo+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IG1pbGUgW21haWx0bzptaWxlLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gVGhvbXNvbg0KPiA+PiBTZW50OiBN b25kYXksIE9jdG9iZXIgMDksIDIwMTcgMTowOCBBTQ0KPiA+PiBUbzogYXJ0QGlldGYub3JnDQo+ ID4+IENjOiBtaWxlQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBkcmFmdC1pZXRmLW1pbGUtcm9s aWUuYWxsQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFttaWxlXSBBcnRhcnQgbGFzdCBjYWxsIHJl dmlldyBvZiBkcmFmdC1pZXRmLW1pbGUtcm9saWUtMTANCj4gPj4NCj4gPj4gUmV2aWV3ZXI6IE1h cnRpbiBUaG9tc29uDQo+ID4+IFJldmlldyByZXN1bHQ6IEFsbW9zdCBSZWFkeQ0KPiA+Pg0KPiA+ PiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCwgYW5kIC0gZGVzcGl0ZSB3aGF0IGFwcGVh cnMgdG8gYmUgYQ0KPiA+PiBsZW5ndGh5IGxpc3Qgb2YgaXNzdWVzIC0gSSB0aGluayB0aGF0IGl0 IGlzIGluIHByZXR0eSBnb29kIHNoYXBlLg0KPiA+PiBJdCdzIGNsZWFyLCByZWFkYWJsZSwgYW5k IGFkZHJlc3NlcyB0aGUgcmVxdWlyZW1lbnRzIHdlbGwuICBNb3N0IG9mDQo+ID4+IG15IGNvbW1l bnRzIHNob3VsZCBiZSB0cml2aWFsIHRvIHJlc29sdmUuDQo+ID4+DQo+ID4+IE1ham9yOg0KPiA+ Pg0KPiA+PiBUaGUgZGVjaXNpb24gdG8gZGVmaW5lIGEgLndlbGwta25vd24gVVJJIHdpdGhvdXQg YSBkaXNjb3Zlcnkgc3RvcnkgaXMNCj4gPj4gLSBpbiBteSBvcGluaW9uIC0gaW5hZHZpc2FibGUu ICBTdWNoIGEgcmVnaXN0cmF0aW9uIGlzIHVzdWFsbHkNCj4gPj4gYXBwcm9wcmlhdGUgaWYgeW91 IGRlc2lnbiBhIHByb3RvY29sIHRoYXQgZGVwZW5kcyBvbiBkaXNjb3ZlcnkgYnkNCj4gPj4gaG9z dG5hbWUgYW5kIHBvcnQuICBBcyBzdWNoLCB0aGlzIGRvZXMgbm90IHVzZSB0aGF0IGF0IGFsbC4g IEENCj4gPj4gY29uZmlndXJhdGlvbiBzeXN0ZW0gY2FuIChhbmQgc2hvdWxkKSBhY2NlcHQgYSBj b21wbGV0ZSBVUkkgZm9yIHRoZQ0KPiA+PiBzZXJ2aWNlIGVuZHBvaW50LiAgSXQgd291bGQgYmUg YmV0dGVyIHRvIGRlZmVyIGNyZWF0aW9uIG9mIHlldA0KPiA+PiBhbm90aGVyIC53ZWxsLWtub3du IFVSSSByZWdpc3RyYXRpb24gdW50aWwgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgY2VydGFpbg0KPiB0 aGF0IGRpc2NvdmVyeSByZXF1aXJlcyBpdC4NCj4gPj4NCj4gPj4gVGhlIHNhbWUgY29tbWVudCBh cHBsaWVzIHRvIHRoZSAud2VsbC1rbm93biByZXNvdXJjZSBmb3IgdGhlIGNhdGVnb3J5DQo+ID4+ IGRvY3VtZW50Lg0KPiA+PiAgR2l2ZW4gdGhhdCB0aGlzIHNvcnQgb2YgZG9jdW1lbnQgaXMgcmVh ZGlseSBkaXNjb3ZlcmFibGUgdmlhIHRoZQ0KPiA+PiBzZXJ2aWNlIGRvY3VtZW50LCBJIHdvdWxk IHNheSB0aGF0IHRoZSBuZWVkIGZvciBhIC53ZWxsLWtub3duDQo+ID4+IHJlc291cmNlIGlzIGxl c3Mgd2VsbC0ganVzdGlmaWVkIHRoYW4gdGhlIHNlcnZpY2UgZG9jdW1lbnQuDQo+ID4+DQo+ID4+ IFRoZSByZXF1aXJlbWVudHMgaW4gU2VjdGlvbiA1LjMgb24gVExTIHVzZSBhcmUgdW5uZWNlc3Nh cmlseSBzdHJpY3QuDQo+ID4+IEl0J3MgZ3JlYXQgdG8gcmVjb21tZW5kIHRoZSB1c2Ugb2YgVExT IDEuMiwgYnV0IGdpdmVuIHRoYXQgdGhlDQo+ID4+IGRvY3VtZW50IGhhcyBubyByZWFsIHJlcXVp cmVtZW50IG9uIGFueSBwYXJ0aWN1bGFyIHZlcnNpb24gb2YgVExTLA0KPiA+PiB0aGUgdXNlIG9m ICJNVVNUIiBoZXJlIGlzIG5vdCBuZWVkZWQuICBTaW1pbGFybHksIHRoZSBwcm9oaWJpdGlvbiBv bg0KPiA+PiB0aGUgdXNlIG9mIDAtUlRUIGlzIGdyb3VuZGxlc3MuICBUaGUgbGVuZ3RoeSBsaXN0 IG9mIHJlcXVpcmVtZW50cw0KPiA+PiBhcm91bmQgY2VydGlmaWNhdGUgdmFsaWRhdGlvbiBvbmx5 IHJpc2sgY3JlYXRpbmcgYSBjb25mbGljdCB3aXRoDQo+ID4+IGFkdmljZSBpbiBvdGhlciBSRkNz LiAgTWFueSwgaWYgbm90IGFsbCwgb2YgdGhlc2UgcmVxdWlyZW1lbnRzIGFyZQ0KPiA+PiB0cmFu c2l0aXZlbHkgaW5jbHVkZWQgYnkgd2F5IG9mIHJlZmVyZW5jaW5nIEhUVFBTIGRvY3VtZW50cy4g IEkgd291bGQNCj4gcHJlZmVyIHRvIHNlZSB0aGlzIGVudGlyZSBzZWN0aW9uIHJlZHVjZWQgdG8g YSBzaW1wbGUgUkZDIDc1MjUgcmVmZXJlbmNlLg0KPiA+Pg0KPiA+PiBVc2VyIGF1dGhlbnRpY2F0 aW9uIGlzIHVuZGVyLXNwZWNpZmllZC4NCj4gPj4NCj4gPj4gKiBTZWN0aW9uIDUuMyBtYW5kYXRl cyB0aGUgdXNlIG9mIFRMUyBjaXBoZXIgc3VpdGVzIHRoYXQgc3VwcG9ydA0KPiA+PiBjbGllbnQg YXV0aGVudGljYXRpb24gdXNpbmcgY2VydGlmaWNhdGVzLCBidXQgb2ZmZXJzIG5vIGZ1cnRoZXIN Cj4gPj4gYWR2aWNlLiAgQXNpZGUgZnJvbSBiZWluZyBhbiB1bm5lY2Vzc2FyeSByZXF1aXJlbWVu dCAtIGNpcGhlciBzdWl0ZXMNCj4gPj4gdGhhdCBzdXBwb3J0IGNlcnRpZmljYXRlLSBiYXNlZCBh dXRoZW50aWNhdGlvbiBvZiBzZXJ2ZXJzIGFsbCBhbGxvdw0KPiA+PiBmb3IgY2xpZW50IGF1dGhl bnRpY2F0aW9uIC0gdGhpcyBzb3J0IG9mIHJlcXVpcmVtZW50IGlzIHJhcmVseQ0KPiA+PiBzdWZm aWNpZW50IGZvciBpbnRlcm9wZXJhdGlvbi4gIEZvciBpbnN0YW5jZSwgeW91IG5lZWQgdG8gc3Bl Y2lmeSBob3cNCj4gPj4gYSBzZXJ2ZXIgd2lsbCByZXF1ZXN0IGEgY2VydGlmaWNhdGUgc3VjaCB0 aGF0IGNsaWVudHMgY2FuIHNlbGVjdCB0aGUNCj4gPj4gY29ycmVjdCBjZXJ0aWZpY2F0ZS4gIElm IGEgY2xpZW50IGFuZCBzZXJ2ZXIgaGF2ZSBhZ3JlZWQgdG8gc2hhcmUNCj4gPj4gaW5mb3JtYXRp b24gb24gdGVybXMgdGhhdCByZWx5IG9uIGF1dGhlbnRpY2F0aW9uIG9mIGNsaWVudHMsIGl0IGlz IGJldHRlciBmb3INCj4gdGhvc2UgcGVlcnMgdG8gYXJyYW5nZSB0aGUgdGVybXMgb24gd2hpY2gg dGhleSB3aWxsIGF1dGhlbnRpY2F0ZS4NCj4gPj4NCj4gPj4gKiBTZWN0aW9uIDUuNCB1c2VzICJT SE9VTEQiIHJlZ2FyZGluZyBjbGllbnQgYXV0aGVudGljYXRpb24gdXNpbmcNCj4gPj4gZmVkZXJh dGlvbiwgYnV0IG9mZmVycyBubyBoaW50cyBhYm91dCB3aGF0IHRoaXMgZW50YWlscy4gIEl0IGFs c28NCj4gPj4gdXNlcyAiU0hPVUxEIiByZWdhcmRpbmcgYXV0aG9yaXphdGlvbiBjaGVja3MsIHdo aWNoIGlzbid0IGFuDQo+ID4+IGludGVyb3BlcmFiaWxpdHkgcmVxdWlyZW1lbnQuICBJdCdzIG1v cmUgb2YgYSAiZG9uJ3QgYmUgc2lsbHkiIHR5cGUNCj4gPj4gb2YgcmVxdWlyZW1lbnQsIHdoaWNo IGRvZXNuJ3QgbmVlZCB0byBiZSB3cml0dGVuIGRvd24gaW4gYW4gUkZDLg0KPiA+Pg0KPiA+PiBT ZWN0aW9uIDUuNSBwcm9oaWJpdHMgdGhlIHVzZSBvZiBHRVQgb24gIi8iLiAgVGhpcyBwcm9oaWJp dHMgdXNlIG9mDQo+ID4+IHRoZSByZXNvdXJjZSBmb3Igb3RoZXIgcHVycG9zZXMuICBJdCBzZWVt cyByZWFzb25hYmxlIHRvIGFjY2VwdCBQT1NUDQo+ID4+IG1lc3NhZ2VzIGFzIGRlZmluZWQgaW4g UkZDIDY1NDYsIGJ1dCB0aGlzIHJlcXVpcmVtZW50IGlzIG92ZXJseQ0KPiA+PiBzdHJpY3QgKGFu ZCBmdXJ0aGVyIGVudHJlbmNoZXMgdGhlIHZpb2xhdGlvbiBvZiBSRkMgNzMyMCkuICBJZiwgZm9y DQo+ID4+IGluc3RhbmNlLCB0aGUgc2VydmVyIG9wZXJhdG9yIHdpc2hlcyB0byBwcm92aWRlIEhU TUwgaW4gcmVzcG9uc2UgdG8gYQ0KPiA+PiBHRVQgcmVxdWVzdCB0byAiLyIsIHRoaXMgd291bGQg cHJvaGliaXQgdGhhdC4gIFRoZSByZXF1aXJlbWVudCB0bw0KPiA+PiByZXR1cm4gNDA0IGlmIFJG QyA2NTQ2IGlzIG5vdCBzdXBwb3J0ZWQgaXMgd29yc2U7IG5vdCBzdXBwb3J0aW5nIFJGQw0KPiA+ PiA2NTQ2IG1pZ2h0IGJlIGEgY2hvaWNlIHRoYXQgYSBkZXBsb3ltZW50IG1ha2VzIHRvIGF2b2lk IHRoZSBuZWVkIHRvDQo+IHJlc2VydmUgIi8iIGZvciB0aGF0IHByb3RvY29sLg0KPiA+Pg0KPiA+ PiBJbiBTZWN0aW9uIDYuMi4zLCB3aGF0IGlzIHRoZSBhZHZhbnRhZ2Ugb2YgInJvbGllOmZvcm1h dCIgb3ZlciBoYXZpbmcNCj4gPj4gYSB3ZWxsLSBkZWZpbmVkIG1lZGlhIHR5cGU/ICBNZWRpYSB0 eXBlcyBjYW4gdGFrZSBhZHZhbnRhZ2Ugb2YNCj4gPj4gY29udGVudCBuZWdvdGlhdGlvbiwgZXhp c3Rpbmcgc3VwcG9ydCBpbiBsaW5rIHJlbGF0aW9ucywgYW5kIG90aGVyIGV4aXN0aW5nDQo+IHRv b2xzLg0KPiA+PiBUaGlzIHJvbGllOmZvcm1hdCBlbGVtZW50IGhhcyBuYW1lc3BhY2UsIGZvcm1h dCwgYW5kIHNjaGVtYTsgdGhlc2UNCj4gPj4gYXJlIG5vdCB1c2VmdWwgdG8gYW55b25lIHRoYXQg aXMgaWdub3JhbnQgb2YgdGhlaXIgY29udGVudHMuICBUaGUNCj4gPj4gb25seSBhZHZhbnRhZ2Ug SSBzZWUgaXMgdGhhdCBzeW50YXggbWlnaHQgYmUgdmFsaWRhdGVkLCBidXQgc2VtYW50aWNzDQo+ ID4+IGNhbid0IGJlIGV4dHJhY3RlZC4gIFRoZXJlJ3MgYSBsb3Qgb2YgaW1wbGllZCB3b3JrIGlu IGFkZGluZyB0aGlzDQo+ID4+IGVsZW1lbnQsIGJ1dCB0aGF0IGRvZXNuJ3Qgc2VlbSB0byBiZSBq dXN0aWZpZWQgYnkgdGhhdCBhZHZhbnRhZ2UuICAoSQ0KPiA+PiBzZWUgdGhhdCBSRkMgNzk3MCBk b2Vzbid0IGRlZmluZSBhIG1lZGlhIHR5cGUsIGJ1dCBpdCBzZWVtcyBsaWtlIGl0DQo+ID4+IHdv dWxkIGJlIGVhc2llciB0byBjb3JyZWN0IHRoYXQgdGhhbiB0byBkZWZpbmUgYW4gZWxlbWVudCBs aWtlIHRoaXMuKQ0KPiA+Pg0KPiA+PiBTZWN0aW9uIDYuMi40IGRlZmluZXMgYSBnZW5lcmljIGtl eS12YWx1ZSBtZWNoYW5pc20uICBCdXQgdGhhdCBpcw0KPiA+PiBzb21ldGhpbmcgdGhhdCBYTUwg aXMgYWN0dWFsbHkgZ29vZCBhdC4gIFdoeSBjYW4ndCB1c2VycyB0aGF0IHJlcXVpcmUNCj4gPj4g YWRkaXRpb25hbCBtZXRhZGF0YSB1c2UgYWRkaXRpb25hbCBtZXRhZGF0YSBhcyBvcmlnaW5hbGx5 IGRlZmluZWQgYnkNCj4gPj4gQXRvbT8gIFRoYXQgaXMsIHJlcGxhY2UgPHJvbGllOnByb3BlcnR5 DQo+IG5hbWU9InVybjppZXRmOnBhcmFtczpyb2xpZTpwcm9wZXJ0eTpjc2lydC1pb2RlZi1pZCIN Cj4gPj4gdmFsdWU9IjEyMzQ1Ii8+IHdpdGggc29tZXRoaW5nIGxpa2UNCj4gPj4gPHJvbGllOmNz aXJ0LWlvZGVmLWlkPjEyMzQ1PC9yb2xpZTpjc2lydC1pb2RlZi1pZD4uICBUaGUgZmluYWwNCj4g Pj4gcGFyYWdyYXBoIG9mIHRoZSBzZWN0aW9uIHJlY29nbml6ZXMgdGhpcyBwb3NzaWJpbGl0eS4N Cj4gPj4NCj4gPj4gTWlub3I6DQo+ID4+DQo+ID4+IFNlY3Rpb24gNS4xLjEgcmVjb21tZW5kcyB0 aGUgdXNlIG9mIHdvcmtzcGFjZXMgdG8gc2VwYXJhdGUgInByaXZhdGUiDQo+ID4+IGFuZCAicHVi bGljIiBpbmZvcm1hdGlvbi4gIEJ1dCB3b3Jrc3BhY2VzIGRvbid0IHJlYWxseSBjb250YWluIGVu b3VnaA0KPiA+PiBpbmZvcm1hdGlvbiB0byBzaWduYWwgdGhlaXIgc3RhdHVzIHRvIGEgY29uc3Vt ZXIgb2YgdGhlIGluZm9ybWF0aW9uLg0KPiA+PiBJIHdvdWxkIHN1Z2dlc3QgbWVudGlvbmluZyB0 aGlzLCByZW1vdmluZyB0aGUgcmVjb21tZW5kYXRpb24sIG9yDQo+ID4+IGV4cGFuZGluZyBvbiB0 aGUgbWFubmVyIGluIHdoaWNoIHRoZSBzdGF0dXMgb2YgaW5mb3JtYXRpb24gaXMgc2lnbmFsZWQu DQo+ID4+DQo+ID4+IFNlY3Rpb24gNi4xLjEgc2F5cyAiemVybyBvciBtb3JlIGF0b206Y2F0ZWdv cnkgZWxlbWVudHMiLCBidXQgdGhpcw0KPiA+PiBjb250cmFkaWN0cyB0aGUgdGV4dCBhbmQgYW1l bmRtZW50IHRvIHRoZSBzY2hlbWEgaW4gU2VjdGlvbiA2LjEuDQo+ID4+DQo+ID4+IFNlY3Rpb24g Ni4xLjMgcmVxdWlyZXMgdXBkYXRpbmcgdGhlICJhdG9tOnVwZGF0ZWQiIGVsZW1lbnQgd2hlbiB0 aGUNCj4gPj4gcmVwcmVzZW50YXRpb24gY2hhbmdlcy4gIEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlz IGlzIHdoYXQgd2FzDQo+ID4+IGludGVuZGVkLiAgSSB0aGluayB0aGF0IHRoZSBlbGVtZW50IG5l ZWRzIHRvIGJlIHVwZGF0ZWQgd2hlbiB0aGUNCj4gPj4gY29udGVudHMgb2YgdGhlIGZlZWQgY2hh bmdlIGluIGFueSB3YXkuDQo+ID4+DQo+ID4+IFF1ZXN0aW9uOiBpdCdzIGZhaXJseSB3aWRlbHkg YWNjZXB0ZWQgdGhhdCB1c2Ugb2YgSVJJcyBpbiBBdG9tIGhhcw0KPiA+PiBiZWVuIGxlc3MgdGhh biBzdWNjZXNzZnVsLiAgRG8geW91IHdhbnQgdG8gbWFuZGF0ZSB1c2Ugb2YgVVJJcw0KPiA+PiBp bnN0ZWFkPyAgVGhpcyB3b3VsZCBhcHBseSB0byBib3RoIGxpbmsgcmVsYXRpb25zIGFuZCB0aGUg InNyYyIgYXR0cmlidXRlLg0KPiA+Pg0KPiA+PiBJbiBTZWN0aW9uIDcuMSwgdGhlIGRlZmluaXRp b24gb2YgdGhlIG5hbWVzcGFjZSBwcmVmaXgNCj4gPj4gInVybjppZXRmOnBhcmFtczpyb2xpZTpj YXRlZ29yeTpsb2NhbCIgc2VlbXMgdW5uZWNlc3NhcnkuICBOYW1lc3BhY2UNCj4gPj4gVVJJcyBh cmUgY2hlYXAgYW5kIGl0IHNlZW1zIHJlYXNvbmFibGUgdG8gZXhwZXJpbWVudCB3aXRoIGZlZWRz IHRoYXQNCj4gPj4gcHJvZHVjZSBub24tUk9MSUUgaW5mb3JtYXRpb24gYnkgb21pdHRpbmcgdGhl DQo+ID4+ICJ1cm46aWV0ZjpwYXJhbXM6cm9saWU6Y2F0ZWdvcnk6aW5mb3JtYXRpb24tdHlwZSIN Cj4gPj4gY2F0ZWdvcnksIGV2ZW4gaWYgdGhhdCBmZWVkIG1pZ2h0IGNvbXBseSB3aXRoIHRoZSBy ZXF1aXJlbWVudHMgb2YgUk9MSUUuDQo+ID4+IFRoZSBvdGhlciB3YXkgdG8gZXhwZXJpbWVudCB3 b3VsZCBiZSB0byB1c2UgdGhlIGNhdGVnb3J5LCBidXQgZGVmaW5lDQo+ID4+IGEgd2F5IHRvIGlk ZW50aWZ5ICJ0ZXJtIiBhdHRyaWJ1dGVzIHRoYXQgYXJlIGZvciB1c2UgaW4gcHJpdmF0ZSBvcg0K PiA+PiBleHBlcmltZW50YWwgY29udGV4dHMuDQo+ID4+DQo+ID4+IEluIFNlY3Rpb24gNy40LCBo b3cgaXMgIi4uLjpyb2xpZTpwcm9wZXJ0eTpjb250ZW50LWF1dGhvci1uYW1lIg0KPiA+PiBzdXBl cmlvciB0byAiYXRvbTphdXRob3IiPw0KPiA+Pg0KPiA+PiBJbiBTZWN0aW9uIDguNCwgIGlzIHRo ZXJlIGEgdW5pcXVlbmVzcyByZXF1aXJlbWVudCBvbiAibmFtZSI/ICBJDQo+IHVuZGVyc3RhbmQN Cj4gPj4gdGhpcyB0byBiZSB0aGUgdGhpbmcgdGhhdCBiZWluZyByZWdpc3RlcmVkLiAgIEFzc3Vt aW5nIHRoYXQsIHdoYXQgcHVycG9zZQ0KPiA+PiBkb2VzDQo+ID4+IHRoZSAiaW5kZXgiIHNlcnZl Pw0KPiA+Pg0KPiA+PiBUaGlzIHN0YXRlbWVudCBmcm9tIFNlY3Rpb24gOSwgIkFzIGRlc2NyaWJl ZCBpbiB0aGUgZGlzY292ZXJ5DQo+ID4+IHNlY3Rpb24sIEROUyBTUlYgUmVjb3JkcyBhcmUgYSBw b3NzaWJsZSBzZWN1cmUgc29sdXRpb24gdG8NCj4gPj4gZGlzY292ZXJ5LiIgaXMgZmFsc2Ugd2l0 aG91dCBmdXJ0aGVyIHF1YWxpZmljYXRpb24uICBTUlYgd2l0aCBETlNTRUMNCj4gPj4gbWlnaHQg YmUgc2VjdXJlLCBidXQgYSBsb3QgZGVwZW5kcyBvbiB0aGUgaW5wdXQgdG8gdGhlIGRpc2NvdmVy eSBwcm9jZXNzDQo+IGFuZCBpdHMgcHJvdmVuYW5jZS4NCj4gPj4NCj4gPj4gSW4gU2VjdGlvbiAx MCwgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgaXMgZmFsc2UgKGFsbCBvZiB0aGUgZGVzY3JpYmVk DQo+ID4+IHByaXZhY3kgdmlvbGF0aW9ucyBhcmUgYXZhaWxhYmxlIHRvIGEgY2xpZW50IG9yIHNl cnZlciwgbm90IHRoaXJkDQo+ID4+IHBhcnRpZXMpOiAiUHJvcGVyIHVzYWdlIG9mIFRMUyBhcyBk ZXNjcmliZWQgaW4gU2VjdGlvbiA1LjMgd2lsbCBpbg0KPiA+PiBtYW55IGNhc2VzIGFpZCBpbiB0 aGUgbWl0aWdhdGlvbiBvZiB0aGVzZSBpc3N1ZXMuIiAgSSB0aGluayB0aGF0IHlvdQ0KPiA+PiBj YW4gc3RyaWtlIHRoaXMgc3RhdGVtZW50IChtb3N0IG9mIHRoZSByZWFzb24gZm9yIHVzZSBvZiBU TFMgaXMganVzdGlmaWVkIGJ5DQo+IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbnl3YXkp Lg0KPiA+Pg0KPiA+PiBOaXRzOg0KPiA+Pg0KPiA+PiBJcyBpdCAiRmVlZCIgb3IgImZlZWQiPyAg UkZDIDQyODcgdXNlcyB0aGUgbGF0dGVyLCBidXQgdGhpcyBkb2N1bWVudA0KPiA+PiBzZWVtcyB0 byBwcmVmZXIgdGhlIFByb3BlciBOb3VuIGZvcm0uDQo+ID4+DQo+ID4+IFNlY3Rpb24gNi4yIHNo b3VsZCBzYXkgd2hhdCBjaGFuZ2VkIGluIHRoZSBzY2hlbWEuICBJdCdzIGhhcmQgdG8NCj4gPj4g ZXllYmFsbCB0aGUgc2NoZW1hIHRvIGRpc2NvdmVyIHRoYXQgImF0b21Db250ZW50IiBpcyBubyBs b25nZXINCj4gPj4gb3B0aW9uYWwuICBUaGUgdHdvIG5ldyBlbGVtZW50cyBhcmUgZWFzeSB0byBz cG90IGFuZCBtaWdodCBjYXVzZSB0aGUNCj4gZmlyc3QgY2hhbmdlIHRvIGJlIG1pc3NlZC4NCj4g Pj4NCj4gPj4gU2VjdGlvbiA2LjIuMSBpcyB0aGUgc2FtZS4gIEl0IHNob3VsZCBleHBsaWNpdGx5 IHNheSB0aGF0IGl0IG9ubHkNCj4gPj4gcGVybWl0cyB0aGUgYXRvbU91dE9mTGluZUNvbnRlbnQg Zm9ybXVsYXRpb24uDQo+ID4+DQo+ID4+IEkgZm91bmQgdGhlIGZvcm11bGF0aW9uIG9mIFNlY3Rp b24gNy4xLjEgY29uZnVzaW5nLiAgSXQgaW5jbHVkZXMgYQ0KPiA+PiBsaXN0IHRoYXQgc2VlbXMg dG8gYmUgYXV0aG9yaXRhdGl2ZSwgdGhlbiBkaXNjbGFpbXMgYW55IGF0dGVtcHQgdG8NCj4gPj4g cmVnaXN0ZXIgdGhlc2UgdGVybXMuDQo+ID4+IE1heWJlIHRoaXMgaXMgYmVjYXVzZSB0aGUgc3Rh dGVtZW50ICJUaGlzIGRvY3VtZW50IGRvZXMgbm90IHNwZWNpZnkNCj4gPj4gYW55IGluZm9ybWF0 aW9uIHR5cGVzLiIgYXBwZWFycyB0b28gbGF0ZS4gIFNvbWUgcmVvcmRlcmluZyBtaWdodCBoZWxw Lg0KPiA+Pg0KPiA+PiBUaGUgZm9ybWF0dGluZyBvZiB0aGUgdGFibGUgaW4gU2VjdGlvbiA4LjMg bWFrZXMgbW9zdCBvZiB0aGUgY29sdW1ucw0KPiA+PiB1bnJlYWRhYmxlLiAgSSB3b3VsZCByZWNv bW1lbmQgYSBzaW1wbGUgbmVzdGVkIGxpc3QuDQo+ID4+DQo+ID4+IEluIHNlY3Rpb24gOSwgdGhl IHVzZSBvZiB0aGUgdGVybSAid2VsbC1rbm93biIgdG8gcmVmZXIgdG8NCj4gPj4gaW5mb3JtYXRp b24gdGhhdCBpcyBlaXRoZXIgcHVibGljIG9yIHdpZGVseSBhdmFpbGFibGUgcmlza3MgbWlzaW50 ZXJwcmV0YXRpb24uDQo+ID4+DQo+ID4+IEZXSVcsIEkgd291bGQgcmV3b3JkIHRoaXMgZW50aXJl IHBhcmFncmFwaCB0byBzYXkgc2ltcGx5ICJBY2Nlc3MNCj4gPj4gY29udHJvbCB0byBpbmZvcm1h dGlvbiBwdWJsaXNoZWQgdXNpbmcgUk9MSUUgc2hvdWxkIHVzZSBtZWNoYW5pc21zDQo+ID4+IHRo YXQgYXJlIGFwcHJvcHJpYXRlIHRvIHRoZSBzZW5zaXRpdml0eSBvZiB0aGUgaW5mb3JtYXRpb24u DQo+ID4+IFByaW1pdGl2ZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIGxpa2UgSFRUUCBCYXNp YyBBdXRoZW50aWNhdGlvbg0KPiA+PiBbUkZDNzYxN10gYXJlIHJhcmVseSBhcHByb3ByaWF0ZSBm b3Igc2Vuc2l0aXZlIGluZm9ybWF0aW9uLiIgIEkNCj4gPj4gZGlkbid0IGZpbmQgdGhlIHJlbWFp bmRlciBvZiB0aGUgdGV4dCBvbiBhdXRoZW50aWNhdGlvbiBlc3BlY2lhbGx5DQo+ID4+IGhlbHBm dWwuICBUaGUgdGV4dCBzZWVtcyB0byBlcXVpdm9jYXRlIG9uIHRoZSBzdWJqZWN0IG9mIGZlZGVy YXRpb24sDQo+IHdoZXJlIGl0IHdvdWxkIGJlIGVhc2llciB0byBzYXkgbm90aGluZy4NCj4gPj4N Cj4gPj4gQWxzbyBpbiBTZWN0aW9uIDksIHRoZSB1c2Ugb2YgdGhlIHRlcm0gIm1lc3NhZ2UiIGlz IHVzZWQgaW4gdGhlDQo+ID4+IGNvbnRleHQgb2YgdXNpbmcgYWRkaXRpb25hbCBzZWN1cml0eSBj b250cm9scy4gIEkgdGhpbmsgdGhhdCB0aGUgd29yZA0KPiA+PiAicmVwcmVzZW50YXRpb24iIGlz IHdoYXQgd2FzIGludGVuZGVkIGhlcmUuDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IG1pbGUgbWFpbGluZyBsaXN0DQo+ID4+ IG1pbGVAaWV0Zi5vcmcNCj4gPj4NCj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuDQo+ID4+IGkNCj4gZXRmLm9yZyUy Rm1haWxtYW4lMkZsaXN0aW5mbyUyRm1pbGUmZGF0YT0wMiU3QzAxJTdDc3RlcGhlbi5iYW5naGFy DQo+ID4+DQo+IHQlNDBuaXN0LmdvdiU3Q2FmM2FmOTFhMWM2ODQ1OTIwMDdkMDhkNTBlZDNkNDAx JTdDMmFiNWQ4MmZkOGZhNDc5Nw0KPiA+Pg0KPiBhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2 MzY0MzEyMjUzMjI4NDU4OTEmc2RhdGE9U3lrRWFzUWxvMWUNCj4gPj4gTWFyWW1LWFNBNUhzT1Vw VEx5amQ5cnNseXZaUHB4YWslM0QmcmVzZXJ2ZWQ9MA0K From nobody Wed Oct 18 07:52:09 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 26CEE132CE7; Wed, 18 Oct 2017 07:52:03 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08151321BB; Wed, 18 Oct 2017 07:52:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=nistgov.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 ud9Ko61u9oWO; Wed, 18 Oct 2017 07:51:59 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0130.outbound.protection.outlook.com [23.103.201.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13808132CE7; Wed, 18 Oct 2017 07:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Fc0Z8Os1gmsXFzeBcvG+37kxbDZbP8FLvCx4glT9/Ng=; b=EBLGp9oYuDtj62UTVV2hLJ1kHY9AgixhJxpdRyI49yUzqxUtpUVPciemFbXgUtBWsFCp3nf4rGmmqyyJBBpyL2L3IjTtXnC3VEbQuGcFH6n6rEy+lQfei3piRd6rCdBAmOyfgnps3y5PU+DgJHVsUxHqhpLxI+e73Am5+0mVjmM= Received: from DM5PR09MB1307.namprd09.prod.outlook.com (10.172.34.141) by DM5PR09MB1307.namprd09.prod.outlook.com (10.172.34.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 18 Oct 2017 14:51:57 +0000 Received: from DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) by DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) with mapi id 15.20.0077.022; Wed, 18 Oct 2017 14:51:56 +0000 From: "Banghart, Stephen A. (Fed)" To: Martin Thomson CC: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Thread-Topic: [mile] Artart last call review of draft-ietf-mile-rolie-10 Thread-Index: AQHTQLy5EiZhxIKVNkSNg/Bn547ThKLoNUiggADmG4CAAJ+WMA== Date: Wed, 18 Oct 2017 14:51:56 +0000 Message-ID: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.220.117] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR09MB1307; 6:d5V8iCnu2+Hi82wqMflkoZmt5TDqYTwyS/WvHXD6yhROi5hg6RpiPSDdJHtIJcF/iHVBJi+VCl3t2X60NVnfqLdvEfk8jNWizyh8WvOiJGXJXZDmoPvWk49Z6Vxw+iXc6btJQzRw4q0leGCxcbMjYUv76e5g6ViRgiUM2WzM0bOzvGOHOSOBS5VqsW9MdYZ6/jA5WjP04698z5EZ6DoM01/OwQPxfPZO9gAP6f1n0RuypZIDfhw9/Ij4PsT3gpaacWebqcnhhMaQyTT1W4yIygF/YodC19LmND7mH95knsQoJ7/w/VrqezOPASZGMlwvIFwY9QM8I9CvQ48su9eyog==; 5:oadVTxAWacZmYPYjb9pE23cDDuyDHvwRppIfR8qs3P7Vyk4w1//ddQy8V/jp4MSER6Mszl8T0/uTL4YVNTENBpuRhHh6YZinG+PlmrKfeYNmW+YKohp6KownNSWHM7tFCsHSVOLYKoY1uV7xegL63Q==; 24:qsA/ModDL8bmcKSH178MkOSJBHWBNaOJEh/8gyMC+ohieV7XhadjD7/yMCWt7XuLFhRpyo6VX/saqLE+lA4MhRVjtUJuulGtsPOUM+id214=; 7:D5nrNKOOof3nR3iVR79ybnDB4Z1P6RDlBlv/y2O69XQItNvEd6LagROhSOchSwE7yFJ1jYGKs9bSUosZnfyLlUgEz57vGBIjZeIoVeT2Ral6ul8Fdg9QJYNfGahk9V8GHYjakoXsuVco9+snwaRhUdsp3NgSWOg7ou1Ny9MV6m+lx+Vnn6ttFSl0LoTQbADy723fRqe6URej3jmatFrKE5tWhUB7flyvrn2ez2Cqjyo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e6816c17-b849-4b2a-ad65-08d51637c78a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR09MB1307; x-ms-traffictypediagnostic: DM5PR09MB1307: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(192374486261705)(189930954265078)(131327999870524)(150554046322364)(788757137089)(219752817060721); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR09MB1307; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR09MB1307; x-forefront-prvs: 0464DBBBC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(43784003)(3905003)(51914003)(55674003)(51444003)(24454002)(13464003)(199003)(189002)(377454003)(5660300001)(50986999)(76176999)(54356999)(105586002)(106356001)(74316002)(2906002)(229853002)(230783001)(6506006)(2950100002)(8676002)(3660700001)(316002)(81166006)(54906003)(3280700002)(8936002)(305945005)(77096006)(6916009)(81156014)(101416001)(7736002)(14454004)(33656002)(53546010)(6306002)(9686003)(3846002)(53936002)(53946003)(102836003)(99286003)(6116002)(7696004)(966005)(189998001)(66066001)(25786009)(2900100001)(86362001)(4326008)(478600001)(6436002)(6246003)(39060400002)(55016002)(68736007)(97736004)(45080400002)(575784001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1307; H:DM5PR09MB1307.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2017 14:51:56.6591 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1307 Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171018145203.26CEE132CE7@ietfa.amsl.com> Resent-Date: Wed, 18 Oct 2017 07:52:03 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 14:52:03 -0000 TWFydGluLA0KDQpUaGFua3MgZm9yIHRydW5jYXRpbmcgdGhlIGV4dHJhIG1haWxpbmcgbGlzdHMu DQoNClRoZSBjbGllbnQgYXV0aG9yaXphdGlvbiByZXF1aXJlbWVudHMgaW4gUk9MSUUgYXJlIGlu dGVuZGVkIHRvIGJlIGltcGxlbWVudGF0aW9uIHJlcXVpcmVtZW50cyBhbmQgbm90IHVzZSByZXF1 aXJlbWVudHMsIHdoaWNoIEkgdGhpbmsgaXMgY2F1c2luZyBzb21lIG9mIHRoZSBjb25mdXNpb24u DQoNClVsdGltYXRlbHksIFJPTElFIHdpbGwgYmUgd2VhcmluZyBvbmUgb2YgdHdvIGhhdHMgaW4g dGhlIHdpbGQsIGEgc2VjdXJlIHNlY3VyaXR5IGluZm9ybWF0aW9uIGV4Y2hhbmdlIGZvciBDU0lS VHMgYW5kIHNoYXJpbmcgY29uc29ydGl1bXMsIGFuZCBhIHB1YmxpYyBmYWNpbmcgc2VjdXJpdHkg aW5mb3JtYXRpb24gZXhjaGFuZ2UgZm9yIHB1YmxpYyBkaXNjbG9zdXJlLiBJbiBvcmRlciBmb3Ig YSBnaXZlbiBpbXBsZW1lbnRhdGlvbiB0byBzdXBwb3J0IGJvdGggb2YgdGhlc2UgdXNlIGNhc2Vz IHN0cm9uZyB1c2VyIGF1dGhlbnRpY2F0aW9uIG5lZWRzIHRvIGJlIHN1cHBvcnRlZC9pbXBsZW1l bnRlZCwgYnV0IGluIG9yZGVyIHRvIHN1cHBvcnQgdGhlIHB1YmxpYyBmYWNpbmcgdXNlIGNhc2Us IHRoZXNlIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyBjYW4ndCBiZSByZXF1aXJlZCB0byBi ZSB0dXJuZWQgb24uDQoNCk91ciBnb2FsIHdhcyB0byBhdHRlbXB0IHRvIHN1cHBvcnQgYm90aCB1 c2UgY2FzZXMgaW4gYSB3YXkgdGhhdCAoaG9wZWZ1bGx5KSBkb2Vzbid0IGNvbXByb21pc2UgdGhl IGNvcmUgdXNhZ2Ugb2YgdGhlIG90aGVyIHVzZSBjYXNlLiBXZSB0cmllZCB0byBhbGxvdyB0aGUg cmVxdWlyZW1lbnRzIHRvIGJlIGFkanVkaWNhdGVkIG9uIGEgd29ya3NwYWNlIGJ5IHdvcmtzcGFj ZSBiYXNpcyBzbyBhIHNpbmdsZSBzaXRlIGNvdWxkIGJlIHRha2luZyBhZHZhbnRhZ2Ugb2YgYm90 aCB1c2UgY2FzZXMgc2ltdWx0YW5lb3VzbHkuDQoNCkkndmUgdGFrZW4geW91ciBzdWdnZXN0aW9u IHRvIGNsZWFuIHVwIHRoZSBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgc2VjdGlvbiBhbmQgcGFy dHMgb2YgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gYnkgcmVtb3Zpbmcgb3Vy IHJlaW52ZW50aW9uIG9mIHRoZSB3aGVlbCBhbmQgbGVhbmluZyBtb3JlIGhlYXZpbHkgb24gcmVm ZXJlbmNpbmcgb3RoZXIgUkZDcyBmb3IgYmVzdCBwcmFjdGljZXMsIGl0J3MgcG9zc2libGUgdGhh dCB0aGUgY2xlYW5lZCB1cCB0ZXh0IGNvbnRyYWRpY3RzIGl0c2VsZiBsZXNzIGFuZCBtaXRpZ2F0 ZXMgdGhlIGlzc3VlLiBQZXJoYXBzIG1vcmUgZXhwbGFuYXRvcnkgdGV4dCBhcm91bmQgdGhlc2Ug dHdvIGNvcmUgdXNlIGNhc2VzIGluIHRoZSBhdXRoZW50aWNhdGlvbiBzZWN0aW9uIHdvdWxkIGhl bHAgdG9vPw0KDQpUaGFua3MsDQpTdGVwaGVuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5j b21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxOCwgMjAxNyAxOjAzIEFNDQo+IFRvOiBC YW5naGFydCwgU3RlcGhlbiBBLiAoRmVkKSA8c3RlcGhlbi5iYW5naGFydEBuaXN0Lmdvdj4NCj4g Q2M6IG1pbGVAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbWlsZS1yb2xpZS5hbGxAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFttaWxlXSBBcnRhcnQgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRm LW1pbGUtcm9saWUtMTANCj4gDQo+ICgtaWV0ZkAgYW5kIGFydEAgdG8gc2F2ZSB0aG9zZSBpbmJv eGVzKQ0KPiANCj4gSGkgU3RlcGhlbiwNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0aW9u LiAgSSBzb21ld2hhdCBleHBlY3RlZCB0aGF0IHRoaXMgd291bGQgYmUgdGhlIHVzZQ0KPiBjYXNl LCBidXQgSSBjb3VsZG4ndCByZWNvbmNpbGUgdGhhdCB3aXRoIHRoZSBsb25nIGxpc3Qgb2YgcmVx dWlyZW1lbnRzIGZvciBjbGllbnQNCj4gYXV0aGVudGljYXRpb24uICBDYW4geW91IGdvIGludG8g c29tZSBtb3JlIGRldGFpbCBhYm91dCB0aGF0IGFzIHdlbGw/ICBIYXBweQ0KPiB0byBoYXNoIHRo YXQgb3V0IGhlcmUgKEknbSBub3Qgc3Vic2NyaWJlZCB0byBtaWxlQCB0aG91Z2gpLg0KPiANCj4g SWYgdGhlIGludGVudCBpcyB0byBoYXZlIHRoZSBpbmZvcm1hdGlvbiBmb3IgYSB3ZWIgc2l0ZSAo YXMgb3Bwb3NlZCB0byB0aGUNCj4gb3JnYW5pemF0aW9uKSBhY2Nlc3NpYmxlIGluIGEgbG9jYXRp b24gdGhhdCBjYW4gYmUgcmVhZGlseSBmb3VuZCwgdGhlbiBJIHRoaW5rDQo+IHRoYXQgeW91IGhh dmUganVzdGlmaWNhdGlvbiBmb3IgdXNpbmcgLndlbGwta25vd24gZm9yIHRoZSBzZXJ2aWNlIGRv Y3VtZW50Lg0KPiBUaGUgY2F0ZWdvcnkgZG9jdW1lbnQgY2FuIGJlIGxpbmtlZCBmcm9tIHRoZSBz ZXJ2aWNlIGRvY3VtZW50LCBzbyBJIHRoaW5rIGl0DQo+IHdvdWxkIGJlIGJlc3QgaWYgeW91IGRp ZCByZW1vdmUgdGhhdCAud2VsbC1rbm93biByZWdpc3RyYXRpb24uICBZb3UgbWlnaHQNCj4gYWxz byBjb25zaWRlciB1c2luZyBzaW1wbHkgLndlbGwta25vd24vcm9saWUgb25jZSB5b3UgaGF2ZSBq dXN0IG9uZQ0KPiByZXNvdXJjZS4NCj4gDQo+IE9uIFdlZCwgT2N0IDE4LCAyMDE3IGF0IDM6MTgg QU0sIEJhbmdoYXJ0LCBTdGVwaGVuIEEuIChGZWQpDQo+IDxzdGVwaGVuLmJhbmdoYXJ0QG5pc3Qu Z292PiB3cm90ZToNCj4gPiBNYXJ0aW4sDQo+ID4NCj4gPiBUaGFua3MgZm9yIHRoZSBncmVhdCBy ZXZpZXcuIFdlJ3ZlIGJlZW4gd29ya2luZyB0aHJvdWdoIHlvdXIgY29tbWVudHMNCj4gYW5kIHBy ZXBhcmluZyBhIC0xMSB2ZXJzaW9uLiBJJ2xsIGhhdmUgYSBmdWxsIHJlc3BvbnNlIHRvIHlvdXIg Y29tbWVudHMgb3V0IHRvDQo+IHRoZSBsaXN0IG9uY2Ugd2UndmUgY29tcGxldGVkIGFkZHJlc3Np bmcgdGhlbSBhbGwsIGJ1dCB3YW50ZWQgdG8gb3BlbiBhDQo+IGRpc2N1c3Npb24gb24gYSBmZXcg cG9pbnRzIGluIHRoZSBtZWFudGltZS4NCj4gPg0KPiA+IFRoZSAud2VsbC1rbm93biByZWdpc3Ry YXRpb24gZm9yIC9zZXJ2aWNlZG9jdW1lbnQgaGFzIGEgdXNlDQo+IGNhc2UvZGlzY292ZXJ5IHN0 b3J5IHRoYXQgd2UgZmVlbCBpcyBpbXBvcnRhbnQgZW5vdWdoIGZvciByZWdpc3RyYXRpb24sIG9y IGF0DQo+IGxlYXN0IGZvciBzdGFuZGFyZGl6YXRpb24uIEluIHRoZSBjYXNlIHdoZXJlIHRoZXJl IGlzIG5vIHN0YW5kYXJkaXplZCBsb2NhdGlvbg0KPiB0ZW1wbGF0ZSBmb3IgdGhlIHNlcnZpY2Ug ZG9jdW1lbnQsIGEgdmVuZG9yL2NvbXBhbnkvc2l0ZSB0aGF0IHdhbnRzIHRvDQo+IHN0YW5kIHVw IGEgUk9MSUUgcmVwb3NpdG9yeSBhbmQgcHJvdmlkZSByZWd1bGFyIHN5bmRpY2F0ZWQgaW5mb3Jt YXRpb24gbXVzdA0KPiBwcm92aWRlIGEgbGluayB0byB0aGUgc2VydmljZSBkb2N1bWVudCBzb21l d2hlcmUgb24gdGhlaXIgcmVndWxhciBzaXRlLCBvcg0KPiBvdGhlcndpc2UgZGlzdHJpYnV0ZSB0 aGUgVVJMLiBXaGlsZSB0aGlzIHBvdGVudGlhbGx5IHByb3ZpZGVzIGEgbWVhbnMgZm9yDQo+IGh1 bWFucyB0byBmaW5kIHRoZSByZXBvc2l0b3J5IChhbHRob3VnaCB0aGUgbGluayB3b3VsZCBsaWtl bHkgYmUgaGlkZGVuIGluDQo+IHNvbWUgc3RyYW5nZSBwbGFjZSksIGl0IGRvZXNuJ3QgaGVscCBh dXRvbWF0ZWQgdG9vbHMgbG9jYXRlIHRoZSByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gQXMgYSB1c2Vy IG9mIFJPTElFLCBJJ2QgbGlrZSB0byBiZSBhYmxlIHRvIHByb3ZpZGUgYSB0b29sIHdpdGggdGhl DQo+IGhvc3RuYW1lOnBvcnQgb2YgYSB2ZW5kb3Igd2hvc2Ugc3luZGljYXRlZCBpbmZvcm1hdGlv biBJJ2QgbGlrZSB0byByZWNlaXZlLA0KPiBhbmQgaGF2ZSB0aGUgdG9vbCByZXR1cm4gdGhlIHN0 YXR1cyBvZiBhbnkgcmVwb3NpdG9yeSB0aGF0IGlzIG9yIGluIG5vdCBob3N0ZWQNCj4gYnkgdGhh dCB0b3AgbGV2ZWwgc2l0ZS4gRm9yIGV4YW1wbGUsIEknZCBsaWtlIHRvIGdpdmUgYSB0b29sDQo+ ICJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD13d3cu bWljcm9zb2Z0LmNvbSZkDQo+IGF0YT0wMiU3QzAxJTdDc3RlcGhlbi5iYW5naGFydCU0MG5pc3Qu Z292JTdDYmE0NmFhZmViZTczNGIzZjY4MDUwDQo+IDhkNTE1ZTU5MjQ2JTdDMmFiNWQ4MmZkOGZh NDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjQzODkNCj4gOTgxMDc2MDczMzcmc2Rh dGE9V00weHNyc1BIY0w1Mm9VODJDOFZsRmxWS1lIZVRkWm9tVER4NldRZ0pZcyUNCj4gM0QmcmVz ZXJ2ZWQ9MCIgYW5kIGhhdmUgaXQgcHJvdmlkZSBtZSBhbGwgdGhlIFJPTElFIChhbmQgbm9uLVJP TElFDQo+IEF0b21QdWIgaWYgcHJvdmlkZWQgaW4gdGhlIHNhbWUgU2VydkRvYykgQ29sbGVjdGlv bnMgcHJvdmlkZWQgYnkgdGhhdCBob3N0Lg0KPiBXaXRob3V0IGEgLndlbGwta25vd24gcmVnaXN0 cmF0aW9uLCB0aGUgc3RhbmRhcmQgd291bGQgaGF2ZSB0byBwcm92aWRlIGENCj4gZGVmaW5lZCBu b24tLy53ZWxsLWtub3duIFVSTCB0ZW1wbGF0ZSBsb2NhdGlvbiwgd2hpY2ggd2UgZmVsdCB3YXMg YmFkDQo+IHByYWN0aWNlLg0KPiA+DQo+ID4gSXRzIGxpa2VseSB0aGF0IHRoZSBzdGFuZGFyZCBk b2Vzbid0IHByb3ZpZGUgZW5vdWdoIGNvbnRleHQgYXJvdW5kIHRoZQ0KPiAvLndlbGwta25vd24g cmVnaXN0cmF0aW9uLCBhbmQgdGhhdCBhZGRpbmcgbW9yZSBleHBsYW5hdG9yeSB0ZXh0IGFyb3Vu ZCBvdXINCj4gZGlzY292ZXJ5IHN0b3J5IHdvdWxkIGhlbHAgbWFrZSB0aGUgbmVlZCBmb3IgYSBV UkwgdGVtcGxhdGUgbW9yZSBjbGVhci4NCj4gPg0KPiA+IElmIHRoZSBpc3N1ZSBpcyB3aXRoIHRo ZSB1c2Ugb2YgLy53ZWxsLWtub3duLCBhbmQgbm90IHdpdGggdGhlIHN0YW5kYXJkaXplZA0KPiBV UkwgdGVtcGxhdGUsIHdlIGNvdWxkIHNpbXBseSByZW1vdmUgdGhlIC53ZWxsLWtub3duIHJlZ2lz dHJhdGlvbiBhbmQNCj4gaW5zdGVhZCBwcm92aWRlIGEgbm9uLXJlZ2lzdGVyZWQgcmVxdWlyZW1l bnQgZm9yIGENCj4ge2hvc3R9L3JvbGllL3NlcnZpY2Vkb2N1bWVudCBVUkwgdGVtcGxhdGUuDQo+ ID4NCj4gPiBXZSBhZ3JlZSB0aGF0IHRoZSBkaXNjb3Zlcnkgc3RvcnkgZm9yIC9jYXRlZ29yeWRv Y3VtZW50IGlzIGRlY2lkZWRseQ0KPiB3ZWFrZXIsIGFzIGFueSBvdXQtb2YtbGluZSBjYXRlZ29y eSBkb2N1bWVudHMgd291bGQgYmUgbGlua2VkIHRvIGZyb20gdGhlDQo+IFNlcnZpY2UgRG9jdW1l bnQuIFdlIHdvdWxkIG9wZW4gdG8gZHJvcHBpbmcgdGhpcw0KPiByZWdpc3RyYXRpb24vcmVxdWly ZW1lbnQgb3V0cmlnaHQgYXMgeW91IHN1Z2dlc3QuDQo+ID4NCj4gPiBUaGFua3MgYWdhaW4gZm9y IHRoZSB0aG9yb3VnaCByZXZpZXcsDQo+ID4gU3RlcGhlbiBCYW5naGFydA0KPiA+DQo+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IG1pbGUgW21haWx0bzptaWxlLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gVGhvbXNvbg0KPiA+PiBTZW50OiBN b25kYXksIE9jdG9iZXIgMDksIDIwMTcgMTowOCBBTQ0KPiA+PiBUbzogYXJ0QGlldGYub3JnDQo+ ID4+IENjOiBtaWxlQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBkcmFmdC1pZXRmLW1pbGUtcm9s aWUuYWxsQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFttaWxlXSBBcnRhcnQgbGFzdCBjYWxsIHJl dmlldyBvZiBkcmFmdC1pZXRmLW1pbGUtcm9saWUtMTANCj4gPj4NCj4gPj4gUmV2aWV3ZXI6IE1h cnRpbiBUaG9tc29uDQo+ID4+IFJldmlldyByZXN1bHQ6IEFsbW9zdCBSZWFkeQ0KPiA+Pg0KPiA+ PiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCwgYW5kIC0gZGVzcGl0ZSB3aGF0IGFwcGVh cnMgdG8gYmUgYQ0KPiA+PiBsZW5ndGh5IGxpc3Qgb2YgaXNzdWVzIC0gSSB0aGluayB0aGF0IGl0 IGlzIGluIHByZXR0eSBnb29kIHNoYXBlLg0KPiA+PiBJdCdzIGNsZWFyLCByZWFkYWJsZSwgYW5k IGFkZHJlc3NlcyB0aGUgcmVxdWlyZW1lbnRzIHdlbGwuICBNb3N0IG9mDQo+ID4+IG15IGNvbW1l bnRzIHNob3VsZCBiZSB0cml2aWFsIHRvIHJlc29sdmUuDQo+ID4+DQo+ID4+IE1ham9yOg0KPiA+ Pg0KPiA+PiBUaGUgZGVjaXNpb24gdG8gZGVmaW5lIGEgLndlbGwta25vd24gVVJJIHdpdGhvdXQg YSBkaXNjb3Zlcnkgc3RvcnkgaXMNCj4gPj4gLSBpbiBteSBvcGluaW9uIC0gaW5hZHZpc2FibGUu ICBTdWNoIGEgcmVnaXN0cmF0aW9uIGlzIHVzdWFsbHkNCj4gPj4gYXBwcm9wcmlhdGUgaWYgeW91 IGRlc2lnbiBhIHByb3RvY29sIHRoYXQgZGVwZW5kcyBvbiBkaXNjb3ZlcnkgYnkNCj4gPj4gaG9z dG5hbWUgYW5kIHBvcnQuICBBcyBzdWNoLCB0aGlzIGRvZXMgbm90IHVzZSB0aGF0IGF0IGFsbC4g IEENCj4gPj4gY29uZmlndXJhdGlvbiBzeXN0ZW0gY2FuIChhbmQgc2hvdWxkKSBhY2NlcHQgYSBj b21wbGV0ZSBVUkkgZm9yIHRoZQ0KPiA+PiBzZXJ2aWNlIGVuZHBvaW50LiAgSXQgd291bGQgYmUg YmV0dGVyIHRvIGRlZmVyIGNyZWF0aW9uIG9mIHlldA0KPiA+PiBhbm90aGVyIC53ZWxsLWtub3du IFVSSSByZWdpc3RyYXRpb24gdW50aWwgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgY2VydGFpbg0KPiB0 aGF0IGRpc2NvdmVyeSByZXF1aXJlcyBpdC4NCj4gPj4NCj4gPj4gVGhlIHNhbWUgY29tbWVudCBh cHBsaWVzIHRvIHRoZSAud2VsbC1rbm93biByZXNvdXJjZSBmb3IgdGhlIGNhdGVnb3J5DQo+ID4+ IGRvY3VtZW50Lg0KPiA+PiAgR2l2ZW4gdGhhdCB0aGlzIHNvcnQgb2YgZG9jdW1lbnQgaXMgcmVh ZGlseSBkaXNjb3ZlcmFibGUgdmlhIHRoZQ0KPiA+PiBzZXJ2aWNlIGRvY3VtZW50LCBJIHdvdWxk IHNheSB0aGF0IHRoZSBuZWVkIGZvciBhIC53ZWxsLWtub3duDQo+ID4+IHJlc291cmNlIGlzIGxl c3Mgd2VsbC0ganVzdGlmaWVkIHRoYW4gdGhlIHNlcnZpY2UgZG9jdW1lbnQuDQo+ID4+DQo+ID4+ IFRoZSByZXF1aXJlbWVudHMgaW4gU2VjdGlvbiA1LjMgb24gVExTIHVzZSBhcmUgdW5uZWNlc3Nh cmlseSBzdHJpY3QuDQo+ID4+IEl0J3MgZ3JlYXQgdG8gcmVjb21tZW5kIHRoZSB1c2Ugb2YgVExT IDEuMiwgYnV0IGdpdmVuIHRoYXQgdGhlDQo+ID4+IGRvY3VtZW50IGhhcyBubyByZWFsIHJlcXVp cmVtZW50IG9uIGFueSBwYXJ0aWN1bGFyIHZlcnNpb24gb2YgVExTLA0KPiA+PiB0aGUgdXNlIG9m ICJNVVNUIiBoZXJlIGlzIG5vdCBuZWVkZWQuICBTaW1pbGFybHksIHRoZSBwcm9oaWJpdGlvbiBv bg0KPiA+PiB0aGUgdXNlIG9mIDAtUlRUIGlzIGdyb3VuZGxlc3MuICBUaGUgbGVuZ3RoeSBsaXN0 IG9mIHJlcXVpcmVtZW50cw0KPiA+PiBhcm91bmQgY2VydGlmaWNhdGUgdmFsaWRhdGlvbiBvbmx5 IHJpc2sgY3JlYXRpbmcgYSBjb25mbGljdCB3aXRoDQo+ID4+IGFkdmljZSBpbiBvdGhlciBSRkNz LiAgTWFueSwgaWYgbm90IGFsbCwgb2YgdGhlc2UgcmVxdWlyZW1lbnRzIGFyZQ0KPiA+PiB0cmFu c2l0aXZlbHkgaW5jbHVkZWQgYnkgd2F5IG9mIHJlZmVyZW5jaW5nIEhUVFBTIGRvY3VtZW50cy4g IEkgd291bGQNCj4gcHJlZmVyIHRvIHNlZSB0aGlzIGVudGlyZSBzZWN0aW9uIHJlZHVjZWQgdG8g YSBzaW1wbGUgUkZDIDc1MjUgcmVmZXJlbmNlLg0KPiA+Pg0KPiA+PiBVc2VyIGF1dGhlbnRpY2F0 aW9uIGlzIHVuZGVyLXNwZWNpZmllZC4NCj4gPj4NCj4gPj4gKiBTZWN0aW9uIDUuMyBtYW5kYXRl cyB0aGUgdXNlIG9mIFRMUyBjaXBoZXIgc3VpdGVzIHRoYXQgc3VwcG9ydA0KPiA+PiBjbGllbnQg YXV0aGVudGljYXRpb24gdXNpbmcgY2VydGlmaWNhdGVzLCBidXQgb2ZmZXJzIG5vIGZ1cnRoZXIN Cj4gPj4gYWR2aWNlLiAgQXNpZGUgZnJvbSBiZWluZyBhbiB1bm5lY2Vzc2FyeSByZXF1aXJlbWVu dCAtIGNpcGhlciBzdWl0ZXMNCj4gPj4gdGhhdCBzdXBwb3J0IGNlcnRpZmljYXRlLSBiYXNlZCBh dXRoZW50aWNhdGlvbiBvZiBzZXJ2ZXJzIGFsbCBhbGxvdw0KPiA+PiBmb3IgY2xpZW50IGF1dGhl bnRpY2F0aW9uIC0gdGhpcyBzb3J0IG9mIHJlcXVpcmVtZW50IGlzIHJhcmVseQ0KPiA+PiBzdWZm aWNpZW50IGZvciBpbnRlcm9wZXJhdGlvbi4gIEZvciBpbnN0YW5jZSwgeW91IG5lZWQgdG8gc3Bl Y2lmeSBob3cNCj4gPj4gYSBzZXJ2ZXIgd2lsbCByZXF1ZXN0IGEgY2VydGlmaWNhdGUgc3VjaCB0 aGF0IGNsaWVudHMgY2FuIHNlbGVjdCB0aGUNCj4gPj4gY29ycmVjdCBjZXJ0aWZpY2F0ZS4gIElm IGEgY2xpZW50IGFuZCBzZXJ2ZXIgaGF2ZSBhZ3JlZWQgdG8gc2hhcmUNCj4gPj4gaW5mb3JtYXRp b24gb24gdGVybXMgdGhhdCByZWx5IG9uIGF1dGhlbnRpY2F0aW9uIG9mIGNsaWVudHMsIGl0IGlz IGJldHRlciBmb3INCj4gdGhvc2UgcGVlcnMgdG8gYXJyYW5nZSB0aGUgdGVybXMgb24gd2hpY2gg dGhleSB3aWxsIGF1dGhlbnRpY2F0ZS4NCj4gPj4NCj4gPj4gKiBTZWN0aW9uIDUuNCB1c2VzICJT SE9VTEQiIHJlZ2FyZGluZyBjbGllbnQgYXV0aGVudGljYXRpb24gdXNpbmcNCj4gPj4gZmVkZXJh dGlvbiwgYnV0IG9mZmVycyBubyBoaW50cyBhYm91dCB3aGF0IHRoaXMgZW50YWlscy4gIEl0IGFs c28NCj4gPj4gdXNlcyAiU0hPVUxEIiByZWdhcmRpbmcgYXV0aG9yaXphdGlvbiBjaGVja3MsIHdo aWNoIGlzbid0IGFuDQo+ID4+IGludGVyb3BlcmFiaWxpdHkgcmVxdWlyZW1lbnQuICBJdCdzIG1v cmUgb2YgYSAiZG9uJ3QgYmUgc2lsbHkiIHR5cGUNCj4gPj4gb2YgcmVxdWlyZW1lbnQsIHdoaWNo IGRvZXNuJ3QgbmVlZCB0byBiZSB3cml0dGVuIGRvd24gaW4gYW4gUkZDLg0KPiA+Pg0KPiA+PiBT ZWN0aW9uIDUuNSBwcm9oaWJpdHMgdGhlIHVzZSBvZiBHRVQgb24gIi8iLiAgVGhpcyBwcm9oaWJp dHMgdXNlIG9mDQo+ID4+IHRoZSByZXNvdXJjZSBmb3Igb3RoZXIgcHVycG9zZXMuICBJdCBzZWVt cyByZWFzb25hYmxlIHRvIGFjY2VwdCBQT1NUDQo+ID4+IG1lc3NhZ2VzIGFzIGRlZmluZWQgaW4g UkZDIDY1NDYsIGJ1dCB0aGlzIHJlcXVpcmVtZW50IGlzIG92ZXJseQ0KPiA+PiBzdHJpY3QgKGFu ZCBmdXJ0aGVyIGVudHJlbmNoZXMgdGhlIHZpb2xhdGlvbiBvZiBSRkMgNzMyMCkuICBJZiwgZm9y DQo+ID4+IGluc3RhbmNlLCB0aGUgc2VydmVyIG9wZXJhdG9yIHdpc2hlcyB0byBwcm92aWRlIEhU TUwgaW4gcmVzcG9uc2UgdG8gYQ0KPiA+PiBHRVQgcmVxdWVzdCB0byAiLyIsIHRoaXMgd291bGQg cHJvaGliaXQgdGhhdC4gIFRoZSByZXF1aXJlbWVudCB0bw0KPiA+PiByZXR1cm4gNDA0IGlmIFJG QyA2NTQ2IGlzIG5vdCBzdXBwb3J0ZWQgaXMgd29yc2U7IG5vdCBzdXBwb3J0aW5nIFJGQw0KPiA+ PiA2NTQ2IG1pZ2h0IGJlIGEgY2hvaWNlIHRoYXQgYSBkZXBsb3ltZW50IG1ha2VzIHRvIGF2b2lk IHRoZSBuZWVkIHRvDQo+IHJlc2VydmUgIi8iIGZvciB0aGF0IHByb3RvY29sLg0KPiA+Pg0KPiA+ PiBJbiBTZWN0aW9uIDYuMi4zLCB3aGF0IGlzIHRoZSBhZHZhbnRhZ2Ugb2YgInJvbGllOmZvcm1h dCIgb3ZlciBoYXZpbmcNCj4gPj4gYSB3ZWxsLSBkZWZpbmVkIG1lZGlhIHR5cGU/ICBNZWRpYSB0 eXBlcyBjYW4gdGFrZSBhZHZhbnRhZ2Ugb2YNCj4gPj4gY29udGVudCBuZWdvdGlhdGlvbiwgZXhp c3Rpbmcgc3VwcG9ydCBpbiBsaW5rIHJlbGF0aW9ucywgYW5kIG90aGVyIGV4aXN0aW5nDQo+IHRv b2xzLg0KPiA+PiBUaGlzIHJvbGllOmZvcm1hdCBlbGVtZW50IGhhcyBuYW1lc3BhY2UsIGZvcm1h dCwgYW5kIHNjaGVtYTsgdGhlc2UNCj4gPj4gYXJlIG5vdCB1c2VmdWwgdG8gYW55b25lIHRoYXQg aXMgaWdub3JhbnQgb2YgdGhlaXIgY29udGVudHMuICBUaGUNCj4gPj4gb25seSBhZHZhbnRhZ2Ug SSBzZWUgaXMgdGhhdCBzeW50YXggbWlnaHQgYmUgdmFsaWRhdGVkLCBidXQgc2VtYW50aWNzDQo+ ID4+IGNhbid0IGJlIGV4dHJhY3RlZC4gIFRoZXJlJ3MgYSBsb3Qgb2YgaW1wbGllZCB3b3JrIGlu IGFkZGluZyB0aGlzDQo+ID4+IGVsZW1lbnQsIGJ1dCB0aGF0IGRvZXNuJ3Qgc2VlbSB0byBiZSBq dXN0aWZpZWQgYnkgdGhhdCBhZHZhbnRhZ2UuICAoSQ0KPiA+PiBzZWUgdGhhdCBSRkMgNzk3MCBk b2Vzbid0IGRlZmluZSBhIG1lZGlhIHR5cGUsIGJ1dCBpdCBzZWVtcyBsaWtlIGl0DQo+ID4+IHdv dWxkIGJlIGVhc2llciB0byBjb3JyZWN0IHRoYXQgdGhhbiB0byBkZWZpbmUgYW4gZWxlbWVudCBs aWtlIHRoaXMuKQ0KPiA+Pg0KPiA+PiBTZWN0aW9uIDYuMi40IGRlZmluZXMgYSBnZW5lcmljIGtl eS12YWx1ZSBtZWNoYW5pc20uICBCdXQgdGhhdCBpcw0KPiA+PiBzb21ldGhpbmcgdGhhdCBYTUwg aXMgYWN0dWFsbHkgZ29vZCBhdC4gIFdoeSBjYW4ndCB1c2VycyB0aGF0IHJlcXVpcmUNCj4gPj4g YWRkaXRpb25hbCBtZXRhZGF0YSB1c2UgYWRkaXRpb25hbCBtZXRhZGF0YSBhcyBvcmlnaW5hbGx5 IGRlZmluZWQgYnkNCj4gPj4gQXRvbT8gIFRoYXQgaXMsIHJlcGxhY2UgPHJvbGllOnByb3BlcnR5 DQo+IG5hbWU9InVybjppZXRmOnBhcmFtczpyb2xpZTpwcm9wZXJ0eTpjc2lydC1pb2RlZi1pZCIN Cj4gPj4gdmFsdWU9IjEyMzQ1Ii8+IHdpdGggc29tZXRoaW5nIGxpa2UNCj4gPj4gPHJvbGllOmNz aXJ0LWlvZGVmLWlkPjEyMzQ1PC9yb2xpZTpjc2lydC1pb2RlZi1pZD4uICBUaGUgZmluYWwNCj4g Pj4gcGFyYWdyYXBoIG9mIHRoZSBzZWN0aW9uIHJlY29nbml6ZXMgdGhpcyBwb3NzaWJpbGl0eS4N Cj4gPj4NCj4gPj4gTWlub3I6DQo+ID4+DQo+ID4+IFNlY3Rpb24gNS4xLjEgcmVjb21tZW5kcyB0 aGUgdXNlIG9mIHdvcmtzcGFjZXMgdG8gc2VwYXJhdGUgInByaXZhdGUiDQo+ID4+IGFuZCAicHVi bGljIiBpbmZvcm1hdGlvbi4gIEJ1dCB3b3Jrc3BhY2VzIGRvbid0IHJlYWxseSBjb250YWluIGVu b3VnaA0KPiA+PiBpbmZvcm1hdGlvbiB0byBzaWduYWwgdGhlaXIgc3RhdHVzIHRvIGEgY29uc3Vt ZXIgb2YgdGhlIGluZm9ybWF0aW9uLg0KPiA+PiBJIHdvdWxkIHN1Z2dlc3QgbWVudGlvbmluZyB0 aGlzLCByZW1vdmluZyB0aGUgcmVjb21tZW5kYXRpb24sIG9yDQo+ID4+IGV4cGFuZGluZyBvbiB0 aGUgbWFubmVyIGluIHdoaWNoIHRoZSBzdGF0dXMgb2YgaW5mb3JtYXRpb24gaXMgc2lnbmFsZWQu DQo+ID4+DQo+ID4+IFNlY3Rpb24gNi4xLjEgc2F5cyAiemVybyBvciBtb3JlIGF0b206Y2F0ZWdv cnkgZWxlbWVudHMiLCBidXQgdGhpcw0KPiA+PiBjb250cmFkaWN0cyB0aGUgdGV4dCBhbmQgYW1l bmRtZW50IHRvIHRoZSBzY2hlbWEgaW4gU2VjdGlvbiA2LjEuDQo+ID4+DQo+ID4+IFNlY3Rpb24g Ni4xLjMgcmVxdWlyZXMgdXBkYXRpbmcgdGhlICJhdG9tOnVwZGF0ZWQiIGVsZW1lbnQgd2hlbiB0 aGUNCj4gPj4gcmVwcmVzZW50YXRpb24gY2hhbmdlcy4gIEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlz IGlzIHdoYXQgd2FzDQo+ID4+IGludGVuZGVkLiAgSSB0aGluayB0aGF0IHRoZSBlbGVtZW50IG5l ZWRzIHRvIGJlIHVwZGF0ZWQgd2hlbiB0aGUNCj4gPj4gY29udGVudHMgb2YgdGhlIGZlZWQgY2hh bmdlIGluIGFueSB3YXkuDQo+ID4+DQo+ID4+IFF1ZXN0aW9uOiBpdCdzIGZhaXJseSB3aWRlbHkg YWNjZXB0ZWQgdGhhdCB1c2Ugb2YgSVJJcyBpbiBBdG9tIGhhcw0KPiA+PiBiZWVuIGxlc3MgdGhh biBzdWNjZXNzZnVsLiAgRG8geW91IHdhbnQgdG8gbWFuZGF0ZSB1c2Ugb2YgVVJJcw0KPiA+PiBp bnN0ZWFkPyAgVGhpcyB3b3VsZCBhcHBseSB0byBib3RoIGxpbmsgcmVsYXRpb25zIGFuZCB0aGUg InNyYyIgYXR0cmlidXRlLg0KPiA+Pg0KPiA+PiBJbiBTZWN0aW9uIDcuMSwgdGhlIGRlZmluaXRp b24gb2YgdGhlIG5hbWVzcGFjZSBwcmVmaXgNCj4gPj4gInVybjppZXRmOnBhcmFtczpyb2xpZTpj YXRlZ29yeTpsb2NhbCIgc2VlbXMgdW5uZWNlc3NhcnkuICBOYW1lc3BhY2UNCj4gPj4gVVJJcyBh cmUgY2hlYXAgYW5kIGl0IHNlZW1zIHJlYXNvbmFibGUgdG8gZXhwZXJpbWVudCB3aXRoIGZlZWRz IHRoYXQNCj4gPj4gcHJvZHVjZSBub24tUk9MSUUgaW5mb3JtYXRpb24gYnkgb21pdHRpbmcgdGhl DQo+ID4+ICJ1cm46aWV0ZjpwYXJhbXM6cm9saWU6Y2F0ZWdvcnk6aW5mb3JtYXRpb24tdHlwZSIN Cj4gPj4gY2F0ZWdvcnksIGV2ZW4gaWYgdGhhdCBmZWVkIG1pZ2h0IGNvbXBseSB3aXRoIHRoZSBy ZXF1aXJlbWVudHMgb2YgUk9MSUUuDQo+ID4+IFRoZSBvdGhlciB3YXkgdG8gZXhwZXJpbWVudCB3 b3VsZCBiZSB0byB1c2UgdGhlIGNhdGVnb3J5LCBidXQgZGVmaW5lDQo+ID4+IGEgd2F5IHRvIGlk ZW50aWZ5ICJ0ZXJtIiBhdHRyaWJ1dGVzIHRoYXQgYXJlIGZvciB1c2UgaW4gcHJpdmF0ZSBvcg0K PiA+PiBleHBlcmltZW50YWwgY29udGV4dHMuDQo+ID4+DQo+ID4+IEluIFNlY3Rpb24gNy40LCBo b3cgaXMgIi4uLjpyb2xpZTpwcm9wZXJ0eTpjb250ZW50LWF1dGhvci1uYW1lIg0KPiA+PiBzdXBl cmlvciB0byAiYXRvbTphdXRob3IiPw0KPiA+Pg0KPiA+PiBJbiBTZWN0aW9uIDguNCwgIGlzIHRo ZXJlIGEgdW5pcXVlbmVzcyByZXF1aXJlbWVudCBvbiAibmFtZSI/ICBJDQo+IHVuZGVyc3RhbmQN Cj4gPj4gdGhpcyB0byBiZSB0aGUgdGhpbmcgdGhhdCBiZWluZyByZWdpc3RlcmVkLiAgIEFzc3Vt aW5nIHRoYXQsIHdoYXQgcHVycG9zZQ0KPiA+PiBkb2VzDQo+ID4+IHRoZSAiaW5kZXgiIHNlcnZl Pw0KPiA+Pg0KPiA+PiBUaGlzIHN0YXRlbWVudCBmcm9tIFNlY3Rpb24gOSwgIkFzIGRlc2NyaWJl ZCBpbiB0aGUgZGlzY292ZXJ5DQo+ID4+IHNlY3Rpb24sIEROUyBTUlYgUmVjb3JkcyBhcmUgYSBw b3NzaWJsZSBzZWN1cmUgc29sdXRpb24gdG8NCj4gPj4gZGlzY292ZXJ5LiIgaXMgZmFsc2Ugd2l0 aG91dCBmdXJ0aGVyIHF1YWxpZmljYXRpb24uICBTUlYgd2l0aCBETlNTRUMNCj4gPj4gbWlnaHQg YmUgc2VjdXJlLCBidXQgYSBsb3QgZGVwZW5kcyBvbiB0aGUgaW5wdXQgdG8gdGhlIGRpc2NvdmVy eSBwcm9jZXNzDQo+IGFuZCBpdHMgcHJvdmVuYW5jZS4NCj4gPj4NCj4gPj4gSW4gU2VjdGlvbiAx MCwgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgaXMgZmFsc2UgKGFsbCBvZiB0aGUgZGVzY3JpYmVk DQo+ID4+IHByaXZhY3kgdmlvbGF0aW9ucyBhcmUgYXZhaWxhYmxlIHRvIGEgY2xpZW50IG9yIHNl cnZlciwgbm90IHRoaXJkDQo+ID4+IHBhcnRpZXMpOiAiUHJvcGVyIHVzYWdlIG9mIFRMUyBhcyBk ZXNjcmliZWQgaW4gU2VjdGlvbiA1LjMgd2lsbCBpbg0KPiA+PiBtYW55IGNhc2VzIGFpZCBpbiB0 aGUgbWl0aWdhdGlvbiBvZiB0aGVzZSBpc3N1ZXMuIiAgSSB0aGluayB0aGF0IHlvdQ0KPiA+PiBj YW4gc3RyaWtlIHRoaXMgc3RhdGVtZW50IChtb3N0IG9mIHRoZSByZWFzb24gZm9yIHVzZSBvZiBU TFMgaXMganVzdGlmaWVkIGJ5DQo+IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbnl3YXkp Lg0KPiA+Pg0KPiA+PiBOaXRzOg0KPiA+Pg0KPiA+PiBJcyBpdCAiRmVlZCIgb3IgImZlZWQiPyAg UkZDIDQyODcgdXNlcyB0aGUgbGF0dGVyLCBidXQgdGhpcyBkb2N1bWVudA0KPiA+PiBzZWVtcyB0 byBwcmVmZXIgdGhlIFByb3BlciBOb3VuIGZvcm0uDQo+ID4+DQo+ID4+IFNlY3Rpb24gNi4yIHNo b3VsZCBzYXkgd2hhdCBjaGFuZ2VkIGluIHRoZSBzY2hlbWEuICBJdCdzIGhhcmQgdG8NCj4gPj4g ZXllYmFsbCB0aGUgc2NoZW1hIHRvIGRpc2NvdmVyIHRoYXQgImF0b21Db250ZW50IiBpcyBubyBs b25nZXINCj4gPj4gb3B0aW9uYWwuICBUaGUgdHdvIG5ldyBlbGVtZW50cyBhcmUgZWFzeSB0byBz cG90IGFuZCBtaWdodCBjYXVzZSB0aGUNCj4gZmlyc3QgY2hhbmdlIHRvIGJlIG1pc3NlZC4NCj4g Pj4NCj4gPj4gU2VjdGlvbiA2LjIuMSBpcyB0aGUgc2FtZS4gIEl0IHNob3VsZCBleHBsaWNpdGx5 IHNheSB0aGF0IGl0IG9ubHkNCj4gPj4gcGVybWl0cyB0aGUgYXRvbU91dE9mTGluZUNvbnRlbnQg Zm9ybXVsYXRpb24uDQo+ID4+DQo+ID4+IEkgZm91bmQgdGhlIGZvcm11bGF0aW9uIG9mIFNlY3Rp b24gNy4xLjEgY29uZnVzaW5nLiAgSXQgaW5jbHVkZXMgYQ0KPiA+PiBsaXN0IHRoYXQgc2VlbXMg dG8gYmUgYXV0aG9yaXRhdGl2ZSwgdGhlbiBkaXNjbGFpbXMgYW55IGF0dGVtcHQgdG8NCj4gPj4g cmVnaXN0ZXIgdGhlc2UgdGVybXMuDQo+ID4+IE1heWJlIHRoaXMgaXMgYmVjYXVzZSB0aGUgc3Rh dGVtZW50ICJUaGlzIGRvY3VtZW50IGRvZXMgbm90IHNwZWNpZnkNCj4gPj4gYW55IGluZm9ybWF0 aW9uIHR5cGVzLiIgYXBwZWFycyB0b28gbGF0ZS4gIFNvbWUgcmVvcmRlcmluZyBtaWdodCBoZWxw Lg0KPiA+Pg0KPiA+PiBUaGUgZm9ybWF0dGluZyBvZiB0aGUgdGFibGUgaW4gU2VjdGlvbiA4LjMg bWFrZXMgbW9zdCBvZiB0aGUgY29sdW1ucw0KPiA+PiB1bnJlYWRhYmxlLiAgSSB3b3VsZCByZWNv bW1lbmQgYSBzaW1wbGUgbmVzdGVkIGxpc3QuDQo+ID4+DQo+ID4+IEluIHNlY3Rpb24gOSwgdGhl IHVzZSBvZiB0aGUgdGVybSAid2VsbC1rbm93biIgdG8gcmVmZXIgdG8NCj4gPj4gaW5mb3JtYXRp b24gdGhhdCBpcyBlaXRoZXIgcHVibGljIG9yIHdpZGVseSBhdmFpbGFibGUgcmlza3MgbWlzaW50 ZXJwcmV0YXRpb24uDQo+ID4+DQo+ID4+IEZXSVcsIEkgd291bGQgcmV3b3JkIHRoaXMgZW50aXJl IHBhcmFncmFwaCB0byBzYXkgc2ltcGx5ICJBY2Nlc3MNCj4gPj4gY29udHJvbCB0byBpbmZvcm1h dGlvbiBwdWJsaXNoZWQgdXNpbmcgUk9MSUUgc2hvdWxkIHVzZSBtZWNoYW5pc21zDQo+ID4+IHRo YXQgYXJlIGFwcHJvcHJpYXRlIHRvIHRoZSBzZW5zaXRpdml0eSBvZiB0aGUgaW5mb3JtYXRpb24u DQo+ID4+IFByaW1pdGl2ZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIGxpa2UgSFRUUCBCYXNp YyBBdXRoZW50aWNhdGlvbg0KPiA+PiBbUkZDNzYxN10gYXJlIHJhcmVseSBhcHByb3ByaWF0ZSBm b3Igc2Vuc2l0aXZlIGluZm9ybWF0aW9uLiIgIEkNCj4gPj4gZGlkbid0IGZpbmQgdGhlIHJlbWFp bmRlciBvZiB0aGUgdGV4dCBvbiBhdXRoZW50aWNhdGlvbiBlc3BlY2lhbGx5DQo+ID4+IGhlbHBm dWwuICBUaGUgdGV4dCBzZWVtcyB0byBlcXVpdm9jYXRlIG9uIHRoZSBzdWJqZWN0IG9mIGZlZGVy YXRpb24sDQo+IHdoZXJlIGl0IHdvdWxkIGJlIGVhc2llciB0byBzYXkgbm90aGluZy4NCj4gPj4N Cj4gPj4gQWxzbyBpbiBTZWN0aW9uIDksIHRoZSB1c2Ugb2YgdGhlIHRlcm0gIm1lc3NhZ2UiIGlz IHVzZWQgaW4gdGhlDQo+ID4+IGNvbnRleHQgb2YgdXNpbmcgYWRkaXRpb25hbCBzZWN1cml0eSBj b250cm9scy4gIEkgdGhpbmsgdGhhdCB0aGUgd29yZA0KPiA+PiAicmVwcmVzZW50YXRpb24iIGlz IHdoYXQgd2FzIGludGVuZGVkIGhlcmUuDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IG1pbGUgbWFpbGluZyBsaXN0DQo+ID4+ IG1pbGVAaWV0Zi5vcmcNCj4gPj4NCj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuDQo+ID4+IGkNCj4gZXRmLm9yZyUy Rm1haWxtYW4lMkZsaXN0aW5mbyUyRm1pbGUmZGF0YT0wMiU3QzAxJTdDc3RlcGhlbi5iYW5naGFy DQo+ID4+DQo+IHQlNDBuaXN0LmdvdiU3Q2FmM2FmOTFhMWM2ODQ1OTIwMDdkMDhkNTBlZDNkNDAx JTdDMmFiNWQ4MmZkOGZhNDc5Nw0KPiA+Pg0KPiBhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2 MzY0MzEyMjUzMjI4NDU4OTEmc2RhdGE9U3lrRWFzUWxvMWUNCj4gPj4gTWFyWW1LWFNBNUhzT1Vw VEx5amQ5cnNseXZaUHB4YWslM0QmcmVzZXJ2ZWQ9MA0K From nobody Wed Oct 18 15:41:35 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DEE132705; Wed, 18 Oct 2017 15:41:33 -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, 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 m-DdbVwgEvaE; Wed, 18 Oct 2017 15:41:32 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 422961321A1; Wed, 18 Oct 2017 15:41:32 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id f66so11675455oib.2; Wed, 18 Oct 2017 15:41:32 -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:content-transfer-encoding; bh=+C59SdKME3TPCgswQ1klVeocI0/El7p9Lo06wTBelUc=; b=PWB09lTvnRejOmD/6LDTAanhiicb9oWtkDuLWx6K2G1fsADvqGXleo91mV9wQ4bJCH vBZzfG55cykb43uKXKSsKYaUvreaw/Ozp7w7Pe2OsyT5B2J08sXBCw3jCcVWXK4ueA4+ IbkhN+BqsBpPt7JlNqKqwxp8BAgAuUpc0xf8vUBZzmGy7cwZC9lp+IVeqntSGCK61Dwv F3Z4vgY4JAReaGc1GWjw553Lk+Re93vo+x37kP5iccTvk3j87GF4OkkiPArydbWjk/qE LKVudUF5TmsFYZySu37WePAg1i8C6ZgY/Es4YEfrdTWzGRCMwbShvTyvYBk1Bn1ogTeS E+Sw== 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:content-transfer-encoding; bh=+C59SdKME3TPCgswQ1klVeocI0/El7p9Lo06wTBelUc=; b=SRFLOxvjSVR5BA6gXxzMi0tI5laUUISmnqnLgtA+gmLpaDCJ5vzLoAJc0Cjv8U5lOh T7F5fa5nKg5davKTtcceFNGK8RQavCRYQskinAwxjy0Ew/dO/eGzhnS7ypt2aHHYv07t MmdacJaPM6agyYWJKXpmOQUVFizI5mQv6ryOfvcOyaa+rBUuZYXz6EhjqH4FUAwRWkXY TsSk6LfO6U/6EA6DSKgDfy9LvPyAogSm6tGYWwNwEE6gdxWyH9vzxgQnm3nQ0RTgqBqe xRsMfrr2BwVA/zWojEA+Dx0Zkl/u96jzf5f8KZxa0o+T8JlF68CjiIkaX+FjqNigZ4O7 eA6Q== X-Gm-Message-State: AMCzsaVLJPF+zTV1TRQlR4BWAKZR6t1qLxchmM/BpsPhN9/81bRC/9Fl 9gdFIM5bJ5tnUCSbbqErYmADDqa/QUkQWoIW4sg= X-Google-Smtp-Source: ABhQp+Tt7FjbuvNy4cidSJ68elV2D7BqkWRjv24I8rRSY2bNGbfgXCBUIJ3RyRHHC8DZYGIjKD7A774M+d/My7PTlQM= X-Received: by 10.202.217.197 with SMTP id q188mr8470305oig.83.1508366491548; Wed, 18 Oct 2017 15:41:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Wed, 18 Oct 2017 15:41:30 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> From: Martin Thomson Date: Thu, 19 Oct 2017 09:41:30 +1100 Message-ID: To: "Banghart, Stephen A. (Fed)" Cc: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 22:41:34 -0000 On Thu, Oct 19, 2017 at 1:51 AM, Banghart, Stephen A. (Fed) wrote: > I've taken your suggestion to clean up the Transport Layer Security secti= on and parts of the Security Considerations section by removing our reinven= tion of the wheel and leaning more heavily on referencing other RFCs for be= st practices, it's possible that the cleaned up text contradicts itself les= s and mitigates the issue. Perhaps more explanatory text around these two c= ore use cases in the authentication section would help too? Yes, the current document heavily emphasizes client authentication as a means to control access to the point that any use of the protocol for public information is lost. From nobody Wed Oct 18 15:41:40 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id DAB3C1321A1; Wed, 18 Oct 2017 15:41:33 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DEE132705; Wed, 18 Oct 2017 15:41:33 -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, 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 m-DdbVwgEvaE; Wed, 18 Oct 2017 15:41:32 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 422961321A1; Wed, 18 Oct 2017 15:41:32 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id f66so11675455oib.2; Wed, 18 Oct 2017 15:41:32 -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:content-transfer-encoding; bh=+C59SdKME3TPCgswQ1klVeocI0/El7p9Lo06wTBelUc=; b=PWB09lTvnRejOmD/6LDTAanhiicb9oWtkDuLWx6K2G1fsADvqGXleo91mV9wQ4bJCH vBZzfG55cykb43uKXKSsKYaUvreaw/Ozp7w7Pe2OsyT5B2J08sXBCw3jCcVWXK4ueA4+ IbkhN+BqsBpPt7JlNqKqwxp8BAgAuUpc0xf8vUBZzmGy7cwZC9lp+IVeqntSGCK61Dwv F3Z4vgY4JAReaGc1GWjw553Lk+Re93vo+x37kP5iccTvk3j87GF4OkkiPArydbWjk/qE LKVudUF5TmsFYZySu37WePAg1i8C6ZgY/Es4YEfrdTWzGRCMwbShvTyvYBk1Bn1ogTeS E+Sw== 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:content-transfer-encoding; bh=+C59SdKME3TPCgswQ1klVeocI0/El7p9Lo06wTBelUc=; b=SRFLOxvjSVR5BA6gXxzMi0tI5laUUISmnqnLgtA+gmLpaDCJ5vzLoAJc0Cjv8U5lOh T7F5fa5nKg5davKTtcceFNGK8RQavCRYQskinAwxjy0Ew/dO/eGzhnS7ypt2aHHYv07t MmdacJaPM6agyYWJKXpmOQUVFizI5mQv6ryOfvcOyaa+rBUuZYXz6EhjqH4FUAwRWkXY TsSk6LfO6U/6EA6DSKgDfy9LvPyAogSm6tGYWwNwEE6gdxWyH9vzxgQnm3nQ0RTgqBqe xRsMfrr2BwVA/zWojEA+Dx0Zkl/u96jzf5f8KZxa0o+T8JlF68CjiIkaX+FjqNigZ4O7 eA6Q== X-Gm-Message-State: AMCzsaVLJPF+zTV1TRQlR4BWAKZR6t1qLxchmM/BpsPhN9/81bRC/9Fl 9gdFIM5bJ5tnUCSbbqErYmADDqa/QUkQWoIW4sg= X-Google-Smtp-Source: ABhQp+Tt7FjbuvNy4cidSJ68elV2D7BqkWRjv24I8rRSY2bNGbfgXCBUIJ3RyRHHC8DZYGIjKD7A774M+d/My7PTlQM= X-Received: by 10.202.217.197 with SMTP id q188mr8470305oig.83.1508366491548; Wed, 18 Oct 2017 15:41:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Wed, 18 Oct 2017 15:41:30 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> From: Martin Thomson Date: Thu, 19 Oct 2017 09:41:30 +1100 Message-ID: To: "Banghart, Stephen A. (Fed)" Cc: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171018224133.DAB3C1321A1@ietfa.amsl.com> Resent-Date: Wed, 18 Oct 2017 15:41:33 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 22:41:34 -0000 On Thu, Oct 19, 2017 at 1:51 AM, Banghart, Stephen A. (Fed) wrote: > I've taken your suggestion to clean up the Transport Layer Security secti= on and parts of the Security Considerations section by removing our reinven= tion of the wheel and leaning more heavily on referencing other RFCs for be= st practices, it's possible that the cleaned up text contradicts itself les= s and mitigates the issue. Perhaps more explanatory text around these two c= ore use cases in the authentication section would help too? Yes, the current document heavily emphasizes client authentication as a means to control access to the point that any use of the protocol for public information is lost. From nobody Thu Oct 19 09:24:24 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D2813235C; Thu, 19 Oct 2017 09:24: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 pYf4dSgsRMam; Thu, 19 Oct 2017 09:24:17 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0125.outbound.protection.outlook.com [23.103.201.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 AAEA713263F; Thu, 19 Oct 2017 09:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8rdIIJ2ehxTBsUl9d09E/T85YGYxvy4KodQRjql2d5E=; b=hnBSYSu690Y2RQ2LZmYQocYMpeGDs16jFza3zI7zs/HZ4w+4rueCF1QLxmPdJSYbH8Ryk3isARsoPsCUvvZNVCUF6hfOvh9BvfB8LpqnUlAQ1Lrgh8Hapnr5jt/FB3VIoKSqcNwWEr3Tu+zx1EdscKocOhbvJyGCO73RxIshNno= Received: from DM5PR09MB1307.namprd09.prod.outlook.com (10.172.34.141) by DM5PR09MB1308.namprd09.prod.outlook.com (10.172.35.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 19 Oct 2017 16:24:15 +0000 Received: from DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) by DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) with mapi id 15.20.0077.023; Thu, 19 Oct 2017 16:24:15 +0000 From: "Banghart, Stephen A. (Fed)" To: Martin Thomson CC: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Thread-Topic: [mile] Artart last call review of draft-ietf-mile-rolie-10 Thread-Index: AQHTQLy5EiZhxIKVNkSNg/Bn547ThKLrUSVQ Date: Thu, 19 Oct 2017 16:24:15 +0000 Message-ID: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> In-Reply-To: <150752570618.18384.5615358468704377459@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.219.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR09MB1308; 6:SSiQXlia3Vmx2nE4+xw5FqlFzTCGg8rsSvokYAHB7VuDNYXyxg8sE09CidtqbftjyFSGbuhNXoWZiei5Hyoo1Abcn2hlu8QABUnZmQLuQuSbHVJCYd1mCPtLXT8EpGOFx8tBAGkkpdyHVPvel8Fhd5loAfAQ3y0z60QdiMyYVVsEDu1e8ToVvbW8HQwChIsMmM9Ktfwn33x29XH2/2oEzaOhsHZi7JfmWFlFC3MuvQXHcADGsMMCVjAD/8HWDvTr2LECr7/puEA2eZlhhI8k/ejif/5KCtjBbIigJdASxVtdftww9STuRSiDCCf5VbyqAHX/Jx56WdK3FiXC1dmazA==; 5:MP75ip/2koWjQ3Y3K9Urtfh6GVMlckT/K7Fq7C7603rURJNg643En2ZbE6tRt51xzAqS5bDoxVt5Vi/PyFs9BxE9wXqzqpdbiM4hMYGdCD/edHfWfgZg0CTaez0OQ1uGPe4NpcruD5bQcQAggSczVQ==; 24:eXigkGwPs+DdRP40Kb16BkyA9JFZnI0f0LdX3nwU/EdWck+ZoM+fadSMyd1qfid96NSnwaF1wldN8ojfn8zm7tvBX4O9byjzQaQkZHf0FkQ=; 7:vMldfDE7Nng1+1nH1ZILKHasN0PHTv/1VJ/N0B37Z30uQhoGq12hYih4CoHIiHmSLQ9AShVysL0eDzjzdVSln+2oiNk4X5CZktETY9hOGA/5S6/sTaA5fLCPezddwIWWthQ9tcHaqI+LzpEmjV6BJTR02tUQEPswWB4M7+Asq/rvUnxaZyJN6zrzWMidx6GBucUR76wP4WquXrJSwDCGovDWk7iNqVsRlr31vovagM0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2820d37e-9b7f-4597-1158-08d5170dd765 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR09MB1308; x-ms-traffictypediagnostic: DM5PR09MB1308: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(189930954265078)(131327999870524)(150554046322364)(788757137089)(219752817060721); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR09MB1308; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR09MB1308; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(13464003)(199003)(43784003)(51444003)(189002)(53546010)(2906002)(8936002)(66066001)(97736004)(3660700001)(33656002)(5660300001)(25786009)(966005)(99286003)(478600001)(53936002)(6306002)(6246003)(54906003)(9686003)(316002)(39060400002)(55016002)(45080400002)(4326008)(86362001)(230783001)(74316002)(189998001)(7736002)(101416001)(14454004)(50986999)(54356999)(76176999)(2900100001)(3846002)(106356001)(305945005)(105586002)(6116002)(102836003)(6916009)(6436002)(6506006)(229853002)(77096006)(81166006)(81156014)(2950100002)(8676002)(7696004)(3280700002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1308; H:DM5PR09MB1307.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 16:24:15.7438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1308 Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 16:24:22 -0000 Martin, I've put the rest of my comments inline, and uploaded a -11 version of ROLI= E to the Github with the changes. Providing there are no additional major c= omments I'll post this version to datatracker today. Thanks again for the great review, Stephen > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Monday, October 09, 2017 1:08 AM > To: art@ietf.org > Cc: mile@ietf.org; ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org > Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 >=20 > Reviewer: Martin Thomson > Review result: Almost Ready >=20 > I have reviewed this document, and - despite what appears to be a lengthy > list of issues - I think that it is in pretty good shape. It's clear, re= adable, and > addresses the requirements well. Most of my comments should be trivial t= o > resolve. >=20 > Major: >=20 > The decision to define a .well-known URI without a discovery story is - i= n my > opinion - inadvisable. Such a registration is usually appropriate if you= design a > protocol that depends on discovery by hostname and port. As such, this > does not use that at all. A configuration system can (and should) accept= a > complete URI for the service endpoint. It would be better to defer creat= ion > of yet another .well-known URI registration until the working group is ce= rtain > that discovery requires it. Discussed in a separate thread. > The same comment applies to the .well-known resource for the category > document. > Given that this sort of document is readily discoverable via the service > document, I would say that the need for a .well-known resource is less we= ll- > justified than the service document. We agree, removed the registration for the category document location. > The requirements in Section 5.3 on TLS use are unnecessarily strict. It'= s great > to recommend the use of TLS 1.2, but given that the document has no real > requirement on any particular version of TLS, the use of "MUST" here is n= ot > needed. Similarly, the prohibition on the use of 0-RTT is groundless. T= he > lengthy list of requirements around certificate validation only risk crea= ting a > conflict with advice in other RFCs. Many, if not all, of these requireme= nts are > transitively included by way of referencing HTTPS documents. I would pre= fer > to see this entire section reduced to a simple RFC 7525 reference. The majority of the section has been reduced to a RFC 7525 reference. We be= lieve that the benefits provided by 0-RTT don't outweigh the loss of forwar= d secrecy. The text currently places this as a suggestion from the authors,= and not a normative requirement. > User authentication is under-specified. As any repository using user authentication is already inherently pre-commu= nicating with its consumers, we felt that underspecifying authentication me= chanisms allowed for each sharing consortium to control their own repositor= ies. Whatever system they are using already for internal/external sharing a= uthentication can be used here as long as it meets the ROLIE requirements. > * Section 5.3 mandates the use of TLS cipher suites that support client > authentication using certificates, but offers no further advice. Aside f= rom > being an unnecessary requirement - cipher suites that support certificate= - > based authentication of servers all allow for client authentication - thi= s sort of > requirement is rarely sufficient for interoperation. For instance, you n= eed to > specify how a server will request a certificate such that clients can sel= ect the > correct certificate. If a client and server have agreed to share informa= tion on > terms that rely on authentication of clients, it is better for those peer= s to > arrange the terms on which they will authenticate. Removed cipher suite text as these recommendations are provided by RFC 7525= .=20 > * Section 5.4 uses "SHOULD" regarding client authentication using federat= ion, > but offers no hints about what this entails. It also uses "SHOULD" regar= ding > authorization checks, which isn't an interoperability requirement. It's = more > of a "don't be silly" type of requirement, which doesn't need to be writt= en > down in an RFC. While its true that this is a "don't do anything stupid" requirement, I thi= nk that its valuable as a reminder that the authorization checks need to su= pport full granularity through the entire resource tree. > Section 5.5 prohibits the use of GET on "/". This prohibits use of the r= esource > for other purposes. It seems reasonable to accept POST messages as > defined in RFC 6546, but this requirement is overly strict (and further > entrenches the violation of RFC 7320). If, for instance, the server oper= ator > wishes to provide HTML in response to a GET request to "/", this would > prohibit that. The requirement to return 404 if RFC 6546 is not supporte= d is > worse; not supporting RFC 6546 might be a choice that a deployment makes > to avoid the need to reserve "/" for that protocol. Cleaned up the text describing this requirement to be more clear that they = only trigger when an implementation has decided to support RFC 6546. Remove= d the 404 requirement when not supporting RFC6546, as I agree that it was o= verly restrictive. > In Section 6.2.3, what is the advantage of "rolie:format" over having a w= ell- > defined media type? Media types can take advantage of content > negotiation, existing support in link relations, and other existing tools= . > This rolie:format element has namespace, format, and schema; these are no= t > useful to anyone that is ignorant of their contents. The only advantage = I see > is that syntax might be validated, but semantics can't be extracted. The= re's a > lot of implied work in adding this element, but that doesn't seem to be > justified by that advantage. (I see that RFC 7970 doesn't define a media= type, > but it seems like it would be easier to correct that than to define an el= ement > like this.) Atom:content has an attribute for media type, which provides information ab= out the serialization of the content representation. In many cases, we foun= d that different formats can appear for the same content within the same me= dia type. For example, the same piece of information may be represented usi= ng two different XML Schemas. The rolie:format element allows the entry to = clarify which "format" its using beyond which serialization it is using. Ul= timately the format element is not registered anywhere, nor is its contents= particularly standardized. We're providing the element as a tool for repos= itory producers to use. > Section 6.2.4 defines a generic key-value mechanism. But that is somethi= ng > that XML is actually good at. Why can't users that require additional > metadata use additional metadata as originally defined by Atom? That is, > replace value=3D"12345"/> with something like > 12345. The final paragraph = of the > section recognizes this possibility. The latter example you provide is still possible, as unrecognized elements = in ROLIE/Atom don't cause validation to fail, but are just potentially igno= red by the client/server. The rolie:property element allows automated syste= ms to have a globally available "vocabulary" of potentially available prope= rties, that can be used to populate tables or fields in automated systems. > Minor: >=20 > Section 5.1.1 recommends the use of workspaces to separate "private" and > "public" information. But workspaces don't really contain enough > information to signal their status to a consumer of the information. I w= ould > suggest mentioning this, removing the recommendation, or expanding on > the manner in which the status of information is signaled. Agreed, I've clarified the text in this section and removed the normative r= ecommendation. > Section 6.1.1 says "zero or more atom:category elements", but this > contradicts the text and amendment to the schema in Section 6.1. Thanks for catching this, fixed. > Section 6.1.3 requires updating the "atom:updated" element when the > representation changes. I don't think that this is what was intended. I= think > that the element needs to be updated when the contents of the feed > change in any way. Agreed, changed. > Question: it's fairly widely accepted that use of IRIs in Atom has been l= ess > than successful. Do you want to mandate use of URIs instead? This would > apply to both link relations and the "src" attribute. We wanted to stay in line with the requirements in Atom, if this becomes an= issue it may be worth re-examining. > In Section 7.1, the definition of the namespace prefix > "urn:ietf:params:rolie:category:local" seems unnecessary. Namespace URIs > are cheap and it seems reasonable to experiment with feeds that produce > non-ROLIE information by omitting the > "urn:ietf:params:rolie:category:information-type" > category, even if that feed might comply with the requirements of ROLIE. > The other way to experiment would be to use the category, but define a wa= y > to identify "term" attributes that are for use in private or experimental > contexts. Agreed. The local registration was providing nothing that XML/Atom don't al= ready provide. As such, we've removed this registration and clarified that = any category not registered via the ROLIE table is considered private. This= should be more in line with how Atom originally handled categories. > In Section 7.4, how is "...:rolie:property:content-author-name" superior = to > "atom:author"? Atom:author provides information on the person or entity that authored the = entry, while the rolie:content-author-name provides information on the pers= on or entity that authored the content. We found that the two often differe= d, and added this property to allow both entities to be described. I added = some extra text to content-author-name to clarify this. > In Section 8.4, is there a uniqueness requirement on "name"? I understa= nd > this to be the thing that being registered. Assuming that, what purpose > does > the "index" serve? Yes name needs to be unique, I added this requirement. We included an index= as an additional unique identifier for the registration as a potential sho= rthand. We've been discussing the possibility of binary serialization of RO= LIE and wanted a shorter form for the registration. > This statement from Section 9, "As described in the discovery section, DN= S > SRV Records are a possible secure solution to discovery." is false withou= t > further qualification. SRV with DNSSEC might be secure, but a lot depend= s on > the input to the discovery process and its provenance. Dropped the "secure" descriptor to avoid being misleading. > In Section 10, the following statement is false (all of the described pri= vacy > violations are available to a client or server, not third parties): "Prop= er usage > of TLS as described in Section 5.3 will in many cases aid in the mitigati= on of > these issues." I think that you can strike this statement (most of the r= eason > for use of TLS is justified by the security considerations anyway). Agreed, none of the privacy issues described included third parties that TL= S could keep away. > Nits: >=20 > Is it "Feed" or "feed"? RFC 4287 uses the latter, but this document seem= s to > prefer the Proper Noun form. We decided to use Feed for referring to the conceptual Feed, and atom:feed = for the actual representation. > Section 6.2 should say what changed in the schema. It's hard to eyeball = the > schema to discover that "atomContent" is no longer optional. The two new > elements are easy to spot and might cause the first change to be missed. >=20 > Section 6.2.1 is the same. It should explicitly say that it only permits= the > atomOutOfLineContent formulation. Agreed, added text explicitly describing the important changes. > I found the formulation of Section 7.1.1 confusing. It includes a list t= hat > seems to be authoritative, then disclaims any attempt to register these > terms. > Maybe this is because the statement "This document does not specify any > information types." appears too late. Some reordering might help. Reordered and provided some additional text to make the list more clear. > The formatting of the table in Section 8.3 makes most of the columns > unreadable. I would recommend a simple nested list. I think the formatting issue is caused by the long note to IANA in the firs= t row. When this note is removed the table formatting should be more sensic= al. > In section 9, the use of the term "well-known" to refer to information th= at is > either public or widely available risks misinterpretation. Changed. > FWIW, I would reword this entire paragraph to say simply "Access control = to > information published using ROLIE should use mechanisms that are > appropriate to the sensitivity of the information. Primitive authenticat= ion > mechanisms like HTTP Basic Authentication [RFC7617] are rarely appropriat= e > for sensitive information." I didn't find the remainder of the text on > authentication especially helpful. The text seems to equivocate on the > subject of federation, where it would be easier to say nothing. Included your text and removed text that was contributing little, this shor= ted the paragraph and rendered it more readable. We kept the text listing v= alid alternatives as we felt it was valuable. > Also in Section 9, the use of the term "message" is used in the context o= f > using additional security controls. I think that the word "representatio= n" is > what was intended here. Changed. > _______________________________________________ > mile mailing list > mile@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fmile&data=3D02%7C01%7Cstephen.banghar > t%40nist.gov%7Caf3af91a1c684592007d08d50ed3d401%7C2ab5d82fd8fa4797 > a93e054655c61dec%7C1%7C0%7C636431225322845891&sdata=3DSykEasQlo1e > MarYmKXSA5HsOUpTLyjd9rslyvZPpxak%3D&reserved=3D0 From nobody Thu Oct 19 09:24:30 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id F1DE313263F; Thu, 19 Oct 2017 09:24:21 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D2813235C; Thu, 19 Oct 2017 09:24: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 pYf4dSgsRMam; Thu, 19 Oct 2017 09:24:17 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0125.outbound.protection.outlook.com [23.103.201.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 AAEA713263F; Thu, 19 Oct 2017 09:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8rdIIJ2ehxTBsUl9d09E/T85YGYxvy4KodQRjql2d5E=; b=hnBSYSu690Y2RQ2LZmYQocYMpeGDs16jFza3zI7zs/HZ4w+4rueCF1QLxmPdJSYbH8Ryk3isARsoPsCUvvZNVCUF6hfOvh9BvfB8LpqnUlAQ1Lrgh8Hapnr5jt/FB3VIoKSqcNwWEr3Tu+zx1EdscKocOhbvJyGCO73RxIshNno= Received: from DM5PR09MB1307.namprd09.prod.outlook.com (10.172.34.141) by DM5PR09MB1308.namprd09.prod.outlook.com (10.172.35.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 19 Oct 2017 16:24:15 +0000 Received: from DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) by DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) with mapi id 15.20.0077.023; Thu, 19 Oct 2017 16:24:15 +0000 From: "Banghart, Stephen A. (Fed)" To: Martin Thomson CC: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Thread-Topic: [mile] Artart last call review of draft-ietf-mile-rolie-10 Thread-Index: AQHTQLy5EiZhxIKVNkSNg/Bn547ThKLrUSVQ Date: Thu, 19 Oct 2017 16:24:15 +0000 Message-ID: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> In-Reply-To: <150752570618.18384.5615358468704377459@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.219.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR09MB1308; 6:SSiQXlia3Vmx2nE4+xw5FqlFzTCGg8rsSvokYAHB7VuDNYXyxg8sE09CidtqbftjyFSGbuhNXoWZiei5Hyoo1Abcn2hlu8QABUnZmQLuQuSbHVJCYd1mCPtLXT8EpGOFx8tBAGkkpdyHVPvel8Fhd5loAfAQ3y0z60QdiMyYVVsEDu1e8ToVvbW8HQwChIsMmM9Ktfwn33x29XH2/2oEzaOhsHZi7JfmWFlFC3MuvQXHcADGsMMCVjAD/8HWDvTr2LECr7/puEA2eZlhhI8k/ejif/5KCtjBbIigJdASxVtdftww9STuRSiDCCf5VbyqAHX/Jx56WdK3FiXC1dmazA==; 5:MP75ip/2koWjQ3Y3K9Urtfh6GVMlckT/K7Fq7C7603rURJNg643En2ZbE6tRt51xzAqS5bDoxVt5Vi/PyFs9BxE9wXqzqpdbiM4hMYGdCD/edHfWfgZg0CTaez0OQ1uGPe4NpcruD5bQcQAggSczVQ==; 24:eXigkGwPs+DdRP40Kb16BkyA9JFZnI0f0LdX3nwU/EdWck+ZoM+fadSMyd1qfid96NSnwaF1wldN8ojfn8zm7tvBX4O9byjzQaQkZHf0FkQ=; 7:vMldfDE7Nng1+1nH1ZILKHasN0PHTv/1VJ/N0B37Z30uQhoGq12hYih4CoHIiHmSLQ9AShVysL0eDzjzdVSln+2oiNk4X5CZktETY9hOGA/5S6/sTaA5fLCPezddwIWWthQ9tcHaqI+LzpEmjV6BJTR02tUQEPswWB4M7+Asq/rvUnxaZyJN6zrzWMidx6GBucUR76wP4WquXrJSwDCGovDWk7iNqVsRlr31vovagM0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2820d37e-9b7f-4597-1158-08d5170dd765 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR09MB1308; x-ms-traffictypediagnostic: DM5PR09MB1308: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(189930954265078)(131327999870524)(150554046322364)(788757137089)(219752817060721); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR09MB1308; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR09MB1308; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(13464003)(199003)(43784003)(51444003)(189002)(53546010)(2906002)(8936002)(66066001)(97736004)(3660700001)(33656002)(5660300001)(25786009)(966005)(99286003)(478600001)(53936002)(6306002)(6246003)(54906003)(9686003)(316002)(39060400002)(55016002)(45080400002)(4326008)(86362001)(230783001)(74316002)(189998001)(7736002)(101416001)(14454004)(50986999)(54356999)(76176999)(2900100001)(3846002)(106356001)(305945005)(105586002)(6116002)(102836003)(6916009)(6436002)(6506006)(229853002)(77096006)(81166006)(81156014)(2950100002)(8676002)(7696004)(3280700002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1308; H:DM5PR09MB1307.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 16:24:15.7438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1308 Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171019162421.F1DE313263F@ietfa.amsl.com> Resent-Date: Thu, 19 Oct 2017 09:24:21 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 16:24:22 -0000 Martin, I've put the rest of my comments inline, and uploaded a -11 version of ROLI= E to the Github with the changes. Providing there are no additional major c= omments I'll post this version to datatracker today. Thanks again for the great review, Stephen > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Monday, October 09, 2017 1:08 AM > To: art@ietf.org > Cc: mile@ietf.org; ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org > Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 >=20 > Reviewer: Martin Thomson > Review result: Almost Ready >=20 > I have reviewed this document, and - despite what appears to be a lengthy > list of issues - I think that it is in pretty good shape. It's clear, re= adable, and > addresses the requirements well. Most of my comments should be trivial t= o > resolve. >=20 > Major: >=20 > The decision to define a .well-known URI without a discovery story is - i= n my > opinion - inadvisable. Such a registration is usually appropriate if you= design a > protocol that depends on discovery by hostname and port. As such, this > does not use that at all. A configuration system can (and should) accept= a > complete URI for the service endpoint. It would be better to defer creat= ion > of yet another .well-known URI registration until the working group is ce= rtain > that discovery requires it. Discussed in a separate thread. > The same comment applies to the .well-known resource for the category > document. > Given that this sort of document is readily discoverable via the service > document, I would say that the need for a .well-known resource is less we= ll- > justified than the service document. We agree, removed the registration for the category document location. > The requirements in Section 5.3 on TLS use are unnecessarily strict. It'= s great > to recommend the use of TLS 1.2, but given that the document has no real > requirement on any particular version of TLS, the use of "MUST" here is n= ot > needed. Similarly, the prohibition on the use of 0-RTT is groundless. T= he > lengthy list of requirements around certificate validation only risk crea= ting a > conflict with advice in other RFCs. Many, if not all, of these requireme= nts are > transitively included by way of referencing HTTPS documents. I would pre= fer > to see this entire section reduced to a simple RFC 7525 reference. The majority of the section has been reduced to a RFC 7525 reference. We be= lieve that the benefits provided by 0-RTT don't outweigh the loss of forwar= d secrecy. The text currently places this as a suggestion from the authors,= and not a normative requirement. > User authentication is under-specified. As any repository using user authentication is already inherently pre-commu= nicating with its consumers, we felt that underspecifying authentication me= chanisms allowed for each sharing consortium to control their own repositor= ies. Whatever system they are using already for internal/external sharing a= uthentication can be used here as long as it meets the ROLIE requirements. > * Section 5.3 mandates the use of TLS cipher suites that support client > authentication using certificates, but offers no further advice. Aside f= rom > being an unnecessary requirement - cipher suites that support certificate= - > based authentication of servers all allow for client authentication - thi= s sort of > requirement is rarely sufficient for interoperation. For instance, you n= eed to > specify how a server will request a certificate such that clients can sel= ect the > correct certificate. If a client and server have agreed to share informa= tion on > terms that rely on authentication of clients, it is better for those peer= s to > arrange the terms on which they will authenticate. Removed cipher suite text as these recommendations are provided by RFC 7525= .=20 > * Section 5.4 uses "SHOULD" regarding client authentication using federat= ion, > but offers no hints about what this entails. It also uses "SHOULD" regar= ding > authorization checks, which isn't an interoperability requirement. It's = more > of a "don't be silly" type of requirement, which doesn't need to be writt= en > down in an RFC. While its true that this is a "don't do anything stupid" requirement, I thi= nk that its valuable as a reminder that the authorization checks need to su= pport full granularity through the entire resource tree. > Section 5.5 prohibits the use of GET on "/". This prohibits use of the r= esource > for other purposes. It seems reasonable to accept POST messages as > defined in RFC 6546, but this requirement is overly strict (and further > entrenches the violation of RFC 7320). If, for instance, the server oper= ator > wishes to provide HTML in response to a GET request to "/", this would > prohibit that. The requirement to return 404 if RFC 6546 is not supporte= d is > worse; not supporting RFC 6546 might be a choice that a deployment makes > to avoid the need to reserve "/" for that protocol. Cleaned up the text describing this requirement to be more clear that they = only trigger when an implementation has decided to support RFC 6546. Remove= d the 404 requirement when not supporting RFC6546, as I agree that it was o= verly restrictive. > In Section 6.2.3, what is the advantage of "rolie:format" over having a w= ell- > defined media type? Media types can take advantage of content > negotiation, existing support in link relations, and other existing tools= From nobody Thu Oct 19 10:17:55 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC4A132E24; Thu, 19 Oct 2017 10:17: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 5XsbuV5mbR2s; Thu, 19 Oct 2017 10:17:52 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 C74D4132CE7; Thu, 19 Oct 2017 10:17:52 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id m18so7709538pgd.13; Thu, 19 Oct 2017 10:17:52 -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:content-transfer-encoding; bh=azux2pCaohyrzsNJvbxlFrzj/mvxO6LrxE9Tu8DgyAo=; b=nYpegiO7BgdweqAaDvCLLexUqgEqrfK08cToiGRqdNzcAcyeMUxTK3Cm/1P6QQDHVf gVVlK+KEUZs3XNt5DPgzo/PRJFq9dBQiP2HqwL241PKRa4AqW5ObvmrdxJ+MRU4m4Ses PtjFTX5XdEzItJJHR/A/SnrL3/A3xUzkfd9thWzRZC/s17Jbxi1TcQgMW+6FuJhEVrtV tfbCJ0ORJWK6k4Yn4H2K2FMsXlR0ixpAW4GADjyOlNvZkppnm7wgT/FuA8o+zFrLCZ8Z 5ceIwao5/zSwpypWML4JZG+blLYlrfbmyFclR1EA2o2+aRdkwQLgEEVkPS4Y9T9imAPs jZNg== 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:content-transfer-encoding; bh=azux2pCaohyrzsNJvbxlFrzj/mvxO6LrxE9Tu8DgyAo=; b=c5NV8S25KZun9X/uBHjUofa+QUkRXdOReO/eZkLxFjjouxSqFMBG8HOZIacpbkJzSB 94Xh4a1PPuZXPQw1vtqTTuKjdKth7aRRGgdy28pzdOwe9rrpfx9Uf532F/9JW9GBbBxy /grsVLsZs3bzb3Oo6xF66PUPNqilOKRuBUHEUZzK62IUIWGoPTlVssvmer3rggC/AEiy agUo3CZrjBFawyHQkq2MYmTAJoBQYQjl4qcVjipR9MlkHl6akD47JyA5FN60qBxyKQbM V60kOiRsH/7rRqOHvw05D/9QlXmv/3fb/UEU65jH/p8dwYhDbQqaVmtuJDYDtvChkxGE I4uw== X-Gm-Message-State: AMCzsaVvTpaunD2icv6S8fqACgM9y3lhzhab1yNHnYvzZwTfVuOZX3gF /4+TVrMN84BEZdHDp+Vkojl5SK9bGL52lln9Iqc= X-Google-Smtp-Source: ABhQp+SDVruZCEkVx5lhJC52eiMoxnL4pRgoUU9C+yHqpwUCiqhxCMhm7846oibb3kXmJnKysrvpoyyrnD+kXSsxVIc= X-Received: by 10.98.33.15 with SMTP id h15mr2095062pfh.319.1508433472390; Thu, 19 Oct 2017 10:17:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Thu, 19 Oct 2017 10:17:11 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> From: Kathleen Moriarty Date: Thu, 19 Oct 2017 13:17:11 -0400 Message-ID: To: "Banghart, Stephen A. (Fed)" Cc: Martin Thomson , "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 17:17:55 -0000 Hi Stephen, On Thu, Oct 19, 2017 at 12:24 PM, Banghart, Stephen A. (Fed) wrote: > Martin, > > I've put the rest of my comments inline, and uploaded a -11 version of RO= LIE to the Github with the changes. Providing there are no additional major= comments I'll post this version to datatracker today. > > Thanks again for the great review, > Stephen > >> -----Original Message----- >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin Thomson >> Sent: Monday, October 09, 2017 1:08 AM >> To: art@ietf.org >> Cc: mile@ietf.org; ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org >> Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 >> >> Reviewer: Martin Thomson >> Review result: Almost Ready >> >> I have reviewed this document, and - despite what appears to be a length= y >> list of issues - I think that it is in pretty good shape. It's clear, r= eadable, and >> addresses the requirements well. Most of my comments should be trivial = to >> resolve. >> >> Major: >> >> The decision to define a .well-known URI without a discovery story is - = in my >> opinion - inadvisable. Such a registration is usually appropriate if yo= u design a >> protocol that depends on discovery by hostname and port. As such, this >> does not use that at all. A configuration system can (and should) accep= t a >> complete URI for the service endpoint. It would be better to defer crea= tion >> of yet another .well-known URI registration until the working group is c= ertain >> that discovery requires it. > > Discussed in a separate thread. > >> The same comment applies to the .well-known resource for the category >> document. >> Given that this sort of document is readily discoverable via the servic= e >> document, I would say that the need for a .well-known resource is less w= ell- >> justified than the service document. > > We agree, removed the registration for the category document location. > >> The requirements in Section 5.3 on TLS use are unnecessarily strict. It= 's great >> to recommend the use of TLS 1.2, but given that the document has no real >> requirement on any particular version of TLS, the use of "MUST" here is = not >> needed. Similarly, the prohibition on the use of 0-RTT is groundless. = The >> lengthy list of requirements around certificate validation only risk cre= ating a >> conflict with advice in other RFCs. Many, if not all, of these requirem= ents are >> transitively included by way of referencing HTTPS documents. I would pr= efer >> to see this entire section reduced to a simple RFC 7525 reference. > > The majority of the section has been reduced to a RFC 7525 reference. We = believe that the benefits provided by 0-RTT don't outweigh the loss of forw= ard secrecy. The text currently places this as a suggestion from the author= s, and not a normative requirement. This is a substantial change as a result of just one reviewer. The only thing the MUST does is hold up final publication until an RFC # is assigned for TLS 1.3. TLS 1.3 shouldn't be too far off, so waiting may be worth having the normative language. I think this is one the WG needs to weigh in on to change and tradeoffs of waiting for final publication. It's not just the editors that recommend this, I do as am sure others do as well. Best regards, Kathleen > >> User authentication is under-specified. > > As any repository using user authentication is already inherently pre-com= municating with its consumers, we felt that underspecifying authentication = mechanisms allowed for each sharing consortium to control their own reposit= ories. Whatever system they are using already for internal/external sharing= authentication can be used here as long as it meets the ROLIE requirements= . > >> * Section 5.3 mandates the use of TLS cipher suites that support client >> authentication using certificates, but offers no further advice. Aside = from >> being an unnecessary requirement - cipher suites that support certificat= e- >> based authentication of servers all allow for client authentication - th= is sort of >> requirement is rarely sufficient for interoperation. For instance, you = need to >> specify how a server will request a certificate such that clients can se= lect the >> correct certificate. If a client and server have agreed to share inform= ation on >> terms that rely on authentication of clients, it is better for those pee= rs to >> arrange the terms on which they will authenticate. > > Removed cipher suite text as these recommendations are provided by RFC 75= 25. > >> * Section 5.4 uses "SHOULD" regarding client authentication using federa= tion, >> but offers no hints about what this entails. It also uses "SHOULD" rega= rding >> authorization checks, which isn't an interoperability requirement. It's= more >> of a "don't be silly" type of requirement, which doesn't need to be writ= ten >> down in an RFC. > > While its true that this is a "don't do anything stupid" requirement, I t= hink that its valuable as a reminder that the authorization checks need to = support full granularity through the entire resource tree. > >> Section 5.5 prohibits the use of GET on "/". This prohibits use of the = resource >> for other purposes. It seems reasonable to accept POST messages as >> defined in RFC 6546, but this requirement is overly strict (and further >> entrenches the violation of RFC 7320). If, for instance, the server ope= rator >> wishes to provide HTML in response to a GET request to "/", this would >> prohibit that. The requirement to return 404 if RFC 6546 is not support= ed is >> worse; not supporting RFC 6546 might be a choice that a deployment makes >> to avoid the need to reserve "/" for that protocol. > > Cleaned up the text describing this requirement to be more clear that the= y only trigger when an implementation has decided to support RFC 6546. Remo= ved the 404 requirement when not supporting RFC6546, as I agree that it was= overly restrictive. > >> In Section 6.2.3, what is the advantage of "rolie:format" over having a = well- >> defined media type? Media types can take advantage of content >> negotiation, existing support in link relations, and other existing tool= s --=20 Best regards, Kathleen From nobody Thu Oct 19 10:18:12 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 20107132CE7; Thu, 19 Oct 2017 10:17:55 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC4A132E24; Thu, 19 Oct 2017 10:17: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 5XsbuV5mbR2s; Thu, 19 Oct 2017 10:17:52 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 C74D4132CE7; Thu, 19 Oct 2017 10:17:52 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id m18so7709538pgd.13; Thu, 19 Oct 2017 10:17:52 -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:content-transfer-encoding; bh=azux2pCaohyrzsNJvbxlFrzj/mvxO6LrxE9Tu8DgyAo=; b=nYpegiO7BgdweqAaDvCLLexUqgEqrfK08cToiGRqdNzcAcyeMUxTK3Cm/1P6QQDHVf gVVlK+KEUZs3XNt5DPgzo/PRJFq9dBQiP2HqwL241PKRa4AqW5ObvmrdxJ+MRU4m4Ses PtjFTX5XdEzItJJHR/A/SnrL3/A3xUzkfd9thWzRZC/s17Jbxi1TcQgMW+6FuJhEVrtV tfbCJ0ORJWK6k4Yn4H2K2FMsXlR0ixpAW4GADjyOlNvZkppnm7wgT/FuA8o+zFrLCZ8Z 5ceIwao5/zSwpypWML4JZG+blLYlrfbmyFclR1EA2o2+aRdkwQLgEEVkPS4Y9T9imAPs jZNg== 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:content-transfer-encoding; bh=azux2pCaohyrzsNJvbxlFrzj/mvxO6LrxE9Tu8DgyAo=; b=c5NV8S25KZun9X/uBHjUofa+QUkRXdOReO/eZkLxFjjouxSqFMBG8HOZIacpbkJzSB 94Xh4a1PPuZXPQw1vtqTTuKjdKth7aRRGgdy28pzdOwe9rrpfx9Uf532F/9JW9GBbBxy /grsVLsZs3bzb3Oo6xF66PUPNqilOKRuBUHEUZzK62IUIWGoPTlVssvmer3rggC/AEiy agUo3CZrjBFawyHQkq2MYmTAJoBQYQjl4qcVjipR9MlkHl6akD47JyA5FN60qBxyKQbM V60kOiRsH/7rRqOHvw05D/9QlXmv/3fb/UEU65jH/p8dwYhDbQqaVmtuJDYDtvChkxGE I4uw== X-Gm-Message-State: AMCzsaVvTpaunD2icv6S8fqACgM9y3lhzhab1yNHnYvzZwTfVuOZX3gF /4+TVrMN84BEZdHDp+Vkojl5SK9bGL52lln9Iqc= X-Google-Smtp-Source: ABhQp+SDVruZCEkVx5lhJC52eiMoxnL4pRgoUU9C+yHqpwUCiqhxCMhm7846oibb3kXmJnKysrvpoyyrnD+kXSsxVIc= X-Received: by 10.98.33.15 with SMTP id h15mr2095062pfh.319.1508433472390; Thu, 19 Oct 2017 10:17:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Thu, 19 Oct 2017 10:17:11 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> From: Kathleen Moriarty Date: Thu, 19 Oct 2017 13:17:11 -0400 Message-ID: To: "Banghart, Stephen A. (Fed)" Cc: Martin Thomson , "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171019171755.20107132CE7@ietfa.amsl.com> Resent-Date: Thu, 19 Oct 2017 10:17:55 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 17:17:55 -0000 Hi Stephen, On Thu, Oct 19, 2017 at 12:24 PM, Banghart, Stephen A. (Fed) wrote: > Martin, > > I've put the rest of my comments inline, and uploaded a -11 version of RO= LIE to the Github with the changes. Providing there are no additional major= comments I'll post this version to datatracker today. > > Thanks again for the great review, > Stephen > >> -----Original Message----- >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin Thomson >> Sent: Monday, October 09, 2017 1:08 AM >> To: art@ietf.org >> Cc: mile@ietf.org; ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org >> Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 >> >> Reviewer: Martin Thomson >> Review result: Almost Ready >> >> I have reviewed this document, and - despite what appears to be a length= y >> list of issues - I think that it is in pretty good shape. It's clear, r= eadable, and >> addresses the requirements well. Most of my comments should be trivial = to >> resolve. >> >> Major: >> >> The decision to define a .well-known URI without a discovery story is - = in my >> opinion - inadvisable. Such a registration is usually appropriate if yo= u design a >> protocol that depends on discovery by hostname and port. As such, this >> does not use that at all. A configuration system can (and should) accep= t a >> complete URI for the service endpoint. It would be better to defer crea= tion >> of yet another .well-known URI registration until the working group is c= ertain >> that discovery requires it. > > Discussed in a separate thread. > >> The same comment applies to the .well-known resource for the category >> document. >> Given that this sort of document is readily discoverable via the servic= e >> document, I would say that the need for a .well-known resource is less w= ell- >> justified than the service document. > > We agree, removed the registration for the category document location. > >> The requirements in Section 5.3 on TLS use are unnecessarily strict. It= 's great >> to recommend the use of TLS 1.2, but given that the document has no real >> requirement on any particular version of TLS, the use of "MUST" here is = not >> needed. Similarly, the prohibition on the use of 0-RTT is groundless. = The >> lengthy list of requirements around certificate validation only risk cre= ating a >> conflict with advice in other RFCs. Many, if not all, of these requirem= ents are >> transitively included by way of referencing HTTPS documents. I would pr= efer >> to see this entire section reduced to a simple RFC 7525 reference. > > The majority of the section has been reduced to a RFC 7525 reference. We = believe that the benefits provided by 0-RTT don't outweigh the loss of forw= ard secrecy. The text currently places this as a suggestion from the author= s, and not a normative requirement. This is a substantial change as a result of just one reviewer. The only thing the MUST does is hold up final publication until an RFC # is assigned for TLS 1.3. TLS 1.3 shouldn't be too far off, so waiting may be worth having the normative language. I think this is one the WG needs to weigh in on to change and tradeoffs of waiting for final publication. It's not just the editors that recommend this, I do as am sure others do as well. Best regards, Kathleen > >> User authentication is under-specified. > > As any repository using user authentication is already inherently pre-com= municating with its consumers, we felt that underspecifying authentication = mechanisms allowed for each sharing consortium to control their own reposit= ories. Whatever system they are using already for internal/external sharing= authentication can be used here as long as it meets the ROLIE requirements= From nobody Thu Oct 19 10:39:47 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257D01329B5; Thu, 19 Oct 2017 10:39:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 BfNvac_nhd9f; Thu, 19 Oct 2017 10:39:43 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0132.outbound.protection.outlook.com [23.103.201.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A39132031; Thu, 19 Oct 2017 10:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8W3Jztahbb5AaIsVmobbRZ8KWWdHPL1FdU6KcrFPNOs=; b=udbv6zq5uQESaMS3ge32TVMVT51EVwkdrfkDt0HlCJM9YZ1qjSV29eIZpdnn2WcZNWYtf9HzUOTxRqdna9XAr5bIBQlCXoMXfbjt22X+p6xUFP/GsWfajZqhiKVunBaRQU+mQ0J2cpB16QAs09hfdJhuMh64Ep7ubK/nmfEK4xs= Received: from DM5PR09MB1307.namprd09.prod.outlook.com (10.172.34.141) by DM5PR09MB1308.namprd09.prod.outlook.com (10.172.35.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 19 Oct 2017 17:39:41 +0000 Received: from DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) by DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) with mapi id 15.20.0077.023; Thu, 19 Oct 2017 17:39:41 +0000 From: "Banghart, Stephen A. (Fed)" To: Kathleen Moriarty CC: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Thread-Topic: [mile] Artart last call review of draft-ietf-mile-rolie-10 Thread-Index: AQHTQLy5EiZhxIKVNkSNg/Bn547ThKLrUSVQgAAplICAAAQPsA== Date: Thu, 19 Oct 2017 17:39:41 +0000 Message-ID: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.219.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR09MB1308; 6:Jtouz6s8NWzRvCBH0rjAxUDHZRo22Jt2jyKO0WFJKPdViJvDAQi6s5WyO3OL+6kSKsetKukhDRIbGcEen994iZN5ZCc3uRDluyh7qKYmn4GROJB7WzUhpuARVZov9mc8HtpR3WrZLxvLLwisPQstZu7bQLegzeTj1c5k1cJ4FhtLFV8TItdneUbGis++Espawv+1Dd8TEGZEgHERCwAIS9FX4alxHeUYi9OtfyLHeQUaZiJc//GVJFHNb56rWTgcJy98aASa8VjuI5lhsv2iiUvuLKEASVZtUcOa8kIOfwkqtW7posz1fsKkT68n779OcE6qaXVRUk8WJpfMvyY7GA==; 5:+ns9M86txL4AMA22ffK6e2BWbWwUocRGgAKWOauRUV299t70LdIEB70lyp4SRk5zdTjyLuLX4MZKS4OCIES2fT+gB8enZsHtY9RvRkwY78eYmRbMhzvA/8E8iqQpIAkn7F4WD0qKQJIR8NEblnYXgg==; 24:Jedqnt51CiVg9rRqG3TeUam32J+VRCwb1KI/otQE4d8snrNtTAVWYmrYn0BW4j0uU6c9Nq53x+sxIOhTB4X90aW/BM8ID2+DDbotJxOniys=; 7:dBhPuB7AIFd5JxB273KJMoeFw9riw9dg13GFQLEnKAEfJSuIHzCsQd9myVnXX2jH2mVH7/528jl6gc4q50cOOH1b+OJojdumLK0hFVSIMFCgd9neqaY9ivDNVqkZQK4gR3HuNj3VWttTV7VjZwbIIjM9+GeAVJ5YOdZpYKj5xjUWko3gfQgS/c1XwuD2neKH/62iXk/1BxvG/gN5p1vE1CuMuczbFH4OnerUGrgLNiA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 48ee1762-c0fb-44c5-f2d7-08d5171860b6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254172)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(48565401081)(2017052603199)(201703131423095); SRVR:DM5PR09MB1308; x-ms-traffictypediagnostic: DM5PR09MB1308: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(150554046322364); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR09MB1308; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR09MB1308; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(43784003)(24454002)(199003)(51444003)(189002)(13464003)(50986999)(3846002)(2900100001)(54356999)(76176999)(6116002)(102836003)(305945005)(106356001)(105586002)(7736002)(230783001)(74316002)(189998001)(101416001)(14454004)(81166006)(8676002)(7696004)(81156014)(2950100002)(68736007)(3280700002)(6506006)(6436002)(6916009)(229853002)(77096006)(3660700001)(97736004)(33656002)(2906002)(53546010)(66066001)(8936002)(54906003)(9686003)(6246003)(39060400002)(316002)(86362001)(4326008)(55016002)(99286003)(25786009)(5660300001)(478600001)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1308; H:DM5PR09MB1307.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 17:39:41.0330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1308 Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 17:39:46 -0000 S2F0aGxlZW4sDQoNCkp1c3QgdG8gY2xhcmlmeSwgdGhlcmUgd2VyZSBubyBub3JtYXRpdmUgY2hh bmdlcyB0byB0aGUgdXNlIG9mIFRMUyAxLjMgb3IgVExTIDEuMiBpbiB0aGlzIC0xMSB1cGRhdGUu IFRoZSBsYXR0ZXIgdGhyZWUgcGFyYWdyYXBocyB3ZXJlIHRydW5jYXRlZCBhcyBpdCB3YXMgZHVw bGljYXRlZCB0ZXh0IG91dCBvZiBSRkMgNzUyNSBhbmQgUkZDIDc1ODkuDQoNClRoZSBub3JtYXRp dmUgcmVxdWlyZW1lbnRzIGZvciBUTFMgcmVtYWluIGFzIGZvbGxvd3M6DQoNCkEgIk1VU1QiIGZv ciBpbXBsZW1lbnRpbmcgVExTIDEuMiB3aXRoIGEgIlNIT1VMRCIgZm9yIGZvbGxvd2luZyB0aGUg QkNQcyBhcyBkZXNjcmliZWQgaW4gUkZDIDc1MjUNCkEgIlJFQ09NTUVOREVEIiBmb3IgaW1wbGVt ZW50aW5nIHRoZSBtb3N0IHJlY2VudCB2ZXJzaW9uIG9mIFRMUyAoQXQgdGhlIG1vbWVudCwgVExT IDEuMykgYWxzbyBiZWluZyBzdXBwb3J0ZWQuDQoNClRoZSBub24tbm9ybWF0aXZlIHJlY29tbWVu ZGF0aW9uIHRoYXQgMC1SVFQgYmUgZGlzYWJsZWQgcmVtYWlucyB1bmNoYW5nZWQuIFdoZW4geW91 IG1lbnRpb24gdGhhdCAid2FpdGluZyBtYXkgYmUgd29ydGggaGF2aW5nIHRoZSBub3JtYXRpdmUg bGFuZ3VhZ2UiIGFyZSB5b3UgcmVmZXJyaW5nIHRvIHRoaXMgcmVjb21tZW5kYXRpb24gb3IgYW5v dGhlciByZXF1aXJlbWVudD8NCg0KVGhhbmtzLA0KU3RlcGhlbg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEthdGhsZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4u bW9yaWFydHkuaWV0ZkBnbWFpbC5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE5LCAy MDE3IDE6MTcgUE0NCj4gVG86IEJhbmdoYXJ0LCBTdGVwaGVuIEEuIChGZWQpIDxzdGVwaGVuLmJh bmdoYXJ0QG5pc3QuZ292Pg0KPiBDYzogTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdt YWlsLmNvbT47IG1pbGVAaWV0Zi5vcmc7IGRyYWZ0LQ0KPiBpZXRmLW1pbGUtcm9saWUuYWxsQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbWlsZV0gQXJ0YXJ0IGxhc3QgY2FsbCByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1taWxlLXJvbGllLTEwDQo+IA0KPiBIaSBTdGVwaGVuLA0KPiANCj4gT24gVGh1 LCBPY3QgMTksIDIwMTcgYXQgMTI6MjQgUE0sIEJhbmdoYXJ0LCBTdGVwaGVuIEEuIChGZWQpDQo+ IDxzdGVwaGVuLmJhbmdoYXJ0QG5pc3QuZ292PiB3cm90ZToNCj4gPiBNYXJ0aW4sDQo+ID4NCj4g PiBJJ3ZlIHB1dCB0aGUgcmVzdCBvZiBteSBjb21tZW50cyBpbmxpbmUsIGFuZCB1cGxvYWRlZCBh IC0xMSB2ZXJzaW9uIG9mDQo+IFJPTElFIHRvIHRoZSBHaXRodWIgd2l0aCB0aGUgY2hhbmdlcy4g UHJvdmlkaW5nIHRoZXJlIGFyZSBubyBhZGRpdGlvbmFsDQo+IG1ham9yIGNvbW1lbnRzIEknbGwg cG9zdCB0aGlzIHZlcnNpb24gdG8gZGF0YXRyYWNrZXIgdG9kYXkuDQo+ID4NCj4gPiBUaGFua3Mg YWdhaW4gZm9yIHRoZSBncmVhdCByZXZpZXcsDQo+ID4gU3RlcGhlbg0KPiA+DQo+ID4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IG1pbGUgW21haWx0bzptaWxlLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gVGhvbXNvbg0KPiA+PiBTZW50OiBNb25k YXksIE9jdG9iZXIgMDksIDIwMTcgMTowOCBBTQ0KPiA+PiBUbzogYXJ0QGlldGYub3JnDQo+ID4+ IENjOiBtaWxlQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBkcmFmdC1pZXRmLW1pbGUtcm9saWUu YWxsQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFttaWxlXSBBcnRhcnQgbGFzdCBjYWxsIHJldmll dyBvZiBkcmFmdC1pZXRmLW1pbGUtcm9saWUtMTANCj4gPj4NCj4gPj4gUmV2aWV3ZXI6IE1hcnRp biBUaG9tc29uDQo+ID4+IFJldmlldyByZXN1bHQ6IEFsbW9zdCBSZWFkeQ0KPiA+Pg0KPiA+PiBJ IGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCwgYW5kIC0gZGVzcGl0ZSB3aGF0IGFwcGVhcnMg dG8gYmUgYQ0KPiA+PiBsZW5ndGh5IGxpc3Qgb2YgaXNzdWVzIC0gSSB0aGluayB0aGF0IGl0IGlz IGluIHByZXR0eSBnb29kIHNoYXBlLg0KPiA+PiBJdCdzIGNsZWFyLCByZWFkYWJsZSwgYW5kIGFk ZHJlc3NlcyB0aGUgcmVxdWlyZW1lbnRzIHdlbGwuICBNb3N0IG9mDQo+ID4+IG15IGNvbW1lbnRz IHNob3VsZCBiZSB0cml2aWFsIHRvIHJlc29sdmUuDQo+ID4+DQo+ID4+IE1ham9yOg0KPiA+Pg0K PiA+PiBUaGUgZGVjaXNpb24gdG8gZGVmaW5lIGEgLndlbGwta25vd24gVVJJIHdpdGhvdXQgYSBk aXNjb3Zlcnkgc3RvcnkgaXMNCj4gPj4gLSBpbiBteSBvcGluaW9uIC0gaW5hZHZpc2FibGUuICBT dWNoIGEgcmVnaXN0cmF0aW9uIGlzIHVzdWFsbHkNCj4gPj4gYXBwcm9wcmlhdGUgaWYgeW91IGRl c2lnbiBhIHByb3RvY29sIHRoYXQgZGVwZW5kcyBvbiBkaXNjb3ZlcnkgYnkNCj4gPj4gaG9zdG5h bWUgYW5kIHBvcnQuICBBcyBzdWNoLCB0aGlzIGRvZXMgbm90IHVzZSB0aGF0IGF0IGFsbC4gIEEN Cj4gPj4gY29uZmlndXJhdGlvbiBzeXN0ZW0gY2FuIChhbmQgc2hvdWxkKSBhY2NlcHQgYSBjb21w bGV0ZSBVUkkgZm9yIHRoZQ0KPiA+PiBzZXJ2aWNlIGVuZHBvaW50LiAgSXQgd291bGQgYmUgYmV0 dGVyIHRvIGRlZmVyIGNyZWF0aW9uIG9mIHlldA0KPiA+PiBhbm90aGVyIC53ZWxsLWtub3duIFVS SSByZWdpc3RyYXRpb24gdW50aWwgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgY2VydGFpbg0KPiB0aGF0 IGRpc2NvdmVyeSByZXF1aXJlcyBpdC4NCj4gPg0KPiA+IERpc2N1c3NlZCBpbiBhIHNlcGFyYXRl IHRocmVhZC4NCj4gPg0KPiA+PiBUaGUgc2FtZSBjb21tZW50IGFwcGxpZXMgdG8gdGhlIC53ZWxs LWtub3duIHJlc291cmNlIGZvciB0aGUgY2F0ZWdvcnkNCj4gPj4gZG9jdW1lbnQuDQo+ID4+ICBH aXZlbiB0aGF0IHRoaXMgc29ydCBvZiBkb2N1bWVudCBpcyByZWFkaWx5IGRpc2NvdmVyYWJsZSB2 aWEgdGhlDQo+ID4+IHNlcnZpY2UgZG9jdW1lbnQsIEkgd291bGQgc2F5IHRoYXQgdGhlIG5lZWQg Zm9yIGEgLndlbGwta25vd24NCj4gPj4gcmVzb3VyY2UgaXMgbGVzcyB3ZWxsLSBqdXN0aWZpZWQg dGhhbiB0aGUgc2VydmljZSBkb2N1bWVudC4NCj4gPg0KPiA+IFdlIGFncmVlLCByZW1vdmVkIHRo ZSByZWdpc3RyYXRpb24gZm9yIHRoZSBjYXRlZ29yeSBkb2N1bWVudCBsb2NhdGlvbi4NCj4gPg0K PiA+PiBUaGUgcmVxdWlyZW1lbnRzIGluIFNlY3Rpb24gNS4zIG9uIFRMUyB1c2UgYXJlIHVubmVj ZXNzYXJpbHkgc3RyaWN0Lg0KPiA+PiBJdCdzIGdyZWF0IHRvIHJlY29tbWVuZCB0aGUgdXNlIG9m IFRMUyAxLjIsIGJ1dCBnaXZlbiB0aGF0IHRoZQ0KPiA+PiBkb2N1bWVudCBoYXMgbm8gcmVhbCBy ZXF1aXJlbWVudCBvbiBhbnkgcGFydGljdWxhciB2ZXJzaW9uIG9mIFRMUywNCj4gPj4gdGhlIHVz ZSBvZiAiTVVTVCIgaGVyZSBpcyBub3QgbmVlZGVkLiAgU2ltaWxhcmx5LCB0aGUgcHJvaGliaXRp b24gb24NCj4gPj4gdGhlIHVzZSBvZiAwLVJUVCBpcyBncm91bmRsZXNzLiAgVGhlIGxlbmd0aHkg bGlzdCBvZiByZXF1aXJlbWVudHMNCj4gPj4gYXJvdW5kIGNlcnRpZmljYXRlIHZhbGlkYXRpb24g b25seSByaXNrIGNyZWF0aW5nIGEgY29uZmxpY3Qgd2l0aA0KPiA+PiBhZHZpY2UgaW4gb3RoZXIg UkZDcy4gIE1hbnksIGlmIG5vdCBhbGwsIG9mIHRoZXNlIHJlcXVpcmVtZW50cyBhcmUNCj4gPj4g dHJhbnNpdGl2ZWx5IGluY2x1ZGVkIGJ5IHdheSBvZiByZWZlcmVuY2luZyBIVFRQUyBkb2N1bWVu dHMuICBJIHdvdWxkDQo+IHByZWZlciB0byBzZWUgdGhpcyBlbnRpcmUgc2VjdGlvbiByZWR1Y2Vk IHRvIGEgc2ltcGxlIFJGQyA3NTI1IHJlZmVyZW5jZS4NCj4gPg0KPiA+IFRoZSBtYWpvcml0eSBv ZiB0aGUgc2VjdGlvbiBoYXMgYmVlbiByZWR1Y2VkIHRvIGEgUkZDIDc1MjUgcmVmZXJlbmNlLiBX ZQ0KPiBiZWxpZXZlIHRoYXQgdGhlIGJlbmVmaXRzIHByb3ZpZGVkIGJ5IDAtUlRUIGRvbid0IG91 dHdlaWdoIHRoZSBsb3NzIG9mDQo+IGZvcndhcmQgc2VjcmVjeS4gVGhlIHRleHQgY3VycmVudGx5 IHBsYWNlcyB0aGlzIGFzIGEgc3VnZ2VzdGlvbiBmcm9tIHRoZQ0KPiBhdXRob3JzLCBhbmQgbm90 IGEgbm9ybWF0aXZlIHJlcXVpcmVtZW50Lg0KPiANCj4gVGhpcyBpcyBhIHN1YnN0YW50aWFsIGNo YW5nZSBhcyBhIHJlc3VsdCBvZiBqdXN0IG9uZSByZXZpZXdlci4gIFRoZSBvbmx5IHRoaW5nDQo+ IHRoZSBNVVNUIGRvZXMgaXMgaG9sZCB1cCBmaW5hbCBwdWJsaWNhdGlvbiB1bnRpbCBhbiBSRkMg IyBpcyBhc3NpZ25lZCBmb3IgVExTDQo+IDEuMy4gIFRMUyAxLjMgc2hvdWxkbid0IGJlIHRvbyBm YXIgb2ZmLCBzbyB3YWl0aW5nIG1heSBiZSB3b3J0aCBoYXZpbmcgdGhlDQo+IG5vcm1hdGl2ZSBs YW5ndWFnZS4gIEkgdGhpbmsgdGhpcyBpcyBvbmUgdGhlIFdHIG5lZWRzIHRvIHdlaWdoIGluIG9u IHRvDQo+IGNoYW5nZSBhbmQgdHJhZGVvZmZzIG9mIHdhaXRpbmcgZm9yIGZpbmFsIHB1YmxpY2F0 aW9uLiAgSXQncyBub3QganVzdCB0aGUgZWRpdG9ycw0KPiB0aGF0IHJlY29tbWVuZCB0aGlzLCBJ IGRvIGFzIGFtIHN1cmUgb3RoZXJzIGRvIGFzIHdlbGwuDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+ IEthdGhsZWVuDQo+ID4NCj4gPj4gVXNlciBhdXRoZW50aWNhdGlvbiBpcyB1bmRlci1zcGVjaWZp ZWQuDQo+ID4NCj4gPiBBcyBhbnkgcmVwb3NpdG9yeSB1c2luZyB1c2VyIGF1dGhlbnRpY2F0aW9u IGlzIGFscmVhZHkgaW5oZXJlbnRseSBwcmUtDQo+IGNvbW11bmljYXRpbmcgd2l0aCBpdHMgY29u c3VtZXJzLCB3ZSBmZWx0IHRoYXQgdW5kZXJzcGVjaWZ5aW5nDQo+IGF1dGhlbnRpY2F0aW9uIG1l Y2hhbmlzbXMgYWxsb3dlZCBmb3IgZWFjaCBzaGFyaW5nIGNvbnNvcnRpdW0gdG8gY29udHJvbA0K PiB0aGVpciBvd24gcmVwb3NpdG9yaWVzLiBXaGF0ZXZlciBzeXN0ZW0gdGhleSBhcmUgdXNpbmcg YWxyZWFkeSBmb3INCj4gaW50ZXJuYWwvZXh0ZXJuYWwgc2hhcmluZyBhdXRoZW50aWNhdGlvbiBj YW4gYmUgdXNlZCBoZXJlIGFzIGxvbmcgYXMgaXQgbWVldHMNCj4gdGhlIFJPTElFIHJlcXVpcmVt ZW50cy4NCj4gPg0KPiA+PiAqIFNlY3Rpb24gNS4zIG1hbmRhdGVzIHRoZSB1c2Ugb2YgVExTIGNp cGhlciBzdWl0ZXMgdGhhdCBzdXBwb3J0DQo+ID4+IGNsaWVudCBhdXRoZW50aWNhdGlvbiB1c2lu ZyBjZXJ0aWZpY2F0ZXMsIGJ1dCBvZmZlcnMgbm8gZnVydGhlcg0KPiA+PiBhZHZpY2UuICBBc2lk ZSBmcm9tIGJlaW5nIGFuIHVubmVjZXNzYXJ5IHJlcXVpcmVtZW50IC0gY2lwaGVyIHN1aXRlcw0K PiA+PiB0aGF0IHN1cHBvcnQgY2VydGlmaWNhdGUtIGJhc2VkIGF1dGhlbnRpY2F0aW9uIG9mIHNl cnZlcnMgYWxsIGFsbG93DQo+ID4+IGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gLSB0aGlzIHNv cnQgb2YgcmVxdWlyZW1lbnQgaXMgcmFyZWx5DQo+ID4+IHN1ZmZpY2llbnQgZm9yIGludGVyb3Bl cmF0aW9uLiAgRm9yIGluc3RhbmNlLCB5b3UgbmVlZCB0byBzcGVjaWZ5IGhvdw0KPiA+PiBhIHNl cnZlciB3aWxsIHJlcXVlc3QgYSBjZXJ0aWZpY2F0ZSBzdWNoIHRoYXQgY2xpZW50cyBjYW4gc2Vs ZWN0IHRoZQ0KPiA+PiBjb3JyZWN0IGNlcnRpZmljYXRlLiAgSWYgYSBjbGllbnQgYW5kIHNlcnZl ciBoYXZlIGFncmVlZCB0byBzaGFyZQ0KPiA+PiBpbmZvcm1hdGlvbiBvbiB0ZXJtcyB0aGF0IHJl bHkgb24gYXV0aGVudGljYXRpb24gb2YgY2xpZW50cywgaXQgaXMgYmV0dGVyIGZvcg0KPiB0aG9z ZSBwZWVycyB0byBhcnJhbmdlIHRoZSB0ZXJtcyBvbiB3aGljaCB0aGV5IHdpbGwgYXV0aGVudGlj YXRlLg0KPiA+DQo+ID4gUmVtb3ZlZCBjaXBoZXIgc3VpdGUgdGV4dCBhcyB0aGVzZSByZWNvbW1l bmRhdGlvbnMgYXJlIHByb3ZpZGVkIGJ5IFJGQw0KPiA3NTI1Lg0KPiA+DQo+ID4+ICogU2VjdGlv biA1LjQgdXNlcyAiU0hPVUxEIiByZWdhcmRpbmcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHVzaW5n DQo+ID4+IGZlZGVyYXRpb24sIGJ1dCBvZmZlcnMgbm8gaGludHMgYWJvdXQgd2hhdCB0aGlzIGVu dGFpbHMuICBJdCBhbHNvDQo+ID4+IHVzZXMgIlNIT1VMRCIgcmVnYXJkaW5nIGF1dGhvcml6YXRp b24gY2hlY2tzLCB3aGljaCBpc24ndCBhbg0KPiA+PiBpbnRlcm9wZXJhYmlsaXR5IHJlcXVpcmVt ZW50LiAgSXQncyBtb3JlIG9mIGEgImRvbid0IGJlIHNpbGx5IiB0eXBlDQo+ID4+IG9mIHJlcXVp cmVtZW50LCB3aGljaCBkb2Vzbid0IG5lZWQgdG8gYmUgd3JpdHRlbiBkb3duIGluIGFuIFJGQy4N Cj4gPg0KPiA+IFdoaWxlIGl0cyB0cnVlIHRoYXQgdGhpcyBpcyBhICJkb24ndCBkbyBhbnl0aGlu ZyBzdHVwaWQiIHJlcXVpcmVtZW50LCBJIHRoaW5rDQo+IHRoYXQgaXRzIHZhbHVhYmxlIGFzIGEg cmVtaW5kZXIgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBjaGVja3MgbmVlZCB0byBzdXBwb3J0DQo+ IGZ1bGwgZ3JhbnVsYXJpdHkgdGhyb3VnaCB0aGUgZW50aXJlIHJlc291cmNlIHRyZWUuDQo+ID4N Cj4gPj4gU2VjdGlvbiA1LjUgcHJvaGliaXRzIHRoZSB1c2Ugb2YgR0VUIG9uICIvIi4gIFRoaXMg cHJvaGliaXRzIHVzZSBvZg0KPiA+PiB0aGUgcmVzb3VyY2UgZm9yIG90aGVyIHB1cnBvc2VzLiAg SXQgc2VlbXMgcmVhc29uYWJsZSB0byBhY2NlcHQgUE9TVA0KPiA+PiBtZXNzYWdlcyBhcyBkZWZp bmVkIGluIFJGQyA2NTQ2LCBidXQgdGhpcyByZXF1aXJlbWVudCBpcyBvdmVybHkNCj4gPj4gc3Ry aWN0IChhbmQgZnVydGhlciBlbnRyZW5jaGVzIHRoZSB2aW9sYXRpb24gb2YgUkZDIDczMjApLiAg SWYsIGZvcg0KPiA+PiBpbnN0YW5jZSwgdGhlIHNlcnZlciBvcGVyYXRvciB3aXNoZXMgdG8gcHJv dmlkZSBIVE1MIGluIHJlc3BvbnNlIHRvIGENCj4gPj4gR0VUIHJlcXVlc3QgdG8gIi8iLCB0aGlz IHdvdWxkIHByb2hpYml0IHRoYXQuICBUaGUgcmVxdWlyZW1lbnQgdG8NCj4gPj4gcmV0dXJuIDQw NCBpZiBSRkMgNjU0NiBpcyBub3Qgc3VwcG9ydGVkIGlzIHdvcnNlOyBub3Qgc3VwcG9ydGluZyBS RkMNCj4gPj4gNjU0NiBtaWdodCBiZSBhIGNob2ljZSB0aGF0IGEgZGVwbG95bWVudCBtYWtlcyB0 byBhdm9pZCB0aGUgbmVlZCB0bw0KPiByZXNlcnZlICIvIiBmb3IgdGhhdCBwcm90b2NvbC4NCj4g Pg0KPiA+IENsZWFuZWQgdXAgdGhlIHRleHQgZGVzY3JpYmluZyB0aGlzIHJlcXVpcmVtZW50IHRv IGJlIG1vcmUgY2xlYXIgdGhhdCB0aGV5DQo+IG9ubHkgdHJpZ2dlciB3aGVuIGFuIGltcGxlbWVu dGF0aW9uIGhhcyBkZWNpZGVkIHRvIHN1cHBvcnQgUkZDIDY1NDYuDQo+IFJlbW92ZWQgdGhlIDQw NCByZXF1aXJlbWVudCB3aGVuIG5vdCBzdXBwb3J0aW5nIFJGQzY1NDYsIGFzIEkgYWdyZWUgdGhh dA0KPiBpdCB3YXMgb3Zlcmx5IHJlc3RyaWN0aXZlLg0KPiA+DQo+ID4+IEluIFNlY3Rpb24gNi4y LjMsIHdoYXQgaXMgdGhlIGFkdmFudGFnZSBvZiAicm9saWU6Zm9ybWF0IiBvdmVyIGhhdmluZw0K PiA+PiBhIHdlbGwtIGRlZmluZWQgbWVkaWEgdHlwZT8gIE1lZGlhIHR5cGVzIGNhbiB0YWtlIGFk dmFudGFnZSBvZg0KPiA+PiBjb250ZW50IG5lZ290aWF0aW9uLCBleGlzdGluZyBzdXBwb3J0IGlu IGxpbmsgcmVsYXRpb25zLCBhbmQgb3RoZXINCj4gPj4gZXhpc3RpbmcgdG9vbHMNCj4gDQo+IA0K PiANCj4gLS0NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gS2F0aGxlZW4NCg== From nobody Thu Oct 19 10:39:53 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 62FC0132031; Thu, 19 Oct 2017 10:39:46 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257D01329B5; Thu, 19 Oct 2017 10:39:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 BfNvac_nhd9f; Thu, 19 Oct 2017 10:39:43 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0132.outbound.protection.outlook.com [23.103.201.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A39132031; Thu, 19 Oct 2017 10:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8W3Jztahbb5AaIsVmobbRZ8KWWdHPL1FdU6KcrFPNOs=; b=udbv6zq5uQESaMS3ge32TVMVT51EVwkdrfkDt0HlCJM9YZ1qjSV29eIZpdnn2WcZNWYtf9HzUOTxRqdna9XAr5bIBQlCXoMXfbjt22X+p6xUFP/GsWfajZqhiKVunBaRQU+mQ0J2cpB16QAs09hfdJhuMh64Ep7ubK/nmfEK4xs= Received: from DM5PR09MB1307.namprd09.prod.outlook.com (10.172.34.141) by DM5PR09MB1308.namprd09.prod.outlook.com (10.172.35.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 19 Oct 2017 17:39:41 +0000 Received: from DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) by DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) with mapi id 15.20.0077.023; Thu, 19 Oct 2017 17:39:41 +0000 From: "Banghart, Stephen A. (Fed)" To: Kathleen Moriarty CC: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Thread-Topic: [mile] Artart last call review of draft-ietf-mile-rolie-10 Thread-Index: AQHTQLy5EiZhxIKVNkSNg/Bn547ThKLrUSVQgAAplICAAAQPsA== Date: Thu, 19 Oct 2017 17:39:41 +0000 Message-ID: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.219.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR09MB1308; 6:Jtouz6s8NWzRvCBH0rjAxUDHZRo22Jt2jyKO0WFJKPdViJvDAQi6s5WyO3OL+6kSKsetKukhDRIbGcEen994iZN5ZCc3uRDluyh7qKYmn4GROJB7WzUhpuARVZov9mc8HtpR3WrZLxvLLwisPQstZu7bQLegzeTj1c5k1cJ4FhtLFV8TItdneUbGis++Espawv+1Dd8TEGZEgHERCwAIS9FX4alxHeUYi9OtfyLHeQUaZiJc//GVJFHNb56rWTgcJy98aASa8VjuI5lhsv2iiUvuLKEASVZtUcOa8kIOfwkqtW7posz1fsKkT68n779OcE6qaXVRUk8WJpfMvyY7GA==; 5:+ns9M86txL4AMA22ffK6e2BWbWwUocRGgAKWOauRUV299t70LdIEB70lyp4SRk5zdTjyLuLX4MZKS4OCIES2fT+gB8enZsHtY9RvRkwY78eYmRbMhzvA/8E8iqQpIAkn7F4WD0qKQJIR8NEblnYXgg==; 24:Jedqnt51CiVg9rRqG3TeUam32J+VRCwb1KI/otQE4d8snrNtTAVWYmrYn0BW4j0uU6c9Nq53x+sxIOhTB4X90aW/BM8ID2+DDbotJxOniys=; 7:dBhPuB7AIFd5JxB273KJMoeFw9riw9dg13GFQLEnKAEfJSuIHzCsQd9myVnXX2jH2mVH7/528jl6gc4q50cOOH1b+OJojdumLK0hFVSIMFCgd9neqaY9ivDNVqkZQK4gR3HuNj3VWttTV7VjZwbIIjM9+GeAVJ5YOdZpYKj5xjUWko3gfQgS/c1XwuD2neKH/62iXk/1BxvG/gN5p1vE1CuMuczbFH4OnerUGrgLNiA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 48ee1762-c0fb-44c5-f2d7-08d5171860b6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254172)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(48565401081)(2017052603199)(201703131423095); SRVR:DM5PR09MB1308; x-ms-traffictypediagnostic: DM5PR09MB1308: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(150554046322364); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR09MB1308; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR09MB1308; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(43784003)(24454002)(199003)(51444003)(189002)(13464003)(50986999)(3846002)(2900100001)(54356999)(76176999)(6116002)(102836003)(305945005)(106356001)(105586002)(7736002)(230783001)(74316002)(189998001)(101416001)(14454004)(81166006)(8676002)(7696004)(81156014)(2950100002)(68736007)(3280700002)(6506006)(6436002)(6916009)(229853002)(77096006)(3660700001)(97736004)(33656002)(2906002)(53546010)(66066001)(8936002)(54906003)(9686003)(6246003)(39060400002)(316002)(86362001)(4326008)(55016002)(99286003)(25786009)(5660300001)(478600001)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1308; H:DM5PR09MB1307.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 17:39:41.0330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1308 Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171019173946.62FC0132031@ietfa.amsl.com> Resent-Date: Thu, 19 Oct 2017 10:39:46 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 17:39:46 -0000 S2F0aGxlZW4sDQoNCkp1c3QgdG8gY2xhcmlmeSwgdGhlcmUgd2VyZSBubyBub3JtYXRpdmUgY2hh bmdlcyB0byB0aGUgdXNlIG9mIFRMUyAxLjMgb3IgVExTIDEuMiBpbiB0aGlzIC0xMSB1cGRhdGUu IFRoZSBsYXR0ZXIgdGhyZWUgcGFyYWdyYXBocyB3ZXJlIHRydW5jYXRlZCBhcyBpdCB3YXMgZHVw bGljYXRlZCB0ZXh0IG91dCBvZiBSRkMgNzUyNSBhbmQgUkZDIDc1ODkuDQoNClRoZSBub3JtYXRp dmUgcmVxdWlyZW1lbnRzIGZvciBUTFMgcmVtYWluIGFzIGZvbGxvd3M6DQoNCkEgIk1VU1QiIGZv ciBpbXBsZW1lbnRpbmcgVExTIDEuMiB3aXRoIGEgIlNIT1VMRCIgZm9yIGZvbGxvd2luZyB0aGUg QkNQcyBhcyBkZXNjcmliZWQgaW4gUkZDIDc1MjUNCkEgIlJFQ09NTUVOREVEIiBmb3IgaW1wbGVt ZW50aW5nIHRoZSBtb3N0IHJlY2VudCB2ZXJzaW9uIG9mIFRMUyAoQXQgdGhlIG1vbWVudCwgVExT IDEuMykgYWxzbyBiZWluZyBzdXBwb3J0ZWQuDQoNClRoZSBub24tbm9ybWF0aXZlIHJlY29tbWVu ZGF0aW9uIHRoYXQgMC1SVFQgYmUgZGlzYWJsZWQgcmVtYWlucyB1bmNoYW5nZWQuIFdoZW4geW91 IG1lbnRpb24gdGhhdCAid2FpdGluZyBtYXkgYmUgd29ydGggaGF2aW5nIHRoZSBub3JtYXRpdmUg bGFuZ3VhZ2UiIGFyZSB5b3UgcmVmZXJyaW5nIHRvIHRoaXMgcmVjb21tZW5kYXRpb24gb3IgYW5v dGhlciByZXF1aXJlbWVudD8NCg0KVGhhbmtzLA0KU3RlcGhlbg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEthdGhsZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4u bW9yaWFydHkuaWV0ZkBnbWFpbC5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE5LCAy MDE3IDE6MTcgUE0NCj4gVG86IEJhbmdoYXJ0LCBTdGVwaGVuIEEuIChGZWQpIDxzdGVwaGVuLmJh bmdoYXJ0QG5pc3QuZ292Pg0KPiBDYzogTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdt YWlsLmNvbT47IG1pbGVAaWV0Zi5vcmc7IGRyYWZ0LQ0KPiBpZXRmLW1pbGUtcm9saWUuYWxsQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbWlsZV0gQXJ0YXJ0IGxhc3QgY2FsbCByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1taWxlLXJvbGllLTEwDQo+IA0KPiBIaSBTdGVwaGVuLA0KPiANCj4gT24gVGh1 LCBPY3QgMTksIDIwMTcgYXQgMTI6MjQgUE0sIEJhbmdoYXJ0LCBTdGVwaGVuIEEuIChGZWQpDQo+ IDxzdGVwaGVuLmJhbmdoYXJ0QG5pc3QuZ292PiB3cm90ZToNCj4gPiBNYXJ0aW4sDQo+ID4NCj4g PiBJJ3ZlIHB1dCB0aGUgcmVzdCBvZiBteSBjb21tZW50cyBpbmxpbmUsIGFuZCB1cGxvYWRlZCBh IC0xMSB2ZXJzaW9uIG9mDQo+IFJPTElFIHRvIHRoZSBHaXRodWIgd2l0aCB0aGUgY2hhbmdlcy4g UHJvdmlkaW5nIHRoZXJlIGFyZSBubyBhZGRpdGlvbmFsDQo+IG1ham9yIGNvbW1lbnRzIEknbGwg cG9zdCB0aGlzIHZlcnNpb24gdG8gZGF0YXRyYWNrZXIgdG9kYXkuDQo+ID4NCj4gPiBUaGFua3Mg YWdhaW4gZm9yIHRoZSBncmVhdCByZXZpZXcsDQo+ID4gU3RlcGhlbg0KPiA+DQo+ID4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IG1pbGUgW21haWx0bzptaWxlLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gVGhvbXNvbg0KPiA+PiBTZW50OiBNb25k YXksIE9jdG9iZXIgMDksIDIwMTcgMTowOCBBTQ0KPiA+PiBUbzogYXJ0QGlldGYub3JnDQo+ID4+ IENjOiBtaWxlQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBkcmFmdC1pZXRmLW1pbGUtcm9saWUu YWxsQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFttaWxlXSBBcnRhcnQgbGFzdCBjYWxsIHJldmll dyBvZiBkcmFmdC1pZXRmLW1pbGUtcm9saWUtMTANCj4gPj4NCj4gPj4gUmV2aWV3ZXI6IE1hcnRp biBUaG9tc29uDQo+ID4+IFJldmlldyByZXN1bHQ6IEFsbW9zdCBSZWFkeQ0KPiA+Pg0KPiA+PiBJ IGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCwgYW5kIC0gZGVzcGl0ZSB3aGF0IGFwcGVhcnMg dG8gYmUgYQ0KPiA+PiBsZW5ndGh5IGxpc3Qgb2YgaXNzdWVzIC0gSSB0aGluayB0aGF0IGl0IGlz IGluIHByZXR0eSBnb29kIHNoYXBlLg0KPiA+PiBJdCdzIGNsZWFyLCByZWFkYWJsZSwgYW5kIGFk ZHJlc3NlcyB0aGUgcmVxdWlyZW1lbnRzIHdlbGwuICBNb3N0IG9mDQo+ID4+IG15IGNvbW1lbnRz IHNob3VsZCBiZSB0cml2aWFsIHRvIHJlc29sdmUuDQo+ID4+DQo+ID4+IE1ham9yOg0KPiA+Pg0K PiA+PiBUaGUgZGVjaXNpb24gdG8gZGVmaW5lIGEgLndlbGwta25vd24gVVJJIHdpdGhvdXQgYSBk aXNjb3Zlcnkgc3RvcnkgaXMNCj4gPj4gLSBpbiBteSBvcGluaW9uIC0gaW5hZHZpc2FibGUuICBT dWNoIGEgcmVnaXN0cmF0aW9uIGlzIHVzdWFsbHkNCj4gPj4gYXBwcm9wcmlhdGUgaWYgeW91IGRl c2lnbiBhIHByb3RvY29sIHRoYXQgZGVwZW5kcyBvbiBkaXNjb3ZlcnkgYnkNCj4gPj4gaG9zdG5h bWUgYW5kIHBvcnQuICBBcyBzdWNoLCB0aGlzIGRvZXMgbm90IHVzZSB0aGF0IGF0IGFsbC4gIEEN Cj4gPj4gY29uZmlndXJhdGlvbiBzeXN0ZW0gY2FuIChhbmQgc2hvdWxkKSBhY2NlcHQgYSBjb21w bGV0ZSBVUkkgZm9yIHRoZQ0KPiA+PiBzZXJ2aWNlIGVuZHBvaW50LiAgSXQgd291bGQgYmUgYmV0 dGVyIHRvIGRlZmVyIGNyZWF0aW9uIG9mIHlldA0KPiA+PiBhbm90aGVyIC53ZWxsLWtub3duIFVS SSByZWdpc3RyYXRpb24gdW50aWwgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgY2VydGFpbg0KPiB0aGF0 IGRpc2NvdmVyeSByZXF1aXJlcyBpdC4NCj4gPg0KPiA+IERpc2N1c3NlZCBpbiBhIHNlcGFyYXRl IHRocmVhZC4NCj4gPg0KPiA+PiBUaGUgc2FtZSBjb21tZW50IGFwcGxpZXMgdG8gdGhlIC53ZWxs LWtub3duIHJlc291cmNlIGZvciB0aGUgY2F0ZWdvcnkNCj4gPj4gZG9jdW1lbnQuDQo+ID4+ICBH aXZlbiB0aGF0IHRoaXMgc29ydCBvZiBkb2N1bWVudCBpcyByZWFkaWx5IGRpc2NvdmVyYWJsZSB2 aWEgdGhlDQo+ID4+IHNlcnZpY2UgZG9jdW1lbnQsIEkgd291bGQgc2F5IHRoYXQgdGhlIG5lZWQg Zm9yIGEgLndlbGwta25vd24NCj4gPj4gcmVzb3VyY2UgaXMgbGVzcyB3ZWxsLSBqdXN0aWZpZWQg dGhhbiB0aGUgc2VydmljZSBkb2N1bWVudC4NCj4gPg0KPiA+IFdlIGFncmVlLCByZW1vdmVkIHRo ZSByZWdpc3RyYXRpb24gZm9yIHRoZSBjYXRlZ29yeSBkb2N1bWVudCBsb2NhdGlvbi4NCj4gPg0K PiA+PiBUaGUgcmVxdWlyZW1lbnRzIGluIFNlY3Rpb24gNS4zIG9uIFRMUyB1c2UgYXJlIHVubmVj ZXNzYXJpbHkgc3RyaWN0Lg0KPiA+PiBJdCdzIGdyZWF0IHRvIHJlY29tbWVuZCB0aGUgdXNlIG9m IFRMUyAxLjIsIGJ1dCBnaXZlbiB0aGF0IHRoZQ0KPiA+PiBkb2N1bWVudCBoYXMgbm8gcmVhbCBy ZXF1aXJlbWVudCBvbiBhbnkgcGFydGljdWxhciB2ZXJzaW9uIG9mIFRMUywNCj4gPj4gdGhlIHVz ZSBvZiAiTVVTVCIgaGVyZSBpcyBub3QgbmVlZGVkLiAgU2ltaWxhcmx5LCB0aGUgcHJvaGliaXRp b24gb24NCj4gPj4gdGhlIHVzZSBvZiAwLVJUVCBpcyBncm91bmRsZXNzLiAgVGhlIGxlbmd0aHkg bGlzdCBvZiByZXF1aXJlbWVudHMNCj4gPj4gYXJvdW5kIGNlcnRpZmljYXRlIHZhbGlkYXRpb24g b25seSByaXNrIGNyZWF0aW5nIGEgY29uZmxpY3Qgd2l0aA0KPiA+PiBhZHZpY2UgaW4gb3RoZXIg UkZDcy4gIE1hbnksIGlmIG5vdCBhbGwsIG9mIHRoZXNlIHJlcXVpcmVtZW50cyBhcmUNCj4gPj4g dHJhbnNpdGl2ZWx5IGluY2x1ZGVkIGJ5IHdheSBvZiByZWZlcmVuY2luZyBIVFRQUyBkb2N1bWVu dHMuICBJIHdvdWxkDQo+IHByZWZlciB0byBzZWUgdGhpcyBlbnRpcmUgc2VjdGlvbiByZWR1Y2Vk IHRvIGEgc2ltcGxlIFJGQyA3NTI1IHJlZmVyZW5jZS4NCj4gPg0KPiA+IFRoZSBtYWpvcml0eSBv ZiB0aGUgc2VjdGlvbiBoYXMgYmVlbiByZWR1Y2VkIHRvIGEgUkZDIDc1MjUgcmVmZXJlbmNlLiBX ZQ0KPiBiZWxpZXZlIHRoYXQgdGhlIGJlbmVmaXRzIHByb3ZpZGVkIGJ5IDAtUlRUIGRvbid0IG91 dHdlaWdoIHRoZSBsb3NzIG9mDQo+IGZvcndhcmQgc2VjcmVjeS4gVGhlIHRleHQgY3VycmVudGx5 IHBsYWNlcyB0aGlzIGFzIGEgc3VnZ2VzdGlvbiBmcm9tIHRoZQ0KPiBhdXRob3JzLCBhbmQgbm90 IGEgbm9ybWF0aXZlIHJlcXVpcmVtZW50Lg0KPiANCj4gVGhpcyBpcyBhIHN1YnN0YW50aWFsIGNo YW5nZSBhcyBhIHJlc3VsdCBvZiBqdXN0IG9uZSByZXZpZXdlci4gIFRoZSBvbmx5IHRoaW5nDQo+ IHRoZSBNVVNUIGRvZXMgaXMgaG9sZCB1cCBmaW5hbCBwdWJsaWNhdGlvbiB1bnRpbCBhbiBSRkMg IyBpcyBhc3NpZ25lZCBmb3IgVExTDQo+IDEuMy4gIFRMUyAxLjMgc2hvdWxkbid0IGJlIHRvbyBm YXIgb2ZmLCBzbyB3YWl0aW5nIG1heSBiZSB3b3J0aCBoYXZpbmcgdGhlDQo+IG5vcm1hdGl2ZSBs YW5ndWFnZS4gIEkgdGhpbmsgdGhpcyBpcyBvbmUgdGhlIFdHIG5lZWRzIHRvIHdlaWdoIGluIG9u IHRvDQo+IGNoYW5nZSBhbmQgdHJhZGVvZmZzIG9mIHdhaXRpbmcgZm9yIGZpbmFsIHB1YmxpY2F0 aW9uLiAgSXQncyBub3QganVzdCB0aGUgZWRpdG9ycw0KPiB0aGF0IHJlY29tbWVuZCB0aGlzLCBJ IGRvIGFzIGFtIHN1cmUgb3RoZXJzIGRvIGFzIHdlbGwuDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+ IEthdGhsZWVuDQo+ID4NCj4gPj4gVXNlciBhdXRoZW50aWNhdGlvbiBpcyB1bmRlci1zcGVjaWZp ZWQuDQo+ID4NCj4gPiBBcyBhbnkgcmVwb3NpdG9yeSB1c2luZyB1c2VyIGF1dGhlbnRpY2F0aW9u IGlzIGFscmVhZHkgaW5oZXJlbnRseSBwcmUtDQo+IGNvbW11bmljYXRpbmcgd2l0aCBpdHMgY29u c3VtZXJzLCB3ZSBmZWx0IHRoYXQgdW5kZXJzcGVjaWZ5aW5nDQo+IGF1dGhlbnRpY2F0aW9uIG1l Y2hhbmlzbXMgYWxsb3dlZCBmb3IgZWFjaCBzaGFyaW5nIGNvbnNvcnRpdW0gdG8gY29udHJvbA0K PiB0aGVpciBvd24gcmVwb3NpdG9yaWVzLiBXaGF0ZXZlciBzeXN0ZW0gdGhleSBhcmUgdXNpbmcg YWxyZWFkeSBmb3INCj4gaW50ZXJuYWwvZXh0ZXJuYWwgc2hhcmluZyBhdXRoZW50aWNhdGlvbiBj YW4gYmUgdXNlZCBoZXJlIGFzIGxvbmcgYXMgaXQgbWVldHMNCj4gdGhlIFJPTElFIHJlcXVpcmVt ZW50cy4NCj4gPg0KPiA+PiAqIFNlY3Rpb24gNS4zIG1hbmRhdGVzIHRoZSB1c2Ugb2YgVExTIGNp cGhlciBzdWl0ZXMgdGhhdCBzdXBwb3J0DQo+ID4+IGNsaWVudCBhdXRoZW50aWNhdGlvbiB1c2lu ZyBjZXJ0aWZpY2F0ZXMsIGJ1dCBvZmZlcnMgbm8gZnVydGhlcg0KPiA+PiBhZHZpY2UuICBBc2lk ZSBmcm9tIGJlaW5nIGFuIHVubmVjZXNzYXJ5IHJlcXVpcmVtZW50IC0gY2lwaGVyIHN1aXRlcw0K PiA+PiB0aGF0IHN1cHBvcnQgY2VydGlmaWNhdGUtIGJhc2VkIGF1dGhlbnRpY2F0aW9uIG9mIHNl cnZlcnMgYWxsIGFsbG93DQo+ID4+IGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gLSB0aGlzIHNv cnQgb2YgcmVxdWlyZW1lbnQgaXMgcmFyZWx5DQo+ID4+IHN1ZmZpY2llbnQgZm9yIGludGVyb3Bl cmF0aW9uLiAgRm9yIGluc3RhbmNlLCB5b3UgbmVlZCB0byBzcGVjaWZ5IGhvdw0KPiA+PiBhIHNl cnZlciB3aWxsIHJlcXVlc3QgYSBjZXJ0aWZpY2F0ZSBzdWNoIHRoYXQgY2xpZW50cyBjYW4gc2Vs ZWN0IHRoZQ0KPiA+PiBjb3JyZWN0IGNlcnRpZmljYXRlLiAgSWYgYSBjbGllbnQgYW5kIHNlcnZl ciBoYXZlIGFncmVlZCB0byBzaGFyZQ0KPiA+PiBpbmZvcm1hdGlvbiBvbiB0ZXJtcyB0aGF0IHJl bHkgb24gYXV0aGVudGljYXRpb24gb2YgY2xpZW50cywgaXQgaXMgYmV0dGVyIGZvcg0KPiB0aG9z ZSBwZWVycyB0byBhcnJhbmdlIHRoZSB0ZXJtcyBvbiB3aGljaCB0aGV5IHdpbGwgYXV0aGVudGlj YXRlLg0KPiA+DQo+ID4gUmVtb3ZlZCBjaXBoZXIgc3VpdGUgdGV4dCBhcyB0aGVzZSByZWNvbW1l bmRhdGlvbnMgYXJlIHByb3ZpZGVkIGJ5IFJGQw0KPiA3NTI1Lg0KPiA+DQo+ID4+ICogU2VjdGlv biA1LjQgdXNlcyAiU0hPVUxEIiByZWdhcmRpbmcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHVzaW5n DQo+ID4+IGZlZGVyYXRpb24sIGJ1dCBvZmZlcnMgbm8gaGludHMgYWJvdXQgd2hhdCB0aGlzIGVu dGFpbHMuICBJdCBhbHNvDQo+ID4+IHVzZXMgIlNIT1VMRCIgcmVnYXJkaW5nIGF1dGhvcml6YXRp b24gY2hlY2tzLCB3aGljaCBpc24ndCBhbg0KPiA+PiBpbnRlcm9wZXJhYmlsaXR5IHJlcXVpcmVt ZW50LiAgSXQncyBtb3JlIG9mIGEgImRvbid0IGJlIHNpbGx5IiB0eXBlDQo+ID4+IG9mIHJlcXVp cmVtZW50LCB3aGljaCBkb2Vzbid0IG5lZWQgdG8gYmUgd3JpdHRlbiBkb3duIGluIGFuIFJGQy4N Cj4gPg0KPiA+IFdoaWxlIGl0cyB0cnVlIHRoYXQgdGhpcyBpcyBhICJkb24ndCBkbyBhbnl0aGlu ZyBzdHVwaWQiIHJlcXVpcmVtZW50LCBJIHRoaW5rDQo+IHRoYXQgaXRzIHZhbHVhYmxlIGFzIGEg cmVtaW5kZXIgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBjaGVja3MgbmVlZCB0byBzdXBwb3J0DQo+ IGZ1bGwgZ3JhbnVsYXJpdHkgdGhyb3VnaCB0aGUgZW50aXJlIHJlc291cmNlIHRyZWUuDQo+ID4N Cj4gPj4gU2VjdGlvbiA1LjUgcHJvaGliaXRzIHRoZSB1c2Ugb2YgR0VUIG9uICIvIi4gIFRoaXMg cHJvaGliaXRzIHVzZSBvZg0KPiA+PiB0aGUgcmVzb3VyY2UgZm9yIG90aGVyIHB1cnBvc2VzLiAg SXQgc2VlbXMgcmVhc29uYWJsZSB0byBhY2NlcHQgUE9TVA0KPiA+PiBtZXNzYWdlcyBhcyBkZWZp bmVkIGluIFJGQyA2NTQ2LCBidXQgdGhpcyByZXF1aXJlbWVudCBpcyBvdmVybHkNCj4gPj4gc3Ry aWN0IChhbmQgZnVydGhlciBlbnRyZW5jaGVzIHRoZSB2aW9sYXRpb24gb2YgUkZDIDczMjApLiAg SWYsIGZvcg0KPiA+PiBpbnN0YW5jZSwgdGhlIHNlcnZlciBvcGVyYXRvciB3aXNoZXMgdG8gcHJv dmlkZSBIVE1MIGluIHJlc3BvbnNlIHRvIGENCj4gPj4gR0VUIHJlcXVlc3QgdG8gIi8iLCB0aGlz IHdvdWxkIHByb2hpYml0IHRoYXQuICBUaGUgcmVxdWlyZW1lbnQgdG8NCj4gPj4gcmV0dXJuIDQw NCBpZiBSRkMgNjU0NiBpcyBub3Qgc3VwcG9ydGVkIGlzIHdvcnNlOyBub3Qgc3VwcG9ydGluZyBS RkMNCj4gPj4gNjU0NiBtaWdodCBiZSBhIGNob2ljZSB0aGF0IGEgZGVwbG95bWVudCBtYWtlcyB0 byBhdm9pZCB0aGUgbmVlZCB0bw0KPiByZXNlcnZlICIvIiBmb3IgdGhhdCBwcm90b2NvbC4NCj4g Pg0KPiA+IENsZWFuZWQgdXAgdGhlIHRleHQgZGVzY3JpYmluZyB0aGlzIHJlcXVpcmVtZW50IHRv IGJlIG1vcmUgY2xlYXIgdGhhdCB0aGV5DQo+IG9ubHkgdHJpZ2dlciB3aGVuIGFuIGltcGxlbWVu dGF0aW9uIGhhcyBkZWNpZGVkIHRvIHN1cHBvcnQgUkZDIDY1NDYuDQo+IFJlbW92ZWQgdGhlIDQw NCByZXF1aXJlbWVudCB3aGVuIG5vdCBzdXBwb3J0aW5nIFJGQzY1NDYsIGFzIEkgYWdyZWUgdGhh dA0KPiBpdCB3YXMgb3Zlcmx5IHJlc3RyaWN0aXZlLg0KPiA+DQo+ID4+IEluIFNlY3Rpb24gNi4y LjMsIHdoYXQgaXMgdGhlIGFkdmFudGFnZSBvZiAicm9saWU6Zm9ybWF0IiBvdmVyIGhhdmluZw0K PiA+PiBhIHdlbGwtIGRlZmluZWQgbWVkaWEgdHlwZT8gIE1lZGlhIHR5cGVzIGNhbiB0YWtlIGFk dmFudGFnZSBvZg0KPiA+PiBjb250ZW50IG5lZ290aWF0aW9uLCBleGlzdGluZyBzdXBwb3J0IGlu IGxpbmsgcmVsYXRpb25zLCBhbmQgb3RoZXINCj4gPj4gZXhpc3RpbmcgdG9vbHMNCj4gDQo+IA0K PiANCj4gLS0NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gS2F0aGxlZW4NCg== From nobody Thu Oct 19 11:24:31 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D74126E64; Thu, 19 Oct 2017 11:24:29 -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 SBPFoSBeHvLa; Thu, 19 Oct 2017 11:24:27 -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 87DD313239C; Thu, 19 Oct 2017 11:24:27 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id b79so7182082pfk.5; Thu, 19 Oct 2017 11:24: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=8FMJEfQF3D2VS/7FWYGlnxy9CLNrGEEYEdarXOebSHI=; b=sHdXdULqmnLYejY4pv2dj2/vFqjExisWdFatP396r8duvh6ysNOSAHz+OTsAjqAIoj sos1s4MLrGwUyQCH1K/2blx7IWkGGk2bML2chE3qXtEwEAeioKXzSXQf1Nu1W/pXTFcG 6lqgp6gORRKosOcLhexTghZY4ZhoE2uqKSfN6ZbzM3yWneRGRObXlPWNyPRcJk7j3JJ6 yiVXlPqYTDcyJAT5Y5if/Y4qzl2QpyX/gZDUb5NBZNhFyVf+Uo5CUVQp3VHK2PByvmWK yz5kFCPswKr+x7NCDDn5dlRMgV7r7OXt/0A1BzBwabymvzZPON9gVk27WL6DstVdeFUx KoOg== 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=8FMJEfQF3D2VS/7FWYGlnxy9CLNrGEEYEdarXOebSHI=; b=rq3feQqfJqQVEfCnS7oBrS+ESqU8+JftbL2vB9LciGgSrhWJ+bQuiFLtQZlaKtieCR UANkQjjJ+h97rBAm5vxtzSucvxBt/iedlPOyYXyZAmTRUofTrEQFXZnX0aCAsbon0882 inLiJbS8gGOciU53x1KawaRwSyL3smZJyXG/xOJOQTro8yjNgX8F11Qx9HUIowOXEmTV 5APhwUqFa/W7Jm5OU+8NoTR6h3tOyrhJi2nusTlFjCo0X8J0zsyXg9mHZN8t3usiBkq/ vtEycnFF0qlNnCwb7XB6/UmGggZgORH9WU3R7UeN0GF6jQ3Ks3Qj8aOV0Qg1zC8MtpZp o9jA== X-Gm-Message-State: AMCzsaX+4abZEdjPRrA3jQP0+Df37AqtZBw16lvPKXEP9S6Dr6MfiZtm dPKeiAH5XrgpHFlFbE0y3DR6kX/BFNnDenjqC68= X-Google-Smtp-Source: ABhQp+QqmihL8v78BaxXLKdgltFAAlKsLdlUPfc/WxGkEgEfInkW0X5/ZNtBg1jzf83KnT3D952B9ADuD4v+lJZNHms= X-Received: by 10.101.83.12 with SMTP id m12mr2039708pgq.153.1508437467007; Thu, 19 Oct 2017 11:24:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Thu, 19 Oct 2017 11:23:46 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> From: Kathleen Moriarty Date: Thu, 19 Oct 2017 14:23:46 -0400 Message-ID: To: "Banghart, Stephen A. (Fed)" Cc: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 18:24:29 -0000 Hi Stephen, On Thu, Oct 19, 2017 at 1:39 PM, Banghart, Stephen A. (Fed) wrote: > Kathleen, > > Just to clarify, there were no normative changes to the use of TLS 1.3 or TLS 1.2 in this -11 update. The latter three paragraphs were truncated as it was duplicated text out of RFC 7525 and RFC 7589. > > The normative requirements for TLS remain as follows: > > A "MUST" for implementing TLS 1.2 with a "SHOULD" for following the BCPs as described in RFC 7525 > A "RECOMMENDED" for implementing the most recent version of TLS (At the moment, TLS 1.3) also being supported. > > The non-normative recommendation that 0-RTT be disabled remains unchanged. When you mention that "waiting may be worth having the normative language" are you referring to this recommendation or another requirement? I should have looked back at the draft. I thought you had a normative statement for 0-RTT and that it had changed from the phrasing in your email. If nothing of substance changed, then we're fine. Thanks, Kathleen > > Thanks, > Stephen > >> -----Original Message----- >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >> Sent: Thursday, October 19, 2017 1:17 PM >> To: Banghart, Stephen A. (Fed) >> Cc: Martin Thomson ; mile@ietf.org; draft- >> ietf-mile-rolie.all@ietf.org >> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 >> >> Hi Stephen, >> >> On Thu, Oct 19, 2017 at 12:24 PM, Banghart, Stephen A. (Fed) >> wrote: >> > Martin, >> > >> > I've put the rest of my comments inline, and uploaded a -11 version of >> ROLIE to the Github with the changes. Providing there are no additional >> major comments I'll post this version to datatracker today. >> > >> > Thanks again for the great review, >> > Stephen >> > >> >> -----Original Message----- >> >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin Thomson >> >> Sent: Monday, October 09, 2017 1:08 AM >> >> To: art@ietf.org >> >> Cc: mile@ietf.org; ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org >> >> Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 >> >> >> >> Reviewer: Martin Thomson >> >> Review result: Almost Ready >> >> >> >> I have reviewed this document, and - despite what appears to be a >> >> lengthy list of issues - I think that it is in pretty good shape. >> >> It's clear, readable, and addresses the requirements well. Most of >> >> my comments should be trivial to resolve. >> >> >> >> Major: >> >> >> >> The decision to define a .well-known URI without a discovery story is >> >> - in my opinion - inadvisable. Such a registration is usually >> >> appropriate if you design a protocol that depends on discovery by >> >> hostname and port. As such, this does not use that at all. A >> >> configuration system can (and should) accept a complete URI for the >> >> service endpoint. It would be better to defer creation of yet >> >> another .well-known URI registration until the working group is certain >> that discovery requires it. >> > >> > Discussed in a separate thread. >> > >> >> The same comment applies to the .well-known resource for the category >> >> document. >> >> Given that this sort of document is readily discoverable via the >> >> service document, I would say that the need for a .well-known >> >> resource is less well- justified than the service document. >> > >> > We agree, removed the registration for the category document location. >> > >> >> The requirements in Section 5.3 on TLS use are unnecessarily strict. >> >> It's great to recommend the use of TLS 1.2, but given that the >> >> document has no real requirement on any particular version of TLS, >> >> the use of "MUST" here is not needed. Similarly, the prohibition on >> >> the use of 0-RTT is groundless. The lengthy list of requirements >> >> around certificate validation only risk creating a conflict with >> >> advice in other RFCs. Many, if not all, of these requirements are >> >> transitively included by way of referencing HTTPS documents. I would >> prefer to see this entire section reduced to a simple RFC 7525 reference. >> > >> > The majority of the section has been reduced to a RFC 7525 reference. We >> believe that the benefits provided by 0-RTT don't outweigh the loss of >> forward secrecy. The text currently places this as a suggestion from the >> authors, and not a normative requirement. >> >> This is a substantial change as a result of just one reviewer. The only thing >> the MUST does is hold up final publication until an RFC # is assigned for TLS >> 1.3. TLS 1.3 shouldn't be too far off, so waiting may be worth having the >> normative language. I think this is one the WG needs to weigh in on to >> change and tradeoffs of waiting for final publication. It's not just the editors >> that recommend this, I do as am sure others do as well. >> >> Best regards, >> Kathleen >> > >> >> User authentication is under-specified. >> > >> > As any repository using user authentication is already inherently pre- >> communicating with its consumers, we felt that underspecifying >> authentication mechanisms allowed for each sharing consortium to control >> their own repositories. Whatever system they are using already for >> internal/external sharing authentication can be used here as long as it meets >> the ROLIE requirements. >> > >> >> * Section 5.3 mandates the use of TLS cipher suites that support >> >> client authentication using certificates, but offers no further >> >> advice. Aside from being an unnecessary requirement - cipher suites >> >> that support certificate- based authentication of servers all allow >> >> for client authentication - this sort of requirement is rarely >> >> sufficient for interoperation. For instance, you need to specify how >> >> a server will request a certificate such that clients can select the >> >> correct certificate. If a client and server have agreed to share >> >> information on terms that rely on authentication of clients, it is better for >> those peers to arrange the terms on which they will authenticate. >> > >> > Removed cipher suite text as these recommendations are provided by RFC >> 7525. >> > >> >> * Section 5.4 uses "SHOULD" regarding client authentication using >> >> federation, but offers no hints about what this entails. It also >> >> uses "SHOULD" regarding authorization checks, which isn't an >> >> interoperability requirement. It's more of a "don't be silly" type >> >> of requirement, which doesn't need to be written down in an RFC. >> > >> > While its true that this is a "don't do anything stupid" requirement, I think >> that its valuable as a reminder that the authorization checks need to support >> full granularity through the entire resource tree. >> > >> >> Section 5.5 prohibits the use of GET on "/". This prohibits use of >> >> the resource for other purposes. It seems reasonable to accept POST >> >> messages as defined in RFC 6546, but this requirement is overly >> >> strict (and further entrenches the violation of RFC 7320). If, for >> >> instance, the server operator wishes to provide HTML in response to a >> >> GET request to "/", this would prohibit that. The requirement to >> >> return 404 if RFC 6546 is not supported is worse; not supporting RFC >> >> 6546 might be a choice that a deployment makes to avoid the need to >> reserve "/" for that protocol. >> > >> > Cleaned up the text describing this requirement to be more clear that they >> only trigger when an implementation has decided to support RFC 6546. >> Removed the 404 requirement when not supporting RFC6546, as I agree that >> it was overly restrictive. >> > >> >> In Section 6.2.3, what is the advantage of "rolie:format" over having >> >> a well- defined media type? Media types can take advantage of >> >> content negotiation, existing support in link relations, and other >> >> existing tools >> >> >> >> -- >> >> Best regards, >> Kathleen -- Best regards, Kathleen From nobody Thu Oct 19 11:24:36 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6E8C913239C; Thu, 19 Oct 2017 11:24:29 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D74126E64; Thu, 19 Oct 2017 11:24:29 -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 SBPFoSBeHvLa; Thu, 19 Oct 2017 11:24:27 -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 87DD313239C; Thu, 19 Oct 2017 11:24:27 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id b79so7182082pfk.5; Thu, 19 Oct 2017 11:24: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=8FMJEfQF3D2VS/7FWYGlnxy9CLNrGEEYEdarXOebSHI=; b=sHdXdULqmnLYejY4pv2dj2/vFqjExisWdFatP396r8duvh6ysNOSAHz+OTsAjqAIoj sos1s4MLrGwUyQCH1K/2blx7IWkGGk2bML2chE3qXtEwEAeioKXzSXQf1Nu1W/pXTFcG 6lqgp6gORRKosOcLhexTghZY4ZhoE2uqKSfN6ZbzM3yWneRGRObXlPWNyPRcJk7j3JJ6 yiVXlPqYTDcyJAT5Y5if/Y4qzl2QpyX/gZDUb5NBZNhFyVf+Uo5CUVQp3VHK2PByvmWK yz5kFCPswKr+x7NCDDn5dlRMgV7r7OXt/0A1BzBwabymvzZPON9gVk27WL6DstVdeFUx KoOg== 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=8FMJEfQF3D2VS/7FWYGlnxy9CLNrGEEYEdarXOebSHI=; b=rq3feQqfJqQVEfCnS7oBrS+ESqU8+JftbL2vB9LciGgSrhWJ+bQuiFLtQZlaKtieCR UANkQjjJ+h97rBAm5vxtzSucvxBt/iedlPOyYXyZAmTRUofTrEQFXZnX0aCAsbon0882 inLiJbS8gGOciU53x1KawaRwSyL3smZJyXG/xOJOQTro8yjNgX8F11Qx9HUIowOXEmTV 5APhwUqFa/W7Jm5OU+8NoTR6h3tOyrhJi2nusTlFjCo0X8J0zsyXg9mHZN8t3usiBkq/ vtEycnFF0qlNnCwb7XB6/UmGggZgORH9WU3R7UeN0GF6jQ3Ks3Qj8aOV0Qg1zC8MtpZp o9jA== X-Gm-Message-State: AMCzsaX+4abZEdjPRrA3jQP0+Df37AqtZBw16lvPKXEP9S6Dr6MfiZtm dPKeiAH5XrgpHFlFbE0y3DR6kX/BFNnDenjqC68= X-Google-Smtp-Source: ABhQp+QqmihL8v78BaxXLKdgltFAAlKsLdlUPfc/WxGkEgEfInkW0X5/ZNtBg1jzf83KnT3D952B9ADuD4v+lJZNHms= X-Received: by 10.101.83.12 with SMTP id m12mr2039708pgq.153.1508437467007; Thu, 19 Oct 2017 11:24:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Thu, 19 Oct 2017 11:23:46 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> From: Kathleen Moriarty Date: Thu, 19 Oct 2017 14:23:46 -0400 Message-ID: To: "Banghart, Stephen A. (Fed)" Cc: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171019182429.6E8C913239C@ietfa.amsl.com> Resent-Date: Thu, 19 Oct 2017 11:24:29 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 18:24:29 -0000 Hi Stephen, On Thu, Oct 19, 2017 at 1:39 PM, Banghart, Stephen A. (Fed) wrote: > Kathleen, > > Just to clarify, there were no normative changes to the use of TLS 1.3 or TLS 1.2 in this -11 update. The latter three paragraphs were truncated as it was duplicated text out of RFC 7525 and RFC 7589. > > The normative requirements for TLS remain as follows: > > A "MUST" for implementing TLS 1.2 with a "SHOULD" for following the BCPs as described in RFC 7525 > A "RECOMMENDED" for implementing the most recent version of TLS (At the moment, TLS 1.3) also being supported. > > The non-normative recommendation that 0-RTT be disabled remains unchanged. When you mention that "waiting may be worth having the normative language" are you referring to this recommendation or another requirement? I should have looked back at the draft. I thought you had a normative statement for 0-RTT and that it had changed from the phrasing in your email. If nothing of substance changed, then we're fine. Thanks, Kathleen > > Thanks, > Stephen > >> -----Original Message----- >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >> Sent: Thursday, October 19, 2017 1:17 PM >> To: Banghart, Stephen A. (Fed) >> Cc: Martin Thomson ; mile@ietf.org; draft- >> ietf-mile-rolie.all@ietf.org >> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 >> >> Hi Stephen, >> >> On Thu, Oct 19, 2017 at 12:24 PM, Banghart, Stephen A. (Fed) >> wrote: >> > Martin, >> > >> > I've put the rest of my comments inline, and uploaded a -11 version of >> ROLIE to the Github with the changes. Providing there are no additional >> major comments I'll post this version to datatracker today. >> > >> > Thanks again for the great review, >> > Stephen >> > >> >> -----Original Message----- >> >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin Thomson >> >> Sent: Monday, October 09, 2017 1:08 AM >> >> To: art@ietf.org >> >> Cc: mile@ietf.org; ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org >> >> Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 >> >> >> >> Reviewer: Martin Thomson >> >> Review result: Almost Ready >> >> >> >> I have reviewed this document, and - despite what appears to be a >> >> lengthy list of issues - I think that it is in pretty good shape. >> >> It's clear, readable, and addresses the requirements well. Most of >> >> my comments should be trivial to resolve. >> >> >> >> Major: >> >> >> >> The decision to define a .well-known URI without a discovery story is >> >> - in my opinion - inadvisable. Such a registration is usually >> >> appropriate if you design a protocol that depends on discovery by >> >> hostname and port. As such, this does not use that at all. A >> >> configuration system can (and should) accept a complete URI for the >> >> service endpoint. It would be better to defer creation of yet >> >> another .well-known URI registration until the working group is certain >> that discovery requires it. >> > >> > Discussed in a separate thread. >> > >> >> The same comment applies to the .well-known resource for the category >> >> document. >> >> Given that this sort of document is readily discoverable via the >> >> service document, I would say that the need for a .well-known >> >> resource is less well- justified than the service document. >> > >> > We agree, removed the registration for the category document location. >> > >> >> The requirements in Section 5.3 on TLS use are unnecessarily strict. >> >> It's great to recommend the use of TLS 1.2, but given that the >> >> document has no real requirement on any particular version of TLS, >> >> the use of "MUST" here is not needed. Similarly, the prohibition on >> >> the use of 0-RTT is groundless. The lengthy list of requirements >> >> around certificate validation only risk creating a conflict with >> >> advice in other RFCs. Many, if not all, of these requirements are >> >> transitively included by way of referencing HTTPS documents. I would >> prefer to see this entire section reduced to a simple RFC 7525 reference. >> > >> > The majority of the section has been reduced to a RFC 7525 reference. We >> believe that the benefits provided by 0-RTT don't outweigh the loss of >> forward secrecy. The text currently places this as a suggestion from the >> authors, and not a normative requirement. >> >> This is a substantial change as a result of just one reviewer. The only thing >> the MUST does is hold up final publication until an RFC # is assigned for TLS >> 1.3. TLS 1.3 shouldn't be too far off, so waiting may be worth having the >> normative language. I think this is one the WG needs to weigh in on to >> change and tradeoffs of waiting for final publication. It's not just the editors >> that recommend this, I do as am sure others do as well. >> >> Best regards, >> Kathleen >> > >> >> User authentication is under-specified. >> > >> > As any repository using user authentication is already inherently pre- >> communicating with its consumers, we felt that underspecifying >> authentication mechanisms allowed for each sharing consortium to control >> their own repositories. Whatever system they are using already for >> internal/external sharing authentication can be used here as long as it meets >> the ROLIE requirements. >> > >> >> * Section 5.3 mandates the use of TLS cipher suites that support >> >> client authentication using certificates, but offers no further >> >> advice. Aside from being an unnecessary requirement - cipher suites >> >> that support certificate- based authentication of servers all allow >> >> for client authentication - this sort of requirement is rarely >> >> sufficient for interoperation. For instance, you need to specify how >> >> a server will request a certificate such that clients can select the >> >> correct certificate. If a client and server have agreed to share >> >> information on terms that rely on authentication of clients, it is better for >> those peers to arrange the terms on which they will authenticate. >> > >> > Removed cipher suite text as these recommendations are provided by RFC >> 7525. >> > >> >> * Section 5.4 uses "SHOULD" regarding client authentication using >> >> federation, but offers no hints about what this entails. It also >> >> uses "SHOULD" regarding authorization checks, which isn't an >> >> interoperability requirement. It's more of a "don't be silly" type >> >> of requirement, which doesn't need to be written down in an RFC. >> > >> > While its true that this is a "don't do anything stupid" requirement, I think >> that its valuable as a reminder that the authorization checks need to support >> full granularity through the entire resource tree. >> > >> >> Section 5.5 prohibits the use of GET on "/". This prohibits use of >> >> the resource for other purposes. It seems reasonable to accept POST >> >> messages as defined in RFC 6546, but this requirement is overly >> >> strict (and further entrenches the violation of RFC 7320). If, for >> >> instance, the server operator wishes to provide HTML in response to a >> >> GET request to "/", this would prohibit that. The requirement to >> >> return 404 if RFC 6546 is not supported is worse; not supporting RFC >> >> 6546 might be a choice that a deployment makes to avoid the need to >> reserve "/" for that protocol. >> > >> > Cleaned up the text describing this requirement to be more clear that they >> only trigger when an implementation has decided to support RFC 6546. >> Removed the 404 requirement when not supporting RFC6546, as I agree that >> it was overly restrictive. >> > >> >> In Section 6.2.3, what is the advantage of "rolie:format" over having >> >> a well- defined media type? Media types can take advantage of >> >> content negotiation, existing support in link relations, and other >> >> existing tools >> >> >> >> -- >> >> Best regards, >> Kathleen -- Best regards, Kathleen From nobody Thu Oct 19 12:04:31 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0021321C7 for ; Thu, 19 Oct 2017 12:04:29 -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, HTML_MESSAGE=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 Mlr2GmfgQQtw for ; Thu, 19 Oct 2017 12:04:24 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 8321B13293A for ; Thu, 19 Oct 2017 12:04:24 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id g69so5997666vke.5 for ; Thu, 19 Oct 2017 12:04:24 -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; bh=O5ejVzQjCCcoSfX5EloxcZZE/nHz75LHYnDtuC4Lcjo=; b=rWL9pfnPeUQhsn+/deBltOwo0ypJ8gB9YZ8CE7WEWyoIQnt8Hw+oXXRXWom7CnLGCb ppx8LiQzNaWbHtEVTjQYofkFCuPeUnquLVSW2yOX1mnj053Z9PtLC7USbyXnpemCNsYc 81apm4kotKVRsqaVFNxfuioeevHCIfqpmEdqSYhb/eVY0aTmAXfd3xH68MSfJsWz3DbT +/XrYxY/ejK2B/Iv09Luxv0lMebaeGAXud1N/uxbyyPHd/om3zIGIUJrgRLfxL9LOtZS xs6fUmAckQBYSWj2emrY+0/AgeZ1E8+H5p58u5GPZI+B7HNM33SzdOwDbocgVrJQ9V6X TVzg== 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; bh=O5ejVzQjCCcoSfX5EloxcZZE/nHz75LHYnDtuC4Lcjo=; b=EX2OeVitO4C+klnQwuMBnB9hxnLVmuSYtYF2vDKWCI2U2HPWtDwpBk3sbCCKpqS0Yv Q+BW3Ac9XDoBC+U5QnhOSRD3nmQMj5kBCHzdb718CNirTxq1v4aSFcfqPuREaCdzicow VXjSjD4SZDI87K5do63Xu1FEPqnPbqEjtv63Yy8B0J+HNO3olvW8k/TVoQDBpYO59B5Y mxcGEt//7nh1zo4ZzVmD90VYCRIpS8WqIz+cur7lqFN+5H62H6doujqVN69kswSTbvrw GoHNQmw0/sogPyYdd2BsJI1qA3rFiBKZNox6cAqELfE22VV4ZHpQ0YmyfZNabCjYBnmC qnEQ== X-Gm-Message-State: AMCzsaUJm81PKpRSBFiNhvvFOiSNShR8aPw7MSdujfUAyhRSm7B29SU+ bQIZbwMnhCShy6kcgZTdyVVkQfexq+jq5PocXFg= X-Google-Smtp-Source: ABhQp+TgIRnj36gyZJybB3Zsr1+ZCnwc0x2mS8oEGZ+7+zaGxebxgc+2DOwR/x4LugZtkYhjUkoWDz5xZnv6Dw3AOOQ= X-Received: by 10.31.174.202 with SMTP id x193mr1705677vke.55.1508439863217; Thu, 19 Oct 2017 12:04:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.4 with HTTP; Thu, 19 Oct 2017 12:04:22 -0700 (PDT) In-Reply-To: References: From: Aaron Fuchs Date: Thu, 19 Oct 2017 15:04:22 -0400 Message-ID: To: mile@ietf.org Content-Type: multipart/alternative; boundary="001a1136f1f036540f055beb0680" Archived-At: Subject: Re: [mile] mile Digest, Vol 78, Issue 15 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 19:04:30 -0000 --001a1136f1f036540f055beb0680 Content-Type: text/plain; charset="UTF-8" help On Thu, Oct 19, 2017 at 3:00 PM, wrote: > Send mile mailing list submissions to > mile@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/mile > or, via email, send a message with subject or body 'help' to > mile-request@ietf.org > > You can reach the person managing the list at > mile-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mile digest..." > > Today's Topics: > > 1. Re: Artart last call review of draft-ietf-mile-rolie-10 > (Kathleen Moriarty) > 2. Re: Artart last call review of draft-ietf-mile-rolie-10 > (Kathleen Moriarty) > > > ---------- Forwarded message ---------- > From: Kathleen Moriarty > To: "Banghart, Stephen A. (Fed)" > Cc: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" > > Bcc: > Date: Thu, 19 Oct 2017 14:23:46 -0400 > Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 > Hi Stephen, > > On Thu, Oct 19, 2017 at 1:39 PM, Banghart, Stephen A. (Fed) > wrote: > > Kathleen, > > > > Just to clarify, there were no normative changes to the use of TLS 1.3 > or TLS 1.2 in this -11 update. The latter three paragraphs were truncated > as it was duplicated text out of RFC 7525 and RFC 7589. > > > > The normative requirements for TLS remain as follows: > > > > A "MUST" for implementing TLS 1.2 with a "SHOULD" for following the BCPs > as described in RFC 7525 > > A "RECOMMENDED" for implementing the most recent version of TLS (At the > moment, TLS 1.3) also being supported. > > > > The non-normative recommendation that 0-RTT be disabled remains > unchanged. When you mention that "waiting may be worth having the normative > language" are you referring to this recommendation or another requirement? > > I should have looked back at the draft. I thought you had a normative > statement for 0-RTT and that it had changed from the phrasing in your > email. If nothing of substance changed, then we're fine. > > Thanks, > Kathleen > > > > > Thanks, > > Stephen > > > >> -----Original Message----- > >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > >> Sent: Thursday, October 19, 2017 1:17 PM > >> To: Banghart, Stephen A. (Fed) > >> Cc: Martin Thomson ; mile@ietf.org; draft- > >> ietf-mile-rolie.all@ietf.org > >> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 > >> > >> Hi Stephen, > >> > >> On Thu, Oct 19, 2017 at 12:24 PM, Banghart, Stephen A. (Fed) > >> wrote: > >> > Martin, > >> > > >> > I've put the rest of my comments inline, and uploaded a -11 version of > >> ROLIE to the Github with the changes. Providing there are no additional > >> major comments I'll post this version to datatracker today. > >> > > >> > Thanks again for the great review, > >> > Stephen > >> > > >> >> -----Original Message----- > >> >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin > Thomson > >> >> Sent: Monday, October 09, 2017 1:08 AM > >> >> To: art@ietf.org > >> >> Cc: mile@ietf.org; ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org > >> >> Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 > >> >> > >> >> Reviewer: Martin Thomson > >> >> Review result: Almost Ready > >> >> > >> >> I have reviewed this document, and - despite what appears to be a > >> >> lengthy list of issues - I think that it is in pretty good shape. > >> >> It's clear, readable, and addresses the requirements well. Most of > >> >> my comments should be trivial to resolve. > >> >> > >> >> Major: > >> >> > >> >> The decision to define a .well-known URI without a discovery story is > >> >> - in my opinion - inadvisable. Such a registration is usually > >> >> appropriate if you design a protocol that depends on discovery by > >> >> hostname and port. As such, this does not use that at all. A > >> >> configuration system can (and should) accept a complete URI for the > >> >> service endpoint. It would be better to defer creation of yet > >> >> another .well-known URI registration until the working group is > certain > >> that discovery requires it. > >> > > >> > Discussed in a separate thread. > >> > > >> >> The same comment applies to the .well-known resource for the category > >> >> document. > >> >> Given that this sort of document is readily discoverable via the > >> >> service document, I would say that the need for a .well-known > >> >> resource is less well- justified than the service document. > >> > > >> > We agree, removed the registration for the category document location. > >> > > >> >> The requirements in Section 5.3 on TLS use are unnecessarily strict. > >> >> It's great to recommend the use of TLS 1.2, but given that the > >> >> document has no real requirement on any particular version of TLS, > >> >> the use of "MUST" here is not needed. Similarly, the prohibition on > >> >> the use of 0-RTT is groundless. The lengthy list of requirements > >> >> around certificate validation only risk creating a conflict with > >> >> advice in other RFCs. Many, if not all, of these requirements are > >> >> transitively included by way of referencing HTTPS documents. I would > >> prefer to see this entire section reduced to a simple RFC 7525 > reference. > >> > > >> > The majority of the section has been reduced to a RFC 7525 reference. > We > >> believe that the benefits provided by 0-RTT don't outweigh the loss of > >> forward secrecy. The text currently places this as a suggestion from the > >> authors, and not a normative requirement. > >> > >> This is a substantial change as a result of just one reviewer. The > only thing > >> the MUST does is hold up final publication until an RFC # is assigned > for TLS > >> 1.3. TLS 1.3 shouldn't be too far off, so waiting may be worth having > the > >> normative language. I think this is one the WG needs to weigh in on to > >> change and tradeoffs of waiting for final publication. It's not just > the editors > >> that recommend this, I do as am sure others do as well. > >> > >> Best regards, > >> Kathleen > >> > > >> >> User authentication is under-specified. > >> > > >> > As any repository using user authentication is already inherently pre- > >> communicating with its consumers, we felt that underspecifying > >> authentication mechanisms allowed for each sharing consortium to control > >> their own repositories. Whatever system they are using already for > >> internal/external sharing authentication can be used here as long as it > meets > >> the ROLIE requirements. > >> > > >> >> * Section 5.3 mandates the use of TLS cipher suites that support > >> >> client authentication using certificates, but offers no further > >> >> advice. Aside from being an unnecessary requirement - cipher suites > >> >> that support certificate- based authentication of servers all allow > >> >> for client authentication - this sort of requirement is rarely > >> >> sufficient for interoperation. For instance, you need to specify how > >> >> a server will request a certificate such that clients can select the > >> >> correct certificate. If a client and server have agreed to share > >> >> information on terms that rely on authentication of clients, it is > better for > >> those peers to arrange the terms on which they will authenticate. > >> > > >> > Removed cipher suite text as these recommendations are provided by RFC > >> 7525. > >> > > >> >> * Section 5.4 uses "SHOULD" regarding client authentication using > >> >> federation, but offers no hints about what this entails. It also > >> >> uses "SHOULD" regarding authorization checks, which isn't an > >> >> interoperability requirement. It's more of a "don't be silly" type > >> >> of requirement, which doesn't need to be written down in an RFC. > >> > > >> > While its true that this is a "don't do anything stupid" requirement, > I think > >> that its valuable as a reminder that the authorization checks need to > support > >> full granularity through the entire resource tree. > >> > > >> >> Section 5.5 prohibits the use of GET on "/". This prohibits use of > >> >> the resource for other purposes. It seems reasonable to accept POST > >> >> messages as defined in RFC 6546, but this requirement is overly > >> >> strict (and further entrenches the violation of RFC 7320). If, for > >> >> instance, the server operator wishes to provide HTML in response to a > >> >> GET request to "/", this would prohibit that. The requirement to > >> >> return 404 if RFC 6546 is not supported is worse; not supporting RFC > >> >> 6546 might be a choice that a deployment makes to avoid the need to > >> reserve "/" for that protocol. > >> > > >> > Cleaned up the text describing this requirement to be more clear that > they > >> only trigger when an implementation has decided to support RFC 6546. > >> Removed the 404 requirement when not supporting RFC6546, as I agree that > >> it was overly restrictive. > >> > > >> >> In Section 6.2.3, what is the advantage of "rolie:format" over having > >> >> a well- defined media type? Media types can take advantage of > >> >> content negotiation, existing support in link relations, and other > >> >> existing tools > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > > > > -- > > Best regards, > Kathleen > > > > > ---------- Forwarded message ---------- > From: Kathleen Moriarty > To: "Banghart, Stephen A. (Fed)" > Cc: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" > > Bcc: > Date: Thu, 19 Oct 2017 14:23:46 -0400 > Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 > Hi Stephen, > > On Thu, Oct 19, 2017 at 1:39 PM, Banghart, Stephen A. (Fed) > wrote: > > Kathleen, > > > > Just to clarify, there were no normative changes to the use of TLS 1.3 > or TLS 1.2 in this -11 update. The latter three paragraphs were truncated > as it was duplicated text out of RFC 7525 and RFC 7589. > > > > The normative requirements for TLS remain as follows: > > > > A "MUST" for implementing TLS 1.2 with a "SHOULD" for following the BCPs > as described in RFC 7525 > > A "RECOMMENDED" for implementing the most recent version of TLS (At the > moment, TLS 1.3) also being supported. > > > > The non-normative recommendation that 0-RTT be disabled remains > unchanged. When you mention that "waiting may be worth having the normative > language" are you referring to this recommendation or another requirement? > > I should have looked back at the draft. I thought you had a normative > statement for 0-RTT and that it had changed from the phrasing in your > email. If nothing of substance changed, then we're fine. > > Thanks, > Kathleen > > > > > Thanks, > > Stephen > > > >> -----Original Message----- > >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > >> Sent: Thursday, October 19, 2017 1:17 PM > >> To: Banghart, Stephen A. (Fed) > >> Cc: Martin Thomson ; mile@ietf.org; draft- > >> ietf-mile-rolie.all@ietf.org > >> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 > >> > >> Hi Stephen, > >> > >> On Thu, Oct 19, 2017 at 12:24 PM, Banghart, Stephen A. (Fed) > >> wrote: > >> > Martin, > >> > > >> > I've put the rest of my comments inline, and uploaded a -11 version of > >> ROLIE to the Github with the changes. Providing there are no additional > >> major comments I'll post this version to datatracker today. > >> > > >> > Thanks again for the great review, > >> > Stephen > >> > > >> >> -----Original Message----- > >> >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin > Thomson > >> >> Sent: Monday, October 09, 2017 1:08 AM > >> >> To: art@ietf.org > >> >> Cc: mile@ietf.org; ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org > >> >> Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 > >> >> > >> >> Reviewer: Martin Thomson > >> >> Review result: Almost Ready > >> >> > >> >> I have reviewed this document, and - despite what appears to be a > >> >> lengthy list of issues - I think that it is in pretty good shape. > >> >> It's clear, readable, and addresses the requirements well. Most of > >> >> my comments should be trivial to resolve. > >> >> > >> >> Major: > >> >> > >> >> The decision to define a .well-known URI without a discovery story is > >> >> - in my opinion - inadvisable. Such a registration is usually > >> >> appropriate if you design a protocol that depends on discovery by > >> >> hostname and port. As such, this does not use that at all. A > >> >> configuration system can (and should) accept a complete URI for the > >> >> service endpoint. It would be better to defer creation of yet > >> >> another .well-known URI registration until the working group is > certain > >> that discovery requires it. > >> > > >> > Discussed in a separate thread. > >> > > >> >> The same comment applies to the .well-known resource for the category > >> >> document. > >> >> Given that this sort of document is readily discoverable via the > >> >> service document, I would say that the need for a .well-known > >> >> resource is less well- justified than the service document. > >> > > >> > We agree, removed the registration for the category document location. > >> > > >> >> The requirements in Section 5.3 on TLS use are unnecessarily strict. > >> >> It's great to recommend the use of TLS 1.2, but given that the > >> >> document has no real requirement on any particular version of TLS, > >> >> the use of "MUST" here is not needed. Similarly, the prohibition on > >> >> the use of 0-RTT is groundless. The lengthy list of requirements > >> >> around certificate validation only risk creating a conflict with > >> >> advice in other RFCs. Many, if not all, of these requirements are > >> >> transitively included by way of referencing HTTPS documents. I would > >> prefer to see this entire section reduced to a simple RFC 7525 > reference. > >> > > >> > The majority of the section has been reduced to a RFC 7525 reference. > We > >> believe that the benefits provided by 0-RTT don't outweigh the loss of > >> forward secrecy. The text currently places this as a suggestion from the > >> authors, and not a normative requirement. > >> > >> This is a substantial change as a result of just one reviewer. The > only thing > >> the MUST does is hold up final publication until an RFC # is assigned > for TLS > >> 1.3. TLS 1.3 shouldn't be too far off, so waiting may be worth having > the > >> normative language. I think this is one the WG needs to weigh in on to > >> change and tradeoffs of waiting for final publication. It's not just > the editors > >> that recommend this, I do as am sure others do as well. > >> > >> Best regards, > >> Kathleen > >> > > >> >> User authentication is under-specified. > >> > > >> > As any repository using user authentication is already inherently pre- > >> communicating with its consumers, we felt that underspecifying > >> authentication mechanisms allowed for each sharing consortium to control > >> their own repositories. Whatever system they are using already for > >> internal/external sharing authentication can be used here as long as it > meets > >> the ROLIE requirements. > >> > > >> >> * Section 5.3 mandates the use of TLS cipher suites that support > >> >> client authentication using certificates, but offers no further > >> >> advice. Aside from being an unnecessary requirement - cipher suites > >> >> that support certificate- based authentication of servers all allow > >> >> for client authentication - this sort of requirement is rarely > >> >> sufficient for interoperation. For instance, you need to specify how > >> >> a server will request a certificate such that clients can select the > >> >> correct certificate. If a client and server have agreed to share > >> >> information on terms that rely on authentication of clients, it is > better for > >> those peers to arrange the terms on which they will authenticate. > >> > > >> > Removed cipher suite text as these recommendations are provided by RFC > >> 7525. > >> > > >> >> * Section 5.4 uses "SHOULD" regarding client authentication using > >> >> federation, but offers no hints about what this entails. It also > >> >> uses "SHOULD" regarding authorization checks, which isn't an > >> >> interoperability requirement. It's more of a "don't be silly" type > >> >> of requirement, which doesn't need to be written down in an RFC. > >> > > >> > While its true that this is a "don't do anything stupid" requirement, > I think > >> that its valuable as a reminder that the authorization checks need to > support > >> full granularity through the entire resource tree. > >> > > >> >> Section 5.5 prohibits the use of GET on "/". This prohibits use of > >> >> the resource for other purposes. It seems reasonable to accept POST > >> >> messages as defined in RFC 6546, but this requirement is overly > >> >> strict (and further entrenches the violation of RFC 7320). If, for > >> >> instance, the server operator wishes to provide HTML in response to a > >> >> GET request to "/", this would prohibit that. The requirement to > >> >> return 404 if RFC 6546 is not supported is worse; not supporting RFC > >> >> 6546 might be a choice that a deployment makes to avoid the need to > >> reserve "/" for that protocol. > >> > > >> > Cleaned up the text describing this requirement to be more clear that > they > >> only trigger when an implementation has decided to support RFC 6546. > >> Removed the 404 requirement when not supporting RFC6546, as I agree that > >> it was overly restrictive. > >> > > >> >> In Section 6.2.3, what is the advantage of "rolie:format" over having > >> >> a well- defined media type? Media types can take advantage of > >> >> content negotiation, existing support in link relations, and other > >> >> existing tools > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > > > > -- > > Best regards, > Kathleen > > > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > > --001a1136f1f036540f055beb0680 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
help

On Thu, Oct 19, 2017 at 3:00 PM, <mile-request@ietf.org= > wrote:
Send mile mailing = list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mile@ietf.org<= /a>

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/<= wbr>listinfo/mile
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mile-r= equest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mile-own= er@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of mile digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: Artart last call review of draft-ietf-mile-rolie-10
=C2=A0 =C2=A0 =C2=A0 (Kathleen Moriarty)
=C2=A0 =C2=A02. Re: Artart last call review of draft-ietf-mile-rolie-10
=C2=A0 =C2=A0 =C2=A0 (Kathleen Moriarty)


---------- Forwarded message ----------
From:=C2=A0Kathleen Mori= arty <kathleen.moria= rty.ietf@gmail.com>
To:=C2=A0"Banghart, Stephen A. (Fed)&quo= t; <stephen.banghart@nist.g= ov>
Cc:=C2=A0"mile@ietf.org= " <mile@ietf.org>, &quo= t;draft-ietf-mile-rol= ie.all@ietf.org" <draft-ietf-mile-rolie.all@ietf.org>
Bcc:=C2=A0
Date:= =C2=A0Thu, 19 Oct 2017 14:23:46 -0400
Subject:=C2=A0Re: [mile] Artart la= st call review of draft-ietf-mile-rolie-10
Hi Stephen,

On Thu, Oct 19, 2017 at 1:39 PM, Banghart, Stephen A. (Fed)
<stephen.banghart@nist.gov<= /a>> wrote:
> Kathleen,
>
> Just to clarify, there were no normative changes to the use of TLS 1.3= or TLS 1.2 in this -11 update. The latter three paragraphs were truncated = as it was duplicated text out of RFC 7525 and RFC 7589.
>
> The normative requirements for TLS remain as follows:
>
> A "MUST" for implementing TLS 1.2 with a "SHOULD" = for following the BCPs as described in RFC 7525
> A "RECOMMENDED" for implementing the most recent version of = TLS (At the moment, TLS 1.3) also being supported.
>
> The non-normative recommendation that 0-RTT be disabled remains unchan= ged. When you mention that "waiting may be worth having the normative = language" are you referring to this recommendation or another requirem= ent?

I should have looked back at the draft.=C2=A0 I thought you had a normative=
statement for 0-RTT and that it had changed from the phrasing in your
email.=C2=A0 If nothing of substance changed, then we're fine.

Thanks,
Kathleen

>
> Thanks,
> Stephen
>
>> -----Original Message-----
>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
>> Sent: Thursday, October 19, 2017 1:17 PM
>> To: Banghart, Stephen A. (Fed) <stephen.banghart@nist.gov>
>> Cc: Martin Thomson <martin.thomson@gmail.com>; mile@ie= tf.org; draft-
>> ietf-mile-rolie.al= l@ietf.org
>> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rol= ie-10
>>
>> Hi Stephen,
>>
>> On Thu, Oct 19, 2017 at 12:24 PM, Banghart, Stephen A. (Fed)
>> <stephen.banghart@= nist.gov> wrote:
>> > Martin,
>> >
>> > I've put the rest of my comments inline, and uploaded a -= 11 version of
>> ROLIE to the Github with the changes. Providing there are no addit= ional
>> major comments I'll post this version to datatracker today. >> >
>> > Thanks again for the great review,
>> > Stephen
>> >
>> >> -----Original Message-----
>> >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin Thomson
>> >> Sent: Monday, October 09, 2017 1:08 AM
>> >> To: art@ietf.org
>> >> Cc: mile@ietf.org; <= a href=3D"mailto:ietf@ietf.org">ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org >> >> Subject: [mile] Artart last call review of draft-ietf-mil= e-rolie-10
>> >>
>> >> Reviewer: Martin Thomson
>> >> Review result: Almost Ready
>> >>
>> >> I have reviewed this document, and - despite what appears= to be a
>> >> lengthy list of issues - I think that it is in pretty goo= d shape.
>> >> It's clear, readable, and addresses the requirements = well.=C2=A0 Most of
>> >> my comments should be trivial to resolve.
>> >>
>> >> Major:
>> >>
>> >> The decision to define a .well-known URI without a discov= ery story is
>> >> - in my opinion - inadvisable.=C2=A0 Such a registration = is usually
>> >> appropriate if you design a protocol that depends on disc= overy by
>> >> hostname and port.=C2=A0 As such, this does not use that = at all.=C2=A0 A
>> >> configuration system can (and should) accept a complete U= RI for the
>> >> service endpoint.=C2=A0 It would be better to defer creat= ion of yet
>> >> another .well-known URI registration until the working gr= oup is certain
>> that discovery requires it.
>> >
>> > Discussed in a separate thread.
>> >
>> >> The same comment applies to the .well-known resource for = the category
>> >> document.
>> >>=C2=A0 Given that this sort of document is readily discove= rable via the
>> >> service document, I would say that the need for a .well-k= nown
>> >> resource is less well- justified than the service documen= t.
>> >
>> > We agree, removed the registration for the category document = location.
>> >
>> >> The requirements in Section 5.3 on TLS use are unnecessar= ily strict.
>> >> It's great to recommend the use of TLS 1.2, but given= that the
>> >> document has no real requirement on any particular versio= n of TLS,
>> >> the use of "MUST" here is not needed.=C2=A0 Sim= ilarly, the prohibition on
>> >> the use of 0-RTT is groundless.=C2=A0 The lengthy list of= requirements
>> >> around certificate validation only risk creating a confli= ct with
>> >> advice in other RFCs.=C2=A0 Many, if not all, of these re= quirements are
>> >> transitively included by way of referencing HTTPS documen= ts.=C2=A0 I would
>> prefer to see this entire section reduced to a simple RFC 7525 ref= erence.
>> >
>> > The majority of the section has been reduced to a RFC 7525 re= ference. We
>> believe that the benefits provided by 0-RTT don't outweigh the= loss of
>> forward secrecy. The text currently places this as a suggestion fr= om the
>> authors, and not a normative requirement.
>>
>> This is a substantial change as a result of just one reviewer.=C2= =A0 The only thing
>> the MUST does is hold up final publication until an RFC # is assig= ned for TLS
>> 1.3.=C2=A0 TLS 1.3 shouldn't be too far off, so waiting may be= worth having the
>> normative language.=C2=A0 I think this is one the WG needs to weig= h in on to
>> change and tradeoffs of waiting for final publication.=C2=A0 It= 9;s not just the editors
>> that recommend this, I do as am sure others do as well.
>>
>> Best regards,
>> Kathleen
>> >
>> >> User authentication is under-specified.
>> >
>> > As any repository using user authentication is already inhere= ntly pre-
>> communicating with its consumers, we felt that underspecifying
>> authentication mechanisms allowed for each sharing consortium to c= ontrol
>> their own repositories. Whatever system they are using already for=
>> internal/external sharing authentication can be used here as long = as it meets
>> the ROLIE requirements.
>> >
>> >> * Section 5.3 mandates the use of TLS cipher suites that = support
>> >> client authentication using certificates, but offers no f= urther
>> >> advice.=C2=A0 Aside from being an unnecessary requirement= - cipher suites
>> >> that support certificate- based authentication of servers= all allow
>> >> for client authentication - this sort of requirement is r= arely
>> >> sufficient for interoperation.=C2=A0 For instance, you ne= ed to specify how
>> >> a server will request a certificate such that clients can= select the
>> >> correct certificate.=C2=A0 If a client and server have ag= reed to share
>> >> information on terms that rely on authentication of clien= ts, it is better for
>> those peers to arrange the terms on which they will authenticate.<= br> >> >
>> > Removed cipher suite text as these recommendations are provid= ed by RFC
>> 7525.
>> >
>> >> * Section 5.4 uses "SHOULD" regarding client au= thentication using
>> >> federation, but offers no hints about what this entails.= =C2=A0 It also
>> >> uses "SHOULD" regarding authorization checks, w= hich isn't an
>> >> interoperability requirement.=C2=A0 It's more of a &q= uot;don't be silly" type
>> >> of requirement, which doesn't need to be written down= in an RFC.
>> >
>> > While its true that this is a "don't do anything stu= pid" requirement, I think
>> that its valuable as a reminder that the authorization checks need= to support
>> full granularity through the entire resource tree.
>> >
>> >> Section 5.5 prohibits the use of GET on "/".=C2= =A0 This prohibits use of
>> >> the resource for other purposes.=C2=A0 It seems reasonabl= e to accept POST
>> >> messages as defined in RFC 6546, but this requirement is = overly
>> >> strict (and further entrenches the violation of RFC 7320)= .=C2=A0 If, for
>> >> instance, the server operator wishes to provide HTML in r= esponse to a
>> >> GET request to "/", this would prohibit that.= =C2=A0 The requirement to
>> >> return 404 if RFC 6546 is not supported is worse; not sup= porting RFC
>> >> 6546 might be a choice that a deployment makes to avoid t= he need to
>> reserve "/" for that protocol.
>> >
>> > Cleaned up the text describing this requirement to be more cl= ear that they
>> only trigger when an implementation has decided to support RFC 654= 6.
>> Removed the 404 requirement when not supporting RFC6546, as I agre= e that
>> it was overly restrictive.
>> >
>> >> In Section 6.2.3, what is the advantage of "rolie:fo= rmat" over having
>> >> a well- defined media type?=C2=A0 Media types can take ad= vantage of
>> >> content negotiation, existing support in link relations, = and other
>> >> existing tools
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen



--

Best regards,
Kathleen




---------- Forwarded message ----------
From:=C2=A0Kathleen Mori= arty <kathleen.moria= rty.ietf@gmail.com>
To:=C2=A0"Banghart, Stephen A. (Fed)&quo= t; <stephen.banghart@nist.g= ov>
Cc:=C2=A0"mile@ietf.org= " <mile@ietf.org>, &quo= t;draft-ietf-mile-rol= ie.all@ietf.org" <draft-ietf-mile-rolie.all@ietf.org>
Bcc:=C2=A0
Date:= =C2=A0Thu, 19 Oct 2017 14:23:46 -0400
Subject:=C2=A0Re: [mile] Artart la= st call review of draft-ietf-mile-rolie-10
Hi Stephen,

On Thu, Oct 19, 2017 at 1:39 PM, Banghart, Stephen A. (Fed)
<stephen.banghart@nist.gov<= /a>> wrote:
> Kathleen,
>
> Just to clarify, there were no normative changes to the use of TLS 1.3= or TLS 1.2 in this -11 update. The latter three paragraphs were truncated = as it was duplicated text out of RFC 7525 and RFC 7589.
>
> The normative requirements for TLS remain as follows:
>
> A "MUST" for implementing TLS 1.2 with a "SHOULD" = for following the BCPs as described in RFC 7525
> A "RECOMMENDED" for implementing the most recent version of = TLS (At the moment, TLS 1.3) also being supported.
>
> The non-normative recommendation that 0-RTT be disabled remains unchan= ged. When you mention that "waiting may be worth having the normative = language" are you referring to this recommendation or another requirem= ent?

I should have looked back at the draft.=C2=A0 I thought you had a normative=
statement for 0-RTT and that it had changed from the phrasing in your
email.=C2=A0 If nothing of substance changed, then we're fine.

Thanks,
Kathleen

>
> Thanks,
> Stephen
>
>> -----Original Message-----
>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
>> Sent: Thursday, October 19, 2017 1:17 PM
>> To: Banghart, Stephen A. (Fed) <stephen.banghart@nist.gov>
>> Cc: Martin Thomson <martin.thomson@gmail.com>; mile@ie= tf.org; draft-
>> ietf-mile-rolie.al= l@ietf.org
>> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rol= ie-10
>>
>> Hi Stephen,
>>
>> On Thu, Oct 19, 2017 at 12:24 PM, Banghart, Stephen A. (Fed)
>> <stephen.banghart@= nist.gov> wrote:
>> > Martin,
>> >
>> > I've put the rest of my comments inline, and uploaded a -= 11 version of
>> ROLIE to the Github with the changes. Providing there are no addit= ional
>> major comments I'll post this version to datatracker today. >> >
>> > Thanks again for the great review,
>> > Stephen
>> >
>> >> -----Original Message-----
>> >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin Thomson
>> >> Sent: Monday, October 09, 2017 1:08 AM
>> >> To: art@ietf.org
>> >> Cc: mile@ietf.org; <= a href=3D"mailto:ietf@ietf.org">ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org >> >> Subject: [mile] Artart last call review of draft-ietf-mil= e-rolie-10
>> >>
>> >> Reviewer: Martin Thomson
>> >> Review result: Almost Ready
>> >>
>> >> I have reviewed this document, and - despite what appears= to be a
>> >> lengthy list of issues - I think that it is in pretty goo= d shape.
>> >> It's clear, readable, and addresses the requirements = well.=C2=A0 Most of
>> >> my comments should be trivial to resolve.
>> >>
>> >> Major:
>> >>
>> >> The decision to define a .well-known URI without a discov= ery story is
>> >> - in my opinion - inadvisable.=C2=A0 Such a registration = is usually
>> >> appropriate if you design a protocol that depends on disc= overy by
>> >> hostname and port.=C2=A0 As such, this does not use that = at all.=C2=A0 A
>> >> configuration system can (and should) accept a complete U= RI for the
>> >> service endpoint.=C2=A0 It would be better to defer creat= ion of yet
>> >> another .well-known URI registration until the working gr= oup is certain
>> that discovery requires it.
>> >
>> > Discussed in a separate thread.
>> >
>> >> The same comment applies to the .well-known resource for = the category
>> >> document.
>> >>=C2=A0 Given that this sort of document is readily discove= rable via the
>> >> service document, I would say that the need for a .well-k= nown
>> >> resource is less well- justified than the service documen= t.
>> >
>> > We agree, removed the registration for the category document = location.
>> >
>> >> The requirements in Section 5.3 on TLS use are unnecessar= ily strict.
>> >> It's great to recommend the use of TLS 1.2, but given= that the
>> >> document has no real requirement on any particular versio= n of TLS,
>> >> the use of "MUST" here is not needed.=C2=A0 Sim= ilarly, the prohibition on
>> >> the use of 0-RTT is groundless.=C2=A0 The lengthy list of= requirements
>> >> around certificate validation only risk creating a confli= ct with
>> >> advice in other RFCs.=C2=A0 Many, if not all, of these re= quirements are
>> >> transitively included by way of referencing HTTPS documen= ts.=C2=A0 I would
>> prefer to see this entire section reduced to a simple RFC 7525 ref= erence.
>> >
>> > The majority of the section has been reduced to a RFC 7525 re= ference. We
>> believe that the benefits provided by 0-RTT don't outweigh the= loss of
>> forward secrecy. The text currently places this as a suggestion fr= om the
>> authors, and not a normative requirement.
>>
>> This is a substantial change as a result of just one reviewer.=C2= =A0 The only thing
>> the MUST does is hold up final publication until an RFC # is assig= ned for TLS
>> 1.3.=C2=A0 TLS 1.3 shouldn't be too far off, so waiting may be= worth having the
>> normative language.=C2=A0 I think this is one the WG needs to weig= h in on to
>> change and tradeoffs of waiting for final publication.=C2=A0 It= 9;s not just the editors
>> that recommend this, I do as am sure others do as well.
>>
>> Best regards,
>> Kathleen
>> >
>> >> User authentication is under-specified.
>> >
>> > As any repository using user authentication is already inhere= ntly pre-
>> communicating with its consumers, we felt that underspecifying
>> authentication mechanisms allowed for each sharing consortium to c= ontrol
>> their own repositories. Whatever system they are using already for=
>> internal/external sharing authentication can be used here as long = as it meets
>> the ROLIE requirements.
>> >
>> >> * Section 5.3 mandates the use of TLS cipher suites that = support
>> >> client authentication using certificates, but offers no f= urther
>> >> advice.=C2=A0 Aside from being an unnecessary requirement= - cipher suites
>> >> that support certificate- based authentication of servers= all allow
>> >> for client authentication - this sort of requirement is r= arely
>> >> sufficient for interoperation.=C2=A0 For instance, you ne= ed to specify how
>> >> a server will request a certificate such that clients can= select the
>> >> correct certificate.=C2=A0 If a client and server have ag= reed to share
>> >> information on terms that rely on authentication of clien= ts, it is better for
>> those peers to arrange the terms on which they will authenticate.<= br> >> >
>> > Removed cipher suite text as these recommendations are provid= ed by RFC
>> 7525.
>> >
>> >> * Section 5.4 uses "SHOULD" regarding client au= thentication using
>> >> federation, but offers no hints about what this entails.= =C2=A0 It also
>> >> uses "SHOULD" regarding authorization checks, w= hich isn't an
>> >> interoperability requirement.=C2=A0 It's more of a &q= uot;don't be silly" type
>> >> of requirement, which doesn't need to be written down= in an RFC.
>> >
>> > While its true that this is a "don't do anything stu= pid" requirement, I think
>> that its valuable as a reminder that the authorization checks need= to support
>> full granularity through the entire resource tree.
>> >
>> >> Section 5.5 prohibits the use of GET on "/".=C2= =A0 This prohibits use of
>> >> the resource for other purposes.=C2=A0 It seems reasonabl= e to accept POST
>> >> messages as defined in RFC 6546, but this requirement is = overly
>> >> strict (and further entrenches the violation of RFC 7320)= .=C2=A0 If, for
>> >> instance, the server operator wishes to provide HTML in r= esponse to a
>> >> GET request to "/", this would prohibit that.= =C2=A0 The requirement to
>> >> return 404 if RFC 6546 is not supported is worse; not sup= porting RFC
>> >> 6546 might be a choice that a deployment makes to avoid t= he need to
>> reserve "/" for that protocol.
>> >
>> > Cleaned up the text describing this requirement to be more cl= ear that they
>> only trigger when an implementation has decided to support RFC 654= 6.
>> Removed the 404 requirement when not supporting RFC6546, as I agre= e that
>> it was overly restrictive.
>> >
>> >> In Section 6.2.3, what is the advantage of "rolie:fo= rmat" over having
>> >> a well- defined media type?=C2=A0 Media types can take ad= vantage of
>> >> content negotiation, existing support in link relations, = and other
>> >> existing tools
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen



--

Best regards,
Kathleen



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


--001a1136f1f036540f055beb0680-- From nobody Thu Oct 19 16:53:53 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D1813219F; Thu, 19 Oct 2017 16:53:51 -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 jlBjhf0ujX09; Thu, 19 Oct 2017 16:53:50 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 E7B59126B7E; Thu, 19 Oct 2017 16:53:49 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id g125so17630854oib.12; Thu, 19 Oct 2017 16:53:49 -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:content-transfer-encoding; bh=zAH0nKWUdPGblb4CyLcEJIceYHy1t1uMdyVh2z7jDYE=; b=gWe3d1Rqucg+2g8/GfnwzJwY4ZgSyY61MOGjhvK1vkDng/dg4yQjFnJlfiJjcsn69J YcfZ5y0W9hjTLkYyWf2u1u47ZnDGztPbFco6Z04+dAKm+Rpa7SQoWrSOGJLNeg405nZj o847qbCCVmAH1R0ERonz1hPHuYLg/C5b68SqJkV2WBobgx3N/4+FrbfCCsfBZm91hNkI fVVrK0zw8EX6exDWcuQCICHrJ19HnJBItlLJaVYQ7wqvB16Ee11Mwub3sNvyql0sQZE0 4vRB74t97YBjLoBOYDo1P7qauzzp7PvzL5kh58brG45rRP+b2mP5J0OD1QRwh0Kgqdt8 QYeg== 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:content-transfer-encoding; bh=zAH0nKWUdPGblb4CyLcEJIceYHy1t1uMdyVh2z7jDYE=; b=B3yHZc2Rhv/RP/5dI063sclZHtmwIaCm9l3V+8j9Pa/v1xreoya8g8bBlgsFd205sD ZzhKXAaDbJl7hgPuwGqxh9Z4GjW+lqaDnd0LjzDSk4EuvUlGx+hUzHTVPXkirojI1aKc WXevWPDOzJgVPoQ+ilnj1uIPnVenv5w6WDztaID0k/Osm89s817FeDiOEyhFfFhCeQuV 3if7IHW38+WXkm59xa/QWxlgwtZlWIMo9Q9jWwdDqhvF9GX0yfEAkESzIu04KfxQ7eI2 1sOpbtct+huKrUwxKhUUMZ1wSX5O6/KA3lTKABASFzCRjkFE+QvKaNjp/58D119Enote 6/pQ== X-Gm-Message-State: AMCzsaWuv7oEvmrVO0mzugZiQBeEw6oz7SiKl1jayN0TO2E92a83u7PQ NgIOYBK2lMFi1HFPKzPDgA7rnYdiD3sIpzWfI45AHg== X-Google-Smtp-Source: ABhQp+TxRZ5AXkvYcLpJBct9bN2WP6COI3vB2QuCQFH4At0k0k95toQoIRJdzRjYe+6Jygq000HB/qNgbezFA587g1I= X-Received: by 10.157.51.146 with SMTP id u18mr1752810otc.98.1508457229086; Thu, 19 Oct 2017 16:53:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Thu, 19 Oct 2017 16:53:48 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> From: Martin Thomson Date: Fri, 20 Oct 2017 10:53:48 +1100 Message-ID: To: "Banghart, Stephen A. (Fed)" Cc: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 23:53:52 -0000 Thanks Stephen, Most of this looks good (I'll trust that your representation of the changes is accurate rather than wade through XML, though I have reviewed some of the changes). On Fri, Oct 20, 2017 at 3:24 AM, Banghart, Stephen A. (Fed) wrote: >> The requirements in Section 5.3 on TLS use are unnecessarily strict. It= 's great >> to recommend the use of TLS 1.2, but given that the document has no real >> requirement on any particular version of TLS, the use of "MUST" here is = not >> needed. Similarly, the prohibition on the use of 0-RTT is groundless. = The >> lengthy list of requirements around certificate validation only risk cre= ating a >> conflict with advice in other RFCs. Many, if not all, of these requirem= ents are >> transitively included by way of referencing HTTPS documents. I would pr= efer >> to see this entire section reduced to a simple RFC 7525 reference. > > The majority of the section has been reduced to a RFC 7525 reference. We = believe that the benefits provided by 0-RTT don't outweigh the loss of forw= ard secrecy. The text currently places this as a suggestion from the author= s, and not a normative requirement. I'm going to push on this one more time. 0-RTT does not necessarily compromise forward secrecy. It is also entirely possible to deploy 0-RTT without risk of replay attack. But these facts don't seem persuasive because it is possible to implement the feature with these risks. The text you provide indicates that it is replay you are concerned about. Do you have any analysis that indicates that someone deploying a server that enables early data would produce harm? Does that analysis suggest any other alternative mitigation strategies? Again, I would prefer that the draft remain silent on this subject. I realize that I'm in the rough here, but I consider this to be a test case for this. The next person who uses HTTP will see your text, notice that it is good, and copy it. It becomes precedent to forbid the use of 0-RTT and we forget *why*. I would prefer that this text be better motivated if it is included. >> User authentication is under-specified. The new text is much more concise and targeted, thank you. >> In Section 6.2.3, what is the advantage of "rolie:format" over having a = well- >> defined media type? Media types can take advantage of content >> negotiation, existing support in link relations, and other existing tool= s. >> This rolie:format element has namespace, format, and schema; these are n= ot >> useful to anyone that is ignorant of their contents. The only advantage= I see >> is that syntax might be validated, but semantics can't be extracted. Th= ere's a >> lot of implied work in adding this element, but that doesn't seem to be >> justified by that advantage. (I see that RFC 7970 doesn't define a medi= a type, >> but it seems like it would be easier to correct that than to define an e= lement >> like this.) > > Atom:content has an attribute for media type, which provides information = about the serialization of the content representation. In many cases, we fo= und that different formats can appear for the same content within the same = media type. For example, the same piece of information may be represented u= sing two different XML Schemas. The rolie:format element allows the entry t= o clarify which "format" its using beyond which serialization it is using. = Ultimately the format element is not registered anywhere, nor is its conten= ts particularly standardized. We're providing the element as a tool for rep= ository producers to use. This is, at least in my opinion, a mistake. It creates another layer of content negotiation that is not visible to HTTP. If the same information can be presented in two different formats, why is it not possible to have two media types? Or at least a parameterized media type that identifies the format. The problem with defining elements is that they are costly. Not so much to specify, but to implement correctly. If you are able to rely on existing mechanisms, you should do that as much as possible. It doesn't sound like you have a concrete use case for this, which makes me nervous. >> Section 6.2.4 defines a generic key-value mechanism. But that is someth= ing >> that XML is actually good at. Why can't users that require additional >> metadata use additional metadata as originally defined by Atom? That is= , >> replace > value=3D"12345"/> with something like >> 12345. The final paragraph= of the >> section recognizes this possibility. > > The latter example you provide is still possible, as unrecognized element= s in ROLIE/Atom don't cause validation to fail, but are just potentially ig= nored by the client/server. The rolie:property element allows automated sys= tems to have a globally available "vocabulary" of potentially available pro= perties, that can be used to populate tables or fields in automated systems= . I realize that the set of attributes you have might be useful in this context. But defining them in XML would be much easier. You don't create a new mechanism for expressing key-value pairs, and the registry that goes with it. That seems like a minor cost, but like in the previous case, the choice to define another bespoke mechanism comes with hidden costs. Why bother when you have a perfectly workable mechanism available to you already? >> Question: it's fairly widely accepted that use of IRIs in Atom has been = less >> than successful. Do you want to mandate use of URIs instead? This woul= d >> apply to both link relations and the "src" attribute. > > We wanted to stay in line with the requirements in Atom, if this becomes = an issue it may be worth re-examining. This is your chance. You don't get to go back or re-examine once your protocol is widely deployed. From nobody Thu Oct 19 16:53:59 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1FD14126B7E; Thu, 19 Oct 2017 16:53:52 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D1813219F; Thu, 19 Oct 2017 16:53:51 -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 jlBjhf0ujX09; Thu, 19 Oct 2017 16:53:50 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 E7B59126B7E; Thu, 19 Oct 2017 16:53:49 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id g125so17630854oib.12; Thu, 19 Oct 2017 16:53:49 -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:content-transfer-encoding; bh=zAH0nKWUdPGblb4CyLcEJIceYHy1t1uMdyVh2z7jDYE=; b=gWe3d1Rqucg+2g8/GfnwzJwY4ZgSyY61MOGjhvK1vkDng/dg4yQjFnJlfiJjcsn69J YcfZ5y0W9hjTLkYyWf2u1u47ZnDGztPbFco6Z04+dAKm+Rpa7SQoWrSOGJLNeg405nZj o847qbCCVmAH1R0ERonz1hPHuYLg/C5b68SqJkV2WBobgx3N/4+FrbfCCsfBZm91hNkI fVVrK0zw8EX6exDWcuQCICHrJ19HnJBItlLJaVYQ7wqvB16Ee11Mwub3sNvyql0sQZE0 4vRB74t97YBjLoBOYDo1P7qauzzp7PvzL5kh58brG45rRP+b2mP5J0OD1QRwh0Kgqdt8 QYeg== 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:content-transfer-encoding; bh=zAH0nKWUdPGblb4CyLcEJIceYHy1t1uMdyVh2z7jDYE=; b=B3yHZc2Rhv/RP/5dI063sclZHtmwIaCm9l3V+8j9Pa/v1xreoya8g8bBlgsFd205sD ZzhKXAaDbJl7hgPuwGqxh9Z4GjW+lqaDnd0LjzDSk4EuvUlGx+hUzHTVPXkirojI1aKc WXevWPDOzJgVPoQ+ilnj1uIPnVenv5w6WDztaID0k/Osm89s817FeDiOEyhFfFhCeQuV 3if7IHW38+WXkm59xa/QWxlgwtZlWIMo9Q9jWwdDqhvF9GX0yfEAkESzIu04KfxQ7eI2 1sOpbtct+huKrUwxKhUUMZ1wSX5O6/KA3lTKABASFzCRjkFE+QvKaNjp/58D119Enote 6/pQ== X-Gm-Message-State: AMCzsaWuv7oEvmrVO0mzugZiQBeEw6oz7SiKl1jayN0TO2E92a83u7PQ NgIOYBK2lMFi1HFPKzPDgA7rnYdiD3sIpzWfI45AHg== X-Google-Smtp-Source: ABhQp+TxRZ5AXkvYcLpJBct9bN2WP6COI3vB2QuCQFH4At0k0k95toQoIRJdzRjYe+6Jygq000HB/qNgbezFA587g1I= X-Received: by 10.157.51.146 with SMTP id u18mr1752810otc.98.1508457229086; Thu, 19 Oct 2017 16:53:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Thu, 19 Oct 2017 16:53:48 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> From: Martin Thomson Date: Fri, 20 Oct 2017 10:53:48 +1100 Message-ID: To: "Banghart, Stephen A. (Fed)" Cc: "mile@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171019235352.1FD14126B7E@ietfa.amsl.com> Resent-Date: Thu, 19 Oct 2017 16:53:52 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 23:53:52 -0000 Thanks Stephen, Most of this looks good (I'll trust that your representation of the changes is accurate rather than wade through XML, though I have reviewed some of the changes). On Fri, Oct 20, 2017 at 3:24 AM, Banghart, Stephen A. (Fed) wrote: >> The requirements in Section 5.3 on TLS use are unnecessarily strict. It= 's great >> to recommend the use of TLS 1.2, but given that the document has no real >> requirement on any particular version of TLS, the use of "MUST" here is = not >> needed. Similarly, the prohibition on the use of 0-RTT is groundless. = The >> lengthy list of requirements around certificate validation only risk cre= ating a >> conflict with advice in other RFCs. Many, if not all, of these requirem= ents are >> transitively included by way of referencing HTTPS documents. I would pr= efer >> to see this entire section reduced to a simple RFC 7525 reference. > > The majority of the section has been reduced to a RFC 7525 reference. We = believe that the benefits provided by 0-RTT don't outweigh the loss of forw= ard secrecy. The text currently places this as a suggestion from the author= s, and not a normative requirement. I'm going to push on this one more time. 0-RTT does not necessarily compromise forward secrecy. It is also entirely possible to deploy 0-RTT without risk of replay attack. But these facts don't seem persuasive because it is possible to implement the feature with these risks. The text you provide indicates that it is replay you are concerned about. Do you have any analysis that indicates that someone deploying a server that enables early data would produce harm? Does that analysis suggest any other alternative mitigation strategies? Again, I would prefer that the draft remain silent on this subject. I realize that I'm in the rough here, but I consider this to be a test case for this. The next person who uses HTTP will see your text, notice that it is good, and copy it. It becomes precedent to forbid the use of 0-RTT and we forget *why*. I would prefer that this text be better motivated if it is included. >> User authentication is under-specified. The new text is much more concise and targeted, thank you. >> In Section 6.2.3, what is the advantage of "rolie:format" over having a = well- >> defined media type? Media types can take advantage of content >> negotiation, existing support in link relations, and other existing tool= s. >> This rolie:format element has namespace, format, and schema; these are n= ot >> useful to anyone that is ignorant of their contents. The only advantage= I see >> is that syntax might be validated, but semantics can't be extracted. Th= ere's a >> lot of implied work in adding this element, but that doesn't seem to be >> justified by that advantage. (I see that RFC 7970 doesn't define a medi= a type, >> but it seems like it would be easier to correct that than to define an e= lement >> like this.) > > Atom:content has an attribute for media type, which provides information = about the serialization of the content representation. In many cases, we fo= und that different formats can appear for the same content within the same = media type. For example, the same piece of information may be represented u= sing two different XML Schemas. The rolie:format element allows the entry t= o clarify which "format" its using beyond which serialization it is using. = Ultimately the format element is not registered anywhere, nor is its conten= ts particularly standardized. We're providing the element as a tool for rep= ository producers to use. This is, at least in my opinion, a mistake. It creates another layer of content negotiation that is not visible to HTTP. If the same information can be presented in two different formats, why is it not possible to have two media types? Or at least a parameterized media type that identifies the format. The problem with defining elements is that they are costly. Not so much to specify, but to implement correctly. If you are able to rely on existing mechanisms, you should do that as much as possible. It doesn't sound like you have a concrete use case for this, which makes me nervous. >> Section 6.2.4 defines a generic key-value mechanism. But that is someth= ing >> that XML is actually good at. Why can't users that require additional >> metadata use additional metadata as originally defined by Atom? That is= , >> replace > value=3D"12345"/> with something like >> 12345. The final paragraph= of the >> section recognizes this possibility. > > The latter example you provide is still possible, as unrecognized element= s in ROLIE/Atom don't cause validation to fail, but are just potentially ig= nored by the client/server. The rolie:property element allows automated sys= tems to have a globally available "vocabulary" of potentially available pro= perties, that can be used to populate tables or fields in automated systems= From nobody Fri Oct 20 08:33:01 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3620313420F; Fri, 20 Oct 2017 08:32:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mile@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150851357917.15411.499797286604991765@ietfa.amsl.com> Date: Fri, 20 Oct 2017 08:32:59 -0700 Archived-At: Subject: [mile] I-D Action: draft-ietf-mile-rolie-11.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 15:32:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Managed Incident Lightweight Exchange WG of the IETF. Title : Resource-Oriented Lightweight Information Exchange Authors : John P. Field Stephen A. Banghart David Waltermire Filename : draft-ietf-mile-rolie-11.txt Pages : 45 Date : 2017-10-20 Abstract: This document defines a resource-oriented approach for security automation information publication, discovery, and sharing. Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources. Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on- demand information exchange network for restricted internal use or public access repositories. This specification extends the Atom Publishing Protocol and Atom Syndication Format to transport and share security automation resource representations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mile-rolie-11 https://datatracker.ietf.org/doc/html/draft-ietf-mile-rolie-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mile-rolie-11 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 Fri Oct 20 08:33:11 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51036134292; Fri, 20 Oct 2017 08:32:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , "Nancy Cam-Winget" X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150851357932.15411.13036195512007499792.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 08:32:59 -0700 Archived-At: Subject: [mile] New Version Notification - draft-ietf-mile-rolie-11.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 15:32:59 -0000 A new version (-11) has been submitted for draft-ietf-mile-rolie: https://www.ietf.org/internet-drafts/draft-ietf-mile-rolie-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-mile-rolie-11 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. IETF Secretariat. From nobody Fri Oct 20 13:29:25 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B96831321C7; Fri, 20 Oct 2017 13:29:23 -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-mile-rolie@ietf.org, mile@ietf.org, mile-chairs@tools.ietf.org, Nancy Cam-Winget , mile-chairs@ietf.org, ncamwing@cisco.com, mile@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150853136375.15398.3882962160280653674.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 13:29:23 -0700 Archived-At: Subject: [mile] Eric Rescorla's No Objection on draft-ietf-mile-rolie-11: (with COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 20:29:24 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-mile-rolie-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-mile-rolie/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- OVERALL I share Martin Thomson's concerns about the restriction on 0-RTT. In the discussion, I saw two sets of concerns about 0-RTT: - Replay - Lack of FS As Martin says, the replay issue is an issue for the HTTP profile, so any concerns should be directed there. I agree that 0-RTT has inferior FS properties, but it's worth noting that TLS 1.2 session resumption with tickets has FS properties that are as bad or worse than those with TLS 1.3 0-RTT, and I don't see a prohibition here on session resumption. This leaves me a bit unclear on the security rationale here, and I think this needs to be consistent. INLINE COMMENTS or serialization. This approach allows the provider to support multiple, compatible formats allowing the consumer to select the most suitable version. What does "compatible" mean here. Do you mean isomorphic? supporting interactive user logins by members of the consortium SHOULD support client authentication via a federated identity scheme. Such as? Proper usage of TLS as described in Section 5.3 will in many cases aid in the mitigation of these issues. You should also note that TLS 1.2 and lower client auth leaks the user's identity to on-the-wire attackers. supported. TLS 1.2 SHOULD be implemented according to all recommendations and best practices present in [RFC7525]. You need a citation to 6125 about valiation, though I realize that 7525 cites it. From nobody Fri Oct 20 17:29:45 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD0E134536; Fri, 20 Oct 2017 17:24:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: mile@ietf.org, Kathleen.Moriarty.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854546597.20809.14913999947507412901.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:25 -0700 Archived-At: Subject: [mile] mile - Requested session has been scheduled for IETF 100 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:26 -0000 Dear Takeshi Takahashi, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mile Session 1 (1:00:00) Thursday, Afternoon Session III 1810-1910 Room Name: Olivia size: 150 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Managed Incident Lightweight Exchange Area Name: Security Area Session Requester: Takeshi Takahashi Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: First Priority: sacm saag ipsecme ipwave i2nsf dots core anima teep Second Priority: 6tisch httpbis tls hip Third Priority: 6lo roll ace lwig t2trg People who must be present: Kathleen Moriarty Nancy Cam-Winget David Waltermire Takeshi Takahashi Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Oct 21 04:08:32 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04A31321AC; Sat, 21 Oct 2017 04:08: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 y91XFXpcOWsT; Sat, 21 Oct 2017 04:08:29 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 EACE513207A; Sat, 21 Oct 2017 04:08:25 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id p1so21278631qtg.2; Sat, 21 Oct 2017 04:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xoGe0jodoBIe5c+d5lBgPiwBaogR9X9BXdTWu5xC+zg=; b=Sk9v/q2NH+cXr4z+0h3vQBm4PgrBcFk9WqLTviuNLHN/uh01WbWqraa8bA85769kQJ oybRmbRIu6AGjcvxtgvFzoV9QGQoWM49l7kj6E/oPcqoNRAskUIsFyah1hL3M2mPmPl1 jxK7eq1z64xdttgVIa/rzivB240wIYIsotGx5xYJDyJkX97RkPr9mApBCB8BQSApe4gl LlJw7CHihcr8iYzhjvbgeAYW7dgNnAb+XB1clY99oC23xBvWfzhJfHKY2O22Q6K8C2qy S+A5fKC6n4YIgiQrpI9xj60cze6zehF3RUFE8tpnWpwNs4+sgpsty5uYO1nGzVvyO8t/ EZmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xoGe0jodoBIe5c+d5lBgPiwBaogR9X9BXdTWu5xC+zg=; b=h4GKGvxp28k/q06ia4XN1Au2xkkJrdhpIgIOQpBOX5AlSJE2ZgQHCJfvs6Iy1V08uf xtSWNotmZyLGiPC7vlyD18+bXhAM9m66sarP2makQu6RKN50Xp2O8lIcnSdViCdwEzHX /tCidtv2IZyATBYgpMWyu5sm8tdVCvbvKFFn2Qx4no1LPNGv7KL8INHiSOSeOHrm01t2 538wfEL1Cw7YCu1DgTiHxcrseurg7heViVKJJuJeBKmH93C0Pl+iNjPHpd+BwZK6hdMb O/fTl1Ks/e6ZqpL8HqeRweCLlbzzFC8aZaZAoIIBMSyccjH1iDJCXx9AAWG/JSsD0bfM i6Qw== X-Gm-Message-State: AMCzsaXUYzNNXHYgPWB6XJ6eOF/LJvb5ZMq/0RvfyDgJ2oQzjJx46Unm OQCXwIhTwSHDHaMGy7DVudr1v54N X-Google-Smtp-Source: ABhQp+SJZ3OB/nWGscIdndvUS/XkjKenCKl+oe/gKOj/Rsyjjv+rfAMyAupAzG7NPnGN4IoUeXtcnw== X-Received: by 10.200.45.178 with SMTP id p47mr11081329qta.263.1508584104816; Sat, 21 Oct 2017 04:08:24 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.s3530.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id m50sm1999093qtm.31.2017.10.21.04.08.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Oct 2017 04:08:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: <150853136375.15398.3882962160280653674.idtracker@ietfa.amsl.com> Date: Sat, 21 Oct 2017 07:08:23 -0400 Cc: The IESG , draft-ietf-mile-rolie@ietf.org, mile@ietf.org, mile-chairs@ietf.org, mile-chairs@tools.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0CA3B0E6-F742-425E-88E4-0B4AC69BA288@gmail.com> References: <150853136375.15398.3882962160280653674.idtracker@ietfa.amsl.com> To: Eric Rescorla Archived-At: Subject: Re: [mile] Eric Rescorla's No Objection on draft-ietf-mile-rolie-11: (with COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 11:08:31 -0000 Hi EKR, Thanks for your review. Sent from my iPhone > On Oct 20, 2017, at 4:29 PM, Eric Rescorla wrote: >=20 > Eric Rescorla has entered the following ballot position for > draft-ietf-mile-rolie-11: 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-mile-rolie/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > OVERALL > I share Martin Thomson's concerns about the restriction on 0-RTT. In > the discussion, I saw two sets of concerns about 0-RTT: >=20 > - Replay > - Lack of FS >=20 > As Martin says, the replay issue is an issue for the HTTP profile, so > any concerns should be directed there. I agree that 0-RTT has inferior > FS properties, but it's worth noting that TLS 1.2 session resumption > with tickets has FS properties that are as bad or worse than those > with TLS 1.3 0-RTT, and I don't see a prohibition here on session > resumption. This leaves me a bit unclear on the security rationale > here, and I think this needs to be consistent. We upgrade to new protocols with the aim of improving security. I think tha= t's a fine assumption for the WG. The profile isn't far enough along at this point and isn't necessary if they= just want to ensure 0-RTT is disabled. This is a community that deals with= vulnerabilities as their day job, with systems that they want hardened as m= uch as possible to avoid issues. I know Martin mentioned wanting a test case= , but that's not fair when they are not ready and have different priorities.= Best, Kathleen=20 >=20 > INLINE COMMENTS > or serialization. This approach allows the provider to support > multiple, compatible formats allowing the consumer to select the > most suitable version. > What does "compatible" mean here. Do you mean isomorphic? >=20 > supporting interactive user logins by members of the consortium > SHOULD support client authentication via a federated identity scheme. > Such as? >=20 > Proper usage of TLS as described in Section 5.3 will in many cases > aid in the mitigation of these issues. > You should also note that TLS 1.2 and lower client auth leaks the user's > identity to on-the-wire attackers. >=20 > supported. TLS 1.2 SHOULD be implemented according to all > recommendations and best practices present in [RFC7525]. > You need a citation to 6125 about valiation, though I realize that 7525 ci= tes > it. >=20 >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From nobody Sat Oct 21 05:57:05 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18A9133065 for ; Sat, 21 Oct 2017 05:57:03 -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 6rtyVne9_boK for ; Sat, 21 Oct 2017 05:57:01 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 1B622133059 for ; Sat, 21 Oct 2017 05:57:01 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id q1so8528677ywh.5 for ; Sat, 21 Oct 2017 05:57:01 -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=tJrf4Di9ckZGxHcs4BYthUDSSY4dv65rVg2JY4d6L7M=; b=YL2sV+ygaQfc4UJVG/MGrE18CUiFQN9rJi8oK7PZVHxKtOMPsWnIgTVf4aW1B/grxu WCoKHo2vntipM8ElTUF8xfuNG0MhWq76/6jG4of3UdmvNn//JnGEPGPQPxqRglbUqOp9 onBXjeIlB59zM6WFOf6u1QI0l4J5V+L3SKe7CBIPo+4cLNHsSFszM6Ma4dnwFED8Aj3b a79MIC9fuVNHRMhiDnWhqm4TowqJ6mPKWgFuYidNu8Tso9P1xZD8j0UE7jB5xWHQw24g ryQMzvIgDok2Xo0yga9egoKt6itHaV7wTWL1SxAw72XHRMU7EHG8Xi6rPaytlE/G5zFl XO5w== 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=tJrf4Di9ckZGxHcs4BYthUDSSY4dv65rVg2JY4d6L7M=; b=Se0jkLOLFaWPIvsb8iB2Z5Gzv7x3y1ey30bnUgBWRlXfmupRbad55pX2hWbJG8gvnu DPgQGnusTtR6v1Oi9lU0RNIBZTNviszaABuEJVJSYbEPeDqkUcIM+yx89lbZSh5BXftL vFoZkVUkej0JO36QW8ndPtrxgBRM6a+KhXogelmba+UzxKKnvHnSa3eJM0bqXDNmvY2e MbOx4fd7rpxCBA78OPBiBwQRT4lQIMEWAj/kY7wbe34r2WPcm1TdPF+ExiE/4+7x8AVa 9Vbc/CC2secT3yAYB9UvIH1NiiwQtgRQXjr4rM83KbFtN1Wqegw/2JJ+Yn6NG9DHRcAk d/4Q== X-Gm-Message-State: AMCzsaVy8EVmZ2G8HvxcgL8PfiBDzKGCOIvzb9rTC8z2/fDCGMfEbqIC VH6U9VRzs8gC1Cc2QG3oNeHbupLfoBD+L2sAt+xoGw== X-Google-Smtp-Source: ABhQp+QRnyiY/M0TArIt6nJXwdwqfbW1KIyVNdeNcZuVj/kiwgDtlLS8qf6SGo/A+kmxdFFzxh5aXmnMrtuJkP1x5Ok= X-Received: by 10.129.108.3 with SMTP id h3mr5157069ywc.327.1508590620352; Sat, 21 Oct 2017 05:57:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sat, 21 Oct 2017 05:56:19 -0700 (PDT) In-Reply-To: <0CA3B0E6-F742-425E-88E4-0B4AC69BA288@gmail.com> References: <150853136375.15398.3882962160280653674.idtracker@ietfa.amsl.com> <0CA3B0E6-F742-425E-88E4-0B4AC69BA288@gmail.com> From: Eric Rescorla Date: Sat, 21 Oct 2017 05:56:19 -0700 Message-ID: To: Kathleen Moriarty Cc: The IESG , draft-ietf-mile-rolie@ietf.org, mile@ietf.org, mile-chairs@ietf.org, mile-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary="001a114d9a2809b8b3055c0e20c0" Archived-At: Subject: Re: [mile] Eric Rescorla's No Objection on draft-ietf-mile-rolie-11: (with COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 12:57:04 -0000 --001a114d9a2809b8b3055c0e20c0 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 21, 2017 at 4:08 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi EKR, > > Thanks for your review. > > Sent from my iPhone > > > On Oct 20, 2017, at 4:29 PM, Eric Rescorla wrote: > > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-mile-rolie-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-mile-rolie/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > OVERALL > > I share Martin Thomson's concerns about the restriction on 0-RTT. In > > the discussion, I saw two sets of concerns about 0-RTT: > > > > - Replay > > - Lack of FS > > > > As Martin says, the replay issue is an issue for the HTTP profile, so > > any concerns should be directed there. I agree that 0-RTT has inferior > > FS properties, but it's worth noting that TLS 1.2 session resumption > > with tickets has FS properties that are as bad or worse than those > > with TLS 1.3 0-RTT, and I don't see a prohibition here on session > > resumption. This leaves me a bit unclear on the security rationale > > here, and I think this needs to be consistent. > > We upgrade to new protocols with the aim of improving security. I think > that's a fine assumption for the WG. > > The profile isn't far enough along at this point and isn't necessary if > they just want to ensure 0-RTT is disabled. This is a community that deals > with vulnerabilities as their day job, with systems that they want hardened > as much as possible to avoid issues. I know Martin mentioned wanting a test > case, but that's not fair when they are not ready and have different > priorities. > Hi Kathleen, I don't think I'm following you. I agree that they don't need to depend on the profile if they want to disable 0-RTT. My question is *why* they want to disable 0-RTT. I heard two reasons cited: (1) concern about replay attacks and (2) lack of FS. Is lack of FS in fact a concern here? -Ekr > Best, > Kathleen > > > > INLINE COMMENTS > > or serialization. This approach allows the provider to support > > multiple, compatible formats allowing the consumer to select the > > most suitable version. > > What does "compatible" mean here. Do you mean isomorphic? > > > > supporting interactive user logins by members of the consortium > > SHOULD support client authentication via a federated identity scheme. > > Such as? > > > > Proper usage of TLS as described in Section 5.3 will in many cases > > aid in the mitigation of these issues. > > You should also note that TLS 1.2 and lower client auth leaks the user's > > identity to on-the-wire attackers. > > > > supported. TLS 1.2 SHOULD be implemented according to all > > recommendations and best practices present in [RFC7525]. > > You need a citation to 6125 about valiation, though I realize that 7525 > cites > > it. > > > > > > _______________________________________________ > > mile mailing list > > mile@ietf.org > > https://www.ietf.org/mailman/listinfo/mile > --001a114d9a2809b8b3055c0e20c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Oct 21, 2017 at 4:08 AM, Kathleen Moriarty &l= t;kat= hleen.moriarty.ietf@gmail.com> wrote:
Hi EKR,

Thanks for your review.

Sent from my iPhone

> On Oct 20, 2017, at 4:29 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-mile-rolie-11: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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/dr= aft-ietf-mile-rolie/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> OVERALL
> I share Martin Thomson's concerns about the restriction on 0-RTT. = In
> the discussion, I saw two sets of concerns about 0-RTT:
>
> - Replay
> - Lack of FS
>
> As Martin says, the replay issue is an issue for the HTTP profile, so<= br> > any concerns should be directed there. I agree that 0-RTT has inferior=
> FS properties, but it's worth noting that TLS 1.2 session resumpti= on
> with tickets has FS properties that are as bad or worse than those
> with TLS 1.3 0-RTT, and I don't see a prohibition here on session<= br> > resumption. This leaves me a bit unclear on the security rationale
> here, and I think this needs to be consistent.

We upgrade to new protocols with the aim of improving security.= =C2=A0 I think that's a fine assumption for the WG.

The profile isn't far enough along at this point and isn't necessar= y if they just want to ensure 0-RTT is disabled.=C2=A0 This is a community = that deals with vulnerabilities as their day job, with systems that they wa= nt hardened as much as possible to avoid issues. I know Martin mentioned wa= nting a test case, but that's not fair when they are not ready and have= different priorities.

Hi Kathleen,

I don't think I'm following you. I agree that= they don't need to depend on the profile if they want to disable 0-RTT= . My question is *why* they want to disable 0-RTT. I heard two reasons cite= d: (1) concern about replay attacks and (2) lack of FS. Is lack of FS in fa= ct a concern here?

-Ekr


Best,
Kathleen
>
> INLINE COMMENTS
>=C2=A0 =C2=A0 =C2=A0 or serialization.=C2=A0 This approach allows the p= rovider to support
>=C2=A0 =C2=A0 =C2=A0 multiple, compatible formats allowing the consumer= to select the
>=C2=A0 =C2=A0 =C2=A0 most suitable version.
> What does "compatible" mean here. Do you mean isomorphic? >
>=C2=A0 =C2=A0supporting interactive user logins by members of the conso= rtium
>=C2=A0 =C2=A0SHOULD support client authentication via a federated ident= ity scheme.
> Such as?
>
>=C2=A0 =C2=A0Proper usage of TLS as described in Section 5.3 will in ma= ny cases
>=C2=A0 =C2=A0aid in the mitigation of these issues.
> You should also note that TLS 1.2 and lower client auth leaks the user= 's
> identity to on-the-wire attackers.
>
>=C2=A0 =C2=A0supported.=C2=A0 TLS 1.2 SHOULD be implemented according t= o all
>=C2=A0 =C2=A0recommendations and best practices present in [RFC7525]. > You need a citation to 6125 about valiation, though I realize that 752= 5 cites
> it.
>
>
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile

--001a114d9a2809b8b3055c0e20c0-- From nobody Sun Oct 22 04:24:25 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEC0138336; Sun, 22 Oct 2017 04:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 UNlS8Mf-0d2K; Sun, 22 Oct 2017 04:24:17 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d: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 76C7A138333; Sun, 22 Oct 2017 04:24:17 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id q83so18922260qke.6; Sun, 22 Oct 2017 04:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uoAG4aWW3/slx37ho1kn9ILvnHPZAK3VWkx8nlBLNjQ=; b=QK6xBbP9aX9hrFFk6SoOE3c7Ew+wTWbBVtgn9wMjuTk8G241Xw+BDn0LJmMqw1MB+8 JeAcc2BhQ5tXyCdXizOW/g7ezF/E+mjwVGxWlkzNUcezR0HSsPQBDYM6Vg9SewLbnx95 q58FjGSZaRhimRVV5X+EUJN4c/sd23qbIljGSp42oP6K7zVcyVJ6gNpwOKem2i1xbgsF zMTHe82sJbC/9gmdKUuAbBJgYkcpOLz2U7tSvMTfBbqDuDMhSX8kmgD2foqmtPIIR86b wSbu85m+5A0F2q9VppDwW8iMuJ+smlmgfRBdjFybZS4QieiGS7O74nAHHRNiVujFCwp+ Q9+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uoAG4aWW3/slx37ho1kn9ILvnHPZAK3VWkx8nlBLNjQ=; b=XCNYCChEQl72Ilnx2875ZwWmH2bBCtfMWjzGb0MteuLKb8AwYYoNzCrDTlL6cWfi3A YUcItkTCY8f47tJXepvfirKAJx+5jj3oLO7i4icY7bt1w+WELzVvn1XPXxKHHMtWNEIw Hkok2A52Cik3tEGtt/4wkwuRtKqjIfJCRO0olIZT1NDersoGeYq+AOU+5rj7dcxdN9I9 lZs8K4jUnHDjhQU53f94hFUcm85zIP3P0Cs7Nw7Btw4oUc+k5NJR6i8acrFBnhRZ82/0 jG4tHU1RiDcwpKSw0ZUThVU0E5gWnkWbs2CAMO4uJ58uX8DjCBGQGsWNElTAyKko82qp TmFA== X-Gm-Message-State: AMCzsaW8ZWzHEIS5hjXNr6AtrYswfBI+E9cZ0gmYxsa99nu7D751y22f SBeyVu1ZRxlMugUagCN1c2Yu/V6b X-Google-Smtp-Source: ABhQp+TDo0cjVCRfjUxVg0jFx4zIm5UAij+QksMGDXJlDyit2EBXOBESbJyeDEq9k+acyfkQhgV73w== X-Received: by 10.55.33.150 with SMTP id f22mr13504345qki.207.1508671456306; Sun, 22 Oct 2017 04:24:16 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.s3530.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id s1sm3380197qte.8.2017.10.22.04.24.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 04:24:14 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-48EA4952-8E43-4EC8-B321-6FACA8F2898E Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Sun, 22 Oct 2017 07:24:13 -0400 Cc: The IESG , draft-ietf-mile-rolie@ietf.org, mile@ietf.org, mile-chairs@ietf.org, mile-chairs@tools.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <5F5FC613-7AE4-48E5-BC11-199443C2622C@gmail.com> References: <150853136375.15398.3882962160280653674.idtracker@ietfa.amsl.com> <0CA3B0E6-F742-425E-88E4-0B4AC69BA288@gmail.com> To: Eric Rescorla Archived-At: Subject: Re: [mile] Eric Rescorla's No Objection on draft-ietf-mile-rolie-11: (with COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 11:24:20 -0000 --Apple-Mail-48EA4952-8E43-4EC8-B321-6FACA8F2898E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Oct 21, 2017, at 8:56 AM, Eric Rescorla wrote: >=20 >=20 >=20 >> On Sat, Oct 21, 2017 at 4:08 AM, Kathleen Moriarty wrote: >> Hi EKR, >>=20 >> Thanks for your review. >>=20 >> Sent from my iPhone >>=20 >> > On Oct 20, 2017, at 4:29 PM, Eric Rescorla wrote: >> > >> > Eric Rescorla has entered the following ballot position for >> > draft-ietf-mile-rolie-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.ht= ml >> > 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-mile-rolie/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > OVERALL >> > I share Martin Thomson's concerns about the restriction on 0-RTT. In >> > the discussion, I saw two sets of concerns about 0-RTT: >> > >> > - Replay >> > - Lack of FS >> > >> > As Martin says, the replay issue is an issue for the HTTP profile, so >> > any concerns should be directed there. I agree that 0-RTT has inferior >> > FS properties, but it's worth noting that TLS 1.2 session resumption >> > with tickets has FS properties that are as bad or worse than those >> > with TLS 1.3 0-RTT, and I don't see a prohibition here on session >> > resumption. This leaves me a bit unclear on the security rationale >> > here, and I think this needs to be consistent. >>=20 >> We upgrade to new protocols with the aim of improving security. I think t= hat's a fine assumption for the WG. >>=20 >> The profile isn't far enough along at this point and isn't necessary if t= hey just want to ensure 0-RTT is disabled. This is a community that deals w= ith vulnerabilities as their day job, with systems that they want hardened a= s much as possible to avoid issues. I know Martin mentioned wanting a test c= ase, but that's not fair when they are not ready and have different prioriti= es. >=20 > Hi Kathleen, >=20 > I don't think I'm following you. I agree that they don't need to depend on= the profile if they want to disable 0-RTT. My question is *why* they want t= o disable 0-RTT. I heard two reasons cited: (1) concern about replay attacks= and (2) lack of FS. Is lack of FS in fact a concern here? Hi EKR, Lack of FS is a concern, so that should be added to the text. =20 They don't care about the performance increase as it's not worth the trade o= ff. Even with mitigations, you have to worry that the developer got it righ= t, the implementer didn't have a configuration mistake, or there's something= wrong with the spec. For sensitive data exchange, it's just a lot easier t= o eliminate possible threats. Kathleen=20 >=20 > -Ek >=20 >>=20 >> Best, >> Kathleen >> > >> > INLINE COMMENTS >> > or serialization. This approach allows the provider to support >> > multiple, compatible formats allowing the consumer to select the >> > most suitable version. >> > What does "compatible" mean here. Do you mean isomorphic? >> > >> > supporting interactive user logins by members of the consortium >> > SHOULD support client authentication via a federated identity scheme.= >> > Such as? >> > >> > Proper usage of TLS as described in Section 5.3 will in many cases >> > aid in the mitigation of these issues. >> > You should also note that TLS 1.2 and lower client auth leaks the user'= s >> > identity to on-the-wire attackers. >> > >> > supported. TLS 1.2 SHOULD be implemented according to all >> > recommendations and best practices present in [RFC7525]. >> > You need a citation to 6125 about valiation, though I realize that 7525= cites >> > it. >> > >> > >> > _______________________________________________ >> > mile mailing list >> > mile@ietf.org >> > https://www.ietf.org/mailman/listinfo/mile >=20 --Apple-Mail-48EA4952-8E43-4EC8-B321-6FACA8F2898E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Oct 21, 2017, at 8:56 AM, Eric Rescorla <ekr@rtfm.com> wrote:



On Sat, Oct 21, 2017 at 4:08 AM, Kathleen Moriarty &= lt;kat= hleen.moriarty.ietf@gmail.com> wrote:
Hi EKR,

Thanks for your review.

Sent from my iPhone

> On Oct 20, 2017, at 4:29 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-mile-rolie-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/ies= g/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/draf= t-ietf-mile-rolie/
>
>
>
> -------------------------------------------------------------= ---------
> COMMENT:
> -------------------------------------------------------------= ---------
>
> OVERALL
> I share Martin Thomson's concerns about the restriction on 0-RTT. In > the discussion, I saw two sets of concerns about 0-RTT:
>
> - Replay
> - Lack of FS
>
> As Martin says, the replay issue is an issue for the HTTP profile, so > any concerns should be directed there. I agree that 0-RTT has inferior<= br> > FS properties, but it's worth noting that TLS 1.2 session resumption > with tickets has FS properties that are as bad or worse than those
> with TLS 1.3 0-RTT, and I don't see a prohibition here on session
> resumption. This leaves me a bit unclear on the security rationale
> here, and I think this needs to be consistent.

We upgrade to new protocols with the aim of improving security.&= nbsp; I think that's a fine assumption for the WG.

The profile isn't far enough along at this point and isn't necessary if they= just want to ensure 0-RTT is disabled.  This is a community that deals= with vulnerabilities as their day job, with systems that they want hardened= as much as possible to avoid issues. I know Martin mentioned wanting a test= case, but that's not fair when they are not ready and have different priori= ties.

Hi Kathleen,

<= div>I don't think I'm following you. I agree that they don't need to depend o= n the profile if they want to disable 0-RTT. My question is *why* they want t= o disable 0-RTT. I heard two reasons cited: (1) concern about replay attacks= and (2) lack of FS. Is lack of FS in fact a concern here?
=

Hi EKR,

Lack of FS= is a concern, so that should be added to the text.  

They don't care about the performance increase as it's not worth the= trade off.  Even with mitigations, you have to worry that the develope= r got it right, the implementer didn't have a configuration mistake, or ther= e's something wrong with the spec.  For sensitive data exchange, it's j= ust a lot easier to eliminate possible threats.

Kat= hleen 

-Ek


Best,
Kathleen
>
> INLINE COMMENTS
>      or serialization.  This approach allows the pr= ovider to support
>      multiple, compatible formats allowing the consumer t= o select the
>      most suitable version.
> What does "compatible" mean here. Do you mean isomorphic?
>
>   supporting interactive user logins by members of the consor= tium
>   SHOULD support client authentication via a federated identi= ty scheme.
> Such as?
>
>   Proper usage of TLS as described in Section 5.3 will in man= y cases
>   aid in the mitigation of these issues.
> You should also note that TLS 1.2 and lower client auth leaks the user'= s
> identity to on-the-wire attackers.
>
>   supported.  TLS 1.2 SHOULD be implemented according to= all
>   recommendations and best practices present in [RFC7525]. > You need a citation to 6125 about valiation, though I realize that 7525= cites
> it.
>
>
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile
=

= --Apple-Mail-48EA4952-8E43-4EC8-B321-6FACA8F2898E-- From nobody Sun Oct 22 06:05:55 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44953138C7E for ; Sun, 22 Oct 2017 06:05:52 -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 Jjg4vbDv5Y77 for ; Sun, 22 Oct 2017 06:05:50 -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 5820A138C79 for ; Sun, 22 Oct 2017 06:05:48 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id y75so9932082ywg.0 for ; Sun, 22 Oct 2017 06:05: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=rkerBjTCoACSI4hhQoMEpnXmYbxsn//dTpRvuzyIc5M=; b=DHmVATkg2RMKNJ8Lv4wJ3aYgm91v9zdU9DkOPSwewvazZa1RVYoas+rJx9aMjfP6w9 4vP6lL5e3hlBcHK2kJUt3vntfe5VcideMZfi015EJ8+R2A9tc0QVJ9clOsysys3yIFCk wO2s6wVqc6XpzRGAKZHlIr1N0/44MGxKE6fJL9L8Cq2FlQtdMJ0Q2AJSkFx/Wk/3l3Yi ZCYSyIygYhrsrVnElfgO9ceQ4N9m51uPsw/SvcSxNKBtLR4097KdFJzUPqxlZ2JYMgWh 8jTsTqdiuc0+nO5RfOfxTLEWfKaROlvSzS6ccEzwKT1QKl+uMcKaLgczxNu7Aw9rpXbq vLsg== 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=rkerBjTCoACSI4hhQoMEpnXmYbxsn//dTpRvuzyIc5M=; b=WEoP/LrLoWocU890Jo/H9nTR7CLsUSOPFG+t4GvE5ydzEQuRoyJLg2+6O4LlSz23Vc 160nWLYSzk0E1DPzwVSymsUgGjuWxo6N2hKFglOXslDUYhWLNdmsoa5h2mjr7STyNgLL r0TRbdu3gQYwbsOHeh8wQNO/8QOHKBjND3FJBNHOPjm5URq9KWb85TgtIoQeclHYf4gI W3zHlmT08v81lo/d8JUyFK0xSpz9U70MUdxFBoCJjfMr78ZkHZX/sN+CnIacSXRUPN10 FHQvwaJSHxfyDz2u49C40uJpP4mnRnlQkmAcL/QzLr2ZL8k1r2UJuGrsclq8uhoQ09Ea ud3A== X-Gm-Message-State: AMCzsaWH+EP204n4SYGHM64+OiWntQW6vwPJ8mH3wfKlAP1V3A1/jRV2 UVbinaejjfxXZtBjye+3hhpCLF2rJO5Oifqf2XmnJw== X-Google-Smtp-Source: ABhQp+SLGEgGvwQoCG3KRNCu3sT4bZgy5yYwnUm0APUfDdYI7PhaXH6HRUuR9nDpTATuMr8gRBWJV0ebTUyMb2OxkGQ= X-Received: by 10.37.188.206 with SMTP id l14mr6447311ybm.419.1508677547609; Sun, 22 Oct 2017 06:05:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sun, 22 Oct 2017 06:05:06 -0700 (PDT) In-Reply-To: <5F5FC613-7AE4-48E5-BC11-199443C2622C@gmail.com> References: <150853136375.15398.3882962160280653674.idtracker@ietfa.amsl.com> <0CA3B0E6-F742-425E-88E4-0B4AC69BA288@gmail.com> <5F5FC613-7AE4-48E5-BC11-199443C2622C@gmail.com> From: Eric Rescorla Date: Sun, 22 Oct 2017 06:05:06 -0700 Message-ID: To: Kathleen Moriarty Cc: The IESG , draft-ietf-mile-rolie@ietf.org, mile@ietf.org, mile-chairs@ietf.org, mile-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary="089e08265a7c4e6236055c225d67" Archived-At: Subject: Re: [mile] Eric Rescorla's No Objection on draft-ietf-mile-rolie-11: (with COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 13:05:52 -0000 --089e08265a7c4e6236055c225d67 Content-Type: text/plain; charset="UTF-8" On Sun, Oct 22, 2017 at 4:24 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > Sent from my iPhone > > On Oct 21, 2017, at 8:56 AM, Eric Rescorla wrote: > > > > On Sat, Oct 21, 2017 at 4:08 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Hi EKR, >> >> Thanks for your review. >> >> Sent from my iPhone >> >> > On Oct 20, 2017, at 4:29 PM, Eric Rescorla wrote: >> > >> > Eric Rescorla has entered the following ballot position for >> > draft-ietf-mile-rolie-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/stat >> ement/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-mile-rolie/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > OVERALL >> > I share Martin Thomson's concerns about the restriction on 0-RTT. In >> > the discussion, I saw two sets of concerns about 0-RTT: >> > >> > - Replay >> > - Lack of FS >> > >> > As Martin says, the replay issue is an issue for the HTTP profile, so >> > any concerns should be directed there. I agree that 0-RTT has inferior >> > FS properties, but it's worth noting that TLS 1.2 session resumption >> > with tickets has FS properties that are as bad or worse than those >> > with TLS 1.3 0-RTT, and I don't see a prohibition here on session >> > resumption. This leaves me a bit unclear on the security rationale >> > here, and I think this needs to be consistent. >> >> We upgrade to new protocols with the aim of improving security. I think >> that's a fine assumption for the WG. >> >> The profile isn't far enough along at this point and isn't necessary if >> they just want to ensure 0-RTT is disabled. This is a community that deals >> with vulnerabilities as their day job, with systems that they want hardened >> as much as possible to avoid issues. I know Martin mentioned wanting a test >> case, but that's not fair when they are not ready and have different >> priorities. >> > > Hi Kathleen, > > I don't think I'm following you. I agree that they don't need to depend on > the profile if they want to disable 0-RTT. My question is *why* they want > to disable 0-RTT. I heard two reasons cited: (1) concern about replay > attacks and (2) lack of FS. Is lack of FS in fact a concern here? > > > Hi EKR, > > Lack of FS is a concern, so that should be added to the text. > > They don't care about the performance increase as it's not worth the trade > off. Even with mitigations, you have to worry that the developer got it > right, the implementer didn't have a configuration mistake, or there's > something wrong with the spec. For sensitive data exchange, it's just a > lot easier to eliminate possible threats. > In that case, it seems like this text ought to also recommend against using TLS 1.2 session resumption. -Ekr Kathleen > > > -Ek > > >> Best, >> Kathleen >> > >> > INLINE COMMENTS >> > or serialization. This approach allows the provider to support >> > multiple, compatible formats allowing the consumer to select the >> > most suitable version. >> > What does "compatible" mean here. Do you mean isomorphic? >> > >> > supporting interactive user logins by members of the consortium >> > SHOULD support client authentication via a federated identity scheme. >> > Such as? >> > >> > Proper usage of TLS as described in Section 5.3 will in many cases >> > aid in the mitigation of these issues. >> > You should also note that TLS 1.2 and lower client auth leaks the user's >> > identity to on-the-wire attackers. >> > >> > supported. TLS 1.2 SHOULD be implemented according to all >> > recommendations and best practices present in [RFC7525]. >> > You need a citation to 6125 about valiation, though I realize that 7525 >> cites >> > it. >> > >> > >> > _______________________________________________ >> > mile mailing list >> > mile@ietf.org >> > https://www.ietf.org/mailman/listinfo/mile >> > > --089e08265a7c4e6236055c225d67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Oct 22, 2017 at 4:24 AM, Kathleen Moriarty &l= t;kat= hleen.moriarty.ietf@gmail.com> wrote:


Sent from my iPhone

On Oct 21, 2017, at 8:56 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Sat, Oct 21, 2017 at 4:0= 8 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.= com> wrote:
Hi EKR,

Thanks for your review.

Sent from my iPhone

> On Oct 20, 2017, at 4:29 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-mile-rolie-11: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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/dr= aft-ietf-mile-rolie/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> OVERALL
> I share Martin Thomson's concerns about the restriction on 0-RTT. = In
> the discussion, I saw two sets of concerns about 0-RTT:
>
> - Replay
> - Lack of FS
>
> As Martin says, the replay issue is an issue for the HTTP profile, so<= br> > any concerns should be directed there. I agree that 0-RTT has inferior=
> FS properties, but it's worth noting that TLS 1.2 session resumpti= on
> with tickets has FS properties that are as bad or worse than those
> with TLS 1.3 0-RTT, and I don't see a prohibition here on session<= br> > resumption. This leaves me a bit unclear on the security rationale
> here, and I think this needs to be consistent.

We upgrade to new protocols with the aim of improving security.= =C2=A0 I think that's a fine assumption for the WG.

The profile isn't far enough along at this point and isn't necessar= y if they just want to ensure 0-RTT is disabled.=C2=A0 This is a community = that deals with vulnerabilities as their day job, with systems that they wa= nt hardened as much as possible to avoid issues. I know Martin mentioned wa= nting a test case, but that's not fair when they are not ready and have= different priorities.

Hi Kathleen,

I don't think I'm following you. I agree that= they don't need to depend on the profile if they want to disable 0-RTT= . My question is *why* they want to disable 0-RTT. I heard two reasons cite= d: (1) concern about replay attacks and (2) lack of FS. Is lack of FS in fa= ct a concern here?

Hi EKR,

Lack of FS is a concern, so that sh= ould be added to the text. =C2=A0

They don't c= are about the performance increase as it's not worth the trade off.=C2= =A0 Even with mitigations, you have to worry that the developer got it righ= t, the implementer didn't have a configuration mistake, or there's = something wrong with the spec.=C2=A0 For sensitive data exchange, it's = just a lot easier to eliminate possible threats.

In that case, it seems like this text ought to also recom= mend against using TLS 1.2 session resumption.

-Ek= r


Kathleen=C2=A0
-Ek


Best,
Kathleen
>
> INLINE COMMENTS
>=C2=A0 =C2=A0 =C2=A0 or serialization.=C2=A0 This approach allows the p= rovider to support
>=C2=A0 =C2=A0 =C2=A0 multiple, compatible formats allowing the consumer= to select the
>=C2=A0 =C2=A0 =C2=A0 most suitable version.
> What does "compatible" mean here. Do you mean isomorphic? >
>=C2=A0 =C2=A0supporting interactive user logins by members of the conso= rtium
>=C2=A0 =C2=A0SHOULD support client authentication via a federated ident= ity scheme.
> Such as?
>
>=C2=A0 =C2=A0Proper usage of TLS as described in Section 5.3 will in ma= ny cases
>=C2=A0 =C2=A0aid in the mitigation of these issues.
> You should also note that TLS 1.2 and lower client auth leaks the user= 's
> identity to on-the-wire attackers.
>
>=C2=A0 =C2=A0supported.=C2=A0 TLS 1.2 SHOULD be implemented according t= o all
>=C2=A0 =C2=A0recommendations and best practices present in [RFC7525]. > You need a citation to 6125 about valiation, though I realize that 752= 5 cites
> it.
>
>
> _______________________________________________
> mile mailing list
> mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile


--089e08265a7c4e6236055c225d67-- From nobody Sun Oct 22 08:50:35 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A6D1399D6; Sun, 22 Oct 2017 08:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 rUMiPt5x_cPB; Sun, 22 Oct 2017 08:50:23 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 2C9B81399D3; Sun, 22 Oct 2017 08:50:23 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id m189so19301112qke.4; Sun, 22 Oct 2017 08:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IemS+ppEf7GMGOaGQ4rsVwYqySwsmFrylc1W7XNzbd0=; b=a8iLeLqVATkF1Eqye/+LYNvKz7Z2nDmOzt7PjvDfTNgntCEZzqzUKAudVDGccf9rQW jxkQaNlekA3H2mDvkATKNR+0G7l/FWphMzBcCKC7dyQ2nWx1wfO8tbNNXAK2xhShzIcL Y7vnTZ4a67S1j/XkzWQHA4J0rjfi9DLVY2liQXOg7MPy3s+ptt2qCnjt43lHm7erFVyX mhbUpf8yafItCIl5mkfWGKlx4KbUZ+Rg4A5NpSoZCyQG/s89prFiqG7v/IkbVlxThEam G+/3t/iC53Rr35+AVYzZWLJmbwNbuJAX1qEy8Rx62L5/q4q2pPXcLmyf6kZgfkP38tPq WD6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IemS+ppEf7GMGOaGQ4rsVwYqySwsmFrylc1W7XNzbd0=; b=Se8NHgzpkOV2L1Pnbcr9Pt9fEZhoaBJEISBKs5Xs+5U6r3uWuF3fJeNuB+kOlqRdu3 2TE9ExAd9y4W8wUOomdJyDPeGBQn4e2zpkdNkTgAXD69g3KCq+nUpZNCCn6pXOm5398z bPbaS1eUIxvu32mg97g6n+kzmQtEeNAaDr7kq5fg2IgtYMBF3c/NwRihITtmsRT0bLtq DvAhZX3nWYRPs6/2NnmHsTakU0a8MHqaIzHpki9IINK2pZ+faRJ517NTpMEf7Bprm+7p wkEmfCeHHK4sABoSU7e0e/DtGHWWRtK5UenXa45fSpo3lKrtDvrYPjW3vlUt1qZViktS /6lg== X-Gm-Message-State: AMCzsaVaRyIXzUDcIyM/6nIXBBoW/2cOH9A1L6qL9R/BpTzLP9IMZjJc KmTJ7Uwybc9iDUs0Dn/PDkxuAwrQ X-Google-Smtp-Source: ABhQp+Qy4MpAYsjYLTvKvIekAjKRazXXAZoHO6x/pq/nkfz0Y/nr80XoGEC4ZiZL2t8NW5L2KbGvIA== X-Received: by 10.55.26.91 with SMTP id a88mr14219396qka.11.1508687422127; Sun, 22 Oct 2017 08:50:22 -0700 (PDT) Received: from ?IPv6:2600:380:bd1d:d4a6:b94a:696e:35cb:921f? ([2600:380:bd1d:d4a6:b94a:696e:35cb:921f]) by smtp.gmail.com with ESMTPSA id l50sm3663791qtl.33.2017.10.22.08.50.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 08:50:21 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E5EF7764-0ADE-4FDE-8361-C849B29C3BAD Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Sun, 22 Oct 2017 11:50:20 -0400 Cc: The IESG , draft-ietf-mile-rolie@ietf.org, mile@ietf.org, mile-chairs@ietf.org, mile-chairs@tools.ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <150853136375.15398.3882962160280653674.idtracker@ietfa.amsl.com> <0CA3B0E6-F742-425E-88E4-0B4AC69BA288@gmail.com> <5F5FC613-7AE4-48E5-BC11-199443C2622C@gmail.com> To: Eric Rescorla Archived-At: Subject: Re: [mile] Eric Rescorla's No Objection on draft-ietf-mile-rolie-11: (with COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 15:50:26 -0000 --Apple-Mail-E5EF7764-0ADE-4FDE-8361-C849B29C3BAD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Oct 22, 2017, at 9:05 AM, Eric Rescorla wrote: >=20 >=20 >=20 >> On Sun, Oct 22, 2017 at 4:24 AM, Kathleen Moriarty wrote: >>=20 >>=20 >> Sent from my iPhone >>=20 >>> On Oct 21, 2017, at 8:56 AM, Eric Rescorla wrote: >>>=20 >>>=20 >>>=20 >>>> On Sat, Oct 21, 2017 at 4:08 AM, Kathleen Moriarty wrote: >>>> Hi EKR, >>>>=20 >>>> Thanks for your review. >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> > On Oct 20, 2017, at 4:29 PM, Eric Rescorla wrote: >>>> > >>>> > Eric Rescorla has entered the following ballot position for >>>> > draft-ietf-mile-rolie-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 th= is >>>> > 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-mile-rolie/ >>>> > >>>> > >>>> > >>>> > ---------------------------------------------------------------------= - >>>> > COMMENT: >>>> > ---------------------------------------------------------------------= - >>>> > >>>> > OVERALL >>>> > I share Martin Thomson's concerns about the restriction on 0-RTT. In >>>> > the discussion, I saw two sets of concerns about 0-RTT: >>>> > >>>> > - Replay >>>> > - Lack of FS >>>> > >>>> > As Martin says, the replay issue is an issue for the HTTP profile, so= >>>> > any concerns should be directed there. I agree that 0-RTT has inferio= r >>>> > FS properties, but it's worth noting that TLS 1.2 session resumption >>>> > with tickets has FS properties that are as bad or worse than those >>>> > with TLS 1.3 0-RTT, and I don't see a prohibition here on session >>>> > resumption. This leaves me a bit unclear on the security rationale >>>> > here, and I think this needs to be consistent. >>>>=20 >>>> We upgrade to new protocols with the aim of improving security. I thin= k that's a fine assumption for the WG. >>>>=20 >>>> The profile isn't far enough along at this point and isn't necessary if= they just want to ensure 0-RTT is disabled. This is a community that deals= with vulnerabilities as their day job, with systems that they want hardened= as much as possible to avoid issues. I know Martin mentioned wanting a test= case, but that's not fair when they are not ready and have different priori= ties. >>>=20 >>> Hi Kathleen, >>>=20 >>> I don't think I'm following you. I agree that they don't need to depend o= n the profile if they want to disable 0-RTT. My question is *why* they want t= o disable 0-RTT. I heard two reasons cited: (1) concern about replay attacks= and (2) lack of FS. Is lack of FS in fact a concern here? >>=20 >> Hi EKR, >>=20 >> Lack of FS is a concern, so that should be added to the text. =20 >>=20 >> They don't care about the performance increase as it's not worth the trad= e off. Even with mitigations, you have to worry that the developer got it r= ight, the implementer didn't have a configuration mistake, or there's someth= ing wrong with the spec. For sensitive data exchange, it's just a lot easie= r to eliminate possible threats. >=20 > In that case, it seems like this text ought to also recommend against usin= g TLS 1.2 session resumption. There may have been text to that effect in the version Martin reviewed and t= hey can certainly add that or add it back. My review had them add 7525, mea= ning to take out duplicative text and then they removed a bunch after Martin= made the same comment. Kathleen=20 >=20 > -Ekr >=20 >=20 >> Kathleen=20 >>>=20 >>> -Ek >>>=20 >>>>=20 >>>> Best, >>>> Kathleen >>>> > >>>> > INLINE COMMENTS >>>> > or serialization. This approach allows the provider to support >>>> > multiple, compatible formats allowing the consumer to select the= >>>> > most suitable version. >>>> > What does "compatible" mean here. Do you mean isomorphic? >>>> > >>>> > supporting interactive user logins by members of the consortium >>>> > SHOULD support client authentication via a federated identity schem= e. >>>> > Such as? >>>> > >>>> > Proper usage of TLS as described in Section 5.3 will in many cases >>>> > aid in the mitigation of these issues. >>>> > You should also note that TLS 1.2 and lower client auth leaks the use= r's >>>> > identity to on-the-wire attackers. >>>> > >>>> > supported. TLS 1.2 SHOULD be implemented according to all >>>> > recommendations and best practices present in [RFC7525]. >>>> > You need a citation to 6125 about valiation, though I realize that 75= 25 cites >>>> > it. >>>> > >>>> > >>>> > _______________________________________________ >>>> > mile mailing list >>>> > mile@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/mile >>>=20 >=20 --Apple-Mail-E5EF7764-0ADE-4FDE-8361-C849B29C3BAD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Oct 22, 2017, at 9:05 AM, Eric Rescorla <ekr@rtfm.com> wrote:



On Sun, Oct 22, 2017 at 4:24 AM, Kathleen Moriarty &= lt;kat= hleen.moriarty.ietf@gmail.com> wrote:


Sent from my iPhone

On Oct 21, 2017, at 8:56 AM, Eric Rescorla <ekr@rtfm.com> wrote:

<= /div>


On Sat, Oct 21, 2017 at 4:08 AM, Kath= leen Moriarty <kathleen.moriarty.ietf@gmail.com><= /span> wrote:
Hi EKR,

Thanks for your review.

Sent from my iPhone

> On Oct 20, 2017, at 4:29 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-mile-rolie-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/ies= g/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/draf= t-ietf-mile-rolie/
>
>
>
> -------------------------------------------------------------= ---------
> COMMENT:
> -------------------------------------------------------------= ---------
>
> OVERALL
> I share Martin Thomson's concerns about the restriction on 0-RTT. In > the discussion, I saw two sets of concerns about 0-RTT:
>
> - Replay
> - Lack of FS
>
> As Martin says, the replay issue is an issue for the HTTP profile, so > any concerns should be directed there. I agree that 0-RTT has inferior<= br> > FS properties, but it's worth noting that TLS 1.2 session resumption > with tickets has FS properties that are as bad or worse than those
> with TLS 1.3 0-RTT, and I don't see a prohibition here on session
> resumption. This leaves me a bit unclear on the security rationale
> here, and I think this needs to be consistent.

We upgrade to new protocols with the aim of improving security.&= nbsp; I think that's a fine assumption for the WG.

The profile isn't far enough along at this point and isn't necessary if they= just want to ensure 0-RTT is disabled.  This is a community that deals= with vulnerabilities as their day job, with systems that they want hardened= as much as possible to avoid issues. I know Martin mentioned wanting a test= case, but that's not fair when they are not ready and have different priori= ties.

Hi Kathleen,

<= div>I don't think I'm following you. I agree that they don't need to depend o= n the profile if they want to disable 0-RTT. My question is *why* they want t= o disable 0-RTT. I heard two reasons cited: (1) concern about replay attacks= and (2) lack of FS. Is lack of FS in fact a concern here?
=

Hi EKR,

Lack of FS is a concern, so that should be added to the text.  

They don't care about the performance increase as it's n= ot worth the trade off.  Even with mitigations, you have to worry that t= he developer got it right, the implementer didn't have a configuration mista= ke, or there's something wrong with the spec.  For sensitive data excha= nge, it's just a lot easier to eliminate possible threats.

In that case, it seems like this text ought to al= so recommend against using TLS 1.2 session resumption.

There may have been text to that effect i= n the version Martin reviewed and they can certainly add that or add it back= .  My review had them add 7525, meaning to take out duplicative text an= d then they removed a bunch after Martin made the same comment.

Kathleen 

-Ekr<= /div>


Kathleen 

<= div>-Ek


Best,
Kathleen
>
> INLINE COMMENTS
>      or serialization.  This approach allows the pr= ovider to support
>      multiple, compatible formats allowing the consumer t= o select the
>      most suitable version.
> What does "compatible" mean here. Do you mean isomorphic?
>
>   supporting interactive user logins by members of the consor= tium
>   SHOULD support client authentication via a federated identi= ty scheme.
> Such as?
>
>   Proper usage of TLS as described in Section 5.3 will in man= y cases
>   aid in the mitigation of these issues.
> You should also note that TLS 1.2 and lower client auth leaks the user'= s
> identity to on-the-wire attackers.
>
>   supported.  TLS 1.2 SHOULD be implemented according to= all
>   recommendations and best practices present in [RFC7525]. > You need a citation to 6125 about valiation, though I realize that 7525= cites
> it.
>
>
> _______________________________________________
> mile mailing list
> mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile
=


= --Apple-Mail-E5EF7764-0ADE-4FDE-8361-C849B29C3BAD-- From nobody Mon Oct 23 11:33:48 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E65138351; Mon, 23 Oct 2017 11:33:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 iNDdAH_J2K5T; Mon, 23 Oct 2017 11:33:45 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0121.outbound.protection.outlook.com [23.103.201.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D5C139A22; Mon, 23 Oct 2017 11:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BJnqfeISv80GkcgTcdp8LDDf3owlYHIVJa7LJeq2GWE=; b=eHb/PZnibsHcyUIyVbM2LdtA6sn97tRl8h4W+niiauneWIrOgkU/pAdTky/IQeyisbvJLoPNo413FTMtJs8Ip54/LBJPpIJiF5srlX5MwPW7wquZj6Yrn0opuQOxJdzkKLHDU30wybo/5DuUC+oczyNknzhIzN+rgkBxUcjZ1ug= Received: from CY4PR09MB1495.namprd09.prod.outlook.com (10.173.191.141) by CY4PR09MB1493.namprd09.prod.outlook.com (10.173.191.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 23 Oct 2017 18:33:43 +0000 Received: from CY4PR09MB1495.namprd09.prod.outlook.com ([10.173.191.141]) by CY4PR09MB1495.namprd09.prod.outlook.com ([10.173.191.141]) with mapi id 15.20.0156.006; Mon, 23 Oct 2017 18:33:43 +0000 From: "Waltermire, David A. (Fed)" To: "art-ads@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" , "mile@ietf.org" Thread-Topic: [mile] Artart last call review of draft-ietf-mile-rolie-10 Thread-Index: AQHTQLy6AlrnYGEzJkSW/mjw8rDt26Lra++AgAB9mgCABewtsA== Date: Mon, 23 Oct 2017 18:33:43 +0000 Message-ID: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1493; 6:Vta+2Tage0dB4BDo01oI7YhyngnRFVRCleveRr3m2pPf+kmOASbRa7G0uw5YnthrwM7k8zZ/TnmTHGzY/wnlI8AohRRAHowfZA2sQTbog9Vw4BbPta6nHDDCEP9NVGTrUS0xFhDXncFzQIGT9Tk5ZgKUlIVER+OqCkHaWx3Y+vLqg66vc6E4siN5sZcPzXA4v5MTZgghTjnczf8YtOTdr7xnm/m4MZteS1M/2jQi90J7dhnXjVwB/JXhrE9yEStIo2LoK7H8Uln7uxIXHCR9C1jlucoc/xtIBRf0Ney64IyoxLUHhVLCURWBdeg87g52RrS080UG2kxRbN5xGsHDJQ==; 5:bp+qHlQHIWWE5pTnpsNDyCpSRYoRjtSraNp2iGcAWOnH9An/KHKazLyjZnkqCa75u98RBf9OSSeswqyAMDYNH34jfcsa4I6CMk2PiQ/UHYgLKLn+onp+DdIIKPmFKPN76SiO3jqsTDuBCmPBQCc57A==; 24:rABFbqDn0WSNxyaUS7LKtm8GnrgHw8Co12qY5wr3CPCuaE/Dpl0TsqjrP+WXYoskWSAdEQowXn55bFDgdEqg9qhx91qpC61BHLUufw9PA5U=; 7:WTiahKy5DXjrDRKsATk9Y7qIjBJ+TZU39j5AJ4JWM0KNVgRi9QxjZYG1xFXmxNTlO1CAWOKGUGzrGdG6To3HGMhsaRUvWDq+e59yI0pwu8YSaQ8fkoa2DZo/KxyFBNVcotVYSsQ1zcJrM60324SgG0Fguj5Tc7A9+3AIZWvwkizTwTJv/z9tZGZCQryDKaGdLf2tX9aMd3uf7RqCCF1MnHbHt8KbMDev3GRZIElC+Ss= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: cf38db75-b25b-4ef5-7216-08d51a4496fc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR09MB1493; x-ms-traffictypediagnostic: CY4PR09MB1493: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231020)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1493; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1493; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(199003)(76104003)(2201001)(14454004)(8936002)(110136005)(2950100002)(2501003)(68736007)(25786009)(3660700001)(3280700002)(81156014)(86362001)(66066001)(316002)(3846002)(450100002)(102836003)(6116002)(2906002)(81166006)(478600001)(8676002)(74316002)(305945005)(105586002)(5660300001)(7736002)(229853002)(9686003)(6436002)(33656002)(76176999)(50986999)(101416001)(77096006)(106356001)(230783001)(189998001)(2900100001)(53936002)(6506006)(97736004)(54356999)(7696004)(6246003)(99286003)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1493; H:CY4PR09MB1495.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 18:33:43.4299 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1493 Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 18:33:47 -0000 QmVuLCBBbGV4ZXksIGFuZCBBZGFtLA0KDQpXb3JraW5nIHRocm91Z2ggTWFydGluJ3MgQVJUQVJU IHJldmlldyBvZiBST0xJRSwgd2UgaGFkIHRoZSBmb2xsb3dpbmcgZXhjaGFuZ2Ugd2l0aCBNYXJ0 aW4uDQoNCj4gPj4gRnJvbSBtYXJ0aW46DQo+ID4+IFF1ZXN0aW9uOiBpdCdzIGZhaXJseSB3aWRl bHkgYWNjZXB0ZWQgdGhhdCB1c2Ugb2YgSVJJcyBpbiBBdG9tIGhhcw0KPiA+PiBiZWVuIGxlc3Mg dGhhbiBzdWNjZXNzZnVsLiAgRG8geW91IHdhbnQgdG8gbWFuZGF0ZSB1c2Ugb2YgVVJJcw0KPiA+ PiBpbnN0ZWFkPyAgVGhpcyB3b3VsZCBhcHBseSB0byBib3RoIGxpbmsgcmVsYXRpb25zIGFuZCB0 aGUgInNyYyIgYXR0cmlidXRlLg0KPiA+DQo+ID4gRnJvbSBTdGVwaGVuOg0KPiA+IFdlIHdhbnRl ZCB0byBzdGF5IGluIGxpbmUgd2l0aCB0aGUgcmVxdWlyZW1lbnRzIGluIEF0b20sIGlmIHRoaXMg YmVjb21lcw0KPiBhbiBpc3N1ZSBpdCBtYXkgYmUgd29ydGggcmUtZXhhbWluaW5nLg0KPiANCj4g RnJvbSBNYXJ0aW46DQo+IFRoaXMgaXMgeW91ciBjaGFuY2UuICBZb3UgZG9uJ3QgZ2V0IHRvIGdv IGJhY2sgb3IgcmUtZXhhbWluZSBvbmNlIHlvdXINCj4gcHJvdG9jb2wgaXMgd2lkZWx5IGRlcGxv eWVkLg0KDQpJIHVuZGVyc3RhbmQgTWFydGluJ3MgcG9pbnQgYWJvdmUuIEl0IGlzIGJhc2ljYWxs eSB0aGF0IFVSSXMgYXJlIG1vcmUgbmFycm93bHkgc2NvcGVkIGFuZCBpbnRlcm9wZXJhYmxlIHRo YW4gSVJJcyBhcmUuIEZyb20gbXkgZXhwZXJpZW5jZSBJIGhhdmUgc2VlbiB0aGF0IFVSSXMgYXJl IGJyb2FkbHkgdXNlZCwgYW5kIElSSXMgaGF2ZSBub3Qgc2VlbiBtdWNoIHVzZS4gR2l2ZW4gdGhp cyBmZWVkYmFjaywgaXQgbG9va3MgbGlrZSB0aGUgYmVzdCB0aGluZyB0byBkbyBtaWdodCBiZSB0 byBicmVhayB3aXRoIEFUT00gYW5kIHVzZSB0aGUgbW9yZSByZXN0cmljdGl2ZSBVUkkgaW4gUk9M SUUgdG8gZW5zdXJlIHRoZSBiZXN0IHBvc3NpYmxlIGludGVyb3BlcmFiaWxpdHkgd2l0aGluIHJl c3VsdGluZyBzb2x1dGlvbnMuDQoNCldoYXQgZG8geW91IHRoaW5rIGFib3V0IHN1Y2ggYSBjaGFu Z2U/IEFueSBhZHZpY2U/DQoNClRoYW5rcywNCkRhdmUNCg0K From nobody Mon Oct 23 11:33:53 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 96248139A22; Mon, 23 Oct 2017 11:33:47 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E65138351; Mon, 23 Oct 2017 11:33:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 iNDdAH_J2K5T; Mon, 23 Oct 2017 11:33:45 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0121.outbound.protection.outlook.com [23.103.201.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D5C139A22; Mon, 23 Oct 2017 11:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BJnqfeISv80GkcgTcdp8LDDf3owlYHIVJa7LJeq2GWE=; b=eHb/PZnibsHcyUIyVbM2LdtA6sn97tRl8h4W+niiauneWIrOgkU/pAdTky/IQeyisbvJLoPNo413FTMtJs8Ip54/LBJPpIJiF5srlX5MwPW7wquZj6Yrn0opuQOxJdzkKLHDU30wybo/5DuUC+oczyNknzhIzN+rgkBxUcjZ1ug= Received: from CY4PR09MB1495.namprd09.prod.outlook.com (10.173.191.141) by CY4PR09MB1493.namprd09.prod.outlook.com (10.173.191.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 23 Oct 2017 18:33:43 +0000 Received: from CY4PR09MB1495.namprd09.prod.outlook.com ([10.173.191.141]) by CY4PR09MB1495.namprd09.prod.outlook.com ([10.173.191.141]) with mapi id 15.20.0156.006; Mon, 23 Oct 2017 18:33:43 +0000 From: "Waltermire, David A. (Fed)" To: "art-ads@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" , "mile@ietf.org" Thread-Topic: [mile] Artart last call review of draft-ietf-mile-rolie-10 Thread-Index: AQHTQLy6AlrnYGEzJkSW/mjw8rDt26Lra++AgAB9mgCABewtsA== Date: Mon, 23 Oct 2017 18:33:43 +0000 Message-ID: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1493; 6:Vta+2Tage0dB4BDo01oI7YhyngnRFVRCleveRr3m2pPf+kmOASbRa7G0uw5YnthrwM7k8zZ/TnmTHGzY/wnlI8AohRRAHowfZA2sQTbog9Vw4BbPta6nHDDCEP9NVGTrUS0xFhDXncFzQIGT9Tk5ZgKUlIVER+OqCkHaWx3Y+vLqg66vc6E4siN5sZcPzXA4v5MTZgghTjnczf8YtOTdr7xnm/m4MZteS1M/2jQi90J7dhnXjVwB/JXhrE9yEStIo2LoK7H8Uln7uxIXHCR9C1jlucoc/xtIBRf0Ney64IyoxLUHhVLCURWBdeg87g52RrS080UG2kxRbN5xGsHDJQ==; 5:bp+qHlQHIWWE5pTnpsNDyCpSRYoRjtSraNp2iGcAWOnH9An/KHKazLyjZnkqCa75u98RBf9OSSeswqyAMDYNH34jfcsa4I6CMk2PiQ/UHYgLKLn+onp+DdIIKPmFKPN76SiO3jqsTDuBCmPBQCc57A==; 24:rABFbqDn0WSNxyaUS7LKtm8GnrgHw8Co12qY5wr3CPCuaE/Dpl0TsqjrP+WXYoskWSAdEQowXn55bFDgdEqg9qhx91qpC61BHLUufw9PA5U=; 7:WTiahKy5DXjrDRKsATk9Y7qIjBJ+TZU39j5AJ4JWM0KNVgRi9QxjZYG1xFXmxNTlO1CAWOKGUGzrGdG6To3HGMhsaRUvWDq+e59yI0pwu8YSaQ8fkoa2DZo/KxyFBNVcotVYSsQ1zcJrM60324SgG0Fguj5Tc7A9+3AIZWvwkizTwTJv/z9tZGZCQryDKaGdLf2tX9aMd3uf7RqCCF1MnHbHt8KbMDev3GRZIElC+Ss= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: cf38db75-b25b-4ef5-7216-08d51a4496fc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR09MB1493; x-ms-traffictypediagnostic: CY4PR09MB1493: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231020)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1493; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1493; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(199003)(76104003)(2201001)(14454004)(8936002)(110136005)(2950100002)(2501003)(68736007)(25786009)(3660700001)(3280700002)(81156014)(86362001)(66066001)(316002)(3846002)(450100002)(102836003)(6116002)(2906002)(81166006)(478600001)(8676002)(74316002)(305945005)(105586002)(5660300001)(7736002)(229853002)(9686003)(6436002)(33656002)(76176999)(50986999)(101416001)(77096006)(106356001)(230783001)(189998001)(2900100001)(53936002)(6506006)(97736004)(54356999)(7696004)(6246003)(99286003)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1493; H:CY4PR09MB1495.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 18:33:43.4299 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1493 Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171023183347.96248139A22@ietfa.amsl.com> Resent-Date: Mon, 23 Oct 2017 11:33:47 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 18:33:47 -0000 QmVuLCBBbGV4ZXksIGFuZCBBZGFtLA0KDQpXb3JraW5nIHRocm91Z2ggTWFydGluJ3MgQVJUQVJU IHJldmlldyBvZiBST0xJRSwgd2UgaGFkIHRoZSBmb2xsb3dpbmcgZXhjaGFuZ2Ugd2l0aCBNYXJ0 aW4uDQoNCj4gPj4gRnJvbSBtYXJ0aW46DQo+ID4+IFF1ZXN0aW9uOiBpdCdzIGZhaXJseSB3aWRl bHkgYWNjZXB0ZWQgdGhhdCB1c2Ugb2YgSVJJcyBpbiBBdG9tIGhhcw0KPiA+PiBiZWVuIGxlc3Mg dGhhbiBzdWNjZXNzZnVsLiAgRG8geW91IHdhbnQgdG8gbWFuZGF0ZSB1c2Ugb2YgVVJJcw0KPiA+ PiBpbnN0ZWFkPyAgVGhpcyB3b3VsZCBhcHBseSB0byBib3RoIGxpbmsgcmVsYXRpb25zIGFuZCB0 aGUgInNyYyIgYXR0cmlidXRlLg0KPiA+DQo+ID4gRnJvbSBTdGVwaGVuOg0KPiA+IFdlIHdhbnRl ZCB0byBzdGF5IGluIGxpbmUgd2l0aCB0aGUgcmVxdWlyZW1lbnRzIGluIEF0b20sIGlmIHRoaXMg YmVjb21lcw0KPiBhbiBpc3N1ZSBpdCBtYXkgYmUgd29ydGggcmUtZXhhbWluaW5nLg0KPiANCj4g RnJvbSBNYXJ0aW46DQo+IFRoaXMgaXMgeW91ciBjaGFuY2UuICBZb3UgZG9uJ3QgZ2V0IHRvIGdv IGJhY2sgb3IgcmUtZXhhbWluZSBvbmNlIHlvdXINCj4gcHJvdG9jb2wgaXMgd2lkZWx5IGRlcGxv eWVkLg0KDQpJIHVuZGVyc3RhbmQgTWFydGluJ3MgcG9pbnQgYWJvdmUuIEl0IGlzIGJhc2ljYWxs eSB0aGF0IFVSSXMgYXJlIG1vcmUgbmFycm93bHkgc2NvcGVkIGFuZCBpbnRlcm9wZXJhYmxlIHRo YW4gSVJJcyBhcmUuIEZyb20gbXkgZXhwZXJpZW5jZSBJIGhhdmUgc2VlbiB0aGF0IFVSSXMgYXJl IGJyb2FkbHkgdXNlZCwgYW5kIElSSXMgaGF2ZSBub3Qgc2VlbiBtdWNoIHVzZS4gR2l2ZW4gdGhp cyBmZWVkYmFjaywgaXQgbG9va3MgbGlrZSB0aGUgYmVzdCB0aGluZyB0byBkbyBtaWdodCBiZSB0 byBicmVhayB3aXRoIEFUT00gYW5kIHVzZSB0aGUgbW9yZSByZXN0cmljdGl2ZSBVUkkgaW4gUk9M SUUgdG8gZW5zdXJlIHRoZSBiZXN0IHBvc3NpYmxlIGludGVyb3BlcmFiaWxpdHkgd2l0aGluIHJl c3VsdGluZyBzb2x1dGlvbnMuDQoNCldoYXQgZG8geW91IHRoaW5rIGFib3V0IHN1Y2ggYSBjaGFu Z2U/IEFueSBhZHZpY2U/DQoNClRoYW5rcywNCkRhdmUNCg0K From nobody Mon Oct 23 12:09:58 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E956139605; Mon, 23 Oct 2017 12:09:55 -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=stpeter.im header.b=amN0JxlA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WzpTVCEn 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 GrAdjy-aFejO; Mon, 23 Oct 2017 12:09:53 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0FE21395F3; Mon, 23 Oct 2017 12:09:53 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 04F7920B77; Mon, 23 Oct 2017 15:09:53 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 23 Oct 2017 15:09:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=XKJ54NuiuzifZeJm/CFxunJhSjlUQmnpFPut66jy4i0=; b=amN0JxlA JOp/BzPAP3JeQMD5UAkGMrOPHpoC8C5yzMJe9dDCOhP2XMeVeC/8YDlHMGDRG0hT Y26TKO2M6ZcjUgbNfLIQSK4GXx5YVBwIERA2clj+x2pda8C1jduS6MVN6VttwTUk P/nk2yv4ae6AlEx6AWU3tRQPJgqJxFCVvxw6dfWWvAJGc5TPWaCB16bGRcQ8y/Kj KjDAN/aSYQ8UZ1mQDS2UDJHlkGr4dZPURKmhfIr+xa5Z2uA9OK1/VwfDTKjpuDdt /kgcbmp4oF752zyeeRhNgaSUgStr7CypryEsA43/0Ygo4hbsFgMip5WXX8AnO6Rb Zr254x8TWauLHA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=XKJ54NuiuzifZeJm/CFxunJhSjlUQ mnpFPut66jy4i0=; b=WzpTVCEnuL3N9ign2kzer5r/syCCDHPPQXwGrRpXnqKvN iZsiON3YXCCTj26I5V3IQ+VIGWUrLAIy38LSLZemcFDNwqiwwZvPVze9utCEIHU1 dmpDNxwF4Ga5tzEzJ6q2A7baBx4mp5czkWlBbY+lXVhyIqOY9YYiGKhCcn983sLz 0u+Y15N1sbO3cVhzc9Cz0A4icWW5i/XgkdTZcSbdEgljqzeDZoci0FLCCMCUkihn uIgW41bbnJnoD76ZPgS40Eu74UmnRSf6cYbgba77v1Ejz05dAtohXj2i/YSirA40 kxBAkdSt3JFrBo1JoplF5js/a2AzGe/CXaQc1qBcg== X-ME-Sender: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 5AD2924134; Mon, 23 Oct 2017 15:09:52 -0400 (EDT) To: "Waltermire, David A. (Fed)" , "art-ads@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" , "mile@ietf.org" References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: <2114e084-bb7e-4d26-f3df-0ca30e3bc882@stpeter.im> Date: Mon, 23 Oct 2017 13:09:51 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qheeLqa57xB8mG1JjjpUB19MgIboRjA0V" Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 19:09:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qheeLqa57xB8mG1JjjpUB19MgIboRjA0V Content-Type: multipart/mixed; boundary="38TDg3vuAB4msANWe66mXqWRK5EOdOnST"; protected-headers="v1" From: Peter Saint-Andre To: "Waltermire, David A. (Fed)" , "art-ads@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" , "mile@ietf.org" Message-ID: <2114e084-bb7e-4d26-f3df-0ca30e3bc882@stpeter.im> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> In-Reply-To: --38TDg3vuAB4msANWe66mXqWRK5EOdOnST Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 10/23/17 12:33 PM, Waltermire, David A. (Fed) wrote: > Ben, Alexey, and Adam, >=20 > Working through Martin's ARTART review of ROLIE, we had the following e= xchange with Martin. >=20 >>>> From martin: >>>> Question: it's fairly widely accepted that use of IRIs in Atom has >>>> been less than successful. Do you want to mandate use of URIs >>>> instead? This would apply to both link relations and the "src" attr= ibute. >>> >>> From Stephen: >>> We wanted to stay in line with the requirements in Atom, if this beco= mes >> an issue it may be worth re-examining. >> >> From Martin: >> This is your chance. You don't get to go back or re-examine once your= >> protocol is widely deployed. >=20 > I understand Martin's point above. It is basically that URIs are more n= arrowly scoped and interoperable than IRIs are. From my experience I have= seen that URIs are broadly used, and IRIs have not seen much use. Given = this feedback, it looks like the best thing to do might be to break with = ATOM and use the more restrictive URI in ROLIE to ensure the best possibl= e interoperability within resulting solutions. >=20 > What do you think about such a change? Any advice? The Atom RFCs were published at a time when IRIs were at the height of their (limited) popularity. Although I don't recall the details, it might even have been the case that an Area Director said "you really ought to be using IRIs because they are more general". I don't see a significant issue with scoping MILE/ROLIE to use URIs, because they are a subset of IRIs. Peter --38TDg3vuAB4msANWe66mXqWRK5EOdOnST-- --qheeLqa57xB8mG1JjjpUB19MgIboRjA0V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAlnuPn8ACgkQ6gakkSvF ram5EhAAp2K4sKz55FUKip0MhbFc3VAmM5tK3nUbX0bCEnkbxKzp2wEh+pOcgMfa iMoxmM0sxu/gpqzhk9Q3YffAk+2MwLGh7E22RluN14x2X9AcHPWpCexc1HWBKWNS E/tEg4jin3T0KUgTLQq0qppJ69wa9uhN2LrUrsGXWmnvAv7l5+3IaX3SPVFxbnYO 34rV5SMacu9KLSMx6r8DXVrI1Yk5c2gqnJTNg6pN3exKFP+AueacX9e9ecQKArRZ t6QsiRO0AcW2lNxThOvu023QWU3SoRdWOt16Vvzmn/x3hO3ofTO80JRYzAKD2WfP IYx3PX2hDAGGb9dNTauyIbDP2AF/sTuCgSTD3ClIKzXAhRg8+P7Q3kKKFUCt89W8 6nqfshheyK20d3bBnjih848mj9KSU8qMFA4TOz8/WQCUPW/1S8HwwvIXMoSVAPHt fvfjYne4+sLnVZUIUNjAOGr9+PCsr4pHSNeVJINPgsTIJAWFEJuNMi1Suyc8Bq4l Y2ucR3stuy2sOp2JvWsIGTRnZdeLcjokQG75+nrxN9MICx9saLm/Kul9Op1fF+uE 7T7Br0G3ZJoPZSsItBsmMlZEcxUqbKBhOcVTOUX38xuca3VyPjOnQPnuTNqvUcfV /oBCR5+aYfrODO+6z/IaWqkC6hR2erQVjP0pQu4PdWfvu7LaVS0= =R3UT -----END PGP SIGNATURE----- --qheeLqa57xB8mG1JjjpUB19MgIboRjA0V-- From nobody Mon Oct 23 12:10:02 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 69FC21395F3; Mon, 23 Oct 2017 12:09:55 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E956139605; Mon, 23 Oct 2017 12:09:55 -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=stpeter.im header.b=amN0JxlA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WzpTVCEn 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 GrAdjy-aFejO; Mon, 23 Oct 2017 12:09:53 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0FE21395F3; Mon, 23 Oct 2017 12:09:53 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 04F7920B77; Mon, 23 Oct 2017 15:09:53 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 23 Oct 2017 15:09:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=XKJ54NuiuzifZeJm/CFxunJhSjlUQmnpFPut66jy4i0=; b=amN0JxlA JOp/BzPAP3JeQMD5UAkGMrOPHpoC8C5yzMJe9dDCOhP2XMeVeC/8YDlHMGDRG0hT Y26TKO2M6ZcjUgbNfLIQSK4GXx5YVBwIERA2clj+x2pda8C1jduS6MVN6VttwTUk P/nk2yv4ae6AlEx6AWU3tRQPJgqJxFCVvxw6dfWWvAJGc5TPWaCB16bGRcQ8y/Kj KjDAN/aSYQ8UZ1mQDS2UDJHlkGr4dZPURKmhfIr+xa5Z2uA9OK1/VwfDTKjpuDdt /kgcbmp4oF752zyeeRhNgaSUgStr7CypryEsA43/0Ygo4hbsFgMip5WXX8AnO6Rb Zr254x8TWauLHA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=XKJ54NuiuzifZeJm/CFxunJhSjlUQ mnpFPut66jy4i0=; b=WzpTVCEnuL3N9ign2kzer5r/syCCDHPPQXwGrRpXnqKvN iZsiON3YXCCTj26I5V3IQ+VIGWUrLAIy38LSLZemcFDNwqiwwZvPVze9utCEIHU1 dmpDNxwF4Ga5tzEzJ6q2A7baBx4mp5czkWlBbY+lXVhyIqOY9YYiGKhCcn983sLz 0u+Y15N1sbO3cVhzc9Cz0A4icWW5i/XgkdTZcSbdEgljqzeDZoci0FLCCMCUkihn uIgW41bbnJnoD76ZPgS40Eu74UmnRSf6cYbgba77v1Ejz05dAtohXj2i/YSirA40 kxBAkdSt3JFrBo1JoplF5js/a2AzGe/CXaQc1qBcg== X-ME-Sender: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 5AD2924134; Mon, 23 Oct 2017 15:09:52 -0400 (EDT) To: "Waltermire, David A. (Fed)" , "art-ads@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" , "mile@ietf.org" References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: <2114e084-bb7e-4d26-f3df-0ca30e3bc882@stpeter.im> Date: Mon, 23 Oct 2017 13:09:51 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qheeLqa57xB8mG1JjjpUB19MgIboRjA0V" Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171023190955.69FC21395F3@ietfa.amsl.com> Resent-Date: Mon, 23 Oct 2017 12:09:55 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 19:09:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qheeLqa57xB8mG1JjjpUB19MgIboRjA0V Content-Type: multipart/mixed; boundary="38TDg3vuAB4msANWe66mXqWRK5EOdOnST"; protected-headers="v1" From: Peter Saint-Andre To: "Waltermire, David A. (Fed)" , "art-ads@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" , "mile@ietf.org" Message-ID: <2114e084-bb7e-4d26-f3df-0ca30e3bc882@stpeter.im> Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> In-Reply-To: --38TDg3vuAB4msANWe66mXqWRK5EOdOnST Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 10/23/17 12:33 PM, Waltermire, David A. (Fed) wrote: > Ben, Alexey, and Adam, >=20 > Working through Martin's ARTART review of ROLIE, we had the following e= xchange with Martin. >=20 >>>> From martin: >>>> Question: it's fairly widely accepted that use of IRIs in Atom has >>>> been less than successful. Do you want to mandate use of URIs >>>> instead? This would apply to both link relations and the "src" attr= ibute. >>> >>> From Stephen: >>> We wanted to stay in line with the requirements in Atom, if this beco= mes >> an issue it may be worth re-examining. >> >> From Martin: >> This is your chance. You don't get to go back or re-examine once your= >> protocol is widely deployed. >=20 > I understand Martin's point above. It is basically that URIs are more n= arrowly scoped and interoperable than IRIs are. From my experience I have= seen that URIs are broadly used, and IRIs have not seen much use. Given = this feedback, it looks like the best thing to do might be to break with = ATOM and use the more restrictive URI in ROLIE to ensure the best possibl= e interoperability within resulting solutions. >=20 > What do you think about such a change? Any advice? The Atom RFCs were published at a time when IRIs were at the height of their (limited) popularity. Although I don't recall the details, it might even have been the case that an Area Director said "you really ought to be using IRIs because they are more general". I don't see a significant issue with scoping MILE/ROLIE to use URIs, because they are a subset of IRIs. Peter --38TDg3vuAB4msANWe66mXqWRK5EOdOnST-- --qheeLqa57xB8mG1JjjpUB19MgIboRjA0V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAlnuPn8ACgkQ6gakkSvF ram5EhAAp2K4sKz55FUKip0MhbFc3VAmM5tK3nUbX0bCEnkbxKzp2wEh+pOcgMfa iMoxmM0sxu/gpqzhk9Q3YffAk+2MwLGh7E22RluN14x2X9AcHPWpCexc1HWBKWNS E/tEg4jin3T0KUgTLQq0qppJ69wa9uhN2LrUrsGXWmnvAv7l5+3IaX3SPVFxbnYO 34rV5SMacu9KLSMx6r8DXVrI1Yk5c2gqnJTNg6pN3exKFP+AueacX9e9ecQKArRZ t6QsiRO0AcW2lNxThOvu023QWU3SoRdWOt16Vvzmn/x3hO3ofTO80JRYzAKD2WfP IYx3PX2hDAGGb9dNTauyIbDP2AF/sTuCgSTD3ClIKzXAhRg8+P7Q3kKKFUCt89W8 6nqfshheyK20d3bBnjih848mj9KSU8qMFA4TOz8/WQCUPW/1S8HwwvIXMoSVAPHt fvfjYne4+sLnVZUIUNjAOGr9+PCsr4pHSNeVJINPgsTIJAWFEJuNMi1Suyc8Bq4l Y2ucR3stuy2sOp2JvWsIGTRnZdeLcjokQG75+nrxN9MICx9saLm/Kul9Op1fF+uE 7T7Br0G3ZJoPZSsItBsmMlZEcxUqbKBhOcVTOUX38xuca3VyPjOnQPnuTNqvUcfV /oBCR5+aYfrODO+6z/IaWqkC6hR2erQVjP0pQu4PdWfvu7LaVS0= =R3UT -----END PGP SIGNATURE----- --qheeLqa57xB8mG1JjjpUB19MgIboRjA0V-- From nobody Mon Oct 23 12:24:37 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E3A139F44; Mon, 23 Oct 2017 12:24:36 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 vjv7Y0xPKKNN; Mon, 23 Oct 2017 12:24:33 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0105.outbound.protection.outlook.com [23.103.201.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1FC138105; Mon, 23 Oct 2017 12:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dwNHtAkg8OujipqQe9FwM2Nf7SkZ8d/F3xS6fLftVHU=; b=Ppz8tfyNkhBnFxF9l+3sEOe+HnS+VSIbjilsjYROCormcp4WNOArZW3+LnnjF/AfAQXvHz5weaOJ+UGsRRfVmVYToPZkqoALjwJ63j3gBh8Cd8Z3+iqqU3vof/PhEERw5CViwLiRk107DgVQewLMXwRcCZoOtoX8zQRR4+y3Egk= Received: from CY4PR09MB1495.namprd09.prod.outlook.com (10.173.191.141) by CY4PR09MB1496.namprd09.prod.outlook.com (10.173.191.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Mon, 23 Oct 2017 19:24:32 +0000 Received: from CY4PR09MB1495.namprd09.prod.outlook.com ([10.173.191.141]) by CY4PR09MB1495.namprd09.prod.outlook.com ([10.173.191.141]) with mapi id 15.20.0156.006; Mon, 23 Oct 2017 19:24:32 +0000 From: "Waltermire, David A. (Fed)" To: Peter Saint-Andre , "art-ads@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" , "mile@ietf.org" Thread-Topic: [mile] Artart last call review of draft-ietf-mile-rolie-10 Thread-Index: AQHTQLy6AlrnYGEzJkSW/mjw8rDt26Lra++AgAB9mgCABewtsIAADdGAgAAD52A= Date: Mon, 23 Oct 2017 19:24:31 +0000 Message-ID: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <2114e084-bb7e-4d26-f3df-0ca30e3bc882@stpeter.im> In-Reply-To: <2114e084-bb7e-4d26-f3df-0ca30e3bc882@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1496; 6:zEv59rzhNfZvdeTjhKKdCowqtVjL+7YY2FgXGb8dgFzcZmqdiaMgO8MaThM20kfTVRk0NzzokM+PZ7ccensj8Q0v9asbnaHiLe4cMVMpuWgFU4RHDr5TvLeGtVzcK28souMatKph5XVXYEy38J2+4x3c1uQfLhX3mzPYUwEKt1679QBg5unPtJVm/ebF/PLl2kwmE+pP+c3w/mZHyDK1PMb3QJSfxdwpta/xniy4cthIYDWk8bXfepuWNeR6Lsi15IsQVi9SIsPN678zdz4Q7Q3lvnCFWk8Hcp+0tsUBGc1AMejHr+8PzjXESjeFuILIsKkN9fMsOZSV6atMgrC4Yw==; 5:LxXRH9MFnSumA9/YkAmWwufPgHDcPlpggs/umG3mvDTHcmcFpHfy9fy55RfrjikFd4DUnnUgPm2hhcym5gFkxgVyQPDU+7K1X9zowGoDyaU/UkxJNLj8pM1DcGRBsZH46urVInWW/uLxBVjDMstRig==; 24:+QunBlBk98VODAkB4ck7y1g5d1/+SSnLY5SHJBwNHfJVPFew6Qqgz52gXKCDdMImp9Uf0HCI9kGNHWAHWpEgibdNBjhPoYXcxMcce2KvCl0=; 7:FPMNpeJv0usDDmOSyvNrejpOHJCi0S0wZ7cBVHef5Qaj/uarvEU2BBwGzaEPBSYfVxHIFpnBhA2/b66m/vQ6OgV5gDEo1aYNDcFxu4qygKjEy19QkOEpb9Zzb/kU+tWQsvaySGKoL2YekHavT+JR8Evv4KooP/XtKZPHE+Me/jFB25iaxTEjDkIfZZ9qm8h81ahpjFJTh9N9Vt3Jx1/1+lcsVZIoeJMrUYgjgmPf6II= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 215a181e-4f00-44e6-e622-08d51a4bb01f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR09MB1496; x-ms-traffictypediagnostic: CY4PR09MB1496: x-exchange-antispam-report-test: UriScan:(65766998875637); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231020)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1496; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1496; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(346002)(39860400002)(376002)(189002)(199003)(24454002)(76104003)(13464003)(2906002)(66066001)(25786009)(316002)(2950100002)(50986999)(76176999)(54356999)(3846002)(2900100001)(6116002)(102836003)(93886005)(230783001)(55016002)(33656002)(110136005)(77096006)(101416001)(6436002)(14454004)(6506006)(86362001)(8936002)(99286003)(229853002)(53936002)(305945005)(6246003)(68736007)(2501003)(9686003)(189998001)(5660300001)(478600001)(2201001)(3660700001)(53546010)(81166006)(3280700002)(105586002)(81156014)(8676002)(7736002)(74316002)(106356001)(7696004)(97736004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1496; H:CY4PR09MB1495.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 215a181e-4f00-44e6-e622-08d51a4bb01f X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 19:24:32.0668 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1496 Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 19:24:36 -0000 VGhhbmtzIFBldGVyIQ0KDQpUaGlzIGlzIGhlbHBmdWwgY29uZmlybWF0aW9uLg0KDQpEYXZlDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGV0ZXIgU2FpbnQtQW5kcmUg W21haWx0bzpzdHBldGVyQHN0cGV0ZXIuaW1dDQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMywg MjAxNyAzOjEwIFBNDQo+IFRvOiBXYWx0ZXJtaXJlLCBEYXZpZCBBLiAoRmVkKSA8ZGF2aWQud2Fs dGVybWlyZUBuaXN0Lmdvdj47IGFydC0NCj4gYWRzQGlldGYub3JnOyBkcmFmdC1pZXRmLW1pbGUt cm9saWUuYWxsQGlldGYub3JnOyBtaWxlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbWlsZV0g QXJ0YXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1taWxlLXJvbGllLTEwDQo+IA0K PiBPbiAxMC8yMy8xNyAxMjozMyBQTSwgV2FsdGVybWlyZSwgRGF2aWQgQS4gKEZlZCkgd3JvdGU6 DQo+ID4gQmVuLCBBbGV4ZXksIGFuZCBBZGFtLA0KPiA+DQo+ID4gV29ya2luZyB0aHJvdWdoIE1h cnRpbidzIEFSVEFSVCByZXZpZXcgb2YgUk9MSUUsIHdlIGhhZCB0aGUgZm9sbG93aW5nDQo+IGV4 Y2hhbmdlIHdpdGggTWFydGluLg0KPiA+DQo+ID4+Pj4gRnJvbSBtYXJ0aW46DQo+ID4+Pj4gUXVl c3Rpb246IGl0J3MgZmFpcmx5IHdpZGVseSBhY2NlcHRlZCB0aGF0IHVzZSBvZiBJUklzIGluIEF0 b20gaGFzDQo+ID4+Pj4gYmVlbiBsZXNzIHRoYW4gc3VjY2Vzc2Z1bC4gIERvIHlvdSB3YW50IHRv IG1hbmRhdGUgdXNlIG9mIFVSSXMNCj4gPj4+PiBpbnN0ZWFkPyAgVGhpcyB3b3VsZCBhcHBseSB0 byBib3RoIGxpbmsgcmVsYXRpb25zIGFuZCB0aGUgInNyYyIgYXR0cmlidXRlLg0KPiA+Pj4NCj4g Pj4+IEZyb20gU3RlcGhlbjoNCj4gPj4+IFdlIHdhbnRlZCB0byBzdGF5IGluIGxpbmUgd2l0aCB0 aGUgcmVxdWlyZW1lbnRzIGluIEF0b20sIGlmIHRoaXMNCj4gPj4+IGJlY29tZXMNCj4gPj4gYW4g aXNzdWUgaXQgbWF5IGJlIHdvcnRoIHJlLWV4YW1pbmluZy4NCj4gPj4NCj4gPj4gRnJvbSBNYXJ0 aW46DQo+ID4+IFRoaXMgaXMgeW91ciBjaGFuY2UuICBZb3UgZG9uJ3QgZ2V0IHRvIGdvIGJhY2sg b3IgcmUtZXhhbWluZSBvbmNlDQo+ID4+IHlvdXIgcHJvdG9jb2wgaXMgd2lkZWx5IGRlcGxveWVk Lg0KPiA+DQo+ID4gSSB1bmRlcnN0YW5kIE1hcnRpbidzIHBvaW50IGFib3ZlLiBJdCBpcyBiYXNp Y2FsbHkgdGhhdCBVUklzIGFyZSBtb3JlDQo+IG5hcnJvd2x5IHNjb3BlZCBhbmQgaW50ZXJvcGVy YWJsZSB0aGFuIElSSXMgYXJlLiBGcm9tIG15IGV4cGVyaWVuY2UgSSBoYXZlDQo+IHNlZW4gdGhh dCBVUklzIGFyZSBicm9hZGx5IHVzZWQsIGFuZCBJUklzIGhhdmUgbm90IHNlZW4gbXVjaCB1c2Uu IEdpdmVuIHRoaXMNCj4gZmVlZGJhY2ssIGl0IGxvb2tzIGxpa2UgdGhlIGJlc3QgdGhpbmcgdG8g ZG8gbWlnaHQgYmUgdG8gYnJlYWsgd2l0aCBBVE9NIGFuZA0KPiB1c2UgdGhlIG1vcmUgcmVzdHJp Y3RpdmUgVVJJIGluIFJPTElFIHRvIGVuc3VyZSB0aGUgYmVzdCBwb3NzaWJsZQ0KPiBpbnRlcm9w ZXJhYmlsaXR5IHdpdGhpbiByZXN1bHRpbmcgc29sdXRpb25zLg0KPiA+DQo+ID4gV2hhdCBkbyB5 b3UgdGhpbmsgYWJvdXQgc3VjaCBhIGNoYW5nZT8gQW55IGFkdmljZT8NCj4gDQo+IFRoZSBBdG9t IFJGQ3Mgd2VyZSBwdWJsaXNoZWQgYXQgYSB0aW1lIHdoZW4gSVJJcyB3ZXJlIGF0IHRoZSBoZWln aHQgb2YNCj4gdGhlaXIgKGxpbWl0ZWQpIHBvcHVsYXJpdHkuIEFsdGhvdWdoIEkgZG9uJ3QgcmVj YWxsIHRoZSBkZXRhaWxzLCBpdCBtaWdodCBldmVuDQo+IGhhdmUgYmVlbiB0aGUgY2FzZSB0aGF0 IGFuIEFyZWEgRGlyZWN0b3Igc2FpZCAieW91IHJlYWxseSBvdWdodCB0byBiZSB1c2luZw0KPiBJ UklzIGJlY2F1c2UgdGhleSBhcmUgbW9yZSBnZW5lcmFsIi4gSSBkb24ndCBzZWUgYSBzaWduaWZp Y2FudCBpc3N1ZSB3aXRoDQo+IHNjb3BpbmcgTUlMRS9ST0xJRSB0byB1c2UgVVJJcywgYmVjYXVz ZSB0aGV5IGFyZSBhIHN1YnNldCBvZiBJUklzLg0KPiANCj4gUGV0ZXINCj4gDQoNCg== From nobody Mon Oct 23 12:24:42 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 99FA5138105; Mon, 23 Oct 2017 12:24:36 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E3A139F44; Mon, 23 Oct 2017 12:24:36 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 vjv7Y0xPKKNN; Mon, 23 Oct 2017 12:24:33 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0105.outbound.protection.outlook.com [23.103.201.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1FC138105; Mon, 23 Oct 2017 12:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dwNHtAkg8OujipqQe9FwM2Nf7SkZ8d/F3xS6fLftVHU=; b=Ppz8tfyNkhBnFxF9l+3sEOe+HnS+VSIbjilsjYROCormcp4WNOArZW3+LnnjF/AfAQXvHz5weaOJ+UGsRRfVmVYToPZkqoALjwJ63j3gBh8Cd8Z3+iqqU3vof/PhEERw5CViwLiRk107DgVQewLMXwRcCZoOtoX8zQRR4+y3Egk= Received: from CY4PR09MB1495.namprd09.prod.outlook.com (10.173.191.141) by CY4PR09MB1496.namprd09.prod.outlook.com (10.173.191.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Mon, 23 Oct 2017 19:24:32 +0000 Received: from CY4PR09MB1495.namprd09.prod.outlook.com ([10.173.191.141]) by CY4PR09MB1495.namprd09.prod.outlook.com ([10.173.191.141]) with mapi id 15.20.0156.006; Mon, 23 Oct 2017 19:24:32 +0000 From: "Waltermire, David A. (Fed)" To: Peter Saint-Andre , "art-ads@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" , "mile@ietf.org" Thread-Topic: [mile] Artart last call review of draft-ietf-mile-rolie-10 Thread-Index: AQHTQLy6AlrnYGEzJkSW/mjw8rDt26Lra++AgAB9mgCABewtsIAADdGAgAAD52A= Date: Mon, 23 Oct 2017 19:24:31 +0000 Message-ID: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <2114e084-bb7e-4d26-f3df-0ca30e3bc882@stpeter.im> In-Reply-To: <2114e084-bb7e-4d26-f3df-0ca30e3bc882@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1496; 6:zEv59rzhNfZvdeTjhKKdCowqtVjL+7YY2FgXGb8dgFzcZmqdiaMgO8MaThM20kfTVRk0NzzokM+PZ7ccensj8Q0v9asbnaHiLe4cMVMpuWgFU4RHDr5TvLeGtVzcK28souMatKph5XVXYEy38J2+4x3c1uQfLhX3mzPYUwEKt1679QBg5unPtJVm/ebF/PLl2kwmE+pP+c3w/mZHyDK1PMb3QJSfxdwpta/xniy4cthIYDWk8bXfepuWNeR6Lsi15IsQVi9SIsPN678zdz4Q7Q3lvnCFWk8Hcp+0tsUBGc1AMejHr+8PzjXESjeFuILIsKkN9fMsOZSV6atMgrC4Yw==; 5:LxXRH9MFnSumA9/YkAmWwufPgHDcPlpggs/umG3mvDTHcmcFpHfy9fy55RfrjikFd4DUnnUgPm2hhcym5gFkxgVyQPDU+7K1X9zowGoDyaU/UkxJNLj8pM1DcGRBsZH46urVInWW/uLxBVjDMstRig==; 24:+QunBlBk98VODAkB4ck7y1g5d1/+SSnLY5SHJBwNHfJVPFew6Qqgz52gXKCDdMImp9Uf0HCI9kGNHWAHWpEgibdNBjhPoYXcxMcce2KvCl0=; 7:FPMNpeJv0usDDmOSyvNrejpOHJCi0S0wZ7cBVHef5Qaj/uarvEU2BBwGzaEPBSYfVxHIFpnBhA2/b66m/vQ6OgV5gDEo1aYNDcFxu4qygKjEy19QkOEpb9Zzb/kU+tWQsvaySGKoL2YekHavT+JR8Evv4KooP/XtKZPHE+Me/jFB25iaxTEjDkIfZZ9qm8h81ahpjFJTh9N9Vt3Jx1/1+lcsVZIoeJMrUYgjgmPf6II= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 215a181e-4f00-44e6-e622-08d51a4bb01f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR09MB1496; x-ms-traffictypediagnostic: CY4PR09MB1496: x-exchange-antispam-report-test: UriScan:(65766998875637); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231020)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1496; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1496; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(346002)(39860400002)(376002)(189002)(199003)(24454002)(76104003)(13464003)(2906002)(66066001)(25786009)(316002)(2950100002)(50986999)(76176999)(54356999)(3846002)(2900100001)(6116002)(102836003)(93886005)(230783001)(55016002)(33656002)(110136005)(77096006)(101416001)(6436002)(14454004)(6506006)(86362001)(8936002)(99286003)(229853002)(53936002)(305945005)(6246003)(68736007)(2501003)(9686003)(189998001)(5660300001)(478600001)(2201001)(3660700001)(53546010)(81166006)(3280700002)(105586002)(81156014)(8676002)(7736002)(74316002)(106356001)(7696004)(97736004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1496; H:CY4PR09MB1495.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 215a181e-4f00-44e6-e622-08d51a4bb01f X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 19:24:32.0668 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1496 Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171023192436.99FA5138105@ietfa.amsl.com> Resent-Date: Mon, 23 Oct 2017 12:24:36 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 19:24:37 -0000 VGhhbmtzIFBldGVyIQ0KDQpUaGlzIGlzIGhlbHBmdWwgY29uZmlybWF0aW9uLg0KDQpEYXZlDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGV0ZXIgU2FpbnQtQW5kcmUg W21haWx0bzpzdHBldGVyQHN0cGV0ZXIuaW1dDQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMywg MjAxNyAzOjEwIFBNDQo+IFRvOiBXYWx0ZXJtaXJlLCBEYXZpZCBBLiAoRmVkKSA8ZGF2aWQud2Fs dGVybWlyZUBuaXN0Lmdvdj47IGFydC0NCj4gYWRzQGlldGYub3JnOyBkcmFmdC1pZXRmLW1pbGUt cm9saWUuYWxsQGlldGYub3JnOyBtaWxlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbWlsZV0g QXJ0YXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1taWxlLXJvbGllLTEwDQo+IA0K PiBPbiAxMC8yMy8xNyAxMjozMyBQTSwgV2FsdGVybWlyZSwgRGF2aWQgQS4gKEZlZCkgd3JvdGU6 DQo+ID4gQmVuLCBBbGV4ZXksIGFuZCBBZGFtLA0KPiA+DQo+ID4gV29ya2luZyB0aHJvdWdoIE1h cnRpbidzIEFSVEFSVCByZXZpZXcgb2YgUk9MSUUsIHdlIGhhZCB0aGUgZm9sbG93aW5nDQo+IGV4 Y2hhbmdlIHdpdGggTWFydGluLg0KPiA+DQo+ID4+Pj4gRnJvbSBtYXJ0aW46DQo+ID4+Pj4gUXVl c3Rpb246IGl0J3MgZmFpcmx5IHdpZGVseSBhY2NlcHRlZCB0aGF0IHVzZSBvZiBJUklzIGluIEF0 b20gaGFzDQo+ID4+Pj4gYmVlbiBsZXNzIHRoYW4gc3VjY2Vzc2Z1bC4gIERvIHlvdSB3YW50IHRv IG1hbmRhdGUgdXNlIG9mIFVSSXMNCj4gPj4+PiBpbnN0ZWFkPyAgVGhpcyB3b3VsZCBhcHBseSB0 byBib3RoIGxpbmsgcmVsYXRpb25zIGFuZCB0aGUgInNyYyIgYXR0cmlidXRlLg0KPiA+Pj4NCj4g Pj4+IEZyb20gU3RlcGhlbjoNCj4gPj4+IFdlIHdhbnRlZCB0byBzdGF5IGluIGxpbmUgd2l0aCB0 aGUgcmVxdWlyZW1lbnRzIGluIEF0b20sIGlmIHRoaXMNCj4gPj4+IGJlY29tZXMNCj4gPj4gYW4g aXNzdWUgaXQgbWF5IGJlIHdvcnRoIHJlLWV4YW1pbmluZy4NCj4gPj4NCj4gPj4gRnJvbSBNYXJ0 aW46DQo+ID4+IFRoaXMgaXMgeW91ciBjaGFuY2UuICBZb3UgZG9uJ3QgZ2V0IHRvIGdvIGJhY2sg b3IgcmUtZXhhbWluZSBvbmNlDQo+ID4+IHlvdXIgcHJvdG9jb2wgaXMgd2lkZWx5IGRlcGxveWVk Lg0KPiA+DQo+ID4gSSB1bmRlcnN0YW5kIE1hcnRpbidzIHBvaW50IGFib3ZlLiBJdCBpcyBiYXNp Y2FsbHkgdGhhdCBVUklzIGFyZSBtb3JlDQo+IG5hcnJvd2x5IHNjb3BlZCBhbmQgaW50ZXJvcGVy YWJsZSB0aGFuIElSSXMgYXJlLiBGcm9tIG15IGV4cGVyaWVuY2UgSSBoYXZlDQo+IHNlZW4gdGhh dCBVUklzIGFyZSBicm9hZGx5IHVzZWQsIGFuZCBJUklzIGhhdmUgbm90IHNlZW4gbXVjaCB1c2Uu IEdpdmVuIHRoaXMNCj4gZmVlZGJhY2ssIGl0IGxvb2tzIGxpa2UgdGhlIGJlc3QgdGhpbmcgdG8g ZG8gbWlnaHQgYmUgdG8gYnJlYWsgd2l0aCBBVE9NIGFuZA0KPiB1c2UgdGhlIG1vcmUgcmVzdHJp Y3RpdmUgVVJJIGluIFJPTElFIHRvIGVuc3VyZSB0aGUgYmVzdCBwb3NzaWJsZQ0KPiBpbnRlcm9w ZXJhYmlsaXR5IHdpdGhpbiByZXN1bHRpbmcgc29sdXRpb25zLg0KPiA+DQo+ID4gV2hhdCBkbyB5 b3UgdGhpbmsgYWJvdXQgc3VjaCBhIGNoYW5nZT8gQW55IGFkdmljZT8NCj4gDQo+IFRoZSBBdG9t IFJGQ3Mgd2VyZSBwdWJsaXNoZWQgYXQgYSB0aW1lIHdoZW4gSVJJcyB3ZXJlIGF0IHRoZSBoZWln aHQgb2YNCj4gdGhlaXIgKGxpbWl0ZWQpIHBvcHVsYXJpdHkuIEFsdGhvdWdoIEkgZG9uJ3QgcmVj YWxsIHRoZSBkZXRhaWxzLCBpdCBtaWdodCBldmVuDQo+IGhhdmUgYmVlbiB0aGUgY2FzZSB0aGF0 IGFuIEFyZWEgRGlyZWN0b3Igc2FpZCAieW91IHJlYWxseSBvdWdodCB0byBiZSB1c2luZw0KPiBJ UklzIGJlY2F1c2UgdGhleSBhcmUgbW9yZSBnZW5lcmFsIi4gSSBkb24ndCBzZWUgYSBzaWduaWZp Y2FudCBpc3N1ZSB3aXRoDQo+IHNjb3BpbmcgTUlMRS9ST0xJRSB0byB1c2UgVVJJcywgYmVjYXVz ZSB0aGV5IGFyZSBhIHN1YnNldCBvZiBJUklzLg0KPiANCj4gUGV0ZXINCj4gDQoNCg== From nobody Mon Oct 23 14:00:05 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49CB13A273; Mon, 23 Oct 2017 13:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 CUDWerEZDK-5; Mon, 23 Oct 2017 13:59:53 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0120.outbound.protection.outlook.com [23.103.201.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638811394F8; Mon, 23 Oct 2017 13:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iJkMEIZZD/LZ4Idiqs8tz7tGFfVIb0bdimajVTtoHOk=; b=1qovylo71860R0V+Zr5USJ+c4w88jGycd1FtvkoSFWCQPZwL4eQrLV6iDlPu2WhxOr1molVdzpDjaSLm6CCPCkdTpLMgsj62w5/gNOM4BFcU16fiVvYFPyU+RsmX6i+1n5VuIRUgWC5WfC6Q8EQzmyzdaNYVvm0ka1Fi4nuxm9M= Received: from MWHPR09MB1197.namprd09.prod.outlook.com (10.172.49.143) by MWHPR09MB1197.namprd09.prod.outlook.com (10.172.49.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Mon, 23 Oct 2017 20:59:51 +0000 Received: from MWHPR09MB1197.namprd09.prod.outlook.com ([10.172.49.143]) by MWHPR09MB1197.namprd09.prod.outlook.com ([10.172.49.143]) with mapi id 15.20.0156.007; Mon, 23 Oct 2017 20:59:51 +0000 From: "Banghart, Stephen A. (Fed)" To: Kathleen Moriarty , Eric Rescorla CC: The IESG , "draft-ietf-mile-rolie@ietf.org" , "mile@ietf.org" , "mile-chairs@ietf.org" , "mile-chairs@tools.ietf.org" Thread-Topic: [mile] Eric Rescorla's No Objection on draft-ietf-mile-rolie-11: (with COMMENT) Thread-Index: AQHTSeIn3Jx0IP2L0UaSlNmBq3zL+6LuJg2AgAAeKICAAXiZgIAAHDAAgAAuKwCAAdUnsA== Date: Mon, 23 Oct 2017 20:59:51 +0000 Message-ID: References: <150853136375.15398.3882962160280653674.idtracker@ietfa.amsl.com> <0CA3B0E6-F742-425E-88E4-0B4AC69BA288@gmail.com> <5F5FC613-7AE4-48E5-BC11-199443C2622C@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.251.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR09MB1197; 6:EOB42PufdemzAzsehfk3DA7M2fwT2A19eTHkaCRPvALGtHX3ovYqyDjBIY1Rquuy1v44jd4m6g+tEJpQo6S6FeIE/bGCTyThcJvGBbvrNcxYik5q/otmR5sobxDqoZcCLeiYvWMgnYf1H6UUTJNV70YgEWIDv2GUXDjqBa6XgKp9C5TfNhGuiqM4Y+SSOQWncRE9dBASjB7vyNyAit8iHup6YxowMjB3zreUgnzpYHmmaY7cCoXgrcMk0C2BThxZ3kXI6sdxeUE7MPyKKYpSEvO6H1LNa74nRyACtesZXCufXGEeRj0JE7qniYlAZlP+Ljwnj6yuPvST6xbhBKBQpw==; 5:/F83a/juORJ6Ov+jvvPHE9eBv6oPnvz5QPghRsMGVX3d+FS56dFA9qxQdLuxWAQIgAOd7rs8enYuv8AiDYZb9v+HBzmKm2WL6nMCfqhNSjpbsgCMaGmQQRdR29w+WmojslyygFSlisCtgR96rSVBOA==; 24:+5bhLrSRX1uD0VNR1BwC0d9Qz6oZCaqg+v6YMF6TPByYsYPaV6FteWlh4UvDhjyClW5efj687ZxKPBmF8XVtoAgfl957gFgM2thB4N6Z9iE=; 7:/W1DYPUQ5BAzdrvYgD5NdM7r5plga6P8kJ423NdTKk/yXzcmmrBblXFKlvamMLsuY9SYzekRU3yEobU3kjCFAFdoXE9aZbtmwy05E1iYrTOsg9B93hn3mLx+zjSsewyn5sDmNzPZLqYM3Z46iN63eAvw4x/76Vi0p8lc4HzaisTOyw8pZH4UpQfsnKmJGcaKUiYI7da0stFJuQifEPBS4zZNpLOG7e4/U3Wx7VH0rvI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9ecd64df-6a39-482c-2e53-08d51a5900de x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:MWHPR09MB1197; x-ms-traffictypediagnostic: MWHPR09MB1197: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(192374486261705)(189930954265078)(219752817060721)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3231020)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR09MB1197; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR09MB1197; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(24454002)(199003)(51444003)(189002)(66066001)(7736002)(8936002)(4326008)(19609705001)(6246003)(53546010)(6506006)(106356001)(105586002)(5003630100001)(6436002)(102836003)(81156014)(81166006)(3846002)(53936002)(966005)(790700001)(2900100001)(97736004)(6116002)(8676002)(478600001)(68736007)(189998001)(5660300001)(54356999)(33656002)(229853002)(74316002)(39060400002)(50986999)(110136005)(86362001)(9686003)(230783001)(76176999)(316002)(236005)(77096006)(7696004)(3660700001)(14454004)(2950100002)(606006)(25786009)(101416001)(3280700002)(55016002)(2906002)(54896002)(6306002)(54906003)(93886005)(99286003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1197; H:MWHPR09MB1197.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR09MB11973430FAC0DCBD7C4391CCF0460MWHPR09MB1197namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 9ecd64df-6a39-482c-2e53-08d51a5900de X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 20:59:51.0359 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1197 Archived-At: Subject: Re: [mile] Eric Rescorla's No Objection on draft-ietf-mile-rolie-11: (with COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 20:59:57 -0000 --_000_MWHPR09MB11973430FAC0DCBD7C4391CCF0460MWHPR09MB1197namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KDQpUaGUgcHJpbWFyeSBpc3N1ZSB3ZSBoYXZlIHdpdGggMC1SVFQgaXMgdGhlIHBvc3Np YmlsaXR5IG9mIHJlcGxheSBhdHRhY2tzLiBST0xJRSBpcyBSRVNUZnVsLCBhbmQgY2FuIGFjY2Vw dCBkYXRhLWFsdGVyaW5nIHJlcXVlc3RzLg0KDQpGb3IgZXhhbXBsZSwgYW4gYXV0b21hdGVkIFJP TElFIHJlcG9zaXRvcnkgdGhhdCB1cGRhdGVzIHZlcnkgZnJlcXVlbnRseSBtYXkgcmVjZWl2ZSBh IFBVVCByZXF1ZXN0IGFnYWluc3QgYSBnaXZlbiByZXNvdXJjZSBhIGZldyB0aW1lcyBhbiBob3Vy IChvciBtb3JlKS4gQW4gYXR0YWNrZXIgbWF5IHN0b3JlIHRoZSBmaXJzdCBQVVQgcmVxdWVzdCwg YW5kIGF0IHRoZSBlbmQgb2YgdGhlIHJlc3VtcHRpb24gd2luZG93IHJlcGxheSB0aGUgUFVUIHJl cXVlc3QsIHJldmVydGluZyB0aGUgcmVzb3VyY2UgdG8gYW4gb2xkIHZlcnNpb24uIE5vdCBvbmx5 IGNvdWxkIGFuIGF0dGFja2VyIGJlIGRvaW5nIHRoaXMgcmVwbGF5IGNvbnRpbnVvdXNseSB0byBj YXVzZSBoYXZvYyBvbiB0aGUgc2VydmVyLCBidXQgdGhlIGNsaWVudCBpcyBjb21wbGV0ZWx5IHVu YXdhcmUgb2YgdGhlIGF0dGFjayB0YWtpbmcgcGxhY2UuDQoNClRoZSBwZXJmb3JtYW5jZSBnYWlu IGlzLCBmb3IgdXMsIG5vdCB3b3J0aCB0aGUgcmlzayBvZiByZXBsYXkuDQoNClRleHQgc2ltaWxh ciB0byB0aGUgZXhhbXBsZSBhbmQganVzdGlmaWNhdGlvbiBpbiB0aGlzIGUtbWFpbCB3aWxsIGJl IGFkZGVkIHRvIHRoZSBzcGVjaWZpY2F0aW9uIHRvIG1ha2Ugb3VyIHJlYXNvbmluZyBtb3JlIGNs ZWFyLiBUaGlzIHNob3VsZCBoZWxwIG1ha2UgaXQgY2xlYXIgd2h5IHdlIHRoaW5rIDAtUlRUIGlz IHVuZGVzaXJhYmxlIGZvciBhbnkgZnV0dXJlIHJlYWRlcnMgb2YgdGhlIHNwZWNpZmljYXRpb24u IEFzIE1hcnRpbiBzYWlkIGVhcmxpZXIsIGl04oCZcyBpbXBvcnRhbnQgdGhhdCB3ZSBkb27igJl0 IGxvc2UgdHJhY2sgb2YgdGhlIHdoeS4NCg0KVGhhbmtzLA0KU3RlcGhlbiBCYW5naGFydA0KDQpG cm9tOiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21h aWwuY29tXQ0KU2VudDogU3VuZGF5LCBPY3RvYmVyIDIyLCAyMDE3IDExOjUwIEFNDQpUbzogRXJp YyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPg0KQ2M6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPjsg ZHJhZnQtaWV0Zi1taWxlLXJvbGllQGlldGYub3JnOyBtaWxlQGlldGYub3JnOyBtaWxlLWNoYWly c0BpZXRmLm9yZzsgbWlsZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWls ZV0gRXJpYyBSZXNjb3JsYSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW1pbGUtcm9saWUt MTE6ICh3aXRoIENPTU1FTlQpDQoNCg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIE9jdCAy MiwgMjAxNywgYXQgOTowNSBBTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpl a3JAcnRmbS5jb20+PiB3cm90ZToNCg0KDQpPbiBTdW4sIE9jdCAyMiwgMjAxNyBhdCA0OjI0IEFN LCBLYXRobGVlbiBNb3JpYXJ0eSA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb208bWFp bHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KU2VudCBm cm9tIG15IGlQaG9uZQ0KDQpPbiBPY3QgMjEsIDIwMTcsIGF0IDg6NTYgQU0sIEVyaWMgUmVzY29y bGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQoNCg0KT24gU2F0 LCBPY3QgMjEsIDIwMTcgYXQgNDowOCBBTSwgS2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVuLm1v cmlhcnR5LmlldGZAZ21haWwuY29tPG1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWls LmNvbT4+IHdyb3RlOg0KSGkgRUtSLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KDQpTZW50 IGZyb20gbXkgaVBob25lDQoNCj4gT24gT2N0IDIwLCAyMDE3LCBhdCA0OjI5IFBNLCBFcmljIFJl c2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KPg0KPiBF cmljIFJlc2NvcmxhIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZv cg0KPiBkcmFmdC1pZXRmLW1pbGUtcm9saWUtMTE6IE5vIE9iamVjdGlvbg0KPg0KPiBXaGVuIHJl c3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0 byBhbGwNCj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMu IChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZl ci4pDQo+DQo+DQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0 YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZpZXNn JTJGc3RhdGVtZW50JTJGZGlzY3Vzcy1jcml0ZXJpYS5odG1sJmRhdGE9MDIlN0MwMSU3Q3N0ZXBo ZW4uYmFuZ2hhcnQlNDBuaXN0LmdvdiU3Q2E0MjBmMDBmMTkzNTQyOGRlYmRmMDhkNTE5NjQ5ZDlm JTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjQ0Mjg0MjI5 NTgxMzAzNCZzZGF0YT1TY1NLZzJNJTJGcFBRYngxQlFZR0VNZlpNVmNQdXVUTUE2Qk9ZZDM5cEM3 MlklM0QmcmVzZXJ2ZWQ9MD4NCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVND VVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4NCj4NCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3 aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1pbGUtcm9saWUvPGh0dHBzOi8v bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG ZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1pZXRmLW1pbGUtcm9saWUlMkYmZGF0 YT0wMiU3QzAxJTdDc3RlcGhlbi5iYW5naGFydCU0MG5pc3QuZ292JTdDYTQyMGYwMGYxOTM1NDI4 ZGViZGYwOGQ1MTk2NDlkOWYlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzEl N0MwJTdDNjM2NDQyODQyMjk1ODEzMDM0JnNkYXRhPVpTMmxoeEw5WVliaFN5Nms5QUQlMkZDTFZH ZkpMUDhXZ2trYjVaN2tmZGxpOCUzRCZyZXNlcnZlZD0wPg0KPg0KPg0KPg0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gT1ZFUkFMTA0KPiBJIHNoYXJl IE1hcnRpbiBUaG9tc29uJ3MgY29uY2VybnMgYWJvdXQgdGhlIHJlc3RyaWN0aW9uIG9uIDAtUlRU LiBJbg0KPiB0aGUgZGlzY3Vzc2lvbiwgSSBzYXcgdHdvIHNldHMgb2YgY29uY2VybnMgYWJvdXQg MC1SVFQ6DQo+DQo+IC0gUmVwbGF5DQo+IC0gTGFjayBvZiBGUw0KPg0KPiBBcyBNYXJ0aW4gc2F5 cywgdGhlIHJlcGxheSBpc3N1ZSBpcyBhbiBpc3N1ZSBmb3IgdGhlIEhUVFAgcHJvZmlsZSwgc28N Cj4gYW55IGNvbmNlcm5zIHNob3VsZCBiZSBkaXJlY3RlZCB0aGVyZS4gSSBhZ3JlZSB0aGF0IDAt UlRUIGhhcyBpbmZlcmlvcg0KPiBGUyBwcm9wZXJ0aWVzLCBidXQgaXQncyB3b3J0aCBub3Rpbmcg dGhhdCBUTFMgMS4yIHNlc3Npb24gcmVzdW1wdGlvbg0KPiB3aXRoIHRpY2tldHMgaGFzIEZTIHBy b3BlcnRpZXMgdGhhdCBhcmUgYXMgYmFkIG9yIHdvcnNlIHRoYW4gdGhvc2UNCj4gd2l0aCBUTFMg MS4zIDAtUlRULCBhbmQgSSBkb24ndCBzZWUgYSBwcm9oaWJpdGlvbiBoZXJlIG9uIHNlc3Npb24N Cj4gcmVzdW1wdGlvbi4gVGhpcyBsZWF2ZXMgbWUgYSBiaXQgdW5jbGVhciBvbiB0aGUgc2VjdXJp dHkgcmF0aW9uYWxlDQo+IGhlcmUsIGFuZCBJIHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUgY29uc2lz dGVudC4NCldlIHVwZ3JhZGUgdG8gbmV3IHByb3RvY29scyB3aXRoIHRoZSBhaW0gb2YgaW1wcm92 aW5nIHNlY3VyaXR5LiAgSSB0aGluayB0aGF0J3MgYSBmaW5lIGFzc3VtcHRpb24gZm9yIHRoZSBX Ry4NCg0KVGhlIHByb2ZpbGUgaXNuJ3QgZmFyIGVub3VnaCBhbG9uZyBhdCB0aGlzIHBvaW50IGFu ZCBpc24ndCBuZWNlc3NhcnkgaWYgdGhleSBqdXN0IHdhbnQgdG8gZW5zdXJlIDAtUlRUIGlzIGRp c2FibGVkLiAgVGhpcyBpcyBhIGNvbW11bml0eSB0aGF0IGRlYWxzIHdpdGggdnVsbmVyYWJpbGl0 aWVzIGFzIHRoZWlyIGRheSBqb2IsIHdpdGggc3lzdGVtcyB0aGF0IHRoZXkgd2FudCBoYXJkZW5l ZCBhcyBtdWNoIGFzIHBvc3NpYmxlIHRvIGF2b2lkIGlzc3Vlcy4gSSBrbm93IE1hcnRpbiBtZW50 aW9uZWQgd2FudGluZyBhIHRlc3QgY2FzZSwgYnV0IHRoYXQncyBub3QgZmFpciB3aGVuIHRoZXkg YXJlIG5vdCByZWFkeSBhbmQgaGF2ZSBkaWZmZXJlbnQgcHJpb3JpdGllcy4NCg0KSGkgS2F0aGxl ZW4sDQoNCkkgZG9uJ3QgdGhpbmsgSSdtIGZvbGxvd2luZyB5b3UuIEkgYWdyZWUgdGhhdCB0aGV5 IGRvbid0IG5lZWQgdG8gZGVwZW5kIG9uIHRoZSBwcm9maWxlIGlmIHRoZXkgd2FudCB0byBkaXNh YmxlIDAtUlRULiBNeSBxdWVzdGlvbiBpcyAqd2h5KiB0aGV5IHdhbnQgdG8gZGlzYWJsZSAwLVJU VC4gSSBoZWFyZCB0d28gcmVhc29ucyBjaXRlZDogKDEpIGNvbmNlcm4gYWJvdXQgcmVwbGF5IGF0 dGFja3MgYW5kICgyKSBsYWNrIG9mIEZTLiBJcyBsYWNrIG9mIEZTIGluIGZhY3QgYSBjb25jZXJu IGhlcmU/DQoNCkhpIEVLUiwNCg0KTGFjayBvZiBGUyBpcyBhIGNvbmNlcm4sIHNvIHRoYXQgc2hv dWxkIGJlIGFkZGVkIHRvIHRoZSB0ZXh0Lg0KDQpUaGV5IGRvbid0IGNhcmUgYWJvdXQgdGhlIHBl cmZvcm1hbmNlIGluY3JlYXNlIGFzIGl0J3Mgbm90IHdvcnRoIHRoZSB0cmFkZSBvZmYuICBFdmVu IHdpdGggbWl0aWdhdGlvbnMsIHlvdSBoYXZlIHRvIHdvcnJ5IHRoYXQgdGhlIGRldmVsb3BlciBn b3QgaXQgcmlnaHQsIHRoZSBpbXBsZW1lbnRlciBkaWRuJ3QgaGF2ZSBhIGNvbmZpZ3VyYXRpb24g bWlzdGFrZSwgb3IgdGhlcmUncyBzb21ldGhpbmcgd3Jvbmcgd2l0aCB0aGUgc3BlYy4gIEZvciBz ZW5zaXRpdmUgZGF0YSBleGNoYW5nZSwgaXQncyBqdXN0IGEgbG90IGVhc2llciB0byBlbGltaW5h dGUgcG9zc2libGUgdGhyZWF0cy4NCg0KSW4gdGhhdCBjYXNlLCBpdCBzZWVtcyBsaWtlIHRoaXMg dGV4dCBvdWdodCB0byBhbHNvIHJlY29tbWVuZCBhZ2FpbnN0IHVzaW5nIFRMUyAxLjIgc2Vzc2lv biByZXN1bXB0aW9uLg0KDQpUaGVyZSBtYXkgaGF2ZSBiZWVuIHRleHQgdG8gdGhhdCBlZmZlY3Qg aW4gdGhlIHZlcnNpb24gTWFydGluIHJldmlld2VkIGFuZCB0aGV5IGNhbiBjZXJ0YWlubHkgYWRk IHRoYXQgb3IgYWRkIGl0IGJhY2suICBNeSByZXZpZXcgaGFkIHRoZW0gYWRkIDc1MjUsIG1lYW5p bmcgdG8gdGFrZSBvdXQgZHVwbGljYXRpdmUgdGV4dCBhbmQgdGhlbiB0aGV5IHJlbW92ZWQgYSBi dW5jaCBhZnRlciBNYXJ0aW4gbWFkZSB0aGUgc2FtZSBjb21tZW50Lg0KDQpLYXRobGVlbg0KDQoN Ci1Fa3INCg0KDQpLYXRobGVlbg0KDQotRWsNCg0KDQpCZXN0LA0KS2F0aGxlZW4NCj4NCj4gSU5M SU5FIENPTU1FTlRTDQo+ICAgICAgb3Igc2VyaWFsaXphdGlvbi4gIFRoaXMgYXBwcm9hY2ggYWxs b3dzIHRoZSBwcm92aWRlciB0byBzdXBwb3J0DQo+ICAgICAgbXVsdGlwbGUsIGNvbXBhdGlibGUg Zm9ybWF0cyBhbGxvd2luZyB0aGUgY29uc3VtZXIgdG8gc2VsZWN0IHRoZQ0KPiAgICAgIG1vc3Qg c3VpdGFibGUgdmVyc2lvbi4NCj4gV2hhdCBkb2VzICJjb21wYXRpYmxlIiBtZWFuIGhlcmUuIERv IHlvdSBtZWFuIGlzb21vcnBoaWM/DQo+DQo+ICAgc3VwcG9ydGluZyBpbnRlcmFjdGl2ZSB1c2Vy IGxvZ2lucyBieSBtZW1iZXJzIG9mIHRoZSBjb25zb3J0aXVtDQo+ICAgU0hPVUxEIHN1cHBvcnQg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIHZpYSBhIGZlZGVyYXRlZCBpZGVudGl0eSBzY2hlbWUuDQo+ IFN1Y2ggYXM/DQo+DQo+ICAgUHJvcGVyIHVzYWdlIG9mIFRMUyBhcyBkZXNjcmliZWQgaW4gU2Vj dGlvbiA1LjMgd2lsbCBpbiBtYW55IGNhc2VzDQo+ICAgYWlkIGluIHRoZSBtaXRpZ2F0aW9uIG9m IHRoZXNlIGlzc3Vlcy4NCj4gWW91IHNob3VsZCBhbHNvIG5vdGUgdGhhdCBUTFMgMS4yIGFuZCBs b3dlciBjbGllbnQgYXV0aCBsZWFrcyB0aGUgdXNlcidzDQo+IGlkZW50aXR5IHRvIG9uLXRoZS13 aXJlIGF0dGFja2Vycy4NCj4NCj4gICBzdXBwb3J0ZWQuICBUTFMgMS4yIFNIT1VMRCBiZSBpbXBs ZW1lbnRlZCBhY2NvcmRpbmcgdG8gYWxsDQo+ICAgcmVjb21tZW5kYXRpb25zIGFuZCBiZXN0IHBy YWN0aWNlcyBwcmVzZW50IGluIFtSRkM3NTI1XS4NCj4gWW91IG5lZWQgYSBjaXRhdGlvbiB0byA2 MTI1IGFib3V0IHZhbGlhdGlvbiwgdGhvdWdoIEkgcmVhbGl6ZSB0aGF0IDc1MjUgY2l0ZXMNCj4g aXQuDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IG1pbGUgbWFpbGluZyBsaXN0DQo+IG1pbGVAaWV0Zi5vcmc8bWFpbHRvOm1pbGVAaWV0 Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlsZTxodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUy RiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRm1pbGUmZGF0YT0wMiU3QzAx JTdDc3RlcGhlbi5iYW5naGFydCU0MG5pc3QuZ292JTdDYTQyMGYwMGYxOTM1NDI4ZGViZGYwOGQ1 MTk2NDlkOWYlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2 NDQyODQyMjk1ODEzMDM0JnNkYXRhPXBBWkk3JTJGTk81WWVWc2dLWmdvV0NLYjNZNURTSDViRGw3 Um9qMlBqTjJTayUzRCZyZXNlcnZlZD0wPg0KDQoNCg== --_000_MWHPR09MB11973430FAC0DCBD7C4391CCF0460MWHPR09MB1197namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIHByaW1hcnkgaXNzdWUgd2UgaGF2ZSB3aXRoIDAtUlRUIGlzIHRoZSBw b3NzaWJpbGl0eSBvZiByZXBsYXkgYXR0YWNrcy4gUk9MSUUgaXMgUkVTVGZ1bCwgYW5kIGNhbiBh Y2NlcHQgZGF0YS1hbHRlcmluZyByZXF1ZXN0cy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G b3IgZXhhbXBsZSwgYW4gYXV0b21hdGVkIFJPTElFIHJlcG9zaXRvcnkgdGhhdCB1cGRhdGVzIHZl cnkgZnJlcXVlbnRseSBtYXkgcmVjZWl2ZSBhIFBVVCByZXF1ZXN0IGFnYWluc3QgYSBnaXZlbiBy ZXNvdXJjZSBhIGZldyB0aW1lcyBhbiBob3VyIChvciBtb3JlKS4gQW4gYXR0YWNrZXIgbWF5IHN0 b3JlIHRoZSBmaXJzdCBQVVQgcmVxdWVzdCwgYW5kIGF0IHRoZSBlbmQgb2YgdGhlIHJlc3VtcHRp b24gd2luZG93DQogcmVwbGF5IHRoZSBQVVQgcmVxdWVzdCwgcmV2ZXJ0aW5nIHRoZSByZXNvdXJj ZSB0byBhbiBvbGQgdmVyc2lvbi4gTm90IG9ubHkgY291bGQgYW4gYXR0YWNrZXIgYmUgZG9pbmcg dGhpcyByZXBsYXkgY29udGludW91c2x5IHRvIGNhdXNlIGhhdm9jIG9uIHRoZSBzZXJ2ZXIsIGJ1 dCB0aGUgY2xpZW50IGlzIGNvbXBsZXRlbHkgdW5hd2FyZSBvZiB0aGUgYXR0YWNrIHRha2luZyBw bGFjZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHBlcmZvcm1hbmNlIGdhaW4gaXMsIGZv ciB1cywgbm90IHdvcnRoIHRoZSByaXNrIG9mIHJlcGxheS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGV4dCBzaW1pbGFyIHRvIHRoZSBleGFtcGxlIGFuZCBqdXN0aWZpY2F0aW9uIGluIHRoaXMg ZS1tYWlsIHdpbGwgYmUgYWRkZWQgdG8gdGhlIHNwZWNpZmljYXRpb24gdG8gbWFrZSBvdXIgcmVh c29uaW5nIG1vcmUgY2xlYXIuIFRoaXMgc2hvdWxkIGhlbHAgbWFrZSBpdCBjbGVhciB3aHkgd2Ug dGhpbmsgMC1SVFQgaXMgdW5kZXNpcmFibGUgZm9yIGFueSBmdXR1cmUgcmVhZGVycyBvZiB0aGUg c3BlY2lmaWNhdGlvbi4NCiBBcyBNYXJ0aW4gc2FpZCBlYXJsaWVyLCBpdOKAmXMgaW1wb3J0YW50 IHRoYXQgd2UgZG9u4oCZdCBsb3NlIHRyYWNrIG9mIHRoZSB3aHkuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0ZXBo ZW4gQmFuZ2hhcnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gS2F0aGxl ZW4gTW9yaWFydHkgW21haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbV0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE9jdG9iZXIgMjIsIDIwMTcgMTE6NTAgQU08YnI+DQo8 Yj5Ubzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDs8YnI+DQo8Yj5DYzo8 L2I+IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OzsgZHJhZnQtaWV0Zi1taWxlLXJvbGll QGlldGYub3JnOyBtaWxlQGlldGYub3JnOyBtaWxlLWNoYWlyc0BpZXRmLm9yZzsgbWlsZS1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttaWxlXSBFcmljIFJl c2NvcmxhJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtbWlsZS1yb2xpZS0xMTogKHdpdGgg Q09NTUVOVCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgaVBob25lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCk9uIE9jdCAyMiwgMjAxNywgYXQgOTowNSBBTSwgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIE9jdCAy MiwgMjAxNyBhdCA0OjI0IEFNLCBLYXRobGVlbiBNb3JpYXJ0eSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2F0aGxl ZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgaVBo b25lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gT2N0IDIx LCAyMDE3LCBhdCA4OjU2IEFNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWty QHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIE9j dCAyMSwgMjAxNyBhdCA0OjA4IEFNLCBLYXRobGVlbiBNb3JpYXJ0eSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2F0 aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGkgRUtSLDxicj4NCjxicj4NClRoYW5rcyBmb3IgeW91ciByZXZp ZXcuPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IGlQaG9uZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCiZndDsgT24gT2N0IDIwLCAyMDE3LCBhdCA0OjI5IFBNLCBFcmljIFJlc2NvcmxhICZs dDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0u Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgRXJpYyBSZXNjb3JsYSBoYXMg ZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8YnI+DQomZ3Q7IGRyYWZ0 LWlldGYtbWlsZS1yb2xpZS0xMTogTm8gT2JqZWN0aW9uPGJyPg0KJmd0Ozxicj4NCiZndDsgV2hl biByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVw bHkgdG8gYWxsPGJyPg0KJmd0OyBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFu ZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpczxicj4NCiZndDsgaW50cm9kdWN0b3J5 IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFBsZWFz ZSByZWZlciB0byA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRmllc2clMkZzdGF0ZW1l bnQlMkZkaXNjdXNzLWNyaXRlcmlhLmh0bWwmYW1wO2RhdGE9MDIlN0MwMSU3Q3N0ZXBoZW4uYmFu Z2hhcnQlNDBuaXN0LmdvdiU3Q2E0MjBmMDBmMTkzNTQyOGRlYmRmMDhkNTE5NjQ5ZDlmJTdDMmFi NWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjQ0Mjg0MjI5NTgxMzAz NCZhbXA7c2RhdGE9U2NTS2cyTSUyRnBQUWJ4MUJRWUdFTWZaTVZjUHV1VE1BNkJPWWQzOXBDNzJZ JTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8L2E+PGJyPg0KJmd0OyBmb3Ig bW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25z Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGgg b3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6PGJyPg0KJmd0OyA8YSBo cmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtaWV0Zi1taWxl LXJvbGllJTJGJmFtcDtkYXRhPTAyJTdDMDElN0NzdGVwaGVuLmJhbmdoYXJ0JTQwbmlzdC5nb3Yl N0NhNDIwZjAwZjE5MzU0MjhkZWJkZjA4ZDUxOTY0OWQ5ZiU3QzJhYjVkODJmZDhmYTQ3OTdhOTNl MDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2MzY0NDI4NDIyOTU4MTMwMzQmYW1wO3NkYXRhPVpTMmxo eEw5WVliaFN5Nms5QUQlMkZDTFZHZkpMUDhXZ2trYjVaN2tmZGxpOCUzRCZhbXA7cmVzZXJ2ZWQ9 MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1taWxlLXJvbGllLzwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IENPTU1FTlQ6PGJyPg0KJmd0OyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KJmd0Ozxicj4NCiZndDsgT1ZFUkFMTDxicj4NCiZndDsgSSBzaGFyZSBNYXJ0 aW4gVGhvbXNvbidzIGNvbmNlcm5zIGFib3V0IHRoZSByZXN0cmljdGlvbiBvbiAwLVJUVC4gSW48 YnI+DQomZ3Q7IHRoZSBkaXNjdXNzaW9uLCBJIHNhdyB0d28gc2V0cyBvZiBjb25jZXJucyBhYm91 dCAwLVJUVDo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIFJlcGxheTxicj4NCiZndDsgLSBMYWNrIG9m IEZTPGJyPg0KJmd0Ozxicj4NCiZndDsgQXMgTWFydGluIHNheXMsIHRoZSByZXBsYXkgaXNzdWUg aXMgYW4gaXNzdWUgZm9yIHRoZSBIVFRQIHByb2ZpbGUsIHNvPGJyPg0KJmd0OyBhbnkgY29uY2Vy bnMgc2hvdWxkIGJlIGRpcmVjdGVkIHRoZXJlLiBJIGFncmVlIHRoYXQgMC1SVFQgaGFzIGluZmVy aW9yPGJyPg0KJmd0OyBGUyBwcm9wZXJ0aWVzLCBidXQgaXQncyB3b3J0aCBub3RpbmcgdGhhdCBU TFMgMS4yIHNlc3Npb24gcmVzdW1wdGlvbjxicj4NCiZndDsgd2l0aCB0aWNrZXRzIGhhcyBGUyBw cm9wZXJ0aWVzIHRoYXQgYXJlIGFzIGJhZCBvciB3b3JzZSB0aGFuIHRob3NlPGJyPg0KJmd0OyB3 aXRoIFRMUyAxLjMgMC1SVFQsIGFuZCBJIGRvbid0IHNlZSBhIHByb2hpYml0aW9uIGhlcmUgb24g c2Vzc2lvbjxicj4NCiZndDsgcmVzdW1wdGlvbi4gVGhpcyBsZWF2ZXMgbWUgYSBiaXQgdW5jbGVh ciBvbiB0aGUgc2VjdXJpdHkgcmF0aW9uYWxlPGJyPg0KJmd0OyBoZXJlLCBhbmQgSSB0aGluayB0 aGlzIG5lZWRzIHRvIGJlIGNvbnNpc3RlbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgdXBncmFkZSB0byBuZXcgcHJvdG9jb2xzIHdpdGgg dGhlIGFpbSBvZiBpbXByb3Zpbmcgc2VjdXJpdHkuJm5ic3A7IEkgdGhpbmsgdGhhdCdzIGEgZmlu ZSBhc3N1bXB0aW9uIGZvciB0aGUgV0cuPGJyPg0KPGJyPg0KVGhlIHByb2ZpbGUgaXNuJ3QgZmFy IGVub3VnaCBhbG9uZyBhdCB0aGlzIHBvaW50IGFuZCBpc24ndCBuZWNlc3NhcnkgaWYgdGhleSBq dXN0IHdhbnQgdG8gZW5zdXJlIDAtUlRUIGlzIGRpc2FibGVkLiZuYnNwOyBUaGlzIGlzIGEgY29t bXVuaXR5IHRoYXQgZGVhbHMgd2l0aCB2dWxuZXJhYmlsaXRpZXMgYXMgdGhlaXIgZGF5IGpvYiwg d2l0aCBzeXN0ZW1zIHRoYXQgdGhleSB3YW50IGhhcmRlbmVkIGFzIG11Y2ggYXMgcG9zc2libGUg dG8gYXZvaWQgaXNzdWVzLg0KIEkga25vdyBNYXJ0aW4gbWVudGlvbmVkIHdhbnRpbmcgYSB0ZXN0 IGNhc2UsIGJ1dCB0aGF0J3Mgbm90IGZhaXIgd2hlbiB0aGV5IGFyZSBub3QgcmVhZHkgYW5kIGhh dmUgZGlmZmVyZW50IHByaW9yaXRpZXMuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBLYXRobGVlbiw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCB0aGluayBJJ20g Zm9sbG93aW5nIHlvdS4gSSBhZ3JlZSB0aGF0IHRoZXkgZG9uJ3QgbmVlZCB0byBkZXBlbmQgb24g dGhlIHByb2ZpbGUgaWYgdGhleSB3YW50IHRvIGRpc2FibGUgMC1SVFQuIE15IHF1ZXN0aW9uIGlz ICp3aHkqIHRoZXkgd2FudCB0byBkaXNhYmxlIDAtUlRULiBJIGhlYXJkIHR3byByZWFzb25zIGNp dGVkOiAoMSkgY29uY2VybiBhYm91dCByZXBsYXkgYXR0YWNrcyBhbmQgKDIpIGxhY2sNCiBvZiBG Uy4gSXMgbGFjayBvZiBGUyBpbiBmYWN0IGEgY29uY2VybiBoZXJlPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEVLUiw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxhY2sgb2YgRlMgaXMgYSBjb25jZXJu LCBzbyB0aGF0IHNob3VsZCBiZSBhZGRlZCB0byB0aGUgdGV4dC4gJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXkgZG9uJ3QgY2Fy ZSBhYm91dCB0aGUgcGVyZm9ybWFuY2UgaW5jcmVhc2UgYXMgaXQncyBub3Qgd29ydGggdGhlIHRy YWRlIG9mZi4mbmJzcDsgRXZlbiB3aXRoIG1pdGlnYXRpb25zLCB5b3UgaGF2ZSB0byB3b3JyeSB0 aGF0IHRoZSBkZXZlbG9wZXIgZ290IGl0IHJpZ2h0LCB0aGUgaW1wbGVtZW50ZXIgZGlkbid0IGhh dmUgYSBjb25maWd1cmF0aW9uIG1pc3Rha2UsIG9yIHRoZXJlJ3Mgc29tZXRoaW5nIHdyb25nIHdp dGgNCiB0aGUgc3BlYy4mbmJzcDsgRm9yIHNlbnNpdGl2ZSBkYXRhIGV4Y2hhbmdlLCBpdCdzIGp1 c3QgYSBsb3QgZWFzaWVyIHRvIGVsaW1pbmF0ZSBwb3NzaWJsZSB0aHJlYXRzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkluIHRoYXQgY2FzZSwgaXQgc2VlbXMgbGlrZSB0aGlzIHRleHQgb3VnaHQgdG8g YWxzbyByZWNvbW1lbmQgYWdhaW5zdCB1c2luZyBUTFMgMS4yIHNlc3Npb24gcmVzdW1wdGlvbi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIG1heSBoYXZlIGJlZW4g dGV4dCB0byB0aGF0IGVmZmVjdCBpbiB0aGUgdmVyc2lvbiBNYXJ0aW4gcmV2aWV3ZWQgYW5kIHRo ZXkgY2FuIGNlcnRhaW5seSBhZGQgdGhhdCBvciBhZGQgaXQgYmFjay4gJm5ic3A7TXkgcmV2aWV3 IGhhZCB0aGVtIGFkZCA3NTI1LCBtZWFuaW5nIHRvIHRha2Ugb3V0IGR1cGxpY2F0aXZlIHRleHQg YW5kIHRoZW4gdGhleSByZW1vdmVkIGEgYnVuY2ggYWZ0ZXIgTWFydGluIG1hZGUgdGhlDQogc2Ft ZSBjb21tZW50LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ S2F0aGxlZW4mbmJzcDs8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LYXRobGVl biZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpCZXN0LDxicj4NCkthdGhsZWVuPGJy Pg0KJmd0Ozxicj4NCiZndDsgSU5MSU5FIENPTU1FTlRTPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7IG9yIHNlcmlhbGl6YXRpb24uJm5ic3A7IFRoaXMgYXBwcm9hY2ggYWxsb3dzIHRoZSBw cm92aWRlciB0byBzdXBwb3J0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IG11bHRpcGxl LCBjb21wYXRpYmxlIGZvcm1hdHMgYWxsb3dpbmcgdGhlIGNvbnN1bWVyIHRvIHNlbGVjdCB0aGU8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgbW9zdCBzdWl0YWJsZSB2ZXJzaW9uLjxicj4N CiZndDsgV2hhdCBkb2VzICZxdW90O2NvbXBhdGlibGUmcXVvdDsgbWVhbiBoZXJlLiBEbyB5b3Ug bWVhbiBpc29tb3JwaGljPzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3N1cHBvcnRp bmcgaW50ZXJhY3RpdmUgdXNlciBsb2dpbnMgYnkgbWVtYmVycyBvZiB0aGUgY29uc29ydGl1bTxi cj4NCiZndDsmbmJzcDsgJm5ic3A7U0hPVUxEIHN1cHBvcnQgY2xpZW50IGF1dGhlbnRpY2F0aW9u IHZpYSBhIGZlZGVyYXRlZCBpZGVudGl0eSBzY2hlbWUuPGJyPg0KJmd0OyBTdWNoIGFzPzxicj4N CiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO1Byb3BlciB1c2FnZSBvZiBUTFMgYXMgZGVzY3Jp YmVkIGluIFNlY3Rpb24gNS4zIHdpbGwgaW4gbWFueSBjYXNlczxicj4NCiZndDsmbmJzcDsgJm5i c3A7YWlkIGluIHRoZSBtaXRpZ2F0aW9uIG9mIHRoZXNlIGlzc3Vlcy48YnI+DQomZ3Q7IFlvdSBz aG91bGQgYWxzbyBub3RlIHRoYXQgVExTIDEuMiBhbmQgbG93ZXIgY2xpZW50IGF1dGggbGVha3Mg dGhlIHVzZXInczxicj4NCiZndDsgaWRlbnRpdHkgdG8gb24tdGhlLXdpcmUgYXR0YWNrZXJzLjxi cj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3N1cHBvcnRlZC4mbmJzcDsgVExTIDEuMiBT SE9VTEQgYmUgaW1wbGVtZW50ZWQgYWNjb3JkaW5nIHRvIGFsbDxicj4NCiZndDsmbmJzcDsgJm5i c3A7cmVjb21tZW5kYXRpb25zIGFuZCBiZXN0IHByYWN0aWNlcyBwcmVzZW50IGluIFtSRkM3NTI1 XS48YnI+DQomZ3Q7IFlvdSBuZWVkIGEgY2l0YXRpb24gdG8gNjEyNSBhYm91dCB2YWxpYXRpb24s IHRob3VnaCBJIHJlYWxpemUgdGhhdCA3NTI1IGNpdGVzPGJyPg0KJmd0OyBpdC48YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7IG1pbGUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVm PSJtYWlsdG86bWlsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1pbGVAaWV0Zi5vcmc8L2E+ PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0 aW5mbyUyRm1pbGUmYW1wO2RhdGE9MDIlN0MwMSU3Q3N0ZXBoZW4uYmFuZ2hhcnQlNDBuaXN0Lmdv diU3Q2E0MjBmMDBmMTkzNTQyOGRlYmRmMDhkNTE5NjQ5ZDlmJTdDMmFiNWQ4MmZkOGZhNDc5N2E5 M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjQ0Mjg0MjI5NTgxMzAzNCZhbXA7c2RhdGE9cEFa STclMkZOTzVZZVZzZ0taZ29XQ0tiM1k1RFNINWJEbDdSb2oyUGpOMlNrJTNEJmFtcDtyZXNlcnZl ZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21pbGU8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_MWHPR09MB11973430FAC0DCBD7C4391CCF0460MWHPR09MB1197namp_-- From nobody Tue Oct 24 19:10:46 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D8B13942F; Tue, 24 Oct 2017 19:10:44 -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-mile-rolie@ietf.org, mile@ietf.org, mile-chairs@tools.ietf.org, Nancy Cam-Winget , mile-chairs@ietf.org, ncamwing@cisco.com, mile@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150889744468.4711.7690332098961761471.idtracker@ietfa.amsl.com> Date: Tue, 24 Oct 2017 19:10:44 -0700 Archived-At: Subject: [mile] Ben Campbell's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 02:10:44 -0000 Ben Campbell has entered the following ballot position for draft-ietf-mile-rolie-11: 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-mile-rolie/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- -5.1.3: I don't think Martin's ART-ART review concern (and Mark's support) about the .well-known URL registration has been fully resolved. While version 11 removed some of the well-known registrations, it still leaves the one. Mark pointed out that RFC 5785 offers explicit guidance that .well-known URLs are intended to offer site-wide policy or metadata, and are not intended for general information retrieval, or to establish a namespace. This usage seems to me to be exactly the sort of thing that the RFC advises against. I recognize that security information is important, but I don't understand why it's discovery needs to be fundamentally different than for other stuff on using ATOM. I'm willing to be convinced, but if there's been a convincing argument so far I've missed it. I'm not sure what to make of the second paragraph. It says DNS SRV can be used to determine the host and port. Is the expectation that people can just do that without further specification, or that someone could specify it in the future? The former is generally not true. If the intent is the latter, please clarify that in the text. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: -2: There are a number of lower case versions of 2119 keywords. If those are intentional, please use the updated boilerplate from RFC 8174. That being said, the following paragraph says the keywords are used for conformance. 2219/8174 keywords are not about conformance. They are about interoperability. If you want to use them for conformance, that's okay--but that means they are no longer being used as intended by 2119, and the boilerplate should be adjusted accordingly. -3.2: I'm confused by the idea the schema is informative. I expect that at least some implementors will implement to the schema. We have a perennial problem where implementors implement the examples rather than the text. It seems like a non-normative schema is even more of an attractive hazard in that regard. -5.4, 2nd paragraph: This seems like an odd thing to state normatively. It seems to push for a specific organizational model for consortiums. It's reasonable to offer guidance, but I think consortiums are going to do whatever they want here. -8.3: What is the registration policy for the top level registry? -10: "Overall, ROLIE introduces few privacy concerns above and beyond those present in any other HTTP protocol. " I'm skeptical that that is true. Security information seems likely to be privacy sensitive, especially compared to some notional "generic" HTTP based protocol. Editorial: -5.1.2, definition of ROLIE collection: This uses the MUST as a definition, rather than a normative requirement. It would be sufficient to say that a ROLIE collection _is_ one that contains... -5.1.3: Typo on first word "..his". -- "requires that an implementation MUST publish" "requires" and "MUST" are redundant. Consider simply saying "An implementation MUST publish..." -6: "The normative requirements in this section are generally oriented towards any content to be published to a ROLIE server." I don't understand the intent here. What else would they be about? 8.1, XML: s/"section A" / "appendix A" From nobody Tue Oct 24 21:04:00 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E42E8138BCD; Tue, 24 Oct 2017 21:03:57 -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-mile-rolie@ietf.org, mile@ietf.org, mile-chairs@tools.ietf.org, Nancy Cam-Winget , mile-chairs@ietf.org, ncamwing@cisco.com, mile@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150890423788.4689.5942012074290459252.idtracker@ietfa.amsl.com> Date: Tue, 24 Oct 2017 21:03:57 -0700 Archived-At: Subject: [mile] Adam Roach's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 04:03:58 -0000 Adam Roach has entered the following ballot position for draft-ietf-mile-rolie-11: 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-mile-rolie/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I agree with Ben, Martin, and Mark: the way this document uses /.well-known/ URIs is not consistent with RFC5785, section 1.1. It should be understood that /.well-known/ URLs are already a carve-out from overall REST principles regarding the agency of content publishers to assign URLs within their domain as they see fit; and, as such, need non-trivial justification for their use. If there were some fully-defined autodiscovery mechanism that were (non-artificially) constrained in such a way that only a host and port were available, then the use of /.well-known/ URIs would be more understandable. The only constraint hinted at in this document that might have these properties is the use of DNS SRV records. Given that ROLIE is defining a green-field protocol, the use of something as constrained as SRV seems ill-advised, given that the use of NAPTR records would trivially allow retrieval of a complete URL instead of just a host/port combination. The bottom line, however, is that we need to defer specification of a /.well-known/ URL until we completely define a discovery protocol that requires it. The corollary is that we should avoid defining a discovery protocol that requires it. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Since ROLIE requires the use of TLS client certificates, all of its resources need to be conveyed over HTTPS (i.e., ROLIE resources can never use "http" IRI schemes, only "https" IRI schemes). The following examples need to be fixed to reflect this: Section 6.1.2: Section B.1: ... ... ... ... ... ------------------------------------------------------------ Additionally, the following href values (also in B.1) are illegal, and need to contain a scheme (presumably, https): ... From nobody Wed Oct 25 07:41:21 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF701384B2; Wed, 25 Oct 2017 07:41:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-mile-rolie@ietf.org, mile@ietf.org, mile-chairs@tools.ietf.org, Nancy Cam-Winget , mile-chairs@ietf.org, ncamwing@cisco.com, mile@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150894247490.4878.17517594836897487607.idtracker@ietfa.amsl.com> Date: Wed, 25 Oct 2017 07:41:14 -0700 Archived-At: Subject: [mile] Alissa Cooper's No Objection on draft-ietf-mile-rolie-11: (with COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 14:41:15 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-mile-rolie-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-mile-rolie/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The schema registration in Section 8.1 says "See section A of this document." I think you mean Appendix A? Also, as with Ben I don't understand what it implies for the schema to be informative. Section 8.3 says "Designated Expert reviews should be routed through the MILE WG mailing list. Failing this, the Designated Expert will be assigned by the IESG." Might it be better to assign a back-up designated expert at the time of the document's approval, so that we don't end up in a situation of prolonging a registration delay by having to find and approve an expert after the WG mailing list has proved unresponsive? From nobody Wed Oct 25 07:45:41 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81315138713; Wed, 25 Oct 2017 07: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 TsvyYFA-9DfE; Wed, 25 Oct 2017 07:45:34 -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 DED8B1384B2; Wed, 25 Oct 2017 07:45:33 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id s75so163328pgs.0; Wed, 25 Oct 2017 07:45:33 -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=xq03SE8Pj+smz/Q4rsAx9ddAqjb2Md9stlkJ29OxZvs=; b=k9i5i0vY1nRw5gOdkJHlb2aLSEROmZldyuJtEDir9FTznom0pqO+P7Ci2GRnXFZ4pr 5/eV2MoW8avU+kgMczs/bw6xdt7u52kXgfatdAJo5LYJ+ERIQvabQR+AwUs2WAQAC26O mGv6tIdHbPqLC9W6dtHdyif+mMjEzfeeH/23vzn+9XyhaLsmE7LCYKaMZ41/vZNNNYrJ 8hSrwHs3+klodvdiSzLw3xtYseIDlSPx+II/qUAcJyrIu6wfx/+AtXzsK+w65mOFVrFg OGjfO42sUWE3GzAbPuLFtI7S7w3OhyJpLj217ScgYx+e3BxGg80dq+zUTl1meAC3ylYz pZXg== 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=xq03SE8Pj+smz/Q4rsAx9ddAqjb2Md9stlkJ29OxZvs=; b=gozNFio9sbuaE+x3Y49XYrk7pg6j906yqkgRan1lZc06cqe0g3kbYq0T2R/j9SkOqQ /2iIh2t5VG+J68u7/0hlhZ9i9n8k9Yq4LO7o2Phedu4rIJhY4DJ7xuxffTK6TD7f+QXb CLBctzajPtSRN7rK5exvaUipsyL+BKMUe8jev64ibtTVwrxxFZqfSnQe0tdqPs0vmFgo 8ciSmJoK/kcTTryb+Dmaes4vGBFLFHAdQgX3l7bEJYWpLIedSG3AkS+NBPKBVLvibS/z UCqrcZnnkcSxe7feFCAX/4B4fpQTNWcBLmekzs3NltBkNQTU1wxnIX3c9i/7VnC7Q8QK ALsQ== X-Gm-Message-State: AMCzsaVyYomqW3frqMqfEqNon+9nadE7htCYMoRj/mImpX89NRh/eSek A0gienC9nDXDcIfkxouk+hEpeJaR30Sy5A/ZF3w= X-Google-Smtp-Source: ABhQp+SzsQSvXYHkECCh+3ErFgU8XQIvjE6/RnfnWYhVUOXF+y+ElLlomT16B8OSUSOjm+LxhS2FwjG56zGE+HvCUKA= X-Received: by 10.98.37.68 with SMTP id l65mr2420919pfl.253.1508942733500; Wed, 25 Oct 2017 07:45:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Wed, 25 Oct 2017 07:44:53 -0700 (PDT) In-Reply-To: <150894247490.4878.17517594836897487607.idtracker@ietfa.amsl.com> References: <150894247490.4878.17517594836897487607.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Wed, 25 Oct 2017 10:44:53 -0400 Message-ID: To: Alissa Cooper Cc: The IESG , draft-ietf-mile-rolie@ietf.org, MILE IETF , mile-chairs@ietf.org, ncamwing@cisco.com, "mile-chairs@tools.ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [mile] Alissa Cooper's No Objection on draft-ietf-mile-rolie-11: (with COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 14:45:35 -0000 On Wed, Oct 25, 2017 at 10:41 AM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-mile-rolie-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-mile-rolie/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The schema registration in Section 8.1 says "See section A of this document." I > think you mean Appendix A? Also, as with Ben I don't understand what it implies > for the schema to be informative. > > Section 8.3 says "Designated Expert reviews should be routed through the MILE > WG mailing list. Failing this, the Designated Expert will be assigned by the > IESG." Might it be better to assign a back-up designated expert at the time of > the document's approval, so that we don't end up in a situation of prolonging a > registration delay by having to find and approve an expert after the WG mailing > list has proved unresponsive? This is my fault, I didn't check the text after I had asked for corrections. If you see the ballot text, I had already named 2 DEs and had expected the text to say that the discussion would be on list. Thanks for catching that! Kathleen > > -- Best regards, Kathleen From nobody Wed Oct 25 08:24:15 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CEF13F3FB; Wed, 25 Oct 2017 08:24:08 -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=nM+5oZ3L; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=k1ugUfNL 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 4x_grl3ywW-Q; Wed, 25 Oct 2017 08:24:07 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A5A13F3DE; Wed, 25 Oct 2017 08:24:07 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C6C49226AA; Wed, 25 Oct 2017 11:24:06 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 25 Oct 2017 11:24:06 -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; s=fm1; bh=DIlcaW2JBcA0tUfEZQQTfuOcpGA1I yM90bxquMy54U0=; b=nM+5oZ3LsYT29ve+YUV3rjAZXGbKdP9SCDAEfBEWXA28z n9NDmVkuRyX0FhVmcO+3D2AyXU5OdXLawFyuMD57y0MCzW0UwbfWEsWd4D9+BWFL tQgdYjWhVJ4mz4/vvViNznTy47LfQ1Rq4LnbOOd6PukBvckxY/FOtsJ4JUOrw47N dJglAi9+gt/RGl1kFm9BArcydx3rUD/EccCHljlTrWXdxAgKLmEY671CCVwNieTd QIUOsTTVhNJTyYVyTXQmKTJ2uJimwbZn3C6zxCGaPH5Ji+mQ/9pqnCKpHtg2xFcn Z25x3yo7Uqdyr256cmJJkMrE2ONnvvzcT2czwmO8w== 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; s=fm1; bh=DIlcaW 2JBcA0tUfEZQQTfuOcpGA1IyM90bxquMy54U0=; b=k1ugUfNLRSIvaTIbuZMOIM Lp88SExZMy4dgzLhQkYDdIuRxwqUOEsTNTTHXPdXNeX1a8nIQVrU9mCw3qLPwYC0 z4lX4jXRnNuVd3Svnr4zDwlGEe8R+jHtSIr1++KsiTAiF8IPg9Swhokm34UGyTua 9zxG9l0R9xIYJ9O3vULiwlZ91XobW7KNB5rIhXFs0tAqrN8h4O4oKPqizxVZ2WB/ Q2gVlRfg+BAc7XeU8iDZhhED09GkJQMELXPN6rLp8+B2TR/mOKdUzJdkuyiqjlf9 OHtrEmbqNKoG0ealpdg70N36aQOEUuGTX2j+18pLpI/elF4zC0W6jpmO++MXPl6g == X-ME-Sender: Received: from sjc-alcoop-88113.cisco.com (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id 6A2217F955; Wed, 25 Oct 2017 11:24:05 -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: Date: Wed, 25 Oct 2017 11:24:03 -0400 Cc: IESG , draft-ietf-mile-rolie@ietf.org, MILE IETF , mile-chairs@ietf.org, ncamwing@cisco.com, "mile-chairs@tools.ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9B228C2F-445F-4EE8-9393-27E7011D1AA6@cooperw.in> References: <150894247490.4878.17517594836897487607.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [mile] Alissa Cooper's No Objection on draft-ietf-mile-rolie-11: (with COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 15:24:09 -0000 > On Oct 25, 2017, at 10:44 AM, Kathleen Moriarty = wrote: >=20 > On Wed, Oct 25, 2017 at 10:41 AM, Alissa Cooper = wrote: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-mile-rolie-11: 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-mile-rolie/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> The schema registration in Section 8.1 says "See section A of this = document." I >> think you mean Appendix A? Also, as with Ben I don't understand what = it implies >> for the schema to be informative. >>=20 >> Section 8.3 says "Designated Expert reviews should be routed through = the MILE >> WG mailing list. Failing this, the Designated Expert will be = assigned by the >> IESG." Might it be better to assign a back-up designated expert at = the time of >> the document's approval, so that we don't end up in a situation of = prolonging a >> registration delay by having to find and approve an expert after the = WG mailing >> list has proved unresponsive? >=20 > This is my fault, I didn't check the text after I had asked for > corrections. If you see the ballot text, I had already named 2 DEs > and had expected the text to say that the discussion would be on list. Oh, great. I did not read the ballot text. ;) >=20 > Thanks for catching that! > Kathleen >>=20 >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Wed Oct 25 13:10:28 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7240A1386F3; Wed, 25 Oct 2017 13:10:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 u-_oN9oz-V6d; Wed, 25 Oct 2017 13:10:24 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0098.outbound.protection.outlook.com [23.103.200.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25ECA137ED6; Wed, 25 Oct 2017 13:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Wzd4mIXLOoRkem0iyHQ61GSbRDjV9+20qvCZHH4mgP4=; b=A1W9GPmYnWKd/Pd5BPQPop3OlqJrA9FglMeYCBx6VnANAAwtDqB/9g18HGWeplycOfLVArj5wP9sDgtmAtadl+GYgdQ0DKJpJXGH3LUY+7zBFd1Sb+10j+M8sGqSjhhnGOre1vtF4uZVVLgv4lpzqTAYxX+rwSaPtr6FffBq1xE= Received: from CY4PR09MB1192.namprd09.prod.outlook.com (10.172.65.146) by CY4PR09MB1189.namprd09.prod.outlook.com (10.172.65.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Wed, 25 Oct 2017 20:10:22 +0000 Received: from CY4PR09MB1192.namprd09.prod.outlook.com ([10.172.65.146]) by CY4PR09MB1192.namprd09.prod.outlook.com ([10.172.65.146]) with mapi id 15.20.0178.007; Wed, 25 Oct 2017 20:10:22 +0000 From: "Banghart, Stephen A. (Fed)" To: Ben Campbell CC: "draft-ietf-mile-rolie@ietf.org" , "mile@ietf.org" , "mile-chairs@tools.ietf.org" , Nancy Cam-Winget , "mile-chairs@ietf.org" , "ncamwing@cisco.com" , "mile@ietf.org" , The IESG Thread-Topic: Ben Campbell's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and COMMENT) Thread-Index: AQHTTTZ/ZRssFCkRtU+t66d26L/EEaL051Ug Date: Wed, 25 Oct 2017 20:10:21 +0000 Message-ID: References: <150889744468.4711.7690332098961761471.idtracker@ietfa.amsl.com> In-Reply-To: <150889744468.4711.7690332098961761471.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.251.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1189; 6:Qpn0qPvoULsdmz7V0i7ah0drTqE9yE16X7oMv/qe7DB1GMJSg27YEMYPl7m5Vopgvyu0NuZ8V2CgBm9z2n/XdUeBhHZo14C+sghqt6/nCi8LHaOjTOmfvi9pZ0I7xDUDeS+haVyCP3KXXPfzqhqWYB1ypLkTK+5fFYZu734fDqH+QY7YNY6uryXl9XQGDgiqAOVpsYZDF7KsKptjdxJR05/rc6/zWBc93jp/u+p0oXvPpYWdcYONq1k8kwxICOjUhaTcpEbYyaRXFe44MGveKUhk9Sp6JLI7MGfdmqA4oPAfqzWOvPereRfjv1ZitodOesMKpm63jJ6+01x0/23jEikzoYRO3BGktZOqeeLCqiA=; 5:sFWTysmxV77FSyxqwzOl0dhecHjZxnjfp/QWBsuWaJISVzhs7UR1ipb6WCn+YMOwlMfRAkvJsa2CHGAIS+S0Hvj40SrPwL/nJ5PjxjhW1omRpvgfIJSqOofBTHUeADnKhcjY7zw0+K1nxHrN8cl5GnbQLEVtixfk7laC1gn4bjc=; 24:Rat88NrECDS6/YgrnCTXSxurvLfv7/7p4yOZoGHSPnzdr/axMVByASJ+2VEDfYPNFatU1ek5vr9IN3nM/4gol1r5azNvY1o+colFeGFSJyQ=; 7:xt5zeyoouXwq3lqzWh7WFLSSmMTW4ZFR1lRdbPpwt55JZwdZ3ymHJcqK59JlnBE+QyeOQufiqeHhRNvWAzGqTgDI6DHYaePOAN33AQYvjGgsLiL5cLg0zajRFyiRTh/WsbIkW9g3EH3YQ62D7x7qQQCGXH9NqZ3/0JOHwjXf1auEIPnkYp39EqZuxg/M8VmubTevUNCfGVqSG9pS8V6ofpV3+h24eXiLPZAa0T7hrTCkZpEz1JIaZknRdfTd4sSW x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 25a0f38f-d0af-4ad8-19bd-08d51be46c06 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR09MB1189; x-ms-traffictypediagnostic: CY4PR09MB1189: x-exchange-antispam-report-test: UriScan:(192374486261705)(189930954265078)(131327999870524)(95692535739014)(219752817060721)(1591387915157); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231020)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1189; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1189; x-forefront-prvs: 0471B73328 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(13464003)(199003)(51914003)(189002)(8676002)(81166006)(86362001)(7736002)(8936002)(45080400002)(2906002)(25786009)(305945005)(478600001)(81156014)(97736004)(7696004)(68736007)(54356999)(106356001)(76176999)(6116002)(14454004)(50986999)(6246003)(189998001)(101416001)(55016002)(102836003)(575784001)(3846002)(54906003)(230783001)(5660300001)(99286003)(33656002)(105586002)(66066001)(53936002)(4326008)(6436002)(316002)(53546010)(6306002)(2900100001)(3660700001)(3280700002)(229853002)(6916009)(77096006)(2950100002)(9686003)(966005)(74316002)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1189; H:CY4PR09MB1192.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 25a0f38f-d0af-4ad8-19bd-08d51be46c06 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2017 20:10:22.0063 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1189 Archived-At: Subject: Re: [mile] Ben Campbell's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 20:10:27 -0000 QmVuLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcsIEkndmUgcHV0IG15IGNvbW1lbnRzL2NoYW5n ZXMgaW5saW5lLg0KDQpUaGFua3MsDQpTdGVwaGVuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogQmVuIENhbXBiZWxsIFttYWlsdG86YmVuQG5vc3RydW0uY29tXQ0KPiBT ZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI0LCAyMDE3IDEwOjExIFBNDQo+IFRvOiBUaGUgSUVTRyA8 aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LWlldGYtbWlsZS1yb2xpZUBpZXRmLm9yZzsgbWls ZUBpZXRmLm9yZzsgbWlsZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7DQo+IE5hbmN5IENhbS1XaW5n ZXQgPG5jYW13aW5nQGNpc2NvLmNvbT47IG1pbGUtY2hhaXJzQGlldGYub3JnOw0KPiBuY2Ftd2lu Z0BjaXNjby5jb207IG1pbGVAaWV0Zi5vcmcNCj4gU3ViamVjdDogQmVuIENhbXBiZWxsJ3MgRGlz Y3VzcyBvbiBkcmFmdC1pZXRmLW1pbGUtcm9saWUtMTE6ICh3aXRoIERJU0NVU1MNCj4gYW5kIENP TU1FTlQpDQo+IA0KPiBCZW4gQ2FtcGJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxs b3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtbWlsZS1yb2xpZS0xMTogRGlzY3Vzcw0KPiAN Cj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBh bmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5k IENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3Jh cGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0bw0KPiBodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5p DQo+IGV0Zi5vcmclMkZpZXNnJTJGc3RhdGVtZW50JTJGZGlzY3Vzcy0NCj4gY3JpdGVyaWEuaHRt bCZkYXRhPTAyJTdDMDElN0NzdGVwaGVuLmJhbmdoYXJ0JTQwbmlzdC5nb3YlN0NhYjU1NjQ4Yw0K PiA4OThmNDI5MTUzNTcwOGQ1MWI0ZDlhNTAlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2 MWRlYyU3QzElNw0KPiBDMCU3QzYzNjQ0NDk0MjQ4MjQ3NTIzMyZzZGF0YT1yZlZxNTRUSkJQWkRs cGlWYTJ1ZjclMkIyT0kzMVBuQW9uaA0KPiBNUVZEbEN5VXZBJTNEJnJlc2VydmVkPTANCj4gZm9y IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9u cy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0 aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyDQo+IGFja2VyLmlldGYu b3JnJTJGZG9jJTJGZHJhZnQtaWV0Zi1taWxlLQ0KPiByb2xpZSUyRiZkYXRhPTAyJTdDMDElN0Nz dGVwaGVuLmJhbmdoYXJ0JTQwbmlzdC5nb3YlN0NhYjU1NjQ4Yzg5OGYNCj4gNDI5MTUzNTcwOGQ1 MWI0ZDlhNTAlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJQ0KPiA3 QzYzNjQ0NDk0MjQ4MjQ3NTIzMyZzZGF0YT1UJTJGaHBBRzAyaVolMkJERHZxemlFY2ZPTUlSRHo2 OUM5aFYNCj4gYjAyWTdYaTB0N1klM0QmcmVzZXJ2ZWQ9MA0KPiANCj4gDQo+IA0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IC01LjEuMzoNCj4gDQo+ IEkgZG9uJ3QgdGhpbmsgTWFydGluJ3MgIEFSVC1BUlQgcmV2aWV3IGNvbmNlcm4gKGFuZCBNYXJr J3Mgc3VwcG9ydCkgYWJvdXQNCj4gdGhlIC53ZWxsLWtub3duIFVSTCByZWdpc3RyYXRpb24gaGFz IGJlZW4gZnVsbHkgcmVzb2x2ZWQuIFdoaWxlIHZlcnNpb24gMTENCj4gcmVtb3ZlZCBzb21lIG9m IHRoZSB3ZWxsLWtub3duIHJlZ2lzdHJhdGlvbnMsIGl0IHN0aWxsIGxlYXZlcyB0aGUgb25lLiAg TWFyaw0KPiBwb2ludGVkIG91dCB0aGF0IFJGQyA1Nzg1IG9mZmVycyBleHBsaWNpdCBndWlkYW5j ZSB0aGF0IC53ZWxsLWtub3duIFVSTHMgYXJlDQo+IGludGVuZGVkIHRvIG9mZmVyIHNpdGUtd2lk ZSBwb2xpY3kgb3IgbWV0YWRhdGEsIGFuZCBhcmUgbm90IGludGVuZGVkIGZvcg0KPiBnZW5lcmFs IGluZm9ybWF0aW9uIHJldHJpZXZhbCwgb3IgdG8gZXN0YWJsaXNoIGEgbmFtZXNwYWNlLiAgVGhp cyB1c2FnZSBzZWVtcw0KPiB0byBtZSB0byBiZSBleGFjdGx5IHRoZSBzb3J0IG9mIHRoaW5nIHRo YXQgdGhlIFJGQyBhZHZpc2VzIGFnYWluc3QuDQo+IA0KPiBJIHJlY29nbml6ZSB0aGF0IHNlY3Vy aXR5IGluZm9ybWF0aW9uIGlzIGltcG9ydGFudCwgYnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkN Cj4gaXQncyBkaXNjb3ZlcnkgbmVlZHMgdG8gYmUgZnVuZGFtZW50YWxseSBkaWZmZXJlbnQgdGhh biBmb3Igb3RoZXIgc3R1ZmYgb24NCj4gdXNpbmcgQVRPTS4gSSdtIHdpbGxpbmcgdG8gYmUgY29u dmluY2VkLCBidXQgaWYgdGhlcmUncyBiZWVuIGEgY29udmluY2luZw0KPiBhcmd1bWVudCBzbyBm YXIgSSd2ZSBtaXNzZWQgaXQuDQoNCkkgcmVwbGllZCB0byBNYXJ0aW4ncyBjb25jZXJuIG9uIHRo aXMgaXNzdWUgaW4gYW4gZWFybGllciBlLW1haWwgYW5kIEkgdGhpbmsgd2UndmUgcmVhY2hlZCBh Z3JlZW1lbnQgb24gdGhlIGp1c3RpZmljYXRpb24gZm9yIHRoZSB3ZWxsLWtub3duIHJlZ2lzdHJh dGlvbiAoaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9taWxlL2diRzVuQzhP aDRxNzZQLTBkWEh3TS16dE1QWSkgDQoNClJPTElFIGlzIGxhcmdlbHkgaW50ZW5kZWQgdG8gYmUg aGFuZGxlZCBieSBhdXRvbWF0ZWQgc3lzdGVtcyB0aGF0IGNhbm5vdCByZWxpYWJseSBsb2NhdGUg bGlua3MgZ2l2ZW4gYnkgZnJvbnQtZmFjaW5nIHNpdGVzLiBJbiB0aGVzZSBjYXNlcywgdGhlIFJP TElFIGNsaWVudHMgbmVlZCBhIHJlbGlhYmxlIHdheSBvZiBmaW5kaW5nIGEgUk9MSUUgcmVwb3Np dG9yeSBob3N0ZWQgYnkgYSBnaXZlbiBzZXJ2ZXIuIFRoZSB3ZWxsLWtub3duIHJlZ2lzdHJhdGlv biBwcm92aWRlcyBhIHN0YW5kYXJkaXplZCBwbGFjZSBmb3IgdGhlIGhlYWQgb2YgdGhlIFJPTElF IHJlcG9zaXRvcnkgdG8gYmUgcmV0cmlldmVkLCBtYWtpbmcgaXQgcG9zc2libGUgZm9yIGFuIGF1 dG9tYXRlZCBzeXN0ZW0gdG8gZnVuY3Rpb24gd2hlbiBvbmx5IGdpdmVuIGEgaG9zdCBuYW1lIGFu ZCBwb3J0Lg0KDQpXZSd2ZSBhZGRlZCB0aGUgZm9sbG93aW5nIGFkZGl0aW9uYWwganVzdGlmaWNh dGlvbiB0ZXh0IHRvIHRoZSBzcGVjaWZpY2F0aW9uIHRvIGhlbHAgY2xhcmlmeSBvdXIgcmVhc29u aW5nLg0KDQoiUk9MSUUgcmVwb3NpdG9yaWVzIGFyZSBsYXJnZWx5IGludGVuZGVkIHRvIGJlIGNv bnN1bWVkIGJ5IGF1dG9tYXRlZCBzeXN0ZW1zLiBXaGlsZSBodW1hbnMgbWF5IGJlIGFibGUgdG8g bmF2aWdhdGUgYSB3ZWIgcGFnZSBvciByZWNlaXZlIGFuIGVtYWlsIHRvIGZpbmQgYSBsaW5rIHRv IHRoZSByZXBvc2l0b3J5LCBhdXRvbWF0ZWQgc3lzdGVtcyBzdHJ1Z2dsZSB3aXRoIHN1Y2ggdGFz a3MuIEJ5IGNyZWF0aW5nIGEgc3RhbmRhcmRpemVkIGxvY2F0aW9uIGZvciB0aGUgU2VydmljZSBE b2N1bWVudCwgUk9MSUUgY2xpZW50cyBuZWVkIG9ubHkgYSBob3N0IG5hbWUgYW5kIHBvcnQgaW4g b3JkZXIgdG8gbG9jYXRlIGEgUk9MSUUgcmVwb3NpdG9yeS4gVGhpcyBsb3dlciBiYXJyaWVyIHRv IGVudHJ5IHJlZHVjZXMgdGhlIGFtb3VudCBvZiBodW1hbiBpbnRlcnZlbnRpb24gcmVxdWlyZWQg Zm9yIFJPTElFIGNsaWVudHMgdG8gYmVnaW4gcmVhZGluZyBGZWVkcy4iDQoNCldlJ3ZlIGRyb3Bw ZWQgdGhlIHdlbGwta25vd24gcmVnaXN0cmF0aW9uIGZvciB0aGUgQ2F0ZWdvcnkgRG9jdW1lbnQs IGFzIGl0IGlzIGxvY2F0YWJsZSBmcm9tIHRoZSBTZXJ2aWNlIERvY3VtZW50IHdoZXJlIGFwcGxp Y2FibGUuDQoNCj4gSSdtIG5vdCBzdXJlIHdoYXQgdG8gbWFrZSBvZiB0aGUgc2Vjb25kIHBhcmFn cmFwaC4gSXQgc2F5cyBETlMgU1JWIGNhbiBiZQ0KPiB1c2VkIHRvIGRldGVybWluZSB0aGUgaG9z dCBhbmQgcG9ydC4gSXMgdGhlIGV4cGVjdGF0aW9uIHRoYXQgcGVvcGxlIGNhbiBqdXN0DQo+IGRv IHRoYXQgd2l0aG91dCBmdXJ0aGVyIHNwZWNpZmljYXRpb24sIG9yIHRoYXQgc29tZW9uZSBjb3Vs ZCBzcGVjaWZ5IGl0IGluIHRoZQ0KPiBmdXR1cmU/DQo+IFRoZSBmb3JtZXIgaXMgZ2VuZXJhbGx5 IG5vdCB0cnVlLiBJZiB0aGUgaW50ZW50IGlzIHRoZSBsYXR0ZXIsIHBsZWFzZSBjbGFyaWZ5IHRo YXQNCj4gaW4gdGhlIHRleHQuDQoNClRoZSBpbnRlbnQgd2FzIHRoZSBsYXR0ZXIuIEkndmUgY2hh bmdlZCB0aGUgZW5kIG9mIHRoYXQgcGFyYWdyYXBoIHRvIGZ1cnRoZXIgY2xhcmlmeSBhcyBmb2xs b3dzOg0KDQoiVXNlIG9mIGEgbWVjaGFuaXNtIHN1Y2ggYXMgRE5TIFNSViBSZWNvcmRzICBjYW4g cHJvdmlkZSBhIHNlY3VyZSBhbmQgcmVsaWFibGUgZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZGV0 ZXJtaW5pbmcgYSBzcGVjaWZpYyBob3N0IGFuZCBwb3J0IHRvIHVzZSBmb3IgcmV0cmlldmluZyBh IFNlcnZpY2UgRG9jdW1lbnQgZm9yIGEgZ2l2ZW4gRE5TIGRvbWFpbi4gVGhpcyBpcyBhIGZlYXR1 cmUgdGhhdCBtYXkgYmUgc3RhbmRhcmRpemVkIGluIHRoZSBmdXR1cmUuIg0KDQo+IA0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFN1YnN0YW50aXZl Og0KPiANCj4gLTI6IFRoZXJlIGFyZSBhIG51bWJlciBvZiBsb3dlciBjYXNlIHZlcnNpb25zIG9m IDIxMTkga2V5d29yZHMuIElmIHRob3NlIGFyZQ0KPiBpbnRlbnRpb25hbCwgcGxlYXNlIHVzZSB0 aGUgdXBkYXRlZCBib2lsZXJwbGF0ZSBmcm9tIFJGQyA4MTc0LiBUaGF0IGJlaW5nDQo+IHNhaWQs IHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoIHNheXMgdGhlIGtleXdvcmRzIGFyZSB1c2VkIGZvciBj b25mb3JtYW5jZS4NCj4gMjIxOS84MTc0IGtleXdvcmRzIGFyZSBub3QgYWJvdXQgY29uZm9ybWFu Y2UuIFRoZXkgYXJlIGFib3V0DQo+IGludGVyb3BlcmFiaWxpdHkuIElmIHlvdSB3YW50IHRvIHVz ZSB0aGVtIGZvciBjb25mb3JtYW5jZSwgdGhhdCdzIG9rYXktLWJ1dA0KPiB0aGF0IG1lYW5zIHRo ZXkgYXJlIG5vIGxvbmdlciBiZWluZyB1c2VkIGFzIGludGVuZGVkIGJ5IDIxMTksIGFuZCB0aGUN Cj4gYm9pbGVycGxhdGUgc2hvdWxkIGJlIGFkanVzdGVkIGFjY29yZGluZ2x5Lg0KDQpUaGUgbG93 ZXIgY2FzZSBrZXl3b3JkcyBhcmUgaW50ZW50aW9uYWwuIFdlJ3ZlIHN3aXRjaGVkIHRoZSBib2ls ZXJwbGF0ZSB0ZXh0IHRvIHRoZSB1cGRhdGVkIDgxNzQgdmVyc2lvbi4NCg0KPiAtMy4yOiBJJ20g Y29uZnVzZWQgYnkgdGhlIGlkZWEgdGhlIHNjaGVtYSBpcyBpbmZvcm1hdGl2ZS4gSSBleHBlY3Qg dGhhdCBhdA0KPiBsZWFzdCBzb21lIGltcGxlbWVudG9ycyB3aWxsIGltcGxlbWVudCAgdG8gdGhl IHNjaGVtYS4gV2UgaGF2ZSBhDQo+IHBlcmVubmlhbCBwcm9ibGVtIHdoZXJlIGltcGxlbWVudG9y cyBpbXBsZW1lbnQgdGhlIGV4YW1wbGVzIHJhdGhlcg0KPiB0aGFuIHRoZSB0ZXh0LiBJdCBzZWVt cyBsaWtlIGEgbm9uLW5vcm1hdGl2ZSBzY2hlbWEgaXMgZXZlbiBtb3JlIG9mIGFuDQo+IGF0dHJh Y3RpdmUgaGF6YXJkIGluIHRoYXQgcmVnYXJkLg0KDQpXZSBmb3VuZCB0aGF0IGF2YWlsYWJsZSBz Y2hlbWEgbGFuZ3VhZ2VzIGNhbm5vdCBleHByZXNzIHRoZSBzYW1lIGNvbXBsZXhpdGllcyB3ZSBj b3VsZCBleHByZXNzIGluIHRleHQuIFRoZXJlIGFyZSBkaWZmaWN1bHQgY29uZGl0aW9uYWwgcmVx dWlyZW1lbnRzIHRoYXQgYXJlIHBvb3JseSBleHByZXNzZWQgaW4gc2NoZW1hcyBidXQgY2FuIGJl IGZpdCBpbnRvIGEgbmVhdCBzZW50ZW5jZS4gSW4gb3JkZXIgdG8gc3VwcG9ydCB0aGUgcGxhY2Vz IHdoZXJlIHdlIGRvIHRoYXQsIHdlIGRlY2lkZWQgdGhhdCBtYWtpbmcgdGhlIHRleHQgbm9ybWF0 aXZlIHdhcyB0aGUgb25seSB3YXkgdG8gZW5zdXJlIHRoYXQgdGhlIHJlcXVpcmVtZW50cyB3ZXJl IGV4cHJlc3NlZCBjbGVhcmx5Lg0KDQpBZGRpdGlvbmFsbHksIEF0b20gU3luZGljYXRpb24gYW5k IHRoZSBBdG9tIFB1Ymxpc2hpbmcgUHJvdG9jb2wgYm90aCBzcGVjaWZ5IHRoYXQgdGhlIHRleHQg aXMgbm9ybWF0aXZlLCBub3QgdGhlIGluY2x1ZGVkIHNjaGVtYXMuIEJ5IG1ha2luZyB0aGUgc2No ZW1hIGluZm9ybWF0aXZlLCB3ZSBhcmUga2VlcGluZyB3aXRoIHRoaXMgcHJhY3RpY2UuDQoNCj4g LTUuNCwgMm5kIHBhcmFncmFwaDogVGhpcyBzZWVtcyBsaWtlIGFuIG9kZCB0aGluZyB0byBzdGF0 ZSBub3JtYXRpdmVseS4gSXQNCj4gc2VlbXMgdG8gcHVzaCBmb3IgYSBzcGVjaWZpYyBvcmdhbml6 YXRpb25hbCBtb2RlbCBmb3IgY29uc29ydGl1bXMuIEl0J3MNCj4gcmVhc29uYWJsZSB0byBvZmZl ciBndWlkYW5jZSwgYnV0IEkgdGhpbmsgY29uc29ydGl1bXMgYXJlIGdvaW5nIHRvIGRvDQo+IHdo YXRldmVyIHRoZXkgd2FudCBoZXJlLg0KDQpSZXdvcmRlZCB0aGlzIHBhcmFncmFwaCBpbnRvIGEg bm9uLW5vcm1hdGl2ZSByZWNvbW1lbmRhdGlvbi4NCg0KPiAtOC4zOiBXaGF0IGlzIHRoZSByZWdp c3RyYXRpb24gcG9saWN5IGZvciB0aGUgdG9wIGxldmVsIHJlZ2lzdHJ5Pw0KDQpUaGVyZSB3YXMg c29tZSBtaXNsZWFkaW5nIHRleHQgdGhhdCBkaXNjdXNzZWQgYSByZWdpc3RyeSB0aGF0IHdlIGRp ZG4ndCBpbnRlbmQgdG8gYmUgY3JlYXRlZC4gV2UndmUgZml4ZWQgdGhlIHRleHQgdG8gbWFrZSBp dCBjbGVhciB0aGF0IHRoZXJlIGlzIG9ubHkgb25lIHJlZ2lzdHJ5IGJlaW5nIGRlZmluZWQgKFJP TElFIFVSTiBQYXJhbWV0ZXJzKSBpbiB0aGlzIHNlY3Rpb24uIFRoZSB1cGRhdGVkIHRleHQgaXMg cHJvdmlkZWQgaGVyZToNCg0KIkEgbmV3IHRvcC1sZXZlbCByZWdpc3RyeSBoYXMgYmVlbiBjcmVh dGVkLCBlbnRpdGxlZCAiUmVzb3VyY2UgT3JpZW50ZWQgTGlnaHR3ZWlnaHQgSW5mb3JtYXRpb24g RXhjaGFuZ2UgKFJPTElFKSBVUk4gUGFyYW1ldGVycyIuIFtUTyBCRSBSRU1PVkVEOiBUaGlzIHJl Z2lzdHJhdGlvbiBzaG91bGQgdGFrZSBwbGFjZSBhdCB0aGUgZm9sbG93aW5nIGxvY2F0aW9uOiBo dHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9yb2xpZV0NCg0KUmVnaXN0cmF0aW9uIGlu IHRoZSBST0xJRSBVUk4gUGFyYW1ldGVycyByZWdpc3RyeSBpcyB2aWEgdGhlIFNwZWNpZmljYXRp b24gUmVxdWlyZWQgcG9saWN5IC4gRGVzaWduYXRlZCBFeHBlcnQgcmV2aWV3cyBzaG91bGQgYmUg cm91dGVkIHRocm91Z2ggdGhlIE1JTEUgV0cgbWFpbGluZyBsaXN0LiBGYWlsaW5nIHRoaXMsIHRo ZSBEZXNpZ25hdGVkIEV4cGVydCB3aWxsIGJlIGFzc2lnbmVkIGJ5IHRoZSBJRVNHLiINCg0KPiAt MTA6ICAgIk92ZXJhbGwsIFJPTElFIGludHJvZHVjZXMgZmV3IHByaXZhY3kgY29uY2VybnMgYWJv dmUgYW5kIGJleW9uZA0KPiB0aG9zZQ0KPiBwcmVzZW50IGluIGFueSBvdGhlciBIVFRQIHByb3Rv Y29sLiAiIEknbSBza2VwdGljYWwgdGhhdCB0aGF0IGlzIHRydWUuIFNlY3VyaXR5DQo+IGluZm9y bWF0aW9uIHNlZW1zIGxpa2VseSB0byBiZSBwcml2YWN5IHNlbnNpdGl2ZSwgZXNwZWNpYWxseSBj b21wYXJlZCB0bw0KPiBzb21lIG5vdGlvbmFsICJnZW5lcmljIiBIVFRQIGJhc2VkIHByb3RvY29s Lg0KDQpXZSd2ZSByZXdyaXR0ZW4gdGhpcyBsYXN0IHBhcmFncmFwaCB0byBwcm92aWRlIG1vcmUg Y2xlYXIgZGV0YWlscyBhcm91bmQgcHJpdmFjeSBjb25jZXJucyBpbiBST0xJRS4gVGhlIHVwZGF0 ZWQgdGV4dCBpcyBwcm92aWRlZCBoZXJlOg0KDQoiT3ZlcmFsbCwgcHJpdmFjeSBjb25jZXJucyBp biBST0xJRSBjYW4gYmUgbWl0aWdhdGVkIGJ5IGZvbGxvd2luZyBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBhbmQgY2FyZWZ1bCB1c2Ugb2YgdGhlIG9wdGlvbmFsIHBlcnNvbmFsbHkgaWRlbnRpZnlp bmcgZWxlbWVudHMgKGUuZy4sIGF1dGhvcikgcHJvdmlkZWQgYnkgQXRvbSBTeW5kaWNhdGlvbiBh bmQgUk9MSUUuIg0KDQo+IEVkaXRvcmlhbDoNCj4gDQo+IC01LjEuMiwgZGVmaW5pdGlvbiBvZiBS T0xJRSBjb2xsZWN0aW9uOiBUaGlzIHVzZXMgdGhlIE1VU1QgYXMgYSBkZWZpbml0aW9uLA0KPiBy YXRoZXIgdGhhbiBhIG5vcm1hdGl2ZSByZXF1aXJlbWVudC4gSXQgd291bGQgYmUgc3VmZmljaWVu dCB0byBzYXkgdGhhdCBhDQo+IFJPTElFIGNvbGxlY3Rpb24gX2lzXyBvbmUgdGhhdCBjb250YWlu cy4uLg0KDQpXZSd2ZSByZXdvcmtlZCB0aGUgdGV4dCB0byBiZSBtb3JlIGFwcHJvcHJpYXRlIGRl ZmluaXRpb25zIG9mIHRlcm1zLCBhbmQgcmVtb3ZlZCBhbGwgbm9ybWF0aXZlIHRleHQgZnJvbSB0 aGVtLiBUaGUgdXBkYXRlZCBkZWZpbml0aW9ucyBmb2xsb3c6DQoNCiJBbiBhcHA6Y29sbGVjdGlv biBpcyBjb25zaWRlcmVkIGEgUk9MSUUgQ29sbGVjdGlvbiB3aGVuIGl0IGNvbnRhaW5zIGFuIGFw cDpjYXRlZ29yaWVzIGVsZW1lbnQgdGhhdCBjb250YWlucyBvbmx5IG9uZSBhdG9tOmNhdGVnb3J5 IGVsZW1lbnQgd2l0aCB0aGUgInNjaGVtZSIgYXR0cmlidXRlIHZhbHVlIG9mICJ1cm46aWV0Zjpw YXJhbXM6cm9saWU6Y2F0ZWdvcnk6aW5mb3JtYXRpb24tdHlwZSIuIEZ1cnRoZXIsIHRoaXMgY2F0 ZWdvcnkgaGFzIGFuIGFwcHJvcHJpYXRlICJ0ZXJtIiBhdHRyaWJ1dGUgdmFsdWUgYXMgZGVmaW5l ZCBpbiBzZWN0aW9uIC4gVGhpcyBlbnN1cmVzIHRoYXQgYSBnaXZlbiBDb2xsZWN0aW9uIGNvcnJl c3BvbmRzIHRvIGEgc3BlY2lmaWMgdHlwZSBvZiBzZWN1cml0eSBhdXRvbWF0aW9uIGluZm9ybWF0 aW9uLg0KDQpBbiBhcHA6Y29sbGVjdGlvbiBpcyBjb25zaWRlcmVkIGEgbm9uLVJPTElFIENvbGxl Y3Rpb24gd2hlbiBpdCBkb2VzIG5vdCBjb250YWluIGFuIGF0b206Y2F0ZWdvcnkgZWxlbWVudCB3 aXRoIGEgInNjaGVtZSIgYXR0cmlidXRlIHZhbHVlIG9mICJ1cm46aWV0ZjpwYXJhbXM6cm9saWU6 Y2F0ZWdvcnk6aW5mb3JtYXRpb24tdHlwZSIuIg0KDQo+IC01LjEuMzogVHlwbyBvbiBmaXJzdCB3 b3JkICIuLmhpcyIuDQo+IC0tICJyZXF1aXJlcyB0aGF0IGFuIGltcGxlbWVudGF0aW9uIE1VU1Qg cHVibGlzaCINCj4gInJlcXVpcmVzIiBhbmQgIk1VU1QiIGFyZSByZWR1bmRhbnQuIENvbnNpZGVy IHNpbXBseSBzYXlpbmcgIkFuDQo+IGltcGxlbWVudGF0aW9uIE1VU1QgcHVibGlzaC4uLiINCg0K QWdyZWVkLCBjaGFuZ2VkLg0KDQo+IC02OiAiVGhlIG5vcm1hdGl2ZSByZXF1aXJlbWVudHMgaW4g dGhpcyBzZWN0aW9uIGFyZSBnZW5lcmFsbHkgb3JpZW50ZWQNCj4gdG93YXJkcyBhbnkgY29udGVu dCB0byBiZSBwdWJsaXNoZWQgdG8gYSBST0xJRSBzZXJ2ZXIuIiBJIGRvbid0IHVuZGVyc3RhbmQN Cj4gdGhlIGludGVudCBoZXJlLiBXaGF0IGVsc2Ugd291bGQgdGhleSBiZSBhYm91dD8NCg0KVGhp cyBzZW50ZW5jZSBkb2VzIHNlZW0gcmF0aGVyIHN0cmFuZ2UgaW4gcmV0cm9zcGVjdC4gSSd2ZSBz dHJ1Y2sgdGhlIHdob2xlIHNlbnRlbmNlIGFuZCBjaGFuZ2VkIHRoZSB3b3JkaW5nIHNsaWdodGx5 LiBIZXJlIGlzIHRoZSBuZXcgdGV4dDoNCg0KIiBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIGEgbnVt YmVyIG9mIHJlc3RyaWN0aW9ucyBvZiBhbmQgZXh0ZW5zaW9ucyB0byB0aGUgQXRvbSBTeW5kaWNh dGlvbiBGb3JtYXQgdGhhdCBkZWZpbmUgdmFsaWQgdXNlIG9mIHRoZSBmb3JtYXQgaW4gdGhlIGNv bnRleHQgb2YgYSBST0xJRSBpbXBsZW1lbnRhdGlvbi4gQW4gdW5kZXJzdGFuZGluZyBvZiB0aGUg QXRvbSBTeW5kaWNhdGlvbiBGb3JtYXQgc3BlY2lmaWNhdGlvbiAgaXMgaGVscGZ1bCB0byB1bmRl cnN0YW5kIHRoZSByZXF1aXJlbWVudHMgaW4gdGhpcyBzZWN0aW9uLiINCg0KPiA4LjEsIFhNTDoN Cj4gcy8ic2VjdGlvbiBBIiAvICJhcHBlbmRpeCBBIg0KDQpGaXhlZC4NCg0K From nobody Wed Oct 25 13:36:03 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D705A13F468; Wed, 25 Oct 2017 13:36:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 khaMnuDGGkwf; Wed, 25 Oct 2017 13:35:59 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0131.outbound.protection.outlook.com [23.103.201.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C95513F462; Wed, 25 Oct 2017 13:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Vh5+dvXUm+S7PUi9n2OoD6XCH784Z3ZcydkCdxIWdRc=; b=HUqA/7mdX+KKv7uu6WWOCaUs9RVOaNYeZ3KY7hmSbkZp9XLAY4pzg8xcaDDmftsaplJoGQ72010KUf09ARA34uiReIEnoK5IDBCb1+Z9yH70Sxwy2ibY8yQieAMvrAT9oO3s2fsp6O1lbSttIEcvlWk/C8WnMEu/dsdoHr+fEfk= Received: from CY4PR09MB1192.namprd09.prod.outlook.com (10.172.65.146) by CY4PR09MB1191.namprd09.prod.outlook.com (10.172.65.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Wed, 25 Oct 2017 20:35:56 +0000 Received: from CY4PR09MB1192.namprd09.prod.outlook.com ([10.172.65.146]) by CY4PR09MB1192.namprd09.prod.outlook.com ([10.172.65.146]) with mapi id 15.20.0178.007; Wed, 25 Oct 2017 20:35:56 +0000 From: "Banghart, Stephen A. (Fed)" To: Adam Roach CC: "draft-ietf-mile-rolie@ietf.org" , "mile@ietf.org" , "mile-chairs@tools.ietf.org" , Nancy Cam-Winget , "mile-chairs@ietf.org" , "ncamwing@cisco.com" , "mile@ietf.org" , The IESG Thread-Topic: Adam Roach's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and COMMENT) Thread-Index: AQHTTUZSm55anh/gYEy4JIuYjSD1UKL1AXmQ Date: Wed, 25 Oct 2017 20:35:56 +0000 Message-ID: References: <150890423788.4689.5942012074290459252.idtracker@ietfa.amsl.com> In-Reply-To: <150890423788.4689.5942012074290459252.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.251.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1191; 6:8mo53B+M+qlhGeZDJIZCJiTK/o3miLQ9XchyzLiBu3czv3cN6wVO2TAge6gR8Gk6TYphNH0D/Xs/qRqWiMNJHggDh2jB53jpeLxowEQBvtqr18wqamEHuZHsMiyS0G3Q0IH3gPWt1BH5lVjWYWU59Vk//5+QrkYkUFg76vLtnZwouVvH+aaizlnTgdi9kQq4OW/q5LGJqKXprt3HewN2T74T1Vdon3Bs0FqXiIm6Q4EJcwZCk6advW9JiXxIQs4FI3t9tBg6KkmLVBjHhWUvD3T0eYz1/I9DhTYGn32aAsvZVoVFTXg7/zSRA5WsuPhIQo1o2J84fnpdMtJFyAdgjA==; 5:MZRV4AQ0xsuIGuJQVLXzRQoiypfUSUi14VMW7SOQxpSwfgIgy/7+LFLAirhhRtOTTVIwNHE+pSC1WaJ0PFGrzI4AIax3vB6AP7i9ZYHunUezovWFZ9G3xKthIdLG324KSURNmWGdUpjtIZXf71uxCw==; 24:LD5YWREb9pJyDHdi3nSMLgP75TENYrlar7LiqcU+lJwFjUTExuNUW9jqhZv3jtyl3PhvYJA19TdcaJ5031TTG7ZXcxsauG0rCjT5xvaElWE=; 7:XrnbNNAKGqnGQvv/QtS7a+UWAd8/ZiwvU0T1c4viJx4acjuxQJf7MSxfgh9EorJ1UxIBsgMm6DRcKAvLaHJpQ4u1Db8CSY85XgoVT2VTFs03yvXFBsjiCatVKzFBf1BpGVzXtLHlzoCAjxc3XrYYkvcHNPTccBDwNk5ZBHUd5stZIQ8ceZDDIbahaYh1zEYay8mESvEbKgUIL536hzIJJNp8SuZxwfLnDqZIq7CM9E8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e094a373-d185-4ae8-893d-08d51be7fe79 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603238); SRVR:CY4PR09MB1191; x-ms-traffictypediagnostic: CY4PR09MB1191: x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(95692535739014)(219752817060721); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231020)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1191; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1191; x-forefront-prvs: 0471B73328 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(199003)(13464003)(189002)(51914003)(50986999)(97736004)(6246003)(5660300001)(3846002)(8936002)(6116002)(478600001)(102836003)(45080400002)(6916009)(53936002)(606006)(2950100002)(74316002)(2900100001)(101416001)(99286003)(68736007)(9686003)(55016002)(189998001)(25786009)(33656002)(81156014)(8676002)(81166006)(6306002)(14454004)(229853002)(6436002)(7696004)(66066001)(53546010)(77096006)(6506006)(7736002)(106356001)(305945005)(316002)(230783001)(105586002)(3280700002)(3660700001)(54356999)(76176999)(575784001)(4326008)(54906003)(86362001)(2906002)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1191; H:CY4PR09MB1192.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: e094a373-d185-4ae8-893d-08d51be7fe79 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2017 20:35:56.2003 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1191 Archived-At: Subject: Re: [mile] Adam Roach's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 20:36:02 -0000 QWRhbSwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBJJ3ZlIHB1dCBteSBjb21tZW50cy9jaGFu Z2VzIGlubGluZS4NCg0KVGhhbmtzLA0KU3RlcGhlbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0uY29tXQ0KPiBT ZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjUsIDIwMTcgMTI6MDQgQU0NCj4gVG86IFRoZSBJRVNH IDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1taWxlLXJvbGllQGlldGYub3JnOyBt aWxlQGlldGYub3JnOyBtaWxlLWNoYWlyc0B0b29scy5pZXRmLm9yZzsNCj4gTmFuY3kgQ2FtLVdp bmdldCA8bmNhbXdpbmdAY2lzY28uY29tPjsgbWlsZS1jaGFpcnNAaWV0Zi5vcmc7DQo+IG5jYW13 aW5nQGNpc2NvLmNvbTsgbWlsZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBBZGFtIFJvYWNoJ3MgRGlz Y3VzcyBvbiBkcmFmdC1pZXRmLW1pbGUtcm9saWUtMTE6ICh3aXRoIERJU0NVU1MgYW5kDQo+IENP TU1FTlQpDQo+IA0KPiBBZGFtIFJvYWNoIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90 IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLW1pbGUtcm9saWUtMTE6IERpc2N1c3MNCj4gDQo+ IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBD QyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBo LCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8NCj4gaHR0cHM6Ly9uYTAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaQ0K PiBldGYub3JnJTJGaWVzZyUyRnN0YXRlbWVudCUyRmRpc2N1c3MtDQo+IGNyaXRlcmlhLmh0bWwm ZGF0YT0wMiU3QzAxJTdDc3RlcGhlbi5iYW5naGFydCU0MG5pc3QuZ292JTdDMDg0NTZkMDlmDQo+ IGExZDRjMWRhMmVhMDhkNTFiNWQ2YjcxJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFk ZWMlN0MxJTcNCj4gQzAlN0M2MzY0NDUwMTA0Mzc4Mzc0MDQmc2RhdGE9WUNpN2dUQXdGWkR2eGl3 elY2Nkl1aG54NzN6aUhlOEdKNkoNCj4gTUpuZUlOamMlM0QmcmVzZXJ2ZWQ9MA0KPiBmb3IgbW9y ZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0K PiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25z LCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHINCj4gYWNrZXIuaWV0Zi5vcmcl MkZkb2MlMkZkcmFmdC1pZXRmLW1pbGUtDQo+IHJvbGllJTJGJmRhdGE9MDIlN0MwMSU3Q3N0ZXBo ZW4uYmFuZ2hhcnQlNDBuaXN0LmdvdiU3QzA4NDU2ZDA5ZmExZA0KPiA0YzFkYTJlYTA4ZDUxYjVk NmI3MSU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzANCj4gJTdDNjM2 NDQ1MDEwNDM3ODM3NDA0JnNkYXRhPVQlMkZpVkZhUElvckJhM2lnRHBSazg3TU0lMkJsMXN3MWhB DQo+IHJCRWhxbXFxalZqSSUzRCZyZXNlcnZlZD0wDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gSSBhZ3JlZSB3aXRoIEJlbiwg TWFydGluLCBhbmQgTWFyazogdGhlIHdheSB0aGlzIGRvY3VtZW50IHVzZXMgLy53ZWxsLQ0KPiBr bm93bi8gVVJJcyBpcyBub3QgY29uc2lzdGVudCB3aXRoIFJGQzU3ODUsIHNlY3Rpb24gMS4xLiBJ dCBzaG91bGQgYmUNCj4gdW5kZXJzdG9vZCB0aGF0IC8ud2VsbC1rbm93bi8gVVJMcyBhcmUgYWxy ZWFkeSBhIGNhcnZlLW91dCBmcm9tIG92ZXJhbGwNCj4gUkVTVCBwcmluY2lwbGVzIHJlZ2FyZGlu ZyB0aGUgYWdlbmN5IG9mIGNvbnRlbnQgcHVibGlzaGVycyB0byBhc3NpZ24gVVJMcw0KPiB3aXRo aW4gdGhlaXIgZG9tYWluIGFzIHRoZXkgc2VlIGZpdDsgYW5kLCBhcyBzdWNoLCBuZWVkIG5vbi10 cml2aWFsIGp1c3RpZmljYXRpb24NCj4gZm9yIHRoZWlyIHVzZS4NCj4gDQo+IElmIHRoZXJlIHdl cmUgc29tZSBmdWxseS1kZWZpbmVkIGF1dG9kaXNjb3ZlcnkgbWVjaGFuaXNtIHRoYXQgd2VyZQ0K PiAobm9uLWFydGlmaWNpYWxseSkgY29uc3RyYWluZWQgaW4gc3VjaCBhIHdheSB0aGF0IG9ubHkg YSBob3N0IGFuZCBwb3J0IHdlcmUNCj4gYXZhaWxhYmxlLCB0aGVuIHRoZSB1c2Ugb2YgLy53ZWxs LWtub3duLyBVUklzIHdvdWxkIGJlIG1vcmUNCj4gdW5kZXJzdGFuZGFibGUuIFRoZSBvbmx5IGNv bnN0cmFpbnQgaGludGVkIGF0IGluIHRoaXMgZG9jdW1lbnQgdGhhdCBtaWdodA0KPiBoYXZlIHRo ZXNlIHByb3BlcnRpZXMgaXMgdGhlIHVzZSBvZiBETlMgU1JWIHJlY29yZHMuIEdpdmVuIHRoYXQg Uk9MSUUgaXMNCj4gZGVmaW5pbmcgYSBncmVlbi1maWVsZCBwcm90b2NvbCwgdGhlIHVzZSBvZiBz b21ldGhpbmcgYXMgY29uc3RyYWluZWQgYXMgU1JWDQo+IHNlZW1zIGlsbC1hZHZpc2VkLCBnaXZl biB0aGF0IHRoZSB1c2Ugb2YgTkFQVFIgcmVjb3JkcyB3b3VsZCB0cml2aWFsbHkgYWxsb3cNCj4g cmV0cmlldmFsIG9mIGEgY29tcGxldGUgVVJMIGluc3RlYWQgb2YganVzdCBhIGhvc3QvcG9ydCBj b21iaW5hdGlvbi4NCj4gDQo+IFRoZSBib3R0b20gbGluZSwgaG93ZXZlciwgaXMgdGhhdCB3ZSBu ZWVkIHRvIGRlZmVyIHNwZWNpZmljYXRpb24gb2YgYSAvLndlbGwtDQo+IGtub3duLyBVUkwgdW50 aWwgd2UgY29tcGxldGVseSBkZWZpbmUgYSBkaXNjb3ZlcnkgcHJvdG9jb2wgdGhhdCByZXF1aXJl cyBpdC4NCj4gVGhlIGNvcm9sbGFyeSBpcyB0aGF0IHdlIHNob3VsZCBhdm9pZCBkZWZpbmluZyBh IGRpc2NvdmVyeSBwcm90b2NvbCB0aGF0DQo+IHJlcXVpcmVzIGl0Lg0KPiANCg0KSSByZXBsaWVk IHRvIE1hcnRpbidzIGNvbmNlcm4gb24gdGhpcyBpc3N1ZSBpbiBhbiBlYXJsaWVyIGUtbWFpbCBh bmQgSSB0aGluayB3ZSd2ZSByZWFjaGVkIGFncmVlbWVudCBvbiB0aGUganVzdGlmaWNhdGlvbiBm b3IgdGhlIHdlbGwta25vd24gcmVnaXN0cmF0aW9uIChodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL21pbGUvZ2JHNW5DOE9oNHE3NlAtMGRYSHdNLXp0TVBZKQ0KDQpXZSBiZWxp ZXZlIHRoYXQgd2UgaGF2ZSBhIG1pbmltYWwgdXNlIGNhc2UvZGlzY292ZXJ5IHN0b3J5IHdoZXJl IFJPTElFIGNsaWVudHMgb25seSBoYXZlIHRoZSBob3N0IG5hbWUgYW5kIHBvcnQgZm9yIGEgcG90 ZW50aWFsIFJPTElFIHNlcnZlciwgYW5kIG5lZWQgYSBzdGFuZGFyZGl6ZWQgd2F5IHRvIGNoZWNr L2xvY2F0ZSB0aGUgbWV0YWRhdGEgb2YgYW4gYXNzb2NpYXRlZCBST0xJRSByZXBvc2l0b3J5LiBJ biB0aGVzZSBjYXNlcyBhdXRvbWF0ZWQgc3lzdGVtcyBuZWVkIGEgbWVhbnMgdG8gbG9jYXRlIGEg Uk9MSUUgcmVwb3NpdG9yeSB3aXRob3V0IGEgaHVtYW4gbmVlZGluZyB0byB0cmFjayBkb3duIGEg bGluayB0aHJvdWdoIGJyb3dzaW5nIHRoZSBzaXRlLCBlbWFpbCwgZXRjLiBQcm92aWRpbmcgYSBV UkwgdGVtcGxhdGUgZm9yIHRoZSBTZXJ2aWNlIERvY3VtZW50IGFsbG93cyB0aGVzZSBhdXRvbWF0 ZWQgc3lzdGVtcyB0byBmaW5kIHRoZSBoZWFkIG9mIHRoZSBST0xJRSByZXBvc2l0b3J5LCBmcm9t IHRoZXJlIGl0IGNhbiBicm93c2UgdGhlIHJlc3Qgb2YgdGhlIENvbGxlY3Rpb25zL0VudHJpZXMg cHJlc2VudC4NCg0KV2UndmUgYWRkZWQgYWRkaXRpb25hbCB0ZXh0IHRvIHRoZSBzZWN0aW9uIGlu IG9yZGVyIHRvIHByb3ZpZGUgbW9yZSBqdXN0aWZpY2F0aW9uL3JlYXNvbmluZyBhcm91bmQgb3Vy IHdlbGwta25vd24gcmVnaXN0cmF0aW9uLiBJJ3ZlIHByb3ZpZGVkIHRoZSBuZXcgcGFyYWdyYXBo IGhlcmU6DQoNCiJST0xJRSByZXBvc2l0b3JpZXMgYXJlIGxhcmdlbHkgaW50ZW5kZWQgdG8gYmUg Y29uc3VtZWQgYnkgYXV0b21hdGVkIHN5c3RlbXMuIFdoaWxlIGh1bWFucyBtYXkgYmUgYWJsZSB0 byBuYXZpZ2F0ZSBhIHdlYiBwYWdlIG9yIHJlY2VpdmUgYW4gZW1haWwgdG8gZmluZCBhIGxpbmsg dG8gdGhlIHJlcG9zaXRvcnksIGF1dG9tYXRlZCBzeXN0ZW1zIHN0cnVnZ2xlIHdpdGggc3VjaCB0 YXNrcy4gQnkgY3JlYXRpbmcgYSBzdGFuZGFyZGl6ZWQgbG9jYXRpb24gZm9yIHRoZSBTZXJ2aWNl IERvY3VtZW50LCBST0xJRSBjbGllbnRzIG5lZWQgb25seSBhIGhvc3QgbmFtZSBhbmQgcG9ydCBp biBvcmRlciB0byBsb2NhdGUgYSBST0xJRSByZXBvc2l0b3J5LiBUaGlzIGxvd2VyIGJhcnJpZXIg dG8gZW50cnkgcmVkdWNlcyB0aGUgYW1vdW50IG9mIGh1bWFuIGludGVydmVudGlvbiByZXF1aXJl ZCBmb3IgUk9MSUUgY2xpZW50cyB0byBiZWdpbiByZWFkaW5nIEZlZWRzLiINCg0KV2UgZGlzY3Vz c2VkIHRoaXMgd2l0aGluIHRoZSBNSUxFIFdHIGFuZCB0aGUgV0cgYWdyZWVkIHRvIGRlZmluZSB0 aGUgLndlbGwta25vd24gYXBwcm9hY2gsIGJ1dCB0byBkZWZlciBvbiBhIHNwZWNpZmljIG1lYW5z IHRvIGRldGVybWluZSB0aGUgaG9zdCBhbmQgcG9ydCBvZiB0aGUgc2VydmVyIGF0IHRoaXMgdGlt ZS4gVGhpcyB3aWxsIGFsbG93IHRoZSBncm91cCB0byBnZXQgc29tZSBpbXBsZW1lbnRhdGlvbiBl eHBlcmllbmNlIHdpdGggUk9MSUUsIHdoaWxlIHJldmlld2luZyB0aGUgU1JWIGFuZCBOQVBUUiBy ZWNvcmQgYXBwcm9hY2hlcyB0byBkZXRlcm1pbmUgd2hhdCB0aGUgYmVzdCBhcHByb2FjaCBpcy4g V2UgY2FuIHRoZW4gd3JpdGUgYW5vdGhlciBkcmFmdCB0aGF0IHByb3ZpZGVzIHRoZXNlIGRldGFp bHMgd2hlbiB3ZSBhcmUgcmVhZHkuIEluIGFueSBjYXNlLCB3ZSBzdGlsbCBuZWVkIGEgd2F5IHRv IGRpc2NvdmVyIHRoZSBTZXJ2aWNlIERvY3VtZW50LCBzbyB0aGUgV0cgZm91bmQgaXQgdG8gYmUg cHJ1ZGVudCB0byBkbyB0aGF0IG5vdy4NCg0KRm9sbG93aW5nIE1hcnRpbidzIGNvbW1lbnRzLCB3 ZSByZW1vdmVkIHRoZSB3ZWxsLWtub3duIHJlZ2lzdHJhdGlvbiBmb3IgdGhlIENhdGVnb3J5IERv Y3VtZW50LCBhcyB0aGlzIGlzIGRpc2NvdmVyYWJsZSBmcm9tIHRoZSBTZXJ2aWNlIERvY3VtZW50 Lg0KDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4g U2luY2UgUk9MSUUgcmVxdWlyZXMgdGhlIHVzZSBvZiBUTFMgY2xpZW50IGNlcnRpZmljYXRlcywg YWxsIG9mIGl0cyByZXNvdXJjZXMgbmVlZA0KPiB0byBiZSBjb252ZXllZCBvdmVyIEhUVFBTIChp LmUuLCBST0xJRSByZXNvdXJjZXMgY2FuIG5ldmVyIHVzZSAiaHR0cCIgSVJJDQo+IHNjaGVtZXMs IG9ubHkgImh0dHBzIiBJUkkgc2NoZW1lcykuIFRoZSBmb2xsb3dpbmcgZXhhbXBsZXMgbmVlZCB0 byBiZSBmaXhlZA0KPiB0byByZWZsZWN0IHRoaXM6DQoNClRoYW5rcyBmb3IgY2F0Y2hpbmcgdGhp cy4gVGhlIGxpbmtzIGhhdmUgYmVlbiBjaGFuZ2VkIHRvIGh0dHBzLg0KDQo+IFNlY3Rpb24gNi4x LjI6DQo+IA0KPiAgICAgICAgICA8bGluayByZWw9InNlbGYiDQo+IGhyZWY9Imh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkYNCj4g ZXhhbXBsZS5vcmclMkZmZWVkQSUzRnBhZ2UlM0Q1JmRhdGE9MDIlN0MwMSU3Q3N0ZXBoZW4uYmFu Z2hhcnQNCj4gJTQwbmlzdC5nb3YlN0MwODQ1NmQwOWZhMWQ0YzFkYTJlYTA4ZDUxYjVkNmI3MSU3 QzJhYjVkODJmZDhmYTQ3OTcNCj4gYTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2NDQ1MDEw NDM3ODM3NDA0JnNkYXRhPU4yWElVV2VjSXIlDQo+IDJCb0VIbkJTVFZaUzBYMkJaUkJkcFIzTiUy QldIWUMzVVpJNCUzRCZyZXNlcnZlZD0wIi8+DQo+ICAgICAgICAgIDxsaW5rIHJlbD0iZmlyc3Qi DQo+IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHAlM0ElMkYlMkYNCj4gZXhhbXBsZS5vcmclMkZmZWVkQSUzRnBhZ2UlM0QxJmRhdGE9 MDIlN0MwMSU3Q3N0ZXBoZW4uYmFuZ2hhcnQNCj4gJTQwbmlzdC5nb3YlN0MwODQ1NmQwOWZhMWQ0 YzFkYTJlYTA4ZDUxYjVkNmI3MSU3QzJhYjVkODJmZDhmYTQ3OTcNCj4gYTkzZTA1NDY1NWM2MWRl YyU3QzElN0MwJTdDNjM2NDQ1MDEwNDM3ODM3NDA0JnNkYXRhPXIydzMyTiUyQjhGDQo+IEpZV25W SU9iWCUyQkxXU3V5Q3lMViUyQkhBRVFsS1JBRUJrQW8wJTNEJnJlc2VydmVkPTAiLz4NCj4gICAg ICAgICAgPGxpbmsgcmVsPSJwcmV2Ig0KPiBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGDQo+IGV4YW1wbGUub3JnJTJG ZmVlZEElM0ZwYWdlJTNENCZkYXRhPTAyJTdDMDElN0NzdGVwaGVuLmJhbmdoYXJ0DQo+ICU0MG5p c3QuZ292JTdDMDg0NTZkMDlmYTFkNGMxZGEyZWEwOGQ1MWI1ZDZiNzElN0MyYWI1ZDgyZmQ4ZmE0 Nzk3DQo+IGE5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjQ0NTAxMDQzNzgzNzQwNCZzZGF0 YT1RaEVZTjRaJTJGDQo+ICUyQjhuZWlrUE53SkdMJTJCR3RvRVUwZ0JyVmxRYmFuWG5hUXJnUSUz RCZyZXNlcnZlZD0wIi8+DQo+ICAgICAgICAgIDxsaW5rIHJlbD0ibmV4dCINCj4gaHJlZj0iaHR0 cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUy RiUyRg0KPiBleGFtcGxlLm9yZyUyRmZlZWRBJTNGcGFnZSUzRDYmZGF0YT0wMiU3QzAxJTdDc3Rl cGhlbi5iYW5naGFydA0KPiAlNDBuaXN0LmdvdiU3QzA4NDU2ZDA5ZmExZDRjMWRhMmVhMDhkNTFi NWQ2YjcxJTdDMmFiNWQ4MmZkOGZhNDc5Nw0KPiBhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2 MzY0NDUwMTA0Mzc4Mzc0MDQmc2RhdGE9cEVKS20xWnV5ajZTDQo+IGREVWtVa0NyUVVScTVLek1t YXd3VElTWlNXZDMlMkIzbyUzRCZyZXNlcnZlZD0wIi8+DQo+ICAgICAgICAgIDxsaW5rIHJlbD0i bGFzdCINCj4gaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cCUzQSUyRiUyRg0KPiBleGFtcGxlLm9yZyUyRmZlZWRBJTNGcGFnZSUzRDEw JmRhdGE9MDIlN0MwMSU3Q3N0ZXBoZW4uYmFuZ2hhcg0KPiB0JTQwbmlzdC5nb3YlN0MwODQ1NmQw OWZhMWQ0YzFkYTJlYTA4ZDUxYjVkNmI3MSU3QzJhYjVkODJmZDhmYTQ3OTcNCj4gYTkzZTA1NDY1 NWM2MWRlYyU3QzElN0MwJTdDNjM2NDQ1MDEwNDM3ODM3NDA0JnNkYXRhPW1INzdydzFUbHNYDQo+ IDhKdU9ZM0VISnlPRXBFekdQY29rdXhnaVQlMkYzMiUyRmxrWSUzRCZyZXNlcnZlZD0wIi8+DQo+ IA0KPiBTZWN0aW9uIEIuMToNCj4gDQo+ICAgICAgICAgPGNvbGxlY3Rpb24NCj4gaHJlZj0iaHR0 cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUy RiUyRg0KPiBleGFtcGxlLm9yZyUyRnByb3ZpZGVyJTJGdnVsbnMmZGF0YT0wMiU3QzAxJTdDc3Rl cGhlbi5iYW5naGFydCU0DQo+IDBuaXN0LmdvdiU3QzA4NDU2ZDA5ZmExZDRjMWRhMmVhMDhkNTFi NWQ2YjcxJTdDMmFiNWQ4MmZkOGZhNDc5N2E5Mw0KPiBlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2 MzY0NDUwMTA0Mzc4Mzc0MDQmc2RhdGE9U0hOb1YzS09kOUJ4Qg0KPiBuZ0NLQW1wbkt3eDlBcWZX QlRkWlRUZXZJWkZNY3clM0QmcmVzZXJ2ZWQ9MCI+DQo+IC4uLg0KPiAgICAgICAgIDxjb2xsZWN0 aW9uDQo+IA0KPiBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwJTNBJTJGJTJGDQo+IGV4YW1wbGUub3JnJTJGcHJvdmlkZXIlMkZwdWJs aWMlMkZ2dWxucyZkYXRhPTAyJTdDMDElN0NzdGVwaGVuLmJhDQo+IG5naGFydCU0MG5pc3QuZ292 JTdDMDg0NTZkMDlmYTFkNGMxZGEyZWEwOGQ1MWI1ZDZiNzElN0MyYWI1ZDgyZmQ4Zg0KPiBhNDc5 N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjQ0NTAxMDQzNzgzNzQwNCZzZGF0YT1CdDJT T24wDQo+IGJzZU12OVpFM2R4a201JTJGdHFGSm9zUUtFMVhDNE9wUmZrSFp3JTNEJnJlc2VydmVk PTAiPg0KPiAuLi4NCj4gICAgICAgICA8Y29sbGVjdGlvbg0KPiANCj4gaHJlZj0iaHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRg0K PiBleGFtcGxlLm9yZyUyRnByb3ZpZGVyJTJGcHJpdmF0ZSUyRmluY2lkZW50cyZkYXRhPTAyJTdD MDElN0NzdGVwaGUNCj4gbi5iYW5naGFydCU0MG5pc3QuZ292JTdDMDg0NTZkMDlmYTFkNGMxZGEy ZWEwOGQ1MWI1ZDZiNzElN0MyYWI1ZDgNCj4gMmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0Mx JTdDMCU3QzYzNjQ0NTAxMDQzNzgzNzQwNCZzZGF0YT1UWA0KPiBOWTQyNEEzSnVIanFNbFBvUmZa bVZUbHdScTAlMkZHU2VXRklQZ2JsUGUwJTNEJnJlc2VydmVkPTAiPg0KPiAuLi4NCj4gICAgICAg IDxsaW5rIHJlbD0ic2VsZiINCj4gDQo+IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkYNCj4gZXhhbXBsZS5vcmclMkZw cm92aWRlciUyRnB1YmxpYyUyRnZ1bG5zJmRhdGE9MDIlN0MwMSU3Q3N0ZXBoZW4uYmENCj4gbmdo YXJ0JTQwbmlzdC5nb3YlN0MwODQ1NmQwOWZhMWQ0YzFkYTJlYTA4ZDUxYjVkNmI3MSU3QzJhYjVk ODJmZDhmDQo+IGE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2NDQ1MDEwNDM3ODM3 NDA0JnNkYXRhPUJ0MlNPbjANCj4gYnNlTXY5WkUzZHhrbTUlMkZ0cUZKb3NRS0UxWEM0T3BSZmtI WnclM0QmcmVzZXJ2ZWQ9MCIgLz4NCj4gICAgICAgIDxsaW5rIHJlbD0ic2VydmljZSINCj4gDQo+ IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHAlM0ElMkYlMkYNCj4gZXhhbXBsZS5vcmclMkZyb2xpZSUyRnNlcnZpY2Vkb2N1bWVudCZk YXRhPTAyJTdDMDElN0NzdGVwaGVuLmJhbmcNCj4gaGFydCU0MG5pc3QuZ292JTdDMDg0NTZkMDlm YTFkNGMxZGEyZWEwOGQ1MWI1ZDZiNzElN0MyYWI1ZDgyZmQ4ZmE0DQo+IDc5N2E5M2UwNTQ2NTVj NjFkZWMlN0MxJTdDMCU3QzYzNjQ0NTAxMDQzNzgzNzQwNCZzZGF0YT16b0RMbjY5OVYNCj4gVCUy RmxxaVl6YXVSMUl0YktTaUlxJTJGYmh3VXp3aE10N3U1b0klM0QmcmVzZXJ2ZWQ9MCIvPg0KPiAu Li4NCj4gICAgICAgICAgPGNvbnRlbnQgdHlwZT0iYXBwbGljYXRpb24veG1sIg0KPiANCj4gc3Jj PSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw JTNBJTJGJTJGdw0KPiB3dy5leGFtcGxlLm9yZyUyRnByb3ZpZGVyJTJGdnVsbnMlMkYxMjM0NTYl MkZkYXRhJmRhdGE9MDIlN0MwMSUNCj4gN0NzdGVwaGVuLmJhbmdoYXJ0JTQwbmlzdC5nb3YlN0Mw ODQ1NmQwOWZhMWQ0YzFkYTJlYTA4ZDUxYjVkNmI3MSUNCj4gN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkz ZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2NDQ1MDEwNDM3ODM3NDA0Jg0KPiBzZGF0YT1oRFRo a3hjbVAzMFhZSE1lRDU4QWFUOWtKc05vNTFMOTdOVEFuVlRuVVBzJTNEJnJlc2VydmVkDQo+ID0w Ii8+DQo+IC4uLg0KPiAgICAgICAgPGNvbnRlbnQgdHlwZT0iYXBwbGljYXRpb24veG1sIg0KPiAN Cj4gc3JjPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwJTNBJTJGJTJGdw0KPiB3dy5leGFtcGxlLm9yZyUyRnByb3ZpZGVyJTJGdnVsbnMlMkYx MjM0NTYlMkZkYXRhJmRhdGE9MDIlN0MwMSUNCj4gN0NzdGVwaGVuLmJhbmdoYXJ0JTQwbmlzdC5n b3YlN0MwODQ1NmQwOWZhMWQ0YzFkYTJlYTA4ZDUxYjVkNmI3MSUNCj4gN0MyYWI1ZDgyZmQ4ZmE0 Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2NDQ1MDEwNDM3ODM3NDA0Jg0KPiBzZGF0 YT1oRFRoa3hjbVAzMFhZSE1lRDU4QWFUOWtKc05vNTFMOTdOVEFuVlRuVVBzJTNEJnJlc2VydmVk DQo+ID0wIj4NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gQWRkaXRpb25hbGx5LCB0aGUgZm9sbG93aW5nIGhy ZWYgdmFsdWVzIChhbHNvIGluIEIuMSkgYXJlIGlsbGVnYWwsIGFuZCBuZWVkIHRvDQo+IGNvbnRh aW4gYSBzY2hlbWUgKHByZXN1bWFibHksIGh0dHBzKToNCg0KQWxzbyBmaXhlZC4NCg0KPiAgICAg ICAgICAgPGF0b206bGluayByZWw9InNlcnZpY2UiDQo+IA0KPiBocmVmPSJodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD13d3cuZXhhbXBsZS5jbw0KPiBt JTJGcm9saWUlMkZzZXJ2aWNlZG9jdW1lbnQmZGF0YT0wMiU3QzAxJTdDc3RlcGhlbi5iYW5naGFy dCU0MG5pDQo+IHN0LmdvdiU3QzA4NDU2ZDA5ZmExZDRjMWRhMmVhMDhkNTFiNWQ2YjcxJTdDMmFi NWQ4MmZkOGZhNDc5N2E5M2UwDQo+IDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2MzY0NDUwMTA0Mzc4 Mzc0MDQmc2RhdGE9cmFuazZTbWJtcSUyQlFzDQo+IEdwVkoxcXNjWW4lMkYzU0Ewa3JxS0RQUUI1 R1N4bTFRJTNEJnJlc2VydmVkPTAiLz4NCj4gLi4uDQo+ICAgICAgICAgICA8YXRvbTpsaW5rIHJl bD0ic2VydmljZSINCj4gDQo+IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPXd3dy5leGFtcGxlLmNvDQo+IG0lMkZyb2xpZSUyRnNlcnZpY2Vk b2N1bWVudCZkYXRhPTAyJTdDMDElN0NzdGVwaGVuLmJhbmdoYXJ0JTQwbmkNCj4gc3QuZ292JTdD MDg0NTZkMDlmYTFkNGMxZGEyZWEwOGQ1MWI1ZDZiNzElN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTAN Cj4gNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjQ0NTAxMDQzNzgzNzQwNCZzZGF0YT1yYW5rNlNt Ym1xJTJCUXMNCj4gR3BWSjFxc2NZbiUyRjNTQTBrcnFLRFBRQjVHU3htMVElM0QmcmVzZXJ2ZWQ9 MCIvPg0KPiANCg0K From nobody Wed Oct 25 13:39:26 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0949139B9F; Wed, 25 Oct 2017 13:39:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mile@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150896396487.4711.3564728519347842551@ietfa.amsl.com> Date: Wed, 25 Oct 2017 13:39:24 -0700 Archived-At: Subject: [mile] I-D Action: draft-ietf-mile-rolie-12.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 20:39:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Managed Incident Lightweight Exchange WG of the IETF. Title : Resource-Oriented Lightweight Information Exchange Authors : John P. Field Stephen A. Banghart David Waltermire Filename : draft-ietf-mile-rolie-12.txt Pages : 46 Date : 2017-10-25 Abstract: This document defines a resource-oriented approach for security automation information publication, discovery, and sharing. Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources. Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on- demand information exchange network for restricted internal use or public access repositories. This specification extends the Atom Publishing Protocol and Atom Syndication Format to transport and share security automation resource representations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mile-rolie-12 https://datatracker.ietf.org/doc/html/draft-ietf-mile-rolie-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mile-rolie-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 Wed Oct 25 13:39:36 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD0A13A317; Wed, 25 Oct 2017 13:39:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , "Nancy Cam-Winget" X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150896396503.4711.1703125647816100730.idtracker@ietfa.amsl.com> Date: Wed, 25 Oct 2017 13:39:25 -0700 Archived-At: Subject: [mile] New Version Notification - draft-ietf-mile-rolie-12.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 20:39:25 -0000 A new version (-12) has been submitted for draft-ietf-mile-rolie: https://www.ietf.org/internet-drafts/draft-ietf-mile-rolie-12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-mile-rolie-12 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. IETF Secretariat. From nobody Wed Oct 25 14:44:05 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0711390EE for ; Wed, 25 Oct 2017 14:44:02 -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, 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 Mz7HbuSQsLGW for ; Wed, 25 Oct 2017 14:44: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 8231413A102 for ; Wed, 25 Oct 2017 14:44:00 -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 v9PLhqF1050600 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 25 Oct 2017 16:43:53 -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: "Banghart, Stephen A. (Fed)" Cc: "ncamwing@cisco.com" , "mile-chairs@tools.ietf.org" , "mile@ietf.org" , The IESG , "mile-chairs@ietf.org" , "draft-ietf-mile-rolie@ietf.org" References: <150890423788.4689.5942012074290459252.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Wed, 25 Oct 2017 16:43:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: [mile] Adam Roach's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 21:44:03 -0000 Based on the example you gave Martin ("I'd like to give a tool 'www.microsoft.com'..."), it sounds like you're not looking for *discoverability* as much as you are *guessability*. Is that an accurate characterization? /a On 10/25/17 3:35 PM, Banghart, Stephen A. (Fed) wrote: > Adam, > > Thanks for the review. I've put my comments/changes inline. > > Thanks, > Stephen > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Wednesday, October 25, 2017 12:04 AM >> To: The IESG >> Cc: draft-ietf-mile-rolie@ietf.org; mile@ietf.org; mile-chairs@tools.ietf.org; >> Nancy Cam-Winget ; mile-chairs@ietf.org; >> ncamwing@cisco.com; mile@ietf.org >> Subject: Adam Roach's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and >> COMMENT) >> >> Adam Roach has entered the following ballot position for >> draft-ietf-mile-rolie-11: 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i >> etf.org%2Fiesg%2Fstatement%2Fdiscuss- >> criteria.html&data=02%7C01%7Cstephen.banghart%40nist.gov%7C08456d09f >> a1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7 >> C0%7C636445010437837404&sdata=YCi7gTAwFZDvxiwzV66Iuhnx73ziHe8GJ6J >> MJneINjc%3D&reserved=0 >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr >> acker.ietf.org%2Fdoc%2Fdraft-ietf-mile- >> rolie%2F&data=02%7C01%7Cstephen.banghart%40nist.gov%7C08456d09fa1d >> 4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0 >> %7C636445010437837404&sdata=T%2FiVFaPIorBa3igDpRk87MM%2Bl1sw1hA >> rBEhqmqqjVjI%3D&reserved=0 >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I agree with Ben, Martin, and Mark: the way this document uses /.well- >> known/ URIs is not consistent with RFC5785, section 1.1. It should be >> understood that /.well-known/ URLs are already a carve-out from overall >> REST principles regarding the agency of content publishers to assign URLs >> within their domain as they see fit; and, as such, need non-trivial justification >> for their use. >> >> If there were some fully-defined autodiscovery mechanism that were >> (non-artificially) constrained in such a way that only a host and port were >> available, then the use of /.well-known/ URIs would be more >> understandable. The only constraint hinted at in this document that might >> have these properties is the use of DNS SRV records. Given that ROLIE is >> defining a green-field protocol, the use of something as constrained as SRV >> seems ill-advised, given that the use of NAPTR records would trivially allow >> retrieval of a complete URL instead of just a host/port combination. >> >> The bottom line, however, is that we need to defer specification of a /.well- >> known/ URL until we completely define a discovery protocol that requires it. >> The corollary is that we should avoid defining a discovery protocol that >> requires it. >> > I replied to Martin's concern on this issue in an earlier e-mail and I think we've reached agreement on the justification for the well-known registration (https://mailarchive.ietf.org/arch/msg/mile/gbG5nC8Oh4q76P-0dXHwM-ztMPY) > > We believe that we have a minimal use case/discovery story where ROLIE clients only have the host name and port for a potential ROLIE server, and need a standardized way to check/locate the metadata of an associated ROLIE repository. In these cases automated systems need a means to locate a ROLIE repository without a human needing to track down a link through browsing the site, email, etc. Providing a URL template for the Service Document allows these automated systems to find the head of the ROLIE repository, from there it can browse the rest of the Collections/Entries present. > > We've added additional text to the section in order to provide more justification/reasoning around our well-known registration. I've provided the new paragraph here: > > "ROLIE repositories are largely intended to be consumed by automated systems. While humans may be able to navigate a web page or receive an email to find a link to the repository, automated systems struggle with such tasks. By creating a standardized location for the Service Document, ROLIE clients need only a host name and port in order to locate a ROLIE repository. This lower barrier to entry reduces the amount of human intervention required for ROLIE clients to begin reading Feeds." > > We discussed this within the MILE WG and the WG agreed to define the .well-known approach, but to defer on a specific means to determine the host and port of the server at this time. This will allow the group to get some implementation experience with ROLIE, while reviewing the SRV and NAPTR record approaches to determine what the best approach is. We can then write another draft that provides these details when we are ready. In any case, we still need a way to discover the Service Document, so the WG found it to be prudent to do that now. > > Following Martin's comments, we removed the well-known registration for the Category Document, as this is discoverable from the Service Document. > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Since ROLIE requires the use of TLS client certificates, all of its resources need >> to be conveyed over HTTPS (i.e., ROLIE resources can never use "http" IRI >> schemes, only "https" IRI schemes). The following examples need to be fixed >> to reflect this: > Thanks for catching this. The links have been changed to https. > >> Section 6.1.2: >> >> > href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F >> example.org%2FfeedA%3Fpage%3D5&data=02%7C01%7Cstephen.banghart >> %40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797 >> a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=N2XIUWecIr% >> 2BoEHnBSTVZS0X2BZRBdpR3N%2BWHYC3UZI4%3D&reserved=0"/> >> > href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F >> example.org%2FfeedA%3Fpage%3D1&data=02%7C01%7Cstephen.banghart >> %40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797 >> a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=r2w32N%2B8F >> JYWnVIObX%2BLWSuyCyLV%2BHAEQlKRAEBkAo0%3D&reserved=0"/> >> > href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F >> example.org%2FfeedA%3Fpage%3D4&data=02%7C01%7Cstephen.banghart >> %40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797 >> a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=QhEYN4Z%2F >> %2B8neikPNwJGL%2BGtoEU0gBrVlQbanXnaQrgQ%3D&reserved=0"/> >> > href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F >> example.org%2FfeedA%3Fpage%3D6&data=02%7C01%7Cstephen.banghart >> %40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797 >> a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=pEJKm1Zuyj6S >> dDUkUkCrQURq5KzMmawwTISZSWd3%2B3o%3D&reserved=0"/> >> > href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F >> example.org%2FfeedA%3Fpage%3D10&data=02%7C01%7Cstephen.banghar >> t%40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797 >> a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=mH77rw1TlsX >> 8JuOY3EHJyOEpEzGPcokuxgiT%2F32%2FlkY%3D&reserved=0"/> >> >> Section B.1: >> >> > href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F >> example.org%2Fprovider%2Fvulns&data=02%7C01%7Cstephen.banghart%4 >> 0nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797a93 >> e054655c61dec%7C1%7C0%7C636445010437837404&sdata=SHNoV3KOd9BxB >> ngCKAmpnKwx9AqfWBTdZTTevIZFMcw%3D&reserved=0"> >> ... >> > >> href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F >> example.org%2Fprovider%2Fpublic%2Fvulns&data=02%7C01%7Cstephen.ba >> nghart%40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8f >> a4797a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=Bt2SOn0 >> bseMv9ZE3dxkm5%2FtqFJosQKE1XC4OpRfkHZw%3D&reserved=0"> >> ... >> > >> href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F >> example.org%2Fprovider%2Fprivate%2Fincidents&data=02%7C01%7Cstephe >> n.banghart%40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d8 >> 2fd8fa4797a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=TX >> NY424A3JuHjqMlPoRfZmVTlwRq0%2FGSeWFIPgblPe0%3D&reserved=0"> >> ... >> > >> href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F >> example.org%2Fprovider%2Fpublic%2Fvulns&data=02%7C01%7Cstephen.ba >> nghart%40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8f >> a4797a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=Bt2SOn0 >> bseMv9ZE3dxkm5%2FtqFJosQKE1XC4OpRfkHZw%3D&reserved=0" /> >> > >> href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F >> example.org%2Frolie%2Fservicedocument&data=02%7C01%7Cstephen.bang >> hart%40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4 >> 797a93e054655c61dec%7C1%7C0%7C636445010437837404&sdata=zoDLn699V >> T%2FlqiYzauR1ItbKSiIq%2FbhwUzwhMt7u5oI%3D&reserved=0"/> >> ... >> > >> src="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw >> ww.example.org%2Fprovider%2Fvulns%2F123456%2Fdata&data=02%7C01% >> 7Cstephen.banghart%40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71% >> 7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636445010437837404& >> sdata=hDThkxcmP30XYHMeD58AaT9kJsNo51L97NTAnVTnUPs%3D&reserved >> =0"/> >> ... >> > >> src="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw >> ww.example.org%2Fprovider%2Fvulns%2F123456%2Fdata&data=02%7C01% >> 7Cstephen.banghart%40nist.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71% >> 7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636445010437837404& >> sdata=hDThkxcmP30XYHMeD58AaT9kJsNo51L97NTAnVTnUPs%3D&reserved >> =0"> >> >> ------------------------------------------------------------ >> >> Additionally, the following href values (also in B.1) are illegal, and need to >> contain a scheme (presumably, https): > Also fixed. > >> > >> href="https://na01.safelinks.protection.outlook.com/?url=www.example.co >> m%2Frolie%2Fservicedocument&data=02%7C01%7Cstephen.banghart%40ni >> st.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797a93e0 >> 54655c61dec%7C1%7C0%7C636445010437837404&sdata=rank6Smbmq%2BQs >> GpVJ1qscYn%2F3SA0krqKDPQB5GSxm1Q%3D&reserved=0"/> >> ... >> > >> href="https://na01.safelinks.protection.outlook.com/?url=www.example.co >> m%2Frolie%2Fservicedocument&data=02%7C01%7Cstephen.banghart%40ni >> st.gov%7C08456d09fa1d4c1da2ea08d51b5d6b71%7C2ab5d82fd8fa4797a93e0 >> 54655c61dec%7C1%7C0%7C636445010437837404&sdata=rank6Smbmq%2BQs >> GpVJ1qscYn%2F3SA0krqKDPQB5GSxm1Q%3D&reserved=0"/> >> From nobody Wed Oct 25 20:35:13 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3006138F47; Wed, 25 Oct 2017 20:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4RUC53VY1xx; Wed, 25 Oct 2017 20:35:09 -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 F0CAB1387BC; Wed, 25 Oct 2017 20:35:08 -0700 (PDT) Received: from [10.0.1.82] (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 v9Q3Z78T014156 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 25 Oct 2017 22:35:08 -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.82] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_85938596-5412-4EB5-8970-865A45A4A32C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Date: Wed, 25 Oct 2017 22:35:06 -0500 In-Reply-To: Cc: "ncamwing@cisco.com" , "mile-chairs@tools.ietf.org" , "mile@ietf.org" , The IESG , "mile-chairs@ietf.org" , "draft-ietf-mile-rolie@ietf.org" To: "Banghart, Stephen A. (Fed)" References: <150889744468.4711.7690332098961761471.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [mile] Ben Campbell's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 03:35:11 -0000 --Apple-Mail=_85938596-5412-4EB5-8970-865A45A4A32C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the response. Comments also inline: > On Oct 25, 2017, at 3:10 PM, Banghart, Stephen A. (Fed) = wrote: >=20 > Ben, >=20 > Thanks for the review, I've put my comments/changes inline. >=20 > Thanks, > Stephen >=20 >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Tuesday, October 24, 2017 10:11 PM >> To: The IESG >> Cc: draft-ietf-mile-rolie@ietf.org; mile@ietf.org; = mile-chairs@tools.ietf.org; >> Nancy Cam-Winget ; mile-chairs@ietf.org; >> ncamwing@cisco.com; mile@ietf.org >> Subject: Ben Campbell's Discuss on draft-ietf-mile-rolie-11: (with = DISCUSS >> and COMMENT) >>=20 [=E2=80=A6] >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> -5.1.3: >>=20 >> I don't think Martin's ART-ART review concern (and Mark's support) = about >> the .well-known URL registration has been fully resolved. While = version 11 >> removed some of the well-known registrations, it still leaves the = one. Mark >> pointed out that RFC 5785 offers explicit guidance that .well-known = URLs are >> intended to offer site-wide policy or metadata, and are not intended = for >> general information retrieval, or to establish a namespace. This = usage seems >> to me to be exactly the sort of thing that the RFC advises against. >>=20 >> I recognize that security information is important, but I don't = understand why >> it's discovery needs to be fundamentally different than for other = stuff on >> using ATOM. I'm willing to be convinced, but if there's been a = convincing >> argument so far I've missed it. >=20 > I replied to Martin's concern on this issue in an earlier e-mail and I = think we've reached agreement on the justification for the well-known = registration = (https://mailarchive.ietf.org/arch/msg/mile/gbG5nC8Oh4q76P-0dXHwM-ztMPY) >=20 > ROLIE is largely intended to be handled by automated systems that = cannot reliably locate links given by front-facing sites. In these = cases, the ROLIE clients need a reliable way of finding a ROLIE = repository hosted by a given server. The well-known registration = provides a standardized place for the head of the ROLIE repository to be = retrieved, making it possible for an automated system to function when = only given a host name and port. >=20 > We've added the following additional justification text to the = specification to help clarify our reasoning. >=20 > "ROLIE repositories are largely intended to be consumed by automated = systems. While humans may be able to navigate a web page or receive an = email to find a link to the repository, automated systems struggle with = such tasks. By creating a standardized location for the Service = Document, ROLIE clients need only a host name and port in order to = locate a ROLIE repository. This lower barrier to entry reduces the = amount of human intervention required for ROLIE clients to begin reading = Feeds.=E2=80=9D It=E2=80=99s not clear to me why its substantially easier to learn name = and port than it is to learn a URL. As Adam pointed out in his separate = DISCUSS, there=E2=80=99s no discovery mechanism (yet) for the hostname = and port=E2=80=94that is, someone will have to tell that automated = system what name and port to use. Adam also pointed out that there are = potential design paths (e.g. NAPTR) for discovery mechanisms that would = give you a URL. .well-known URLs are intended for when no other discovery mechanisms = make sense. >=20 > We've dropped the well-known registration for the Category Document, = as it is locatable from the Service Document where applicable. >=20 >> I'm not sure what to make of the second paragraph. It says DNS SRV = can be >> used to determine the host and port. Is the expectation that people = can just >> do that without further specification, or that someone could specify = it in the >> future? >> The former is generally not true. If the intent is the latter, please = clarify that >> in the text. >=20 > The intent was the latter. I've changed the end of that paragraph to = further clarify as follows: >=20 > "Use of a mechanism such as DNS SRV Records can provide a secure and = reliable discovery mechanism for determining a specific host and port to = use for retrieving a Service Document for a given DNS domain. This is a = feature that may be standardized in the future.=E2=80=9D That would resolve my concern. >=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Substantive: >>=20 >> -2: There are a number of lower case versions of 2119 keywords. If = those are >> intentional, please use the updated boilerplate from RFC 8174. That = being >> said, the following paragraph says the keywords are used for = conformance. >> 2219/8174 keywords are not about conformance. They are about >> interoperability. If you want to use them for conformance, that's = okay--but >> that means they are no longer being used as intended by 2119, and the >> boilerplate should be adjusted accordingly. >=20 > The lower case keywords are intentional. We've switched the = boilerplate text to the updated 8174 version. Okay. >=20 >> -3.2: I'm confused by the idea the schema is informative. I expect = that at >> least some implementors will implement to the schema. We have a >> perennial problem where implementors implement the examples rather >> than the text. It seems like a non-normative schema is even more of = an >> attractive hazard in that regard. >=20 > We found that available schema languages cannot express the same = complexities we could express in text. There are difficult conditional = requirements that are poorly expressed in schemas but can be fit into a = neat sentence. In order to support the places where we do that, we = decided that making the text normative was the only way to ensure that = the requirements were expressed clearly. >=20 > Additionally, Atom Syndication and the Atom Publishing Protocol both = specify that the text is normative, not the included schemas. By making = the schema informative, we are keeping with this practice. Do you believe an implementer could reasonably code this just from the = text without looking at the schema? The problem of needing additional constraints over what can be expressed = in a formal language, whether that=E2=80=99s a schema, ABNF, etc, is = common. It=E2=80=99s typical to still consider the normative definition = to include both the formal definition and those additional constraints. >=20 >> -5.4, 2nd paragraph: This seems like an odd thing to state = normatively. It >> seems to push for a specific organizational model for consortiums. = It's >> reasonable to offer guidance, but I think consortiums are going to do >> whatever they want here. >=20 > Reworded this paragraph into a non-normative recommendation. Okay. >=20 >> -8.3: What is the registration policy for the top level registry? >=20 > There was some misleading text that discussed a registry that we = didn't intend to be created. We've fixed the text to make it clear that = there is only one registry being defined (ROLIE URN Parameters) in this = section. The updated text is provided here: >=20 > "A new top-level registry has been created, entitled "Resource = Oriented Lightweight Information Exchange (ROLIE) URN Parameters". [TO = BE REMOVED: This registration should take place at the following = location: https://www.iana.org/assignments/rolie] >=20 > Registration in the ROLIE URN Parameters registry is via the = Specification Required policy . Designated Expert reviews should be = routed through the MILE WG mailing list. Failing this, the Designated = Expert will be assigned by the IESG.=E2=80=9D >=20 Okay, that works for moe. >> -10: "Overall, ROLIE introduces few privacy concerns above and = beyond >> those >> present in any other HTTP protocol. " I'm skeptical that that is = true. Security >> information seems likely to be privacy sensitive, especially compared = to >> some notional "generic" HTTP based protocol. >=20 > We've rewritten this last paragraph to provide more clear details = around privacy concerns in ROLIE. The updated text is provided here: >=20 > "Overall, privacy concerns in ROLIE can be mitigated by following = security considerations and careful use of the optional personally = identifying elements (e.g., author) provided by Atom Syndication and = ROLIE.=E2=80=9D Okay. [Your responses to my editorial comments all look good.] Thanks! Ben. --Apple-Mail=_85938596-5412-4EB5-8970-865A45A4A32C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlnxV+oACgkQgFZKbJXz 1A1k4RAAkFSy+CbrJ+PvknqoRl0LLd+DdN3aSGe1MpbSVBWvef5E0PlRsz5mhbU4 rRSbSNo1wFlKGG5m8RfwPAiRd05qDwyZSzQ369OperEEzJHp43/PGT17focNlZ3r k3jVBbpa6FE14NGA2n0fOwSJczxBA1xcSlDy1d1YK5cU1Q7HN4Gwh30T/B1ys0Fs /dwRwy2rcOsjRLqNPDi3pdv+QrEMqtcViDX48eu8vphpQAB4nySScrU1o2ZR4ONh fzd3nNfeFqEH4rQb0zSXZOAdvxMAma+UZZtuHPYJLez+SvBhkjphyWb80jsRb0cF 0z7Poc+/paR4RzxYURw3aGyFD0dYnKxK4IOTQuAw/GqUzb2ZN0JTqwLtDwWXrFqj eZTDmNHXZFbmFZmGABGROe0qEEoMxXiOb9CHxNlGlMzi3sYBMXJ8etLo3+FgxgkW 1tZUCjQbfr3Mxg8qheunj+Rd6LI3GcpuEZIVqqidc2IBnVR7jAgKi11of3SD+reF iFTkRxBgZAXO0AorRuRgWgJzYfb5fwD7X6UaptPWBR5UKIMxe+K5AkPKR3bsgXZC ZeGmLmAlKyE4EvDhAp2XFbJivWqtLkv4yoP1hMgLxGQ2QD39jMJOKYBmOEnDEsej gbcdc6PXWSG+odWpuRJj4b3O8lggQILmMIWrDyH9m29gDn5R1ig= =cDz7 -----END PGP SIGNATURE----- --Apple-Mail=_85938596-5412-4EB5-8970-865A45A4A32C-- From nobody Thu Oct 26 04:15:17 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0FA13F574; Thu, 26 Oct 2017 04:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 bXetvIgr0z7y; Thu, 26 Oct 2017 04:15:15 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 6223D13F571; Thu, 26 Oct 2017 04:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1509016496; d=isode.com; s=june2016; i=@isode.com; bh=u8/dkdgJNn0WKXzYqZ/Oen1ZipNbOT5gWP8EhAyKQBQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=dJHsu/E6LCUkm1l52RCHso4MoRCAQBU6x1rHf3obEdLNE/qrstiYXf4sakskBnLwr24rnU tNK/dWtebV/2hPdMGzFX0k4fSSfRapWkl08SCX09o2gPYyojxMSZHbs4/oc+ImlpY4jyvg ZebGQErYTPCpAuJoEvC4g/PcRGRbKpU=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 26 Oct 2017 12:14:56 +0100 To: Peter Saint-Andre , "Waltermire, David A. (Fed)" , "art-ads@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" , "mile@ietf.org" References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <2114e084-bb7e-4d26-f3df-0ca30e3bc882@stpeter.im> From: Alexey Melnikov Message-ID: <319205e4-846c-3243-722e-e0e8922f827f@isode.com> Date: Thu, 26 Oct 2017 12:14:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: <2114e084-bb7e-4d26-f3df-0ca30e3bc882@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 11:15:16 -0000 On 23/10/2017 20:09, Peter Saint-Andre wrote: > On 10/23/17 12:33 PM, Waltermire, David A. (Fed) wrote: >> Ben, Alexey, and Adam, >> >> Working through Martin's ARTART review of ROLIE, we had the following exchange with Martin. >> >>>>> From martin: >>>>> Question: it's fairly widely accepted that use of IRIs in Atom has >>>>> been less than successful. Do you want to mandate use of URIs >>>>> instead? This would apply to both link relations and the "src" attribute. >>>> From Stephen: >>>> We wanted to stay in line with the requirements in Atom, if this becomes >>> an issue it may be worth re-examining. >>> >>> From Martin: >>> This is your chance. You don't get to go back or re-examine once your >>> protocol is widely deployed. >> I understand Martin's point above. It is basically that URIs are more narrowly scoped and interoperable than IRIs are. From my experience I have seen that URIs are broadly used, and IRIs have not seen much use. Given this feedback, it looks like the best thing to do might be to break with ATOM and use the more restrictive URI in ROLIE to ensure the best possible interoperability within resulting solutions. >> >> What do you think about such a change? Any advice? > The Atom RFCs were published at a time when IRIs were at the height of > their (limited) popularity. Although I don't recall the details, it > might even have been the case that an Area Director said "you really > ought to be using IRIs because they are more general". I don't see a > significant issue with scoping MILE/ROLIE to use URIs, because they are > a subset of IRIs. +1. From nobody Thu Oct 26 04:15:23 2017 Return-Path: X-Original-To: expand-draft-ietf-mile-rolie.all@virtual.ietf.org Delivered-To: mile@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 50AF813F571; Thu, 26 Oct 2017 04:15:16 -0700 (PDT) X-Original-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mile-rolie.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0FA13F574; Thu, 26 Oct 2017 04:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 bXetvIgr0z7y; Thu, 26 Oct 2017 04:15:15 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 6223D13F571; Thu, 26 Oct 2017 04:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1509016496; d=isode.com; s=june2016; i=@isode.com; bh=u8/dkdgJNn0WKXzYqZ/Oen1ZipNbOT5gWP8EhAyKQBQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=dJHsu/E6LCUkm1l52RCHso4MoRCAQBU6x1rHf3obEdLNE/qrstiYXf4sakskBnLwr24rnU tNK/dWtebV/2hPdMGzFX0k4fSSfRapWkl08SCX09o2gPYyojxMSZHbs4/oc+ImlpY4jyvg ZebGQErYTPCpAuJoEvC4g/PcRGRbKpU=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 26 Oct 2017 12:14:56 +0100 To: Peter Saint-Andre , "Waltermire, David A. (Fed)" , "art-ads@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" , "mile@ietf.org" References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <2114e084-bb7e-4d26-f3df-0ca30e3bc882@stpeter.im> From: Alexey Melnikov Message-ID: <319205e4-846c-3243-722e-e0e8922f827f@isode.com> Date: Thu, 26 Oct 2017 12:14:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: <2114e084-bb7e-4d26-f3df-0ca30e3bc882@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Resent-From: Resent-To: jfield@pivotal.io, stephen.banghart@nist.gov, david.waltermire@nist.gov, ncamwing@cisco.com, takeshi_takahashi@nict.go.jp, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, mile-chairs@tools.ietf.org, mile@ietf.org, Nancy Cam-Winget Resent-Message-Id: <20171026111516.50AF813F571@ietfa.amsl.com> Resent-Date: Thu, 26 Oct 2017 04:15:16 -0700 (PDT) Archived-At: Subject: Re: [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 11:15:16 -0000 On 23/10/2017 20:09, Peter Saint-Andre wrote: > On 10/23/17 12:33 PM, Waltermire, David A. (Fed) wrote: >> Ben, Alexey, and Adam, >> >> Working through Martin's ARTART review of ROLIE, we had the following exchange with Martin. >> >>>>> From martin: >>>>> Question: it's fairly widely accepted that use of IRIs in Atom has >>>>> been less than successful. Do you want to mandate use of URIs >>>>> instead? This would apply to both link relations and the "src" attribute. >>>> From Stephen: >>>> We wanted to stay in line with the requirements in Atom, if this becomes >>> an issue it may be worth re-examining. >>> >>> From Martin: >>> This is your chance. You don't get to go back or re-examine once your >>> protocol is widely deployed. >> I understand Martin's point above. It is basically that URIs are more narrowly scoped and interoperable than IRIs are. From my experience I have seen that URIs are broadly used, and IRIs have not seen much use. Given this feedback, it looks like the best thing to do might be to break with ATOM and use the more restrictive URI in ROLIE to ensure the best possible interoperability within resulting solutions. >> >> What do you think about such a change? Any advice? > The Atom RFCs were published at a time when IRIs were at the height of > their (limited) popularity. Although I don't recall the details, it > might even have been the case that an Area Director said "you really > ought to be using IRIs because they are more general". I don't see a > significant issue with scoping MILE/ROLIE to use URIs, because they are > a subset of IRIs. +1. From nobody Thu Oct 26 04:36:41 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C524013AF23; Thu, 26 Oct 2017 04:36:39 -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-mile-rolie@ietf.org, mile@ietf.org, mile-chairs@tools.ietf.org, Nancy Cam-Winget , mile-chairs@ietf.org, ncamwing@cisco.com, mile@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150901779979.24032.748907899531480416.idtracker@ietfa.amsl.com> Date: Thu, 26 Oct 2017 04:36:39 -0700 Archived-At: Subject: [mile] Alexey Melnikov's Discuss on draft-ietf-mile-rolie-12: (with DISCUSS and COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 11:36:40 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-mile-rolie-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-mile-rolie/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a useful document and I will be balloting "Yes" once the following small issues are resolved/discussed (some of these come from Martin's ARTART review): 1) 7.4. The "rolie:property" Extension Point urn:ietf:params:rolie:property:content-id The "value" attribute of this property is a text representation of an identifier pertaining to or extracted from the content referenced by the "src" attribute of the entry's atom:content element. Maybe it is just me, but I can't figure out what is the syntax of this field. Can you provide a reference or at least give an example? 2) From Martin's review: Section 5.5 prohibits the use of GET on "/". This prohibits use of the resource for other purposes. It seems reasonable to accept POST messages as defined in RFC 6546, but this requirement is overly strict (and further entrenches the violation of RFC 7320). If, for instance, the server operator wishes to provide HTML in response to a GET request to "/", this would prohibit that. The requirement to return 404 if RFC 6546 is not supported is worse; not supporting RFC 6546 might be a choice that a deployment makes to avoid the need to reserve "/" for that protocol. Alexey: The text in -12 is an improvement, but I think it is still confusing. Maybe mention something along the lines of Martin's suggestion for the case when RFC 6546 is not supported (or at least not followed as far as the "/" resource is concerned). 5.5. / (forward slash) Resource URL If the "/" resource is unsupported, then a request for this resource MAY be handled as deemed appropriate by the server. Nit: You haven't expressed any requirement on implementations here, so use of MAY does not seem appropriate. What are you actually suggesting here? 3) I think some of the text in 6.1.2 is misleading (or I might be wrong): Based on RFC5005 section 3 [RFC5005], link elements SHOULD be included in all Feeds to support paging using the following link relation types: o "first" - Indicates that the href attribute value of the link identifies a resource URI for the furthest preceding page of the Feed. o "last" - Indicates that the href attribute value of the link identifies a resource URI for the furthest following page of the Feed. o "previous" - Indicates that the href attribute value of the link identifies a resource URI for the immediately preceding page of the Feed. o "next" - Indicates that the href attribute value of the link identifies a resource URI for the immediately following page of the Feed. Original definitions of these link relations don't include the word "page". I should double check with Mark Nottigham, but I think they reference the next/previous, first/last entry, not page. (And a page may contain several entries.) If I am correct, I don't think it is Ok to redefine meaning of existing link relations the way you do. 4) In Section 8.3: Registration in the ROLIE URN Parameters registry is via the Specification Required policy [RFC8126]. Designated Expert reviews should be routed through the MILE WG mailing list. Failing this, the Designated Expert will be assigned by the IESG. As other people already pointed out, the last 2 sentences are confusing. Are you trying to say that registration requests must be sent to the MILE mailing list or that they must be reviewed there? This is actually significant for IANA workflow. One possibility is that all requests are sent to the MILE mailing list and then the designated expert forwards approved requests to IANA. In this case if a Designated Expert misses a request, IANA wouldn't even know that the requester is waiting for the Designated Expert. Another possibility is for all requests to be submitted to IANA directly, then IANA can track them. IANA might either forward requests to the MILE mailing list or require that all request being submitted to the MILE mailing list first before being sent to IANA. So please clarify. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Recommending use of .well-known was my fault. I am looking forward to further discussion of this issue. I think the document needs some form of service discovery (and lack of DNS SRV details is a pity) and discovery of root entry for ROLIE. So I think some form of .well-known is probably needed. I am glad you got rid of IRIs. That was one of my discussion points on -11. I am still concerned that user authentication is under-specified, but I can live with existing text. 6.2.1. Use of the "atom:content" Element This restricts atomContent in ROLIE to the atomOutofLine forumulation presented in[RFC4287]. Typo: formulation In 6.2.3. Use of the "rolie:format" Element The rolie:format element MAY provide a "schema-type" attribute, which is a mime type identifying the format of the schema resource "mime type" should be either "MIME type" or "media type". The latter is the preferred term these days. You also need a normative reference to media types, at least to RFC 2045. identified by the "schema-location" attribute. The following nominal example shows how these attributes describe the format of the content: I think you meant "schema-type=" (note you have "-" instead of "="). In 6.2.3 (on page 17) The URI used for the "ns" attribute value MUST be an absolute or opaque URI. What is "opaque" URI? The sentence make it sound as if it is a term, opposite to absolute URI. Or are you trying to say that non resolvable URNs are Ok here? I suggest deleting "or opaque" from the above sentence or replacing it with something clearer. In 6.2.4. Use of the rolie:property Element Implementations MAY use locally defined and namespaced elements in an Entry in order to provide additional information. Clients that do not recognize a property with an unregistered name attribute MAY ignore the rolie:property. The second "MAY": or do what? Should the MAY be changed to a MUST? From nobody Thu Oct 26 07:53:40 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3C213F5A2; Thu, 26 Oct 2017 07:53:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=nistgov.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 Y8-KIdmUmR52; Thu, 26 Oct 2017 07:53:28 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0133.outbound.protection.outlook.com [23.103.200.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3605E13F5B8; Thu, 26 Oct 2017 07:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ng9+ATgprX2koTLd2ExGUYo4JQCkgad/hhOFd0QW46E=; b=lMMRSsrnosHoNBTIacVJVcOwoZkagJq7zxvSLuq/TbmH9ju3jcsq8IddwQkcT6fbLJjyQVp8CdbYBytq6nywy2hgQFl5mGSUsaQGdjHmOhAs+GKqt2nbtt8mG/EuJFWhCAJu1g1WbI044B+9As4+VrULY0cqbFhwWamZ+xjG6Gg= Received: from MWHPR09MB1197.namprd09.prod.outlook.com (10.172.49.143) by MWHPR09MB1200.namprd09.prod.outlook.com (10.172.49.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Thu, 26 Oct 2017 14:53:21 +0000 Received: from MWHPR09MB1197.namprd09.prod.outlook.com ([10.172.49.143]) by MWHPR09MB1197.namprd09.prod.outlook.com ([10.172.49.143]) with mapi id 15.20.0178.007; Thu, 26 Oct 2017 14:53:21 +0000 From: "Banghart, Stephen A. (Fed)" To: Alexey Melnikov , The IESG CC: "draft-ietf-mile-rolie@ietf.org" , "mile@ietf.org" , "mile-chairs@ietf.org" , "mile-chairs@tools.ietf.org" Thread-Topic: [mile] Alexey Melnikov's Discuss on draft-ietf-mile-rolie-12: (with DISCUSS and COMMENT) Thread-Index: AQHTTk67TVClY4fT2Uypi26HgjU1DaL2I2Hg Date: Thu, 26 Oct 2017 14:53:21 +0000 Message-ID: References: <150901779979.24032.748907899531480416.idtracker@ietfa.amsl.com> In-Reply-To: <150901779979.24032.748907899531480416.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.251.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR09MB1200; 6:gnRcNni05xJ/YjUbFJDLRhHD0TGoJE/jtRtdtAvfC4fe4RHD1vxwaeQXkHcSBx+3VniFwnNl8JWqRj1nd+q+SLp/7ASPUpCkHaeMZc/kv8hVEDWgTuN52L6Je6jeDyeXGHj54O2B9qJOnZr2f2YbOTBKcMOySmkD8yf5iT/dp6T+tA9KYtfdjcwcKlaAWWPrJlAqoQ4rWTBOy9erEs6wYXScfzwNP/7M8cZkti0R7Sh0v7tv8y/Sn1bIKoKokjtdiZ9L8hAiHjE+OJwJBB+A7Aujt16OHVE5OCZdWAF+c/8pD1m4jdkSsYq1RPGh665rdRvUGFIMBfFLBXFm09HjNp5dm6vBQ+kI+4qLuJyWb7o=; 5:4pCThHB7i1fP356JDKDWu7SOkm6T9ySoYwp5hoG9A67YRCFpnqNThe2WnNeg0Z08g3Cw8PnMps1Qz06tM9HoyqoNgrxTJIeQaIYX1Rsx+ebiFK1bDQ2RShqjgC9OeRfcqqz8rbWE9nIvOOScVsNy9yziXlhmXFRXTfKDgo5Zc7g=; 24:oz8YzhqIGeGnHI9uvJcwQ2AY7fY5ElQARugiKYluwU4g5KP9y6jfc2J9noLJ60Ay3Scqk9S+vj3AXLXWddrh703zzDdOXgqRo0Q81WGq5m8=; 7:ZmdsS7vZigzFY/2qG9sKGmDjWpgCKUCK+o9KWhGkCLh4KDhrMUJpmD1GJhxYn4NqQmRtp0H0rlyYj01lAcXJ4BL5Q5TZqOX0Od/hYiPaegJAp18EzZiNJ5mQ6e3x1tZVZMMlLb/OBIBwd02Fcg/ErbpExLpDlysx6FKfrBGoo922JXMmuruTuTKz/AyYiGaQB7TLuXptCQqO4NDhp5lQzkiH4M/xr2k3YKeHFi6sEwmIgDr05tok0GlKpSzuaKra x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 29f154e9-8e98-499d-6b37-08d51c814d46 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:MWHPR09MB1200; x-ms-traffictypediagnostic: MWHPR09MB1200: x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(131327999870524)(219752817060721)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231020)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR09MB1200; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR09MB1200; x-forefront-prvs: 04724A515E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(189002)(51914003)(13464003)(51444003)(199003)(966005)(81156014)(74316002)(189998001)(8676002)(99286003)(81166006)(6246003)(8666007)(55016002)(230783001)(5660300001)(6506006)(106356001)(77096006)(2906002)(478600001)(25786009)(97736004)(53936002)(305945005)(9686003)(7736002)(6306002)(45080400002)(86362001)(8936002)(4326008)(105586002)(68736007)(3660700001)(3280700002)(2950100002)(2900100001)(6116002)(54356999)(50986999)(3846002)(316002)(229853002)(76176999)(575784001)(7696004)(54906003)(14454004)(110136005)(101416001)(6436002)(66066001)(53546010)(554214002)(33656002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1200; H:MWHPR09MB1197.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 29f154e9-8e98-499d-6b37-08d51c814d46 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 14:53:21.3268 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1200 Archived-At: Subject: Re: [mile] Alexey Melnikov's Discuss on draft-ietf-mile-rolie-12: (with DISCUSS and COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 14:53:32 -0000 Alexey, Thanks for the review, comments inline. Thanks, Stephen Banghart > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Alexey Melnikov > Sent: Thursday, October 26, 2017 7:37 AM > To: The IESG > Cc: draft-ietf-mile-rolie@ietf.org; mile@ietf.org; mile-chairs@ietf.org; = mile- > chairs@tools.ietf.org > Subject: [mile] Alexey Melnikov's Discuss on draft-ietf-mile-rolie-12: (w= ith > DISCUSS and COMMENT) >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-mile-rolie-12: Discuss >=20 [snip] >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This is a useful document and I will be balloting "Yes" once the followin= g small > issues are resolved/discussed (some of these come from Martin's ARTART > review): >=20 > 1) 7.4. The "rolie:property" Extension Point >=20 > urn:ietf:params:rolie:property:content-id The "value" attribute of > this property is a text representation of an identifier pertaining > to or extracted from the content referenced by the "src" attribute > of the entry's atom:content element. >=20 > Maybe it is just me, but I can't figure out what is the syntax of this fi= eld. > Can you provide a reference or at least give an example? Sure. This field is exposing some identifier for the resource in the atom:c= ontent element. For example, if the atom:content is linking to an IODEF doc= ument, the only way (without this property) for a consumer to learn any ide= ntifying information about that document is to download it.=20 For the sake of example, lets say that inside that IODEF document is a ID= =3D"ID12345" element. In the ROLIE feed, the rolie:property element exposes= the ID, so then the rolie:property field would be "name"=3D "urn:ietf:para= ms:rolie:property:content-id" and value=3D"ID12345". If this still seems confusing we can rewrite the text in the specification = or include an example to clarify. > 2) From Martin's review: >=20 > Section 5.5 prohibits the use of GET on "/". This prohibits use of the r= esource > for other purposes. It seems reasonable to accept POST messages as > defined in RFC 6546, but this requirement is overly strict (and further > entrenches the violation of RFC 7320). If, for instance, the server oper= ator > wishes to provide HTML in response to a GET request to "/", this would > prohibit that. The requirement to return 404 if RFC 6546 is not supporte= d is > worse; not supporting RFC 6546 might be a choice that a deployment makes > to avoid the need to reserve "/" for that protocol. >=20 > Alexey: The text in -12 is an improvement, but I think it is still confus= ing. > Maybe mention something along the lines of Martin's suggestion for the ca= se > when RFC 6546 is not supported (or at least not followed as far as the "/= " > resource is concerned). >=20 > 5.5. / (forward slash) Resource URL >=20 > If the "/" resource is unsupported, then a request for this resource > MAY be handled as deemed appropriate by the server. >=20 > Nit: You haven't expressed any requirement on implementations here, so > use of MAY does not seem appropriate. What are you actually suggesting > here? This last sentence was meant to be addressing the case where RFC 6546 is no= t supported. I've removed the normative requirement and updated the sentenc= e: "If RFC 6546 is unsupported, then a request for the "/" resource may be han= dled as deemed appropriate by the server." And to help clarify I have added this sentence to the first paragraph: "The following requirements apply only to implementations supporting RFC 65= 46." Does this address your concerns? I'd like to fully address Martin's origina= l comments, as I agree that restricting the "/" resource on all servers is = detrimental. > 3) I think some of the text in 6.1.2 is misleading (or I might be wrong): >=20 > Based on RFC5005 section 3 [RFC5005], link > elements SHOULD be included in all Feeds to support paging using the > following link relation types: >=20 > o "first" - Indicates that the href attribute value of the link > identifies a resource URI for the furthest preceding page of the > Feed. >=20 > o "last" - Indicates that the href attribute value of the link > identifies a resource URI for the furthest following page of the > Feed. >=20 > o "previous" - Indicates that the href attribute value of the link > identifies a resource URI for the immediately preceding page of > the Feed. >=20 > o "next" - Indicates that the href attribute value of the link > identifies a resource URI for the immediately following page of > the Feed. >=20 > Original definitions of these link relations don't include the word "page= ". I > should double check with Mark Nottigham, but I think they reference the > next/previous, first/last entry, not page. (And a page may contain severa= l > entries.) If I am correct, I don't think it is Ok to redefine meaning of = existing > link relations the way you do. Section 3 ("Paged Feeds") in RFC 5005 defines paged feeds as a set of linke= d feed documents, where each feed document contains a subset of entries. Th= e explicit wording used in the link relations is as follows: o "first" - A URI that refers to the furthest preceding document in a series of documents. o "last" - A URI that refers to the furthest following document in a series of documents. o "previous" - A URI that refers to the immediately preceding document in a series of documents. o "next" - A URI that refers to the immediately following document in a series of documents. We've swapped in the word "page" instead of "document" in our document, as = we felt that "page" made more inherent sense without the context of the res= t of RFC 5005. I believe that we have not changed the definition of the lin= k relations in any way, so changing the wording back to the original would = not be a huge problem for us if you think it is needed. > 4) In Section 8.3: >=20 > Registration in the ROLIE URN Parameters registry is via the > Specification Required policy [RFC8126]. Designated Expert reviews > should be routed through the MILE WG mailing list. Failing this, the > Designated Expert will be assigned by the IESG. >=20 > As other people already pointed out, the last 2 sentences are confusing. > Are you trying to say that registration requests must be sent to the MILE > mailing list or that they must be reviewed there? This is actually signif= icant for > IANA workflow. >=20 > One possibility is that all requests are sent to the MILE mailing list an= d then > the designated expert forwards approved requests to IANA. In this case if= a > Designated Expert misses a request, IANA wouldn't even know that the > requester is waiting for the Designated Expert. >=20 > Another possibility is for all requests to be submitted to IANA directly,= then > IANA can track them. IANA might either forward requests to the MILE maili= ng > list or require that all request being submitted to the MILE mailing list= first > before being sent to IANA. >=20 > So please clarify. Our original intent here was to have IANA receive and track requests, then = send the requests to the MILE mailing list, and then if there is no respons= e, fall back to pre-named Designated Experts (the authors).=20 We are having trouble correctly putting together text to express this. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Recommending use of .well-known was my fault. I am looking forward to > further discussion of this issue. I think the document needs some form of > service discovery (and lack of DNS SRV details is a pity) and discovery o= f root > entry for ROLIE. So I think some form of .well-known is probably needed. >=20 > I am glad you got rid of IRIs. That was one of my discussion points on -1= 1. >=20 > I am still concerned that user authentication is under-specified, but I c= an live > with existing text. >=20 > 6.2.1. Use of the "atom:content" Element >=20 > This restricts atomContent in ROLIE to the atomOutofLine forumulation > presented in[RFC4287]. >=20 > Typo: formulation Fixed, thank you. > In 6.2.3. Use of the "rolie:format" Element >=20 > The rolie:format element MAY provide a "schema-type" attribute, which > is a mime type identifying the format of the schema resource >=20 > "mime type" should be either "MIME type" or "media type". The latter is t= he > preferred term these days. You also need a normative reference to media > types, at least to RFC 2045. Changed to media type, and reference added to RFC 2045. > identified by the "schema-location" attribute. >=20 > The following nominal example shows how these attributes describe the > format of the content: >=20 > version=3D"2.0" > schema-location=3D >=20 > "https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww > .iana.org%2Fassignments%2Fxml-registry%2Fschema%2Fiodef- > 2.0.xsd&data=3D02%7C01%7Cstephen.banghart%40nist.gov%7C5adedf178b8c4 > ef12b9d08d51c65d567%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7 > C636446146074444836&sdata=3DkKbwLXchAMCF8Gw%2FQUb8xfq5nClUocI30z > wO5lK3XWs%3D&reserved=3D0" > schema-type-"text/xml"/> >=20 > I think you meant "schema-type=3D" (note you have "-" instead of "=3D"). Fixed, thanks. > In 6.2.3 (on page 17) >=20 > The URI used for the "ns" attribute value MUST be an absolute > or opaque URI. >=20 > What is "opaque" URI? The sentence make it sound as if it is a term, oppo= site > to absolute URI. Or are you trying to say that non resolvable URNs are Ok > here? > I suggest deleting "or opaque" from the above sentence or replacing it wi= th > something clearer. I've deleted the "or opaque", as the intent was to disallow relative URIs. = I think that the current requirement followed by the last sentence of the p= aragraph (The resource identified by the URI need not be resolvable.) provi= de enough information. > In 6.2.4. Use of the rolie:property Element >=20 > Implementations MAY use locally defined and namespaced elements in an > Entry in order to provide additional information. Clients that do > not recognize a property with an unregistered name attribute MAY > ignore the rolie:property. >=20 > The second "MAY": or do what? Should the MAY be changed to a MUST? >=20 Yes, this was intended to be a MUST. The client MUST NOT fail parsing conte= nt that contains an unrecognized property. I changed the keyword to MUST an= d provided some additional text to clarify: "The client MUST NOT fail parsing content that contains an unrecognized property." > _______________________________________________ > mile mailing list > mile@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fmile&data=3D02%7C01%7Cstephen.banghar > t%40nist.gov%7C5adedf178b8c4ef12b9d08d51c65d567%7C2ab5d82fd8fa4797 > a93e054655c61dec%7C1%7C0%7C636446146074444836&sdata=3DkgE4ok9Q5Zz > %2B3suOnaPnESNVDonXUwYn0tQJKXm73i0%3D&reserved=3D0 From nobody Thu Oct 26 08:06:16 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C541389E1; Thu, 26 Oct 2017 08:06:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=nistgov.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 figPdEDVG2WB; Thu, 26 Oct 2017 08:06:06 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0131.outbound.protection.outlook.com [23.103.200.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABC013F5AC; Thu, 26 Oct 2017 08:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=d8ZM87fqp8sVuua3d6r3uwjjCatQ4jKodsSQ7UZbgxc=; b=B35e9Kl6C7MDYjQnViTxV0XNwiykgyHuVFgGafWQEexdUxYtPhB/zhRAjEwYPXOa/eTT5LMBIrxKB+DRn8rUbj2im1nJsZ4fRI6Msjmz1FbDt/6bEODuOk8+NoErtzgpGa5HemKcBRv8aQ2pNKUnRTwaXYHBa6xlLxi1MjmaXTk= Received: from MWHPR09MB1197.namprd09.prod.outlook.com (10.172.49.143) by MWHPR09MB1197.namprd09.prod.outlook.com (10.172.49.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Thu, 26 Oct 2017 15:06:02 +0000 Received: from MWHPR09MB1197.namprd09.prod.outlook.com ([10.172.49.143]) by MWHPR09MB1197.namprd09.prod.outlook.com ([10.172.49.143]) with mapi id 15.20.0178.007; Thu, 26 Oct 2017 15:06:02 +0000 From: "Banghart, Stephen A. (Fed)" To: Ben Campbell CC: "ncamwing@cisco.com" , "mile-chairs@tools.ietf.org" , "mile@ietf.org" , The IESG , "mile-chairs@ietf.org" , "draft-ietf-mile-rolie@ietf.org" Thread-Topic: Ben Campbell's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and COMMENT) Thread-Index: AQHTTTZ/ZRssFCkRtU+t66d26L/EEaL051UggACVEgCAAL2M4A== Date: Thu, 26 Oct 2017 15:06:02 +0000 Message-ID: References: <150889744468.4711.7690332098961761471.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.251.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR09MB1197; 6:vVEtVDUkFZ9T6d+ENHrQUqV6utVKetUOF2Z5m7HLZRTazZwT5uX+UWdPhvR8dDny0XB8hVxjJ1wvFEo1b9qe5bYPHhffDvNx+3dcQf6Tc4IA/yZF/1phHbgpHJWfOeGsBWJDe3ykml3Ssf2gGeNAuXWtRke8xj674bUl4JAasv9h7fRS3GbM/lMhSiWslkGalSdP//w1Tv5ESl+5eTZ3nR0zA2/eRYxC86PwG31PXvTY6GUIvYt6RgB8VPCQR8QUIgLiCPSqFNBvqtgsR03Sx3Nv7EWYE5gPyCMUeSuK0CRk/1tRlCEjTJ6QqgGIvPcf26RjCKg6JorxoY5AjZrxEG6FB/2lu1QAKI7fclqZEpQ=; 5:Eqse7FKmQpig3Lzd1Gt2efc68ykD0kjH44KTBhP0ksZJA09N7su0C2n+H3vrz6+YqndOXOP+/i4apO0B5EQZOk+RVF3wtJ0BLzRSX+zJ2w0vyQxMaItgg3MtAB7UEJMEgXBkjAHepPWVWk5kkxjZLjRzDseVacGuSHmyp9GLqQ0=; 24:rDn0PGO6zKz3ngpJA9D6idsTw0D3UWO887iXMaahSsX6+aAZFRRusCzWQWzKb1oCEQ5Fbz8Sv3nUoksdcAeVKyh7Z85EcTxuh4MwZBXYWFg=; 7:AbkHX1sqVxg6Oe83JvB/N5O1GOtYxmueQB/edRy1j0zo/BByxFiC1AfxSfLhjkCVEq6P4O1Ya6WBLC4hLMIv25bsOALvueodacPCj9GPrHwdVs+hTOe1SO5LwjIcDKpaQXo9rbiKAwbI8ab3pDUK5zsBRRZsp7A7zqHCwyE6zsGEi4sQX1te/FFahlD5R7/N739E0NqKdmEKv1+bjNfKPX/oSA80CdzmrPcI4JawwjtMtatNwMiKuLf9V6NZ7bMB x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 36425a48-e8e4-4c8c-b8d3-08d51c8312cb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603238); SRVR:MWHPR09MB1197; x-ms-traffictypediagnostic: MWHPR09MB1197: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(131327999870524)(150554046322364)(95692535739014)(1591387915157); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(3231020)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR09MB1197; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR09MB1197; x-forefront-prvs: 04724A515E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(3905003)(24454002)(199003)(189002)(13464003)(51914003)(3660700001)(54906003)(229853002)(189998001)(86362001)(6916009)(53936002)(2950100002)(316002)(14454004)(6246003)(230783001)(2900100001)(105586002)(478600001)(966005)(7696004)(45080400002)(76176999)(50986999)(54356999)(33656002)(5660300001)(106356001)(101416001)(74316002)(6306002)(66066001)(4326008)(81166006)(53386004)(8936002)(81156014)(8676002)(7736002)(305945005)(53546010)(3280700002)(9686003)(25786009)(2906002)(55016002)(6436002)(99286003)(68736007)(6116002)(3846002)(77096006)(97736004)(6506006)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1197; H:MWHPR09MB1197.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 36425a48-e8e4-4c8c-b8d3-08d51c8312cb X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 15:06:02.1771 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1197 Archived-At: Subject: Re: [mile] Ben Campbell's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 15:06:09 -0000 QmVuLA0KDQpNeSByZXNwb25zZXMgYXJlIGlubGluZS4NCg0KVGhhbmtzLA0KU3RlcGhlbg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRv OmJlbkBub3N0cnVtLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDI1LCAyMDE3IDEx OjM1IFBNDQo+IFRvOiBCYW5naGFydCwgU3RlcGhlbiBBLiAoRmVkKSA8c3RlcGhlbi5iYW5naGFy dEBuaXN0Lmdvdj4NCj4gQ2M6IG5jYW13aW5nQGNpc2NvLmNvbTsgbWlsZS1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc7IG1pbGVAaWV0Zi5vcmc7IFRoZQ0KPiBJRVNHIDxpZXNnQGlldGYub3JnPjsgbWls ZS1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbWlsZS1yb2xpZUBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogQmVuIENhbXBiZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW1pbGUtcm9saWUt MTE6ICh3aXRoIERJU0NVU1MNCj4gYW5kIENPTU1FTlQpDQo+IA0KPiBUaGFua3MgZm9yIHRoZSBy ZXNwb25zZS4gQ29tbWVudHMgYWxzbyBpbmxpbmU6DQo+IA0KPiA+IE9uIE9jdCAyNSwgMjAxNywg YXQgMzoxMCBQTSwgQmFuZ2hhcnQsIFN0ZXBoZW4gQS4gKEZlZCkNCj4gPHN0ZXBoZW4uYmFuZ2hh cnRAbmlzdC5nb3Y+IHdyb3RlOg0KPiA+DQo+ID4gQmVuLA0KPiA+DQo+ID4gVGhhbmtzIGZvciB0 aGUgcmV2aWV3LCBJJ3ZlIHB1dCBteSBjb21tZW50cy9jaGFuZ2VzIGlubGluZS4NCj4gPg0KPiA+ IFRoYW5rcywNCj4gPiBTdGVwaGVuDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPj4gRnJvbTogQmVuIENhbXBiZWxsIFttYWlsdG86YmVuQG5vc3RydW0uY29tXQ0KPiA+ PiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI0LCAyMDE3IDEwOjExIFBNDQo+ID4+IFRvOiBUaGUg SUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gPj4gQ2M6IGRyYWZ0LWlldGYtbWlsZS1yb2xpZUBpZXRm Lm9yZzsgbWlsZUBpZXRmLm9yZzsNCj4gPj4gbWlsZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IE5h bmN5IENhbS1XaW5nZXQgPG5jYW13aW5nQGNpc2NvLmNvbT47DQo+ID4+IG1pbGUtY2hhaXJzQGll dGYub3JnOyBuY2Ftd2luZ0BjaXNjby5jb207IG1pbGVAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDog QmVuIENhbXBiZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW1pbGUtcm9saWUtMTE6ICh3aXRo DQo+ID4+IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4+DQo+IA0KPiBb4oCmXQ0KPiANCj4gPj4N Cj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4gRElTQ1VTUzoNCj4gPj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4+IC0NCj4gPj4NCj4gPj4gLTUuMS4zOg0KPiA+Pg0KPiA+PiBJIGRvbid0IHRoaW5r IE1hcnRpbidzICBBUlQtQVJUIHJldmlldyBjb25jZXJuIChhbmQgTWFyaydzIHN1cHBvcnQpDQo+ ID4+IGFib3V0IHRoZSAud2VsbC1rbm93biBVUkwgcmVnaXN0cmF0aW9uIGhhcyBiZWVuIGZ1bGx5 IHJlc29sdmVkLiBXaGlsZQ0KPiA+PiB2ZXJzaW9uIDExIHJlbW92ZWQgc29tZSBvZiB0aGUgd2Vs bC1rbm93biByZWdpc3RyYXRpb25zLCBpdCBzdGlsbA0KPiA+PiBsZWF2ZXMgdGhlIG9uZS4gIE1h cmsgcG9pbnRlZCBvdXQgdGhhdCBSRkMgNTc4NSBvZmZlcnMgZXhwbGljaXQNCj4gPj4gZ3VpZGFu Y2UgdGhhdCAud2VsbC1rbm93biBVUkxzIGFyZSBpbnRlbmRlZCB0byBvZmZlciBzaXRlLXdpZGUg cG9saWN5DQo+ID4+IG9yIG1ldGFkYXRhLCBhbmQgYXJlIG5vdCBpbnRlbmRlZCBmb3IgZ2VuZXJh bCBpbmZvcm1hdGlvbiByZXRyaWV2YWwsDQo+ID4+IG9yIHRvIGVzdGFibGlzaCBhIG5hbWVzcGFj ZS4gIFRoaXMgdXNhZ2Ugc2VlbXMgdG8gbWUgdG8gYmUgZXhhY3RseSB0aGUNCj4gc29ydCBvZiB0 aGluZyB0aGF0IHRoZSBSRkMgYWR2aXNlcyBhZ2FpbnN0Lg0KPiA+Pg0KPiA+PiBJIHJlY29nbml6 ZSB0aGF0IHNlY3VyaXR5IGluZm9ybWF0aW9uIGlzIGltcG9ydGFudCwgYnV0IEkgZG9uJ3QNCj4g Pj4gdW5kZXJzdGFuZCB3aHkgaXQncyBkaXNjb3ZlcnkgbmVlZHMgdG8gYmUgZnVuZGFtZW50YWxs eSBkaWZmZXJlbnQNCj4gPj4gdGhhbiBmb3Igb3RoZXIgc3R1ZmYgb24gdXNpbmcgQVRPTS4gSSdt IHdpbGxpbmcgdG8gYmUgY29udmluY2VkLCBidXQNCj4gPj4gaWYgdGhlcmUncyBiZWVuIGEgY29u dmluY2luZyBhcmd1bWVudCBzbyBmYXIgSSd2ZSBtaXNzZWQgaXQuDQo+ID4NCj4gPiBJIHJlcGxp ZWQgdG8gTWFydGluJ3MgY29uY2VybiBvbiB0aGlzIGlzc3VlIGluIGFuIGVhcmxpZXIgZS1tYWls IGFuZCBJDQo+ID4gdGhpbmsgd2UndmUgcmVhY2hlZCBhZ3JlZW1lbnQgb24gdGhlIGp1c3RpZmlj YXRpb24gZm9yIHRoZSB3ZWxsLWtub3duDQo+ID4gcmVnaXN0cmF0aW9uDQo+ID4gKGh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbWlsZS9nYkc1bkM4T2g0cTc2UC0wZFhId00t DQo+IHp0TVANCj4gPiBZKQ0KPiA+DQo+ID4gUk9MSUUgaXMgbGFyZ2VseSBpbnRlbmRlZCB0byBi ZSBoYW5kbGVkIGJ5IGF1dG9tYXRlZCBzeXN0ZW1zIHRoYXQgY2Fubm90DQo+IHJlbGlhYmx5IGxv Y2F0ZSBsaW5rcyBnaXZlbiBieSBmcm9udC1mYWNpbmcgc2l0ZXMuIEluIHRoZXNlIGNhc2VzLCB0 aGUgUk9MSUUNCj4gY2xpZW50cyBuZWVkIGEgcmVsaWFibGUgd2F5IG9mIGZpbmRpbmcgYSBST0xJ RSByZXBvc2l0b3J5IGhvc3RlZCBieSBhIGdpdmVuDQo+IHNlcnZlci4gVGhlIHdlbGwta25vd24g cmVnaXN0cmF0aW9uIHByb3ZpZGVzIGEgc3RhbmRhcmRpemVkIHBsYWNlIGZvciB0aGUNCj4gaGVh ZCBvZiB0aGUgUk9MSUUgcmVwb3NpdG9yeSB0byBiZSByZXRyaWV2ZWQsIG1ha2luZyBpdCBwb3Nz aWJsZSBmb3IgYW4NCj4gYXV0b21hdGVkIHN5c3RlbSB0byBmdW5jdGlvbiB3aGVuIG9ubHkgZ2l2 ZW4gYSBob3N0IG5hbWUgYW5kIHBvcnQuDQo+ID4NCj4gPiBXZSd2ZSBhZGRlZCB0aGUgZm9sbG93 aW5nIGFkZGl0aW9uYWwganVzdGlmaWNhdGlvbiB0ZXh0IHRvIHRoZSBzcGVjaWZpY2F0aW9uDQo+ IHRvIGhlbHAgY2xhcmlmeSBvdXIgcmVhc29uaW5nLg0KPiA+DQo+ID4gIlJPTElFIHJlcG9zaXRv cmllcyBhcmUgbGFyZ2VseSBpbnRlbmRlZCB0byBiZSBjb25zdW1lZCBieSBhdXRvbWF0ZWQNCj4g c3lzdGVtcy4gV2hpbGUgaHVtYW5zIG1heSBiZSBhYmxlIHRvIG5hdmlnYXRlIGEgd2ViIHBhZ2Ug b3IgcmVjZWl2ZSBhbg0KPiBlbWFpbCB0byBmaW5kIGEgbGluayB0byB0aGUgcmVwb3NpdG9yeSwg YXV0b21hdGVkIHN5c3RlbXMgc3RydWdnbGUgd2l0aCBzdWNoDQo+IHRhc2tzLiBCeSBjcmVhdGlu ZyBhIHN0YW5kYXJkaXplZCBsb2NhdGlvbiBmb3IgdGhlIFNlcnZpY2UgRG9jdW1lbnQsIFJPTElF DQo+IGNsaWVudHMgbmVlZCBvbmx5IGEgaG9zdCBuYW1lIGFuZCBwb3J0IGluIG9yZGVyIHRvIGxv Y2F0ZSBhIFJPTElFIHJlcG9zaXRvcnkuDQo+IFRoaXMgbG93ZXIgYmFycmllciB0byBlbnRyeSBy ZWR1Y2VzIHRoZSBhbW91bnQgb2YgaHVtYW4gaW50ZXJ2ZW50aW9uDQo+IHJlcXVpcmVkIGZvciBS T0xJRSBjbGllbnRzIHRvIGJlZ2luIHJlYWRpbmcgRmVlZHMu4oCdDQo+IA0KPiBJdOKAmXMgbm90 IGNsZWFyIHRvIG1lIHdoeSBpdHMgc3Vic3RhbnRpYWxseSBlYXNpZXIgdG8gbGVhcm4gbmFtZSBh bmQgcG9ydCB0aGFuIGl0DQo+IGlzIHRvIGxlYXJuIGEgVVJMLiBBcyBBZGFtIHBvaW50ZWQgb3V0 IGluIGhpcyBzZXBhcmF0ZSBESVNDVVNTLCB0aGVyZeKAmXMgbm8NCj4gZGlzY292ZXJ5IG1lY2hh bmlzbSAoeWV0KSBmb3IgdGhlIGhvc3RuYW1lIGFuZCBwb3J04oCUdGhhdCBpcywgc29tZW9uZSB3 aWxsDQo+IGhhdmUgdG8gdGVsbCB0aGF0IGF1dG9tYXRlZCBzeXN0ZW0gd2hhdCBuYW1lIGFuZCBw b3J0IHRvIHVzZS4gQWRhbSBhbHNvDQo+IHBvaW50ZWQgb3V0IHRoYXQgdGhlcmUgYXJlIHBvdGVu dGlhbCBkZXNpZ24gcGF0aHMgKGUuZy4gTkFQVFIpIGZvciBkaXNjb3ZlcnkNCj4gbWVjaGFuaXNt cyB0aGF0IHdvdWxkIGdpdmUgeW91IGEgVVJMLg0KPiANCj4gLndlbGwta25vd24gVVJMcyBhcmUg aW50ZW5kZWQgZm9yIHdoZW4gbm8gb3RoZXIgZGlzY292ZXJ5IG1lY2hhbmlzbXMNCj4gbWFrZSBz ZW5zZS4NCg0KV2UgYXJlIGNvbnNpZGVyaW5nIHRoZSB1c2UgY2FzZSB3aGVyZSBhIHZlbmRvciB3 YW50cyB0byBwcm92aWRlIHNlY3VyaXR5IGF1dG9tYXRpb24gaW5mb3JtYXRpb24gdGhyb3VnaCBS T0xJRSwgc3VjaCBhcyBwdWJsaWMgZGlzY2xvc2Ugb2YgdnVsbmVyYWJpbGl0aWVzLCBvciBzb2Z0 d2FyZSBtZXRhZGF0YS4gUG90ZW50aWFsIGNvbnN1bWVycyBrbm93IHRoZSBob3N0bmFtZSBhbmQg cG9ydCBvZiB0aGUgdmVuZG9yIGFscmVhZHksIGJ1dCBuZWVkIHRvIGtub3cgd2hlcmUgdG8gZmlu ZCB0aGUgUk9MSUUgcmVwb3NpdG9yeS4gSW4gdGhpcyBjYXNlLCBwcm92aWRpbmcgYSB0b29sIHdp dGggYSBob3N0bmFtZSBhbmQgcG9ydCBpcyBzdWJzdGFudGlhbGx5IGVhc2llciB0aGFuIHRyYWNr aW5nIGRvd24gYSBST0xJRSBTZXJ2aWNlIERvY3VtZW50IFVSTC4NCg0KRm9yIGV4YW1wbGUsIGlm IEkgd2FudCB0byBoYXZlIG15IFJPTElFIGNsaWVudCB0b29sIGNoZWNrIHRvIHNlZSBpZiBNaWNy b3NvZnQgaXMgaG9zdGluZyBhIFJPTElFIHJlcG9zaXRvcnksIEkgbmVlZCBvbmx5IHRvIHByb3Zp ZGUgaXQgd2l0aCAiaHR0cDovL21pY3Jvc29mdC5jb20iIGFuZCBpdCdsbCBkbyB0aGUgcmVzdC4N Cg0KQWRkaXRpb25hbGx5LCB3ZSBmZWVsIHRoYXQgYSB3ZWxsLWtub3duIHJlZ2lzdHJhdGlvbiB3 aWxsIGJlIG5lZWRlZCBmb3IgYSBmdWxsIGRpc2NvdmVyeSBzeXN0ZW0sIGFuZCBhcyBzdWNoLCB0 aGlzIGlzIGxheWluZyB0aGUgZm91bmRhdGlvbiBmb3IgdGhhdCB3b3JrIGluIHRoZSBmdXR1cmUu IA0KDQo+ID4NCj4gPiBXZSd2ZSBkcm9wcGVkIHRoZSB3ZWxsLWtub3duIHJlZ2lzdHJhdGlvbiBm b3IgdGhlIENhdGVnb3J5IERvY3VtZW50LCBhcw0KPiBpdCBpcyBsb2NhdGFibGUgZnJvbSB0aGUg U2VydmljZSBEb2N1bWVudCB3aGVyZSBhcHBsaWNhYmxlLg0KPiANCj4gPiA+DQo+ID4+IEknbSBu b3Qgc3VyZSB3aGF0IHRvIG1ha2Ugb2YgdGhlIHNlY29uZCBwYXJhZ3JhcGguIEl0IHNheXMgRE5T IFNSVg0KPiA+PiBjYW4gYmUgdXNlZCB0byBkZXRlcm1pbmUgdGhlIGhvc3QgYW5kIHBvcnQuIElz IHRoZSBleHBlY3RhdGlvbiB0aGF0DQo+ID4+IHBlb3BsZSBjYW4ganVzdCBkbyB0aGF0IHdpdGhv dXQgZnVydGhlciBzcGVjaWZpY2F0aW9uLCBvciB0aGF0DQo+ID4+IHNvbWVvbmUgY291bGQgc3Bl Y2lmeSBpdCBpbiB0aGUgZnV0dXJlPw0KPiA+PiBUaGUgZm9ybWVyIGlzIGdlbmVyYWxseSBub3Qg dHJ1ZS4gSWYgdGhlIGludGVudCBpcyB0aGUgbGF0dGVyLCBwbGVhc2UNCj4gPj4gY2xhcmlmeSB0 aGF0IGluIHRoZSB0ZXh0Lg0KPiA+DQo+ID4gVGhlIGludGVudCB3YXMgdGhlIGxhdHRlci4gSSd2 ZSBjaGFuZ2VkIHRoZSBlbmQgb2YgdGhhdCBwYXJhZ3JhcGggdG8gZnVydGhlcg0KPiBjbGFyaWZ5 IGFzIGZvbGxvd3M6DQo+ID4NCj4gPiAiVXNlIG9mIGEgbWVjaGFuaXNtIHN1Y2ggYXMgRE5TIFNS ViBSZWNvcmRzICBjYW4gcHJvdmlkZSBhIHNlY3VyZSBhbmQNCj4gcmVsaWFibGUgZGlzY292ZXJ5 IG1lY2hhbmlzbSBmb3IgZGV0ZXJtaW5pbmcgYSBzcGVjaWZpYyBob3N0IGFuZCBwb3J0IHRvIHVz ZQ0KPiBmb3IgcmV0cmlldmluZyBhIFNlcnZpY2UgRG9jdW1lbnQgZm9yIGEgZ2l2ZW4gRE5TIGRv bWFpbi4gVGhpcyBpcyBhIGZlYXR1cmUNCj4gdGhhdCBtYXkgYmUgc3RhbmRhcmRpemVkIGluIHRo ZSBmdXR1cmUu4oCdDQo+IA0KPiBUaGF0IHdvdWxkIHJlc29sdmUgbXkgY29uY2Vybi4NCj4gDQo+ ID4NCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4gQ09NTUVOVDoNCj4gPj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4NCj4gPj4gU3Vic3RhbnRpdmU6DQo+ID4+DQo+ID4+ IC0yOiBUaGVyZSBhcmUgYSBudW1iZXIgb2YgbG93ZXIgY2FzZSB2ZXJzaW9ucyBvZiAyMTE5IGtl eXdvcmRzLiBJZg0KPiA+PiB0aG9zZSBhcmUgaW50ZW50aW9uYWwsIHBsZWFzZSB1c2UgdGhlIHVw ZGF0ZWQgYm9pbGVycGxhdGUgZnJvbSBSRkMNCj4gPj4gODE3NC4gVGhhdCBiZWluZyBzYWlkLCB0 aGUgZm9sbG93aW5nIHBhcmFncmFwaCBzYXlzIHRoZSBrZXl3b3JkcyBhcmUgdXNlZA0KPiBmb3Ig Y29uZm9ybWFuY2UuDQo+ID4+IDIyMTkvODE3NCBrZXl3b3JkcyBhcmUgbm90IGFib3V0IGNvbmZv cm1hbmNlLiBUaGV5IGFyZSBhYm91dA0KPiA+PiBpbnRlcm9wZXJhYmlsaXR5LiBJZiB5b3Ugd2Fu dCB0byB1c2UgdGhlbSBmb3IgY29uZm9ybWFuY2UsIHRoYXQncw0KPiA+PiBva2F5LS1idXQgdGhh dCBtZWFucyB0aGV5IGFyZSBubyBsb25nZXIgYmVpbmcgdXNlZCBhcyBpbnRlbmRlZCBieQ0KPiA+ PiAyMTE5LCBhbmQgdGhlIGJvaWxlcnBsYXRlIHNob3VsZCBiZSBhZGp1c3RlZCBhY2NvcmRpbmds eS4NCj4gPg0KPiA+IFRoZSBsb3dlciBjYXNlIGtleXdvcmRzIGFyZSBpbnRlbnRpb25hbC4gV2Un dmUgc3dpdGNoZWQgdGhlIGJvaWxlcnBsYXRlDQo+IHRleHQgdG8gdGhlIHVwZGF0ZWQgODE3NCB2 ZXJzaW9uLg0KPiANCj4gT2theS4NCj4gDQo+ID4NCj4gPj4gLTMuMjogSSdtIGNvbmZ1c2VkIGJ5 IHRoZSBpZGVhIHRoZSBzY2hlbWEgaXMgaW5mb3JtYXRpdmUuIEkgZXhwZWN0DQo+ID4+IHRoYXQg YXQgbGVhc3Qgc29tZSBpbXBsZW1lbnRvcnMgd2lsbCBpbXBsZW1lbnQgIHRvIHRoZSBzY2hlbWEu IFdlDQo+ID4+IGhhdmUgYSBwZXJlbm5pYWwgcHJvYmxlbSB3aGVyZSBpbXBsZW1lbnRvcnMgaW1w bGVtZW50IHRoZSBleGFtcGxlcw0KPiA+PiByYXRoZXIgdGhhbiB0aGUgdGV4dC4gSXQgc2VlbXMg bGlrZSBhIG5vbi1ub3JtYXRpdmUgc2NoZW1hIGlzIGV2ZW4NCj4gPj4gbW9yZSBvZiBhbiBhdHRy YWN0aXZlIGhhemFyZCBpbiB0aGF0IHJlZ2FyZC4NCj4gPg0KPiA+IFdlIGZvdW5kIHRoYXQgYXZh aWxhYmxlIHNjaGVtYSBsYW5ndWFnZXMgY2Fubm90IGV4cHJlc3MgdGhlIHNhbWUNCj4gY29tcGxl eGl0aWVzIHdlIGNvdWxkIGV4cHJlc3MgaW4gdGV4dC4gVGhlcmUgYXJlIGRpZmZpY3VsdCBjb25k aXRpb25hbA0KPiByZXF1aXJlbWVudHMgdGhhdCBhcmUgcG9vcmx5IGV4cHJlc3NlZCBpbiBzY2hl bWFzIGJ1dCBjYW4gYmUgZml0IGludG8gYSBuZWF0DQo+IHNlbnRlbmNlLiBJbiBvcmRlciB0byBz dXBwb3J0IHRoZSBwbGFjZXMgd2hlcmUgd2UgZG8gdGhhdCwgd2UgZGVjaWRlZCB0aGF0DQo+IG1h a2luZyB0aGUgdGV4dCBub3JtYXRpdmUgd2FzIHRoZSBvbmx5IHdheSB0byBlbnN1cmUgdGhhdCB0 aGUNCj4gcmVxdWlyZW1lbnRzIHdlcmUgZXhwcmVzc2VkIGNsZWFybHkuDQo+ID4NCj4gPiBBZGRp dGlvbmFsbHksIEF0b20gU3luZGljYXRpb24gYW5kIHRoZSBBdG9tIFB1Ymxpc2hpbmcgUHJvdG9j b2wgYm90aA0KPiBzcGVjaWZ5IHRoYXQgdGhlIHRleHQgaXMgbm9ybWF0aXZlLCBub3QgdGhlIGlu Y2x1ZGVkIHNjaGVtYXMuIEJ5IG1ha2luZyB0aGUNCj4gc2NoZW1hIGluZm9ybWF0aXZlLCB3ZSBh cmUga2VlcGluZyB3aXRoIHRoaXMgcHJhY3RpY2UuDQo+IA0KPiBEbyB5b3UgYmVsaWV2ZSBhbiBp bXBsZW1lbnRlciBjb3VsZCByZWFzb25hYmx5IGNvZGUgdGhpcyBqdXN0IGZyb20gdGhlIHRleHQN Cj4gd2l0aG91dCBsb29raW5nIGF0IHRoZSBzY2hlbWE/DQo+IA0KPiBUaGUgcHJvYmxlbSBvZiBu ZWVkaW5nIGFkZGl0aW9uYWwgY29uc3RyYWludHMgb3ZlciB3aGF0IGNhbiBiZSBleHByZXNzZWQg aW4NCj4gYSBmb3JtYWwgbGFuZ3VhZ2UsIHdoZXRoZXIgdGhhdOKAmXMgYSBzY2hlbWEsIEFCTkYs IGV0YywgaXMgY29tbW9uLiBJdOKAmXMNCj4gdHlwaWNhbCB0byBzdGlsbCBjb25zaWRlciB0aGUg bm9ybWF0aXZlIGRlZmluaXRpb24gdG8gaW5jbHVkZSBib3RoIHRoZSBmb3JtYWwNCj4gZGVmaW5p dGlvbiBhbmQgdGhvc2UgYWRkaXRpb25hbCBjb25zdHJhaW50cy4NCg0KR2l2ZW4gdGhhdCBhbiBp bXBsZW1lbnRlciB3b3VsZCBuZWVkIHRvIGNhcmVmdWxseSByZWFkIHRoZSBwbGFpbiB0ZXh0IGlu IGVpdGhlciBjYXNlLCB3ZSBmZWVsIHRoYXQgdXNpbmcgdGhlIG1vc3QgZXhwcmVzc2l2ZSBvcHRp b24gZm9yIHRoZSBub3JtYXRpdmUgcmVxdWlyZW1lbnQgaXMgdGhlIGJlc3Qgd2F5IG9mIGRvaW5n IGl0Lg0KDQpIYXZpbmcgd3JpdHRlbiBhbiBpbXBsZW1lbnRhdGlvbiBvZiBBdG9tIFB1YiAoV2hp Y2ggdXNlcyBub3JtYXRpdmUgcGxhaW4gdGV4dCkgYW5kIG9mIFJPTElFLCBJIHdpc2ggSSBjb3Vs ZCBqdXN0IGNvcHkgYW5kIHBhc3RlIHNvbWUgc2NoZW1hIGFuZCBiZSBkb25lLCBidXQgZ2l2ZW4g dGhhdCBpdCBpc27igJl0IHBvc3NpYmxlLCB1c2luZyB0aGUgcGxhaW4gdGV4dCB0byBpbXBsZW1l bnQgd2Fzbid0IGJhZC4NCg0KPiA+DQo+ID4+IC01LjQsIDJuZCBwYXJhZ3JhcGg6IFRoaXMgc2Vl bXMgbGlrZSBhbiBvZGQgdGhpbmcgdG8gc3RhdGUNCj4gPj4gbm9ybWF0aXZlbHkuIEl0IHNlZW1z IHRvIHB1c2ggZm9yIGEgc3BlY2lmaWMgb3JnYW5pemF0aW9uYWwgbW9kZWwgZm9yDQo+ID4+IGNv bnNvcnRpdW1zLiBJdCdzIHJlYXNvbmFibGUgdG8gb2ZmZXIgZ3VpZGFuY2UsIGJ1dCBJIHRoaW5r DQo+ID4+IGNvbnNvcnRpdW1zIGFyZSBnb2luZyB0byBkbyB3aGF0ZXZlciB0aGV5IHdhbnQgaGVy ZS4NCj4gPg0KPiA+IFJld29yZGVkIHRoaXMgcGFyYWdyYXBoIGludG8gYSBub24tbm9ybWF0aXZl IHJlY29tbWVuZGF0aW9uLg0KPiANCj4gT2theS4NCj4gDQo+ID4NCj4gPj4gLTguMzogV2hhdCBp cyB0aGUgcmVnaXN0cmF0aW9uIHBvbGljeSBmb3IgdGhlIHRvcCBsZXZlbCByZWdpc3RyeT8NCj4g Pg0KPiA+IFRoZXJlIHdhcyBzb21lIG1pc2xlYWRpbmcgdGV4dCB0aGF0IGRpc2N1c3NlZCBhIHJl Z2lzdHJ5IHRoYXQgd2UgZGlkbid0DQo+IGludGVuZCB0byBiZSBjcmVhdGVkLiBXZSd2ZSBmaXhl ZCB0aGUgdGV4dCB0byBtYWtlIGl0IGNsZWFyIHRoYXQgdGhlcmUgaXMgb25seQ0KPiBvbmUgcmVn aXN0cnkgYmVpbmcgZGVmaW5lZCAoUk9MSUUgVVJOIFBhcmFtZXRlcnMpIGluIHRoaXMgc2VjdGlv bi4gVGhlDQo+IHVwZGF0ZWQgdGV4dCBpcyBwcm92aWRlZCBoZXJlOg0KPiA+DQo+ID4gIkEgbmV3 IHRvcC1sZXZlbCByZWdpc3RyeSBoYXMgYmVlbiBjcmVhdGVkLCBlbnRpdGxlZCAiUmVzb3VyY2UN Cj4gPiBPcmllbnRlZCBMaWdodHdlaWdodCBJbmZvcm1hdGlvbiBFeGNoYW5nZSAoUk9MSUUpIFVS TiBQYXJhbWV0ZXJzIi4gW1RPDQo+ID4gQkUgUkVNT1ZFRDogVGhpcyByZWdpc3RyYXRpb24gc2hv dWxkIHRha2UgcGxhY2UgYXQgdGhlIGZvbGxvd2luZw0KPiA+IGxvY2F0aW9uOiBodHRwczovL3d3 dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9yb2xpZV0NCj4gPg0KPiA+IFJlZ2lzdHJhdGlvbiBpbiB0 aGUgUk9MSUUgVVJOIFBhcmFtZXRlcnMgcmVnaXN0cnkgaXMgdmlhIHRoZSBTcGVjaWZpY2F0aW9u DQo+IFJlcXVpcmVkIHBvbGljeSAuIERlc2lnbmF0ZWQgRXhwZXJ0IHJldmlld3Mgc2hvdWxkIGJl IHJvdXRlZCB0aHJvdWdoIHRoZQ0KPiBNSUxFIFdHIG1haWxpbmcgbGlzdC4gRmFpbGluZyB0aGlz LCB0aGUgRGVzaWduYXRlZCBFeHBlcnQgd2lsbCBiZSBhc3NpZ25lZCBieQ0KPiB0aGUgSUVTRy7i gJ0NCj4gPg0KPiANCj4gT2theSwgdGhhdCB3b3JrcyBmb3IgbW9lLg0KPiANCj4gPj4gLTEwOiAg ICJPdmVyYWxsLCBST0xJRSBpbnRyb2R1Y2VzIGZldyBwcml2YWN5IGNvbmNlcm5zIGFib3ZlIGFu ZCBiZXlvbmQNCj4gPj4gdGhvc2UNCj4gPj4gcHJlc2VudCBpbiBhbnkgb3RoZXIgSFRUUCBwcm90 b2NvbC4gIiBJJ20gc2tlcHRpY2FsIHRoYXQgdGhhdCBpcw0KPiA+PiB0cnVlLiBTZWN1cml0eSBp bmZvcm1hdGlvbiBzZWVtcyBsaWtlbHkgdG8gYmUgcHJpdmFjeSBzZW5zaXRpdmUsDQo+ID4+IGVz cGVjaWFsbHkgY29tcGFyZWQgdG8gc29tZSBub3Rpb25hbCAiZ2VuZXJpYyIgSFRUUCBiYXNlZCBw cm90b2NvbC4NCj4gPg0KPiA+IFdlJ3ZlIHJld3JpdHRlbiB0aGlzIGxhc3QgcGFyYWdyYXBoIHRv IHByb3ZpZGUgbW9yZSBjbGVhciBkZXRhaWxzIGFyb3VuZA0KPiBwcml2YWN5IGNvbmNlcm5zIGlu IFJPTElFLiBUaGUgdXBkYXRlZCB0ZXh0IGlzIHByb3ZpZGVkIGhlcmU6DQo+ID4NCj4gPiAiT3Zl cmFsbCwgcHJpdmFjeSBjb25jZXJucyBpbiBST0xJRSBjYW4gYmUgbWl0aWdhdGVkIGJ5IGZvbGxv d2luZyBzZWN1cml0eQ0KPiBjb25zaWRlcmF0aW9ucyBhbmQgY2FyZWZ1bCB1c2Ugb2YgdGhlIG9w dGlvbmFsIHBlcnNvbmFsbHkgaWRlbnRpZnlpbmcNCj4gZWxlbWVudHMgKGUuZy4sIGF1dGhvcikg cHJvdmlkZWQgYnkgQXRvbSBTeW5kaWNhdGlvbiBhbmQgUk9MSUUu4oCdDQo+IA0KPiBPa2F5Lg0K PiANCj4gW1lvdXIgcmVzcG9uc2VzIHRvIG15IGVkaXRvcmlhbCBjb21tZW50cyBhbGwgbG9vayBn b29kLl0NCj4gDQo+IFRoYW5rcyENCj4gDQo+IEJlbi4NCg0K From nobody Thu Oct 26 08:42:00 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091CB13F3C0; Thu, 26 Oct 2017 08:41:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=nistgov.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 flMY0tIM8mGe; Thu, 26 Oct 2017 08:41:53 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0102.outbound.protection.outlook.com [23.103.201.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A178137C2E; Thu, 26 Oct 2017 08:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pEeSKdbekgb/tA7L6Qf24ZrKqka+O8CHKN2U/V2IhdU=; b=SdgglgRe8vNfbnsTjf4vrItVEYmVi/kviQFDGQPg12vEc5cGqUTA8W/xQrvGoOWVssHkIx0suW4sn2fdp6MMdJR0dWRscyzKku91k1otrsFRg+wqfOKD2mZ9bZX7B+5PBKxlftK4etQ7UZ4rs1ogW3XMB3hQJmvYQ9WdpQq1VoA= Received: from MWHPR09MB1197.namprd09.prod.outlook.com (10.172.49.143) by MWHPR09MB1199.namprd09.prod.outlook.com (10.172.49.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Thu, 26 Oct 2017 15:41:50 +0000 Received: from MWHPR09MB1197.namprd09.prod.outlook.com ([10.172.49.143]) by MWHPR09MB1197.namprd09.prod.outlook.com ([10.172.49.143]) with mapi id 15.20.0178.007; Thu, 26 Oct 2017 15:41:50 +0000 From: "Banghart, Stephen A. (Fed)" To: Adam Roach CC: "ncamwing@cisco.com" , "mile-chairs@tools.ietf.org" , "mile@ietf.org" , The IESG , "mile-chairs@ietf.org" , "draft-ietf-mile-rolie@ietf.org" , "Ben Campbell" Thread-Topic: Adam Roach's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and COMMENT) Thread-Index: AQHTTUZSm55anh/gYEy4JIuYjSD1UKL1AXmQgAAYpoCAASM0QA== Date: Thu, 26 Oct 2017 15:41:50 +0000 Message-ID: References: <150890423788.4689.5942012074290459252.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.251.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR09MB1199; 6:Kgdn+fd7KZW/d5KRCWcTj8saE9y0iwF2XQg2X8pb1soZMPxyk+cwaZJ4hFZSr+gqs6gCmkvgZ4v8KUjk5N7BVti+N8atYGYl3BYdAG2bqxT/bVJSHZFoLhgWXA1DyK52Z1/U6CvHMj7vwBqBwyUnj8/6K7rYD+IQ3Ch04lIRgnPrtnxSOQ9DHxd1xgMu9Q+qqM9W71fbsEtqYi4xtSEjlfPysDNXevfcI8YWXzO+EpZkr2IL238jGF3GQPx9O865lolAMAWxisnb6fNfvTaFZMAtASeg3OE6x1V22q/Dw2j4mAX3jn1PltU1NEzKgdHCxZTBJa2S46c2EYRvfh+PVAuH13yp4ZBQMcgPvOkKWg8=; 5:tYjF1gwMbxe4Qfy0k98XapX1xbMxqvDKP5cLZfTcdODZDL3J/3jf+BIRfvN/UFPEurHDS0em1oqYaajDa8b5SC8yv7zGYFjAiRk/MjNjyZR1nfzWr1e8JGdWXI6Yfno3HpgVyY1Mc3dMrLtt9HhDk+0WLx0GJkEhFpXqpDT18LU=; 24:t7g2yFGtsBEJs0VH646BpzjKx2bBV8JyxaS8Ha19y/6JBho3B0REvZmCK+dBFEQJpphZUSMcJA+snWgR4vEnEXT+0cLoosnII8OPjoz244o=; 7:sy3SB78uLsQ2+YiUt2mciK9WAR0Mg0zdH/vsy3Dg3fU7QqxTfldnrJ/qBBxLaFrom5AnypLBCCGgTj7r4owiALDiTYC5YExA7+KMbfpM0l8u007s9LB8omNb+m1ai2N1edklwaSJoFiURVlZPMOoEuvvgIw2yUCoPTNWLDNP5bhZklsztcZr5WFYVJ9DoHTHwEV3ZeZBLH5gmPB4/9wxE8nxTkgQZZ8Dur6o8e3fEvYzapvVhHZl+xfl70mWzRpk x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 05c4618d-07c3-4e12-0ce0-08d51c88131a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:MWHPR09MB1199; x-ms-traffictypediagnostic: MWHPR09MB1199: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(189930954265078)(95692535739014)(219752817060721); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(3231020)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR09MB1199; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR09MB1199; x-forefront-prvs: 04724A515E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(13464003)(24454002)(51914003)(189002)(3905003)(199003)(316002)(25786009)(105586002)(7696004)(54356999)(54906003)(2900100001)(50986999)(478600001)(76176999)(8676002)(106356001)(8936002)(6116002)(3846002)(102836003)(606006)(81156014)(81166006)(966005)(53546010)(66066001)(74316002)(230783001)(45080400002)(305945005)(33656002)(7736002)(101416001)(2950100002)(6916009)(68736007)(6246003)(575784001)(14454004)(4326008)(189998001)(5660300001)(3280700002)(3660700001)(2906002)(86362001)(99286003)(6306002)(229853002)(53936002)(55016002)(6436002)(77096006)(6506006)(97736004)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1199; H:MWHPR09MB1197.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 05c4618d-07c3-4e12-0ce0-08d51c88131a X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 15:41:50.1897 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1199 Archived-At: Subject: Re: [mile] Adam Roach's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 15:41:58 -0000 QWRhbSwNCg0KVG8gYXZvaWQgYXJndWluZyBzZW1hbnRpY3Mgb24gZ3Vlc3NhYmlsaXR5IHZzIGRp c2NvdmVyYWJpbGl0eSwgSSB3b3VsZCBzYXkgdGhhdCBhdCB0aGlzIGN1cnJlbnQgc3RhZ2UsIHRo ZSB3ZWxsLWtub3duIHJlZ2lzdHJhdGlvbiBhbGxvd3MgYW4gYXV0b21hdGVkIHN5c3RlbSB0byBy ZWxpYWJseSBjaGVjayBpZiBhIGdpdmVuIGhvc3QgaXMgaG9zdGluZyBhIFJPTElFIHJlcG9zaXRv cnksIGFuZCBpZiB0aGV5IGFyZSwgdG8gcHJvdmlkZSB0aGUgaGVhZCBvZiB0aGF0IHJlcG9zaXRv cnkuIFRoaXMgbWVjaGFuaXNtIGlzIHVzYWJsZSBhY3Jvc3MgYWxsIFJPTElFIHJlcG9zaXRvcmll cy4NCg0KRnVsbHkgYXV0b21hdGVkIGRpc2NvdmVyYWJpbGl0eSBpcyBzb21ldGhpbmcgdGhhdCB3 ZSB3YW50LCBhbmQgd2UnbGwgbmVlZCB0aGlzIHJlZ2lzdHJhdGlvbiBmb3IgdGhhdCBpbiB0aGUg ZnV0dXJlLiBHdWVzc2FiaWxpdHksIGluIHRoZSBtZWFuIHRpbWUsIHByb3ZpZGVzIGRlbW9uc3Ry YWJsZSB2YWx1ZS4NCg0KVGhhbmtzLA0KU3RlcGhlbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0uY29tXQ0KPiBT ZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjUsIDIwMTcgNTo0NCBQTQ0KPiBUbzogQmFuZ2hhcnQs IFN0ZXBoZW4gQS4gKEZlZCkgPHN0ZXBoZW4uYmFuZ2hhcnRAbmlzdC5nb3Y+DQo+IENjOiBuY2Ft d2luZ0BjaXNjby5jb207IG1pbGUtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBtaWxlQGlldGYub3Jn OyBUaGUNCj4gSUVTRyA8aWVzZ0BpZXRmLm9yZz47IG1pbGUtY2hhaXJzQGlldGYub3JnOyBkcmFm dC1pZXRmLW1pbGUtcm9saWVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IEFkYW0gUm9hY2gncyBE aXNjdXNzIG9uIGRyYWZ0LWlldGYtbWlsZS1yb2xpZS0xMTogKHdpdGggRElTQ1VTUw0KPiBhbmQg Q09NTUVOVCkNCj4gDQo+IEJhc2VkIG9uIHRoZSBleGFtcGxlIHlvdSBnYXZlIE1hcnRpbiAoIkkn ZCBsaWtlIHRvIGdpdmUgYSB0b29sDQo+ICdodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD13d3cubWljcm9zb2Z0LmNvbSZkDQo+IGF0YT0wMiU3QzAxJTdD c3RlcGhlbi5iYW5naGFydCU0MG5pc3QuZ292JTdDODNjMjg2YzkyNmVkNGM4NTI3NDMwOA0KPiBk NTFiZjE4MGJhJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYz NjQ0NTY0DQo+IDY0NDUzNTI1NTkmc2RhdGE9dUg0anZqMzNicVRnNU4yRlNqUXdnUzhLeXNkeGFR MmdkVnJ3TlYzTENqYyUzRA0KPiAmcmVzZXJ2ZWQ9MCcuLi4iKSwgaXQgc291bmRzIGxpa2UgeW91 J3JlIG5vdCBsb29raW5nIGZvcg0KPiAqZGlzY292ZXJhYmlsaXR5KiBhcyBtdWNoIGFzIHlvdSBh cmUgKmd1ZXNzYWJpbGl0eSouIElzIHRoYXQgYW4gYWNjdXJhdGUNCj4gY2hhcmFjdGVyaXphdGlv bj8NCj4gDQo+IC9hDQo+IA0KPiBPbiAxMC8yNS8xNyAzOjM1IFBNLCBCYW5naGFydCwgU3RlcGhl biBBLiAoRmVkKSB3cm90ZToNCj4gPiBBZGFtLA0KPiA+DQo+ID4gVGhhbmtzIGZvciB0aGUgcmV2 aWV3LiBJJ3ZlIHB1dCBteSBjb21tZW50cy9jaGFuZ2VzIGlubGluZS4NCj4gPg0KPiA+IFRoYW5r cywNCj4gPiBTdGVwaGVuDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g Pj4gRnJvbTogQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dDQo+ID4+IFNlbnQ6 IFdlZG5lc2RheSwgT2N0b2JlciAyNSwgMjAxNyAxMjowNCBBTQ0KPiA+PiBUbzogVGhlIElFU0cg PGllc2dAaWV0Zi5vcmc+DQo+ID4+IENjOiBkcmFmdC1pZXRmLW1pbGUtcm9saWVAaWV0Zi5vcmc7 IG1pbGVAaWV0Zi5vcmc7IG1pbGUtDQo+IGNoYWlyc0B0b29scy5pZXRmLm9yZzsNCj4gPj4gTmFu Y3kgQ2FtLVdpbmdldCA8bmNhbXdpbmdAY2lzY28uY29tPjsgbWlsZS1jaGFpcnNAaWV0Zi5vcmc7 DQo+ID4+IG5jYW13aW5nQGNpc2NvLmNvbTsgbWlsZUBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBB ZGFtIFJvYWNoJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW1pbGUtcm9saWUtMTE6ICh3aXRoIERJ U0NVU1MNCj4gYW5kDQo+ID4+IENPTU1FTlQpDQo+ID4+DQo+ID4+IEFkYW0gUm9hY2ggaGFzIGVu dGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ID4+IGRyYWZ0LWlldGYt bWlsZS1yb2xpZS0xMTogRGlzY3Vzcw0KPiA+Pg0KPiA+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFz ZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gZW1haWwN Cj4gPj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZy ZWUgdG8gY3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5DQo+ID4+IHBhcmFncmFwaCwgaG93ZXZlci4p DQo+ID4+DQo+ID4+DQo+ID4+IFBsZWFzZSByZWZlciB0bw0KPiA+Pg0KPiBodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5p DQo+ID4+IGV0Zi5vcmclMkZpZXNnJTJGc3RhdGVtZW50JTJGZGlzY3Vzcy0NCj4gPj4NCj4gY3Jp dGVyaWEuaHRtbCZkYXRhPTAyJTdDMDElN0NzdGVwaGVuLmJhbmdoYXJ0JTQwbmlzdC5nb3YlN0Mw ODQ1NmQwOWYNCj4gPj4NCj4gYTFkNGMxZGEyZWEwOGQ1MWI1ZDZiNzElN0MyYWI1ZDgyZmQ4ZmE0 Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElNw0KPiA+Pg0KPiBDMCU3QzYzNjQ0NTAxMDQzNzgzNzQw NCZzZGF0YT1ZQ2k3Z1RBd0ZaRHZ4aXd6VjY2SXVobng3M3ppSGU4R0o2Sg0KPiA+PiBNSm5lSU5q YyUzRCZyZXNlcnZlZD0wDQo+ID4+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElT Q1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ID4+DQo+ID4+DQo+ID4+IFRoZSBkb2N1bWVu dCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToN Cj4gPj4NCj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHINCj4gPj4gYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFm dC1pZXRmLW1pbGUtDQo+ID4+DQo+IHJvbGllJTJGJmRhdGE9MDIlN0MwMSU3Q3N0ZXBoZW4uYmFu Z2hhcnQlNDBuaXN0LmdvdiU3QzA4NDU2ZDA5ZmExZA0KPiA+Pg0KPiA0YzFkYTJlYTA4ZDUxYjVk NmI3MSU3QzJhYjVkODJmZDhmYTQ3OTdhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzANCj4gPj4NCj4g JTdDNjM2NDQ1MDEwNDM3ODM3NDA0JnNkYXRhPVQlMkZpVkZhUElvckJhM2lnRHBSazg3TU0lMkJs MXN3MWhBDQo+ID4+IHJCRWhxbXFxalZqSSUzRCZyZXNlcnZlZD0wDQo+ID4+DQo+ID4+DQo+ID4+ DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gRElTQ1VTUzoNCj4gPj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+Pg0KPiA+PiBJIGFncmVlIHdpdGggQmVuLCBNYXJ0aW4sIGFuZCBNYXJrOiB0aGUgd2F5IHRo aXMgZG9jdW1lbnQgdXNlcyAvLndlbGwtDQo+ID4+IGtub3duLyBVUklzIGlzIG5vdCBjb25zaXN0 ZW50IHdpdGggUkZDNTc4NSwgc2VjdGlvbiAxLjEuIEl0IHNob3VsZCBiZQ0KPiA+PiB1bmRlcnN0 b29kIHRoYXQgLy53ZWxsLWtub3duLyBVUkxzIGFyZSBhbHJlYWR5IGEgY2FydmUtb3V0IGZyb20g b3ZlcmFsbA0KPiA+PiBSRVNUIHByaW5jaXBsZXMgcmVnYXJkaW5nIHRoZSBhZ2VuY3kgb2YgY29u dGVudCBwdWJsaXNoZXJzIHRvIGFzc2lnbiBVUkxzDQo+ID4+IHdpdGhpbiB0aGVpciBkb21haW4g YXMgdGhleSBzZWUgZml0OyBhbmQsIGFzIHN1Y2gsIG5lZWQgbm9uLXRyaXZpYWwNCj4ganVzdGlm aWNhdGlvbg0KPiA+PiBmb3IgdGhlaXIgdXNlLg0KPiA+Pg0KPiA+PiBJZiB0aGVyZSB3ZXJlIHNv bWUgZnVsbHktZGVmaW5lZCBhdXRvZGlzY292ZXJ5IG1lY2hhbmlzbSB0aGF0IHdlcmUNCj4gPj4g KG5vbi1hcnRpZmljaWFsbHkpIGNvbnN0cmFpbmVkIGluIHN1Y2ggYSB3YXkgdGhhdCBvbmx5IGEg aG9zdCBhbmQgcG9ydCB3ZXJlDQo+ID4+IGF2YWlsYWJsZSwgdGhlbiB0aGUgdXNlIG9mIC8ud2Vs bC1rbm93bi8gVVJJcyB3b3VsZCBiZSBtb3JlDQo+ID4+IHVuZGVyc3RhbmRhYmxlLiBUaGUgb25s eSBjb25zdHJhaW50IGhpbnRlZCBhdCBpbiB0aGlzIGRvY3VtZW50IHRoYXQgbWlnaHQNCj4gPj4g aGF2ZSB0aGVzZSBwcm9wZXJ0aWVzIGlzIHRoZSB1c2Ugb2YgRE5TIFNSViByZWNvcmRzLiBHaXZl biB0aGF0IFJPTElFIGlzDQo+ID4+IGRlZmluaW5nIGEgZ3JlZW4tZmllbGQgcHJvdG9jb2wsIHRo ZSB1c2Ugb2Ygc29tZXRoaW5nIGFzIGNvbnN0cmFpbmVkIGFzDQo+IFNSVg0KPiA+PiBzZWVtcyBp bGwtYWR2aXNlZCwgZ2l2ZW4gdGhhdCB0aGUgdXNlIG9mIE5BUFRSIHJlY29yZHMgd291bGQgdHJp dmlhbGx5DQo+IGFsbG93DQo+ID4+IHJldHJpZXZhbCBvZiBhIGNvbXBsZXRlIFVSTCBpbnN0ZWFk IG9mIGp1c3QgYSBob3N0L3BvcnQgY29tYmluYXRpb24uDQo+ID4+DQo+ID4+IFRoZSBib3R0b20g bGluZSwgaG93ZXZlciwgaXMgdGhhdCB3ZSBuZWVkIHRvIGRlZmVyIHNwZWNpZmljYXRpb24gb2Yg YQ0KPiAvLndlbGwtDQo+ID4+IGtub3duLyBVUkwgdW50aWwgd2UgY29tcGxldGVseSBkZWZpbmUg YSBkaXNjb3ZlcnkgcHJvdG9jb2wgdGhhdCByZXF1aXJlcw0KPiBpdC4NCj4gPj4gVGhlIGNvcm9s bGFyeSBpcyB0aGF0IHdlIHNob3VsZCBhdm9pZCBkZWZpbmluZyBhIGRpc2NvdmVyeSBwcm90b2Nv bCB0aGF0DQo+ID4+IHJlcXVpcmVzIGl0Lg0KPiA+Pg0KPiA+IEkgcmVwbGllZCB0byBNYXJ0aW4n cyBjb25jZXJuIG9uIHRoaXMgaXNzdWUgaW4gYW4gZWFybGllciBlLW1haWwgYW5kIEkgdGhpbmsN Cj4gd2UndmUgcmVhY2hlZCBhZ3JlZW1lbnQgb24gdGhlIGp1c3RpZmljYXRpb24gZm9yIHRoZSB3 ZWxsLWtub3duDQo+IHJlZ2lzdHJhdGlvbg0KPiAoaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZtYWlsYQ0KPiByY2hpdmUuaWV0 Zi5vcmclMkZhcmNoJTJGbXNnJTJGbWlsZSUyRmdiRzVuQzhPaDRxNzZQLTBkWEh3TS0NCj4genRN UFkmZGF0YT0wMiU3QzAxJTdDc3RlcGhlbi5iYW5naGFydCU0MG5pc3QuZ292JTdDODNjMjg2Yzky NmVkNGMNCj4gODUyNzQzMDhkNTFiZjE4MGJhJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVj NjFkZWMlN0MxJTdDMCU3Qw0KPiA2MzY0NDU2NDY0NDUzNTI1NTkmc2RhdGE9ZmpjVGNsajJwY2pW eUZMMCUyRjl4bU5qVld3OFY4WG5FZldXSkINCj4gT3NocWxCTSUzRCZyZXNlcnZlZD0wKQ0KPiA+ DQo+ID4gV2UgYmVsaWV2ZSB0aGF0IHdlIGhhdmUgYSBtaW5pbWFsIHVzZSBjYXNlL2Rpc2NvdmVy eSBzdG9yeSB3aGVyZSBST0xJRQ0KPiBjbGllbnRzIG9ubHkgaGF2ZSB0aGUgaG9zdCBuYW1lIGFu ZCBwb3J0IGZvciBhIHBvdGVudGlhbCBST0xJRSBzZXJ2ZXIsIGFuZA0KPiBuZWVkIGEgc3RhbmRh cmRpemVkIHdheSB0byBjaGVjay9sb2NhdGUgdGhlIG1ldGFkYXRhIG9mIGFuIGFzc29jaWF0ZWQN Cj4gUk9MSUUgcmVwb3NpdG9yeS4gSW4gdGhlc2UgY2FzZXMgYXV0b21hdGVkIHN5c3RlbXMgbmVl ZCBhIG1lYW5zIHRvIGxvY2F0ZQ0KPiBhIFJPTElFIHJlcG9zaXRvcnkgd2l0aG91dCBhIGh1bWFu IG5lZWRpbmcgdG8gdHJhY2sgZG93biBhIGxpbmsgdGhyb3VnaA0KPiBicm93c2luZyB0aGUgc2l0 ZSwgZW1haWwsIGV0Yy4gUHJvdmlkaW5nIGEgVVJMIHRlbXBsYXRlIGZvciB0aGUgU2VydmljZQ0K PiBEb2N1bWVudCBhbGxvd3MgdGhlc2UgYXV0b21hdGVkIHN5c3RlbXMgdG8gZmluZCB0aGUgaGVh ZCBvZiB0aGUgUk9MSUUNCj4gcmVwb3NpdG9yeSwgZnJvbSB0aGVyZSBpdCBjYW4gYnJvd3NlIHRo ZSByZXN0IG9mIHRoZSBDb2xsZWN0aW9ucy9FbnRyaWVzDQo+IHByZXNlbnQuDQo+ID4NCj4gPiBX ZSd2ZSBhZGRlZCBhZGRpdGlvbmFsIHRleHQgdG8gdGhlIHNlY3Rpb24gaW4gb3JkZXIgdG8gcHJv dmlkZSBtb3JlDQo+IGp1c3RpZmljYXRpb24vcmVhc29uaW5nIGFyb3VuZCBvdXIgd2VsbC1rbm93 biByZWdpc3RyYXRpb24uIEkndmUgcHJvdmlkZWQgdGhlDQo+IG5ldyBwYXJhZ3JhcGggaGVyZToN Cj4gPg0KPiA+ICJST0xJRSByZXBvc2l0b3JpZXMgYXJlIGxhcmdlbHkgaW50ZW5kZWQgdG8gYmUg Y29uc3VtZWQgYnkgYXV0b21hdGVkDQo+IHN5c3RlbXMuIFdoaWxlIGh1bWFucyBtYXkgYmUgYWJs ZSB0byBuYXZpZ2F0ZSBhIHdlYiBwYWdlIG9yIHJlY2VpdmUgYW4NCj4gZW1haWwgdG8gZmluZCBh IGxpbmsgdG8gdGhlIHJlcG9zaXRvcnksIGF1dG9tYXRlZCBzeXN0ZW1zIHN0cnVnZ2xlIHdpdGgg c3VjaA0KPiB0YXNrcy4gQnkgY3JlYXRpbmcgYSBzdGFuZGFyZGl6ZWQgbG9jYXRpb24gZm9yIHRo ZSBTZXJ2aWNlIERvY3VtZW50LCBST0xJRQ0KPiBjbGllbnRzIG5lZWQgb25seSBhIGhvc3QgbmFt ZSBhbmQgcG9ydCBpbiBvcmRlciB0byBsb2NhdGUgYSBST0xJRSByZXBvc2l0b3J5Lg0KPiBUaGlz IGxvd2VyIGJhcnJpZXIgdG8gZW50cnkgcmVkdWNlcyB0aGUgYW1vdW50IG9mIGh1bWFuIGludGVy dmVudGlvbg0KPiByZXF1aXJlZCBmb3IgUk9MSUUgY2xpZW50cyB0byBiZWdpbiByZWFkaW5nIEZl ZWRzLiINCj4gPg0KPiA+IFdlIGRpc2N1c3NlZCB0aGlzIHdpdGhpbiB0aGUgTUlMRSBXRyBhbmQg dGhlIFdHIGFncmVlZCB0byBkZWZpbmUgdGhlDQo+IC53ZWxsLWtub3duIGFwcHJvYWNoLCBidXQg dG8gZGVmZXIgb24gYSBzcGVjaWZpYyBtZWFucyB0byBkZXRlcm1pbmUgdGhlDQo+IGhvc3QgYW5k IHBvcnQgb2YgdGhlIHNlcnZlciBhdCB0aGlzIHRpbWUuIFRoaXMgd2lsbCBhbGxvdyB0aGUgZ3Jv dXAgdG8gZ2V0IHNvbWUNCj4gaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSB3aXRoIFJPTElFLCB3 aGlsZSByZXZpZXdpbmcgdGhlIFNSViBhbmQgTkFQVFINCj4gcmVjb3JkIGFwcHJvYWNoZXMgdG8g ZGV0ZXJtaW5lIHdoYXQgdGhlIGJlc3QgYXBwcm9hY2ggaXMuIFdlIGNhbiB0aGVuDQo+IHdyaXRl IGFub3RoZXIgZHJhZnQgdGhhdCBwcm92aWRlcyB0aGVzZSBkZXRhaWxzIHdoZW4gd2UgYXJlIHJl YWR5LiBJbiBhbnkNCj4gY2FzZSwgd2Ugc3RpbGwgbmVlZCBhIHdheSB0byBkaXNjb3ZlciB0aGUg U2VydmljZSBEb2N1bWVudCwgc28gdGhlIFdHIGZvdW5kDQo+IGl0IHRvIGJlIHBydWRlbnQgdG8g ZG8gdGhhdCBub3cuDQo+ID4NCj4gPiBGb2xsb3dpbmcgTWFydGluJ3MgY29tbWVudHMsIHdlIHJl bW92ZWQgdGhlIHdlbGwta25vd24gcmVnaXN0cmF0aW9uIGZvcg0KPiB0aGUgQ2F0ZWdvcnkgRG9j dW1lbnQsIGFzIHRoaXMgaXMgZGlzY292ZXJhYmxlIGZyb20gdGhlIFNlcnZpY2UgRG9jdW1lbnQu DQo+ID4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiBDT01NRU5UOg0KPiA+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4+DQo+ID4+IFNpbmNlIFJPTElFIHJlcXVpcmVzIHRoZSB1c2Ugb2YgVExTIGNsaWVu dCBjZXJ0aWZpY2F0ZXMsIGFsbCBvZiBpdHMgcmVzb3VyY2VzDQo+IG5lZWQNCj4gPj4gdG8gYmUg Y29udmV5ZWQgb3ZlciBIVFRQUyAoaS5lLiwgUk9MSUUgcmVzb3VyY2VzIGNhbiBuZXZlciB1c2Ug Imh0dHAiIElSSQ0KPiA+PiBzY2hlbWVzLCBvbmx5ICJodHRwcyIgSVJJIHNjaGVtZXMpLiBUaGUg Zm9sbG93aW5nIGV4YW1wbGVzIG5lZWQgdG8gYmUNCj4gZml4ZWQNCj4gPj4gdG8gcmVmbGVjdCB0 aGlzOg0KPiA+IFRoYW5rcyBmb3IgY2F0Y2hpbmcgdGhpcy4gVGhlIGxpbmtzIGhhdmUgYmVlbiBj aGFuZ2VkIHRvIGh0dHBzLg0KPiA+DQo+ID4+IFNlY3Rpb24gNi4xLjI6DQo+ID4+DQo+ID4+ICAg ICAgICAgICA8bGluayByZWw9InNlbGYiDQo+ID4+DQo+IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkYNCj4gPj4NCj4g ZXhhbXBsZS5vcmclMkZmZWVkQSUzRnBhZ2UlM0Q1JmRhdGE9MDIlN0MwMSU3Q3N0ZXBoZW4uYmFu Z2hhcnQNCj4gPj4NCj4gJTQwbmlzdC5nb3YlN0MwODQ1NmQwOWZhMWQ0YzFkYTJlYTA4ZDUxYjVk NmI3MSU3QzJhYjVkODJmZDhmYTQ3OTcNCj4gPj4NCj4gYTkzZTA1NDY1NWM2MWRlYyU3QzElN0Mw JTdDNjM2NDQ1MDEwNDM3ODM3NDA0JnNkYXRhPU4yWElVV2VjSXIlDQo+ID4+IDJCb0VIbkJTVFZa UzBYMkJaUkJkcFIzTiUyQldIWUMzVVpJNCUzRCZyZXNlcnZlZD0wIi8+DQo+ID4+ICAgICAgICAg ICA8bGluayByZWw9ImZpcnN0Ig0KPiA+Pg0KPiBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGDQo+ID4+DQo+IGV4YW1w bGUub3JnJTJGZmVlZEElM0ZwYWdlJTNEMSZkYXRhPTAyJTdDMDElN0NzdGVwaGVuLmJhbmdoYXJ0 DQo+ID4+DQo+ICU0MG5pc3QuZ292JTdDMDg0NTZkMDlmYTFkNGMxZGEyZWEwOGQ1MWI1ZDZiNzEl N0MyYWI1ZDgyZmQ4ZmE0Nzk3DQo+ID4+DQo+IGE5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYz NjQ0NTAxMDQzNzgzNzQwNCZzZGF0YT1yMnczMk4lMkI4Rg0KPiA+PiBKWVduVklPYlglMkJMV1N1 eUN5TFYlMkJIQUVRbEtSQUVCa0FvMCUzRCZyZXNlcnZlZD0wIi8+DQo+ID4+ICAgICAgICAgICA8 bGluayByZWw9InByZXYiDQo+ID4+DQo+IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkYNCj4gPj4NCj4gZXhhbXBsZS5v cmclMkZmZWVkQSUzRnBhZ2UlM0Q0JmRhdGE9MDIlN0MwMSU3Q3N0ZXBoZW4uYmFuZ2hhcnQNCj4g Pj4NCj4gJTQwbmlzdC5nb3YlN0MwODQ1NmQwOWZhMWQ0YzFkYTJlYTA4ZDUxYjVkNmI3MSU3QzJh YjVkODJmZDhmYTQ3OTcNCj4gPj4NCj4gYTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2NDQ1 MDEwNDM3ODM3NDA0JnNkYXRhPVFoRVlONFolMkYNCj4gPj4gJTJCOG5laWtQTndKR0wlMkJHdG9F VTBnQnJWbFFiYW5YbmFRcmdRJTNEJnJlc2VydmVkPTAiLz4NCj4gPj4gICAgICAgICAgIDxsaW5r IHJlbD0ibmV4dCINCj4gPj4NCj4gaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRg0KPiA+Pg0KPiBleGFtcGxlLm9yZyUy RmZlZWRBJTNGcGFnZSUzRDYmZGF0YT0wMiU3QzAxJTdDc3RlcGhlbi5iYW5naGFydA0KPiA+Pg0K PiAlNDBuaXN0LmdvdiU3QzA4NDU2ZDA5ZmExZDRjMWRhMmVhMDhkNTFiNWQ2YjcxJTdDMmFiNWQ4 MmZkOGZhNDc5Nw0KPiA+Pg0KPiBhOTNlMDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2MzY0NDUwMTA0 Mzc4Mzc0MDQmc2RhdGE9cEVKS20xWnV5ajZTDQo+ID4+IGREVWtVa0NyUVVScTVLek1tYXd3VElT WlNXZDMlMkIzbyUzRCZyZXNlcnZlZD0wIi8+DQo+ID4+ICAgICAgICAgICA8bGluayByZWw9Imxh c3QiDQo+ID4+DQo+IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkYNCj4gPj4NCj4gZXhhbXBsZS5vcmclMkZmZWVkQSUz RnBhZ2UlM0QxMCZkYXRhPTAyJTdDMDElN0NzdGVwaGVuLmJhbmdoYXINCj4gPj4NCj4gdCU0MG5p c3QuZ292JTdDMDg0NTZkMDlmYTFkNGMxZGEyZWEwOGQ1MWI1ZDZiNzElN0MyYWI1ZDgyZmQ4ZmE0 Nzk3DQo+ID4+DQo+IGE5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjQ0NTAxMDQzNzgzNzQw NCZzZGF0YT1tSDc3cncxVGxzWA0KPiA+PiA4SnVPWTNFSEp5T0VwRXpHUGNva3V4Z2lUJTJGMzIl MkZsa1klM0QmcmVzZXJ2ZWQ9MCIvPg0KPiA+Pg0KPiA+PiBTZWN0aW9uIEIuMToNCj4gPj4NCj4g Pj4gICAgICAgICAgPGNvbGxlY3Rpb24NCj4gPj4NCj4gaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRg0KPiA+Pg0KPiBl eGFtcGxlLm9yZyUyRnByb3ZpZGVyJTJGdnVsbnMmZGF0YT0wMiU3QzAxJTdDc3RlcGhlbi5iYW5n aGFydCU0DQo+ID4+DQo+IDBuaXN0LmdvdiU3QzA4NDU2ZDA5ZmExZDRjMWRhMmVhMDhkNTFiNWQ2 YjcxJTdDMmFiNWQ4MmZkOGZhNDc5N2E5Mw0KPiA+Pg0KPiBlMDU0NjU1YzYxZGVjJTdDMSU3QzAl N0M2MzY0NDUwMTA0Mzc4Mzc0MDQmc2RhdGE9U0hOb1YzS09kOUJ4Qg0KPiA+PiBuZ0NLQW1wbkt3 eDlBcWZXQlRkWlRUZXZJWkZNY3clM0QmcmVzZXJ2ZWQ9MCI+DQo+ID4+IC4uLg0KPiA+PiAgICAg ICAgICA8Y29sbGVjdGlvbg0KPiA+Pg0KPiA+Pg0KPiBocmVmPSJodHRwczovL25hMDEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGDQo+ID4+DQo+IGV4 YW1wbGUub3JnJTJGcHJvdmlkZXIlMkZwdWJsaWMlMkZ2dWxucyZkYXRhPTAyJTdDMDElN0NzdGVw aGVuLmJhDQo+ID4+DQo+IG5naGFydCU0MG5pc3QuZ292JTdDMDg0NTZkMDlmYTFkNGMxZGEyZWEw OGQ1MWI1ZDZiNzElN0MyYWI1ZDgyZmQ4Zg0KPiA+Pg0KPiBhNDc5N2E5M2UwNTQ2NTVjNjFkZWMl N0MxJTdDMCU3QzYzNjQ0NTAxMDQzNzgzNzQwNCZzZGF0YT1CdDJTT24wDQo+ID4+IGJzZU12OVpF M2R4a201JTJGdHFGSm9zUUtFMVhDNE9wUmZrSFp3JTNEJnJlc2VydmVkPTAiPg0KPiA+PiAuLi4N Cj4gPj4gICAgICAgICAgPGNvbGxlY3Rpb24NCj4gPj4NCj4gPj4NCj4gaHJlZj0iaHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRg0K PiA+Pg0KPiBleGFtcGxlLm9yZyUyRnByb3ZpZGVyJTJGcHJpdmF0ZSUyRmluY2lkZW50cyZkYXRh PTAyJTdDMDElN0NzdGVwaGUNCj4gPj4NCj4gbi5iYW5naGFydCU0MG5pc3QuZ292JTdDMDg0NTZk MDlmYTFkNGMxZGEyZWEwOGQ1MWI1ZDZiNzElN0MyYWI1ZDgNCj4gPj4NCj4gMmZkOGZhNDc5N2E5 M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjQ0NTAxMDQzNzgzNzQwNCZzZGF0YT1UWA0KPiA+ PiBOWTQyNEEzSnVIanFNbFBvUmZabVZUbHdScTAlMkZHU2VXRklQZ2JsUGUwJTNEJnJlc2VydmVk PTAiPg0KPiA+PiAuLi4NCj4gPj4gICAgICAgICA8bGluayByZWw9InNlbGYiDQo+ID4+DQo+ID4+ DQo+IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHAlM0ElMkYlMkYNCj4gPj4NCj4gZXhhbXBsZS5vcmclMkZwcm92aWRlciUyRnB1Ymxp YyUyRnZ1bG5zJmRhdGE9MDIlN0MwMSU3Q3N0ZXBoZW4uYmENCj4gPj4NCj4gbmdoYXJ0JTQwbmlz dC5nb3YlN0MwODQ1NmQwOWZhMWQ0YzFkYTJlYTA4ZDUxYjVkNmI3MSU3QzJhYjVkODJmZDhmDQo+ ID4+DQo+IGE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2NDQ1MDEwNDM3ODM3NDA0 JnNkYXRhPUJ0MlNPbjANCj4gPj4gYnNlTXY5WkUzZHhrbTUlMkZ0cUZKb3NRS0UxWEM0T3BSZmtI WnclM0QmcmVzZXJ2ZWQ9MCIgLz4NCj4gPj4gICAgICAgICA8bGluayByZWw9InNlcnZpY2UiDQo+ ID4+DQo+ID4+DQo+IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkYNCj4gPj4NCj4gZXhhbXBsZS5vcmclMkZyb2xpZSUy RnNlcnZpY2Vkb2N1bWVudCZkYXRhPTAyJTdDMDElN0NzdGVwaGVuLmJhbmcNCj4gPj4NCj4gaGFy dCU0MG5pc3QuZ292JTdDMDg0NTZkMDlmYTFkNGMxZGEyZWEwOGQ1MWI1ZDZiNzElN0MyYWI1ZDgy ZmQ4ZmE0DQo+ID4+DQo+IDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYzNjQ0NTAxMDQz NzgzNzQwNCZzZGF0YT16b0RMbjY5OVYNCj4gPj4gVCUyRmxxaVl6YXVSMUl0YktTaUlxJTJGYmh3 VXp3aE10N3U1b0klM0QmcmVzZXJ2ZWQ9MCIvPg0KPiA+PiAuLi4NCj4gPj4gICAgICAgICAgIDxj b250ZW50IHR5cGU9ImFwcGxpY2F0aW9uL3htbCINCj4gPj4NCj4gPj4NCj4gc3JjPSJodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJG dw0KPiA+Pg0KPiB3dy5leGFtcGxlLm9yZyUyRnByb3ZpZGVyJTJGdnVsbnMlMkYxMjM0NTYlMkZk YXRhJmRhdGE9MDIlN0MwMSUNCj4gPj4NCj4gN0NzdGVwaGVuLmJhbmdoYXJ0JTQwbmlzdC5nb3Yl N0MwODQ1NmQwOWZhMWQ0YzFkYTJlYTA4ZDUxYjVkNmI3MSUNCj4gPj4NCj4gN0MyYWI1ZDgyZmQ4 ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2NDQ1MDEwNDM3ODM3NDA0Jg0KPiA+ Pg0KPiBzZGF0YT1oRFRoa3hjbVAzMFhZSE1lRDU4QWFUOWtKc05vNTFMOTdOVEFuVlRuVVBzJTNE JnJlc2VydmVkDQo+ID4+ID0wIi8+DQo+ID4+IC4uLg0KPiA+PiAgICAgICAgIDxjb250ZW50IHR5 cGU9ImFwcGxpY2F0aW9uL3htbCINCj4gPj4NCj4gPj4NCj4gc3JjPSJodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGdw0KPiA+Pg0K PiB3dy5leGFtcGxlLm9yZyUyRnByb3ZpZGVyJTJGdnVsbnMlMkYxMjM0NTYlMkZkYXRhJmRhdGE9 MDIlN0MwMSUNCj4gPj4NCj4gN0NzdGVwaGVuLmJhbmdoYXJ0JTQwbmlzdC5nb3YlN0MwODQ1NmQw OWZhMWQ0YzFkYTJlYTA4ZDUxYjVkNmI3MSUNCj4gPj4NCj4gN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkz ZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2NDQ1MDEwNDM3ODM3NDA0Jg0KPiA+Pg0KPiBzZGF0 YT1oRFRoa3hjbVAzMFhZSE1lRDU4QWFUOWtKc05vNTFMOTdOVEFuVlRuVVBzJTNEJnJlc2VydmVk DQo+ID4+ID0wIj4NCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+DQo+ID4+IEFkZGl0aW9uYWxseSwgdGhl IGZvbGxvd2luZyBocmVmIHZhbHVlcyAoYWxzbyBpbiBCLjEpIGFyZSBpbGxlZ2FsLCBhbmQgbmVl ZCB0bw0KPiA+PiBjb250YWluIGEgc2NoZW1lIChwcmVzdW1hYmx5LCBodHRwcyk6DQo+ID4gQWxz byBmaXhlZC4NCj4gPg0KPiA+PiAgICAgICAgICAgIDxhdG9tOmxpbmsgcmVsPSJzZXJ2aWNlIg0K PiA+Pg0KPiA+Pg0KPiBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD13d3cuZXhhbXBsZS5jbw0KPiA+Pg0KPiBtJTJGcm9saWUlMkZzZXJ2aWNl ZG9jdW1lbnQmZGF0YT0wMiU3QzAxJTdDc3RlcGhlbi5iYW5naGFydCU0MG5pDQo+ID4+DQo+IHN0 LmdvdiU3QzA4NDU2ZDA5ZmExZDRjMWRhMmVhMDhkNTFiNWQ2YjcxJTdDMmFiNWQ4MmZkOGZhNDc5 N2E5M2UwDQo+ID4+DQo+IDU0NjU1YzYxZGVjJTdDMSU3QzAlN0M2MzY0NDUwMTA0Mzc4Mzc0MDQm c2RhdGE9cmFuazZTbWJtcSUyQlFzDQo+ID4+IEdwVkoxcXNjWW4lMkYzU0Ewa3JxS0RQUUI1R1N4 bTFRJTNEJnJlc2VydmVkPTAiLz4NCj4gPj4gLi4uDQo+ID4+ICAgICAgICAgICAgPGF0b206bGlu ayByZWw9InNlcnZpY2UiDQo+ID4+DQo+ID4+DQo+IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPXd3dy5leGFtcGxlLmNvDQo+ID4+DQo+IG0l MkZyb2xpZSUyRnNlcnZpY2Vkb2N1bWVudCZkYXRhPTAyJTdDMDElN0NzdGVwaGVuLmJhbmdoYXJ0 JTQwbmkNCj4gPj4NCj4gc3QuZ292JTdDMDg0NTZkMDlmYTFkNGMxZGEyZWEwOGQ1MWI1ZDZiNzEl N0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTANCj4gPj4NCj4gNTQ2NTVjNjFkZWMlN0MxJTdDMCU3QzYz NjQ0NTAxMDQzNzgzNzQwNCZzZGF0YT1yYW5rNlNtYm1xJTJCUXMNCj4gPj4gR3BWSjFxc2NZbiUy RjNTQTBrcnFLRFBRQjVHU3htMVElM0QmcmVzZXJ2ZWQ9MCIvPg0KPiA+Pg0KDQo= From nobody Thu Oct 26 10:55:32 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A1C13F5D3; Thu, 26 Oct 2017 10:55:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , "Nancy Cam-Winget" X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150904052968.24220.18028595285214324530.idtracker@ietfa.amsl.com> Date: Thu, 26 Oct 2017 10:55:29 -0700 From: IETF Secretariat Archived-At: Subject: [mile] Datatracker State Update Notice: X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 17:55:30 -0000 IESG state changed: New State: IESG Evaluation::Revised I-D Needed (The previous state was IESG Evaluation) Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/ From nobody Fri Oct 27 06:31:14 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0805413A292; Fri, 27 Oct 2017 06:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 6zmgi69360zy; Fri, 27 Oct 2017 06:31:10 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6EA13F516; Fri, 27 Oct 2017 06:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1509111068; d=isode.com; s=june2016; i=@isode.com; bh=HeTpTvcxU8j3eraHDTlJh+yf0Y/il6QfHxh/MIhQvL8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=eYFS2TVkVPmulEoOfAYkc/bDkvFDfklgH63CCpq46GDGrDkflLD6ILlAGOciujG1gajcAg gCMbVQS3b1Ss5k9VxJG516r1xbP0aWxkw2kXzITzHYywxnNtjxG+MDPzAHuUbdtEEsAMxM /FYr33Y3korTi/XkDWMypzHrLwcjF6A=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 27 Oct 2017 14:31:07 +0100 To: "Banghart, Stephen A. (Fed)" , Alexey Melnikov , The IESG Cc: "draft-ietf-mile-rolie@ietf.org" , "mile@ietf.org" , "mile-chairs@ietf.org" , "mile-chairs@tools.ietf.org" References: <150901779979.24032.748907899531480416.idtracker@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <15775d70-9578-b186-2e93-83d4b5d9160c@isode.com> Date: Fri, 27 Oct 2017 14:30:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [mile] Alexey Melnikov's Discuss on draft-ietf-mile-rolie-12: (with DISCUSS and COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 13:31:13 -0000 Hi Stephen, On 26/10/2017 15:53, Banghart, Stephen A. (Fed) wrote: > Alexey, > > Thanks for the review, comments inline. > > Thanks, > Stephen Banghart > >> -----Original Message----- >> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Alexey Melnikov >> Sent: Thursday, October 26, 2017 7:37 AM >> To: The IESG >> Cc: draft-ietf-mile-rolie@ietf.org; mile@ietf.org; mile-chairs@ietf.org; = mile- >> chairs@tools.ietf.org >> Subject: [mile] Alexey Melnikov's Discuss on draft-ietf-mile-rolie-12: (w= ith >> DISCUSS and COMMENT) >> >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-mile-rolie-12: Discuss >> > [snip] >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This is a useful document and I will be balloting "Yes" once the followin= g small >> issues are resolved/discussed (some of these come from Martin's ARTART >> review): >> >> 1) 7.4. The "rolie:property" Extension Point >> >> urn:ietf:params:rolie:property:content-id The "value" attribute of >> this property is a text representation of an identifier pertaining >> to or extracted from the content referenced by the "src" attribute >> of the entry's atom:content element. >> >> Maybe it is just me, but I can't figure out what is the syntax of this fi= eld. >> Can you provide a reference or at least give an example? > Sure. This field is exposing some identifier for the resource in the atom:= content element. For example, if the atom:content is linking to an IODEF doc= ument, the only way (without this property) for a consumer to learn any iden= tifying information about that document is to download it. > > For the sake of example, lets say that inside that IODEF document is a ID= =3D"ID12345" element. In the ROLIE feed, the rolie:property element exposes = the ID, so then the rolie:property field would be "name"=3D "urn:ietf:params= :rolie:property:content-id" and value=3D"ID12345". > > If this still seems confusing we can rewrite the text in the specification= or include an example to clarify. I think giving an example for IODEF would be great. If the value can be=20 anything else, it would be good to say that too. (I was partially confused because Content-ID means something else in=20 email, so lack of reference is not helping.) >> 2) From Martin's review: >> >> Section 5.5 prohibits the use of GET on "/". This prohibits use of the r= esource >> for other purposes. It seems reasonable to accept POST messages as >> defined in RFC 6546, but this requirement is overly strict (and further >> entrenches the violation of RFC 7320). If, for instance, the server oper= ator >> wishes to provide HTML in response to a GET request to "/", this would >> prohibit that. The requirement to return 404 if RFC 6546 is not supporte= d is >> worse; not supporting RFC 6546 might be a choice that a deployment makes >> to avoid the need to reserve "/" for that protocol. >> >> Alexey: The text in -12 is an improvement, but I think it is still confus= ing. >> Maybe mention something along the lines of Martin's suggestion for the ca= se >> when RFC 6546 is not supported (or at least not followed as far as the "/= " >> resource is concerned). >> >> 5.5. / (forward slash) Resource URL >> >> If the "/" resource is unsupported, then a request for this resource >> MAY be handled as deemed appropriate by the server. >> >> Nit: You haven't expressed any requirement on implementations here, so >> use of MAY does not seem appropriate. What are you actually suggesting >> here? > This last sentence was meant to be addressing the case where RFC 6546 is n= ot supported. I've removed the normative requirement and updated the sentenc= e: > > "If RFC 6546 is unsupported, then a request for the "/" resource may be ha= ndled as deemed appropriate by the server." > > And to help clarify I have added this sentence to the first paragraph: > > "The following requirements apply only to implementations supporting RFC 6= 546." > > Does this address your concerns? I'd like to fully address Martin's origin= al comments, as I agree that restricting the "/" resource on all servers is = detrimental. Works for me. >> 3) I think some of the text in 6.1.2 is misleading (or I might be wrong): >> >> Based on RFC5005 section 3 [RFC5005], link >> elements SHOULD be included in all Feeds to support paging using the >> following link relation types: >> >> o "first" - Indicates that the href attribute value of the link >> identifies a resource URI for the furthest preceding page of the >> Feed. >> >> o "last" - Indicates that the href attribute value of the link >> identifies a resource URI for the furthest following page of the >> Feed. >> >> o "previous" - Indicates that the href attribute value of the link >> identifies a resource URI for the immediately preceding page of >> the Feed. >> >> o "next" - Indicates that the href attribute value of the link >> identifies a resource URI for the immediately following page of >> the Feed. >> >> Original definitions of these link relations don't include the word "page= ". I >> should double check with Mark Nottigham, but I think they reference the >> next/previous, first/last entry, not page. (And a page may contain severa= l >> entries.) If I am correct, I don't think it is Ok to redefine meaning of = existing >> link relations the way you do. > Section 3 ("Paged Feeds") in RFC 5005 defines paged feeds as a set of link= ed feed documents, where each feed document contains a subset of entries. Th= e explicit wording used in the link relations is as follows: > > o "first" - A URI that refers to the furthest preceding document in > a series of documents. > > o "last" - A URI that refers to the furthest following document in a > series of documents. > > o "previous" - A URI that refers to the immediately preceding > document in a series of documents. > > o "next" - A URI that refers to the immediately following document > in a series of documents. > > We've swapped in the word "page" instead of "document" in our document, as= we felt that "page" made more inherent sense without the context of the res= t of RFC 5005. I believe that we have not changed the definition of the link= relations in any way, so changing the wording back to the original would no= t be a huge problem for us if you think it is needed. Let me following with Mark Nottingham on this. >> 4) In Section 8.3: >> >> Registration in the ROLIE URN Parameters registry is via the >> Specification Required policy [RFC8126]. Designated Expert reviews >> should be routed through the MILE WG mailing list. Failing this, the >> Designated Expert will be assigned by the IESG. >> >> As other people already pointed out, the last 2 sentences are confusing. >> Are you trying to say that registration requests must be sent to the MILE >> mailing list or that they must be reviewed there? This is actually signif= icant for >> IANA workflow. >> >> One possibility is that all requests are sent to the MILE mailing list an= d then >> the designated expert forwards approved requests to IANA. In this case if= a >> Designated Expert misses a request, IANA wouldn't even know that the >> requester is waiting for the Designated Expert. >> >> Another possibility is for all requests to be submitted to IANA directly,= then >> IANA can track them. IANA might either forward requests to the MILE maili= ng >> list or require that all request being submitted to the MILE mailing list= first >> before being sent to IANA. >> >> So please clarify. > Our original intent here was to have IANA receive and track requests, then= send the requests to the MILE mailing list, and then if there is no respons= e, fall back to pre-named Designated Experts (the authors). IANA doesn't track comments, because they lack technical skills to=20 evaluate request. So a Designated Expert must always be involved. > We are having trouble correctly putting together text to express this. Maybe say something like this: OLD: Designated Expert reviews should be routed through the MILE WG mailing list. Failing this, the Designated Expert will be assigned by the IESG. NEW: Registration requests must be sent to both the MILE WG mailing list (mil= e@ietf.org) and IANA. IANA will forward registration requests to the Designated Expe= rt. Or you can ask IANA if they are happy to just receive and forward all regist= ration requests to mile@ietf.org. (There is no need to say "Designated Expert will be assigned by the IESG", b= ecause this is the default.) >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- =C2=A0(snip) >> In 6.2.3 (on page 17) >> >> The URI used for the "ns" attribute value MUST be an absolute >> or opaque URI. >> >> What is "opaque" URI? The sentence make it sound as if it is a term, oppo= site >> to absolute URI. Or are you trying to say that non resolvable URNs are Ok >> here? >> I suggest deleting "or opaque" from the above sentence or replacing it wi= th >> something clearer. > I've deleted the "or opaque", as the intent was to disallow relative URIs.= I think that the current requirement followed by the last sentence of the p= aragraph (The resource identified by the URI need not be resolvable.) provid= e enough information. Agreed. >> In 6.2.4. Use of the rolie:property Element >> >> Implementations MAY use locally defined and namespaced elements in an >> Entry in order to provide additional information. Clients that do >> not recognize a property with an unregistered name attribute MAY >> ignore the rolie:property. >> >> The second "MAY": or do what? Should the MAY be changed to a MUST? >> > Yes, this was intended to be a MUST. The client MUST NOT fail parsing cont= ent that contains an unrecognized property. I changed the keyword to MUST an= d provided some additional text to clarify: > > "The client MUST NOT fail parsing content that > contains an unrecognized property." Much better, thank you. From nobody Fri Oct 27 10:52:36 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EFC13F5B1; Fri, 27 Oct 2017 10:52:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 2e5sa1nZ2wkn; Fri, 27 Oct 2017 10:52:26 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0104.outbound.protection.outlook.com [23.103.201.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B87113F422; Fri, 27 Oct 2017 10:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MUxmNcb77VYXYPmqDDEJqmNtTjE19Y6xxsGFX/AlSeo=; b=utV1Is+uubxRCo/BXasEtLSW0fcT2mOjZYOBr9TOTLDmh0QbZ2GDKpPScDlv5PaEGC2FUAcxwa3tregXDyyK4zl98maAhDpmdIr2IVpFdOT7sKsQL/8XHl9ijNyMbOPGLQn7ml6kE+IFAKb3XyItrvjiCvl+k4Om54gPonu5VZk= Received: from MWHPR09MB1197.namprd09.prod.outlook.com (10.172.49.143) by MWHPR09MB1197.namprd09.prod.outlook.com (10.172.49.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Fri, 27 Oct 2017 17:52:22 +0000 Received: from MWHPR09MB1197.namprd09.prod.outlook.com ([10.172.49.143]) by MWHPR09MB1197.namprd09.prod.outlook.com ([10.172.49.143]) with mapi id 15.20.0178.007; Fri, 27 Oct 2017 17:52:22 +0000 From: "Banghart, Stephen A. (Fed)" To: Alexey Melnikov , Alexey Melnikov , The IESG CC: "draft-ietf-mile-rolie@ietf.org" , "mile@ietf.org" , "mile-chairs@ietf.org" , "mile-chairs@tools.ietf.org" Thread-Topic: [mile] Alexey Melnikov's Discuss on draft-ietf-mile-rolie-12: (with DISCUSS and COMMENT) Thread-Index: AQHTTyfgFtGQTlSQWU2lQUtx6feo+6L38ppw Date: Fri, 27 Oct 2017 17:52:22 +0000 Message-ID: References: <150901779979.24032.748907899531480416.idtracker@ietfa.amsl.com> <15775d70-9578-b186-2e93-83d4b5d9160c@isode.com> In-Reply-To: <15775d70-9578-b186-2e93-83d4b5d9160c@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.251.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR09MB1197; 6:O/0FzhL2BCpbpl3CeO3TmZuXCEY7shwrCtrGFvPqFcxtJP3aLc7d36digiKWVqvSrlNsFuzczQrtsHzny3CfhrwXNPQg1HkZM42FZF1YRHQi0C1sWyilT8vjQlUpveTvJ63Pu1wRerfjvJ8NTUCQjN+V6bBPEY7QxH7iAcjHX9LYs/ei74tL4NWZLJYHQfJp7IjuUhNPIlhNp1ZTcJKJ79Yazk+e8tlH5Fn5kqI+rDsEdlQk79bkABP6cj74vv84ObhumOIKECQcBXM49lJXQuaqAmgVDzjr+0+Z4iwWDytda9m1uc0D5ckpjdDbeUdjEbHRVa2vbtf3V1NT9Yl1WFzDmkmG5gaU7T7gvNuy/Ys=; 5:zeDGXOyYNkaRmPwBZA/EamMrQ8+BXoObefpSpxHFNPjoT4vhjpGI1NtCN7MidYathX2qV3uBr34ZfdUtBCXPax1dHwJU7O5mwgNcdXX6EySUbX4TnKfdhNMrbG6NfY2P5A6qK9aUYSmLtuWHsJY+KLA1/7b+TmQ9Gm9F519oi6s=; 24:M2lsy9890PxooCHDK3hKRAa+ewwaBOIf7gic+11Rk62M7mDzPH1I/3O2ERUEtAt/ZVGgvpOnEMQlgcRzSilaCuikux42KWRcDiRTZBgdM/o=; 7:AM9PqiUtIotgfQ8F9rewaGXj0sAM/uG8aDtB0pSSXU3DrffhZ6764Zw3wjIfGCH8S0aLvADrtBj+FIsMjG2CWL4dbXhHQkgJqocvLBp/iR7zt290/YR7ZTtRNNPonYtZP3NvQWUJtUPY1nR2DRk0egSIUNyMUqgcWLB4aSz06vkh1HRbmIyjPEeawpfV2NRILpNyCepgCuu6QSbBZc+jC617AcK7Rpb/UqzkVKfsaKEYSHNfstyBoKU+mqdlrCRN x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7d403ea7-aa43-4945-cd2a-08d51d6379ba x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:MWHPR09MB1197; x-ms-traffictypediagnostic: MWHPR09MB1197: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(131327999870524)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(3231020)(6055026)(6041248)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR09MB1197; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR09MB1197; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(24454002)(199003)(51914003)(189002)(13464003)(54906003)(110136005)(86362001)(3660700001)(53936002)(2950100002)(316002)(229853002)(230783001)(14454004)(6246003)(5660300001)(74316002)(105586002)(7696004)(478600001)(76176999)(54356999)(50986999)(189998001)(2900100001)(106356001)(33656002)(101416001)(8676002)(3846002)(8936002)(3280700002)(66066001)(81156014)(4326008)(81166006)(305945005)(53546010)(7736002)(25786009)(8666007)(68736007)(9686003)(2906002)(55016002)(6436002)(6116002)(102836003)(6506006)(77096006)(99286003)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1197; H:MWHPR09MB1197.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 7d403ea7-aa43-4945-cd2a-08d51d6379ba X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 17:52:22.2796 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1197 Archived-At: Subject: Re: [mile] Alexey Melnikov's Discuss on draft-ietf-mile-rolie-12: (with DISCUSS and COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 17:52:29 -0000 QWxleGV5LA0KDQpSZXBvbnNlcyBpbmxpbmUuIEkndmUgYWRkZWQgY2hhbmdlcyBiYXNlZCBvbiB5 b3VyIHJvbGllOnByb3BlcnR5IGNvbW1lbnRzIGFuZCB5b3VyIElBTkEgY29tbWVudHMuIEkgd2ls bCB3YWl0IG9uIE1hcmsncyByZXNwb25zZSBvbiBSRkMgNTAwNSBmb3IgdGhhdCBzZWN0aW9uLg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFsZXhleSBNZWxuaWtvdiBb bWFpbHRvOmFsZXhleS5tZWxuaWtvdkBpc29kZS5jb21dDQo+IFNlbnQ6IEZyaWRheSwgT2N0b2Jl ciAyNywgMjAxNyA5OjMxIEFNDQo+IFRvOiBCYW5naGFydCwgU3RlcGhlbiBBLiAoRmVkKSA8c3Rl cGhlbi5iYW5naGFydEBuaXN0Lmdvdj47IEFsZXhleQ0KPiBNZWxuaWtvdiA8YWFtZWxuaWtvdkBm YXN0bWFpbC5mbT47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1t aWxlLXJvbGllQGlldGYub3JnOyBtaWxlQGlldGYub3JnOyBtaWxlLWNoYWlyc0BpZXRmLm9yZzsg bWlsZS0NCj4gY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbWlsZV0gQWxl eGV5IE1lbG5pa292J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW1pbGUtcm9saWUtMTI6DQo+ICh3 aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBIaSBTdGVwaGVuLA0KPiANCj4gT24gMjYv MTAvMjAxNyAxNTo1MywgQmFuZ2hhcnQsIFN0ZXBoZW4gQS4gKEZlZCkgd3JvdGU6DQo+IA0KPiA+ IEFsZXhleSwNCj4gPg0KPiA+IFRoYW5rcyBmb3IgdGhlIHJldmlldywgY29tbWVudHMgaW5saW5l Lg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IFN0ZXBoZW4gQmFuZ2hhcnQNCj4gPg0KPiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBtaWxlIFttYWlsdG86bWlsZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGV5DQo+ID4+IE1lbG5pa292DQo+ID4+IFNl bnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDc6MzcgQU0NCj4gPj4gVG86IFRoZSBJRVNH IDxpZXNnQGlldGYub3JnPg0KPiA+PiBDYzogZHJhZnQtaWV0Zi1taWxlLXJvbGllQGlldGYub3Jn OyBtaWxlQGlldGYub3JnOw0KPiA+PiBtaWxlLWNoYWlyc0BpZXRmLm9yZzsgbWlsZS0gY2hhaXJz QHRvb2xzLmlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFttaWxlXSBBbGV4ZXkgTWVsbmlrb3YncyBE aXNjdXNzIG9uDQo+ID4+IGRyYWZ0LWlldGYtbWlsZS1yb2xpZS0xMjogKHdpdGggRElTQ1VTUyBh bmQgQ09NTUVOVCkNCj4gPj4NCj4gPj4gQWxleGV5IE1lbG5pa292IGhhcyBlbnRlcmVkIHRoZSBm b2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+PiBkcmFmdC1pZXRmLW1pbGUtcm9saWUt MTI6IERpc2N1c3MNCj4gPj4NCj4gPiBbc25pcF0NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0N Cj4gPj4gRElTQ1VTUzoNCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4NCj4gPj4gVGhp cyBpcyBhIHVzZWZ1bCBkb2N1bWVudCBhbmQgSSB3aWxsIGJlIGJhbGxvdGluZyAiWWVzIiBvbmNl IHRoZQ0KPiA+PiBmb2xsb3dpbmcgc21hbGwgaXNzdWVzIGFyZSByZXNvbHZlZC9kaXNjdXNzZWQg KHNvbWUgb2YgdGhlc2UgY29tZQ0KPiA+PiBmcm9tIE1hcnRpbidzIEFSVEFSVA0KPiA+PiByZXZp ZXcpOg0KPiA+Pg0KPiA+PiAxKSA3LjQuICBUaGUgInJvbGllOnByb3BlcnR5IiBFeHRlbnNpb24g UG9pbnQNCj4gPj4NCj4gPj4gICAgIHVybjppZXRmOnBhcmFtczpyb2xpZTpwcm9wZXJ0eTpjb250 ZW50LWlkICBUaGUgInZhbHVlIiBhdHRyaWJ1dGUgb2YNCj4gPj4gICAgICAgIHRoaXMgcHJvcGVy dHkgaXMgYSB0ZXh0IHJlcHJlc2VudGF0aW9uIG9mIGFuIGlkZW50aWZpZXIgcGVydGFpbmluZw0K PiA+PiAgICAgICAgdG8gb3IgZXh0cmFjdGVkIGZyb20gdGhlIGNvbnRlbnQgcmVmZXJlbmNlZCBi eSB0aGUgInNyYyIgYXR0cmlidXRlDQo+ID4+ICAgICAgICBvZiB0aGUgZW50cnkncyBhdG9tOmNv bnRlbnQgZWxlbWVudC4NCj4gPj4NCj4gPj4gTWF5YmUgaXQgaXMganVzdCBtZSwgYnV0IEkgY2Fu J3QgZmlndXJlIG91dCB3aGF0IGlzIHRoZSBzeW50YXggb2YgdGhpcyBmaWVsZC4NCj4gPj4gQ2Fu IHlvdSBwcm92aWRlIGEgcmVmZXJlbmNlIG9yIGF0IGxlYXN0IGdpdmUgYW4gZXhhbXBsZT8NCj4g PiBTdXJlLiBUaGlzIGZpZWxkIGlzIGV4cG9zaW5nIHNvbWUgaWRlbnRpZmllciBmb3IgdGhlIHJl c291cmNlIGluIHRoZQ0KPiBhdG9tOmNvbnRlbnQgZWxlbWVudC4gRm9yIGV4YW1wbGUsIGlmIHRo ZSBhdG9tOmNvbnRlbnQgaXMgbGlua2luZyB0byBhbg0KPiBJT0RFRiBkb2N1bWVudCwgdGhlIG9u bHkgd2F5ICh3aXRob3V0IHRoaXMgcHJvcGVydHkpIGZvciBhIGNvbnN1bWVyIHRvDQo+IGxlYXJu IGFueSBpZGVudGlmeWluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGF0IGRvY3VtZW50IGlzIHRvIGRv d25sb2FkIGl0Lg0KPiA+DQo+ID4gRm9yIHRoZSBzYWtlIG9mIGV4YW1wbGUsIGxldHMgc2F5IHRo YXQgaW5zaWRlIHRoYXQgSU9ERUYgZG9jdW1lbnQgaXMgYQ0KPiBJRD0iSUQxMjM0NSIgZWxlbWVu dC4gSW4gdGhlIFJPTElFIGZlZWQsIHRoZSByb2xpZTpwcm9wZXJ0eSBlbGVtZW50DQo+IGV4cG9z ZXMgdGhlIElELCBzbyB0aGVuIHRoZSByb2xpZTpwcm9wZXJ0eSBmaWVsZCB3b3VsZCBiZSAibmFt ZSI9DQo+ICJ1cm46aWV0ZjpwYXJhbXM6cm9saWU6cHJvcGVydHk6Y29udGVudC1pZCIgYW5kIHZh bHVlPSJJRDEyMzQ1Ii4NCj4gPg0KPiA+IElmIHRoaXMgc3RpbGwgc2VlbXMgY29uZnVzaW5nIHdl IGNhbiByZXdyaXRlIHRoZSB0ZXh0IGluIHRoZSBzcGVjaWZpY2F0aW9uIG9yDQo+IGluY2x1ZGUg YW4gZXhhbXBsZSB0byBjbGFyaWZ5Lg0KPiBJIHRoaW5rIGdpdmluZyBhbiBleGFtcGxlIGZvciBJ T0RFRiB3b3VsZCBiZSBncmVhdC4gSWYgdGhlIHZhbHVlIGNhbiBiZQ0KPiBhbnl0aGluZyBlbHNl LCBpdCB3b3VsZCBiZSBnb29kIHRvIHNheSB0aGF0IHRvby4NCj4NCj4gKEkgd2FzIHBhcnRpYWxs eSBjb25mdXNlZCBiZWNhdXNlIENvbnRlbnQtSUQgbWVhbnMgc29tZXRoaW5nIGVsc2UgaW4gZW1h aWwsDQo+IHNvIGxhY2sgb2YgcmVmZXJlbmNlIGlzIG5vdCBoZWxwaW5nLikNCg0KSSd2ZSBhZGRl ZCBhbiBleGFtcGxlIHRvIHRoZSBzZWN0aW9uIGluIHF1ZXN0aW9uIHRvIGNsYXJpZnkgaXQgZnVy dGhlcjoNCg0KCSJUaGUgInZhbHVlIiBhdHRyaWJ1dGUgb2YgdGhpcyBwcm9wZXJ0eSBpcyBhIHRl eHQgcmVwcmVzZW50YXRpb24NCiAgICAgICAgICAgIG9mIGFuIGlkZW50aWZpZXIgcGVydGFpbmlu ZyB0byBvciBleHRyYWN0ZWQgZnJvbSB0aGUgY29udGVudA0KICAgICAgICAgICAgcmVmZXJlbmNl ZCBieSB0aGUgInNyYyIgYXR0cmlidXRlIG9mIHRoZSBlbnRyeSdzIGF0b206Y29udGVudA0KICAg ICAgICAgICAgZWxlbWVudC4gRm9yIGV4YW1wbGUsIGlmIHRoZSBhdG9tOmVudHJ5J3MgYXRvbTpj b250ZW50DQogICAgICAgICAgICBlbGVtZW50IGxpbmtzIHRvIGFuIElPREVGIGRvY3VtZW50LCB0 aGUgImNvbnRlbnQtaWQiDQogICAgICAgICAgICB2YWx1ZSB3b3VsZCBiZSBhbiBpZGVudGlmaWVy IG9mIHRoYXQgSU9ERUYgZG9jdW1lbnQuIg0KDQo+ID4+IDIpIEZyb20gTWFydGluJ3MgcmV2aWV3 Og0KPiA+Pg0KPiA+PiBTZWN0aW9uIDUuNSBwcm9oaWJpdHMgdGhlIHVzZSBvZiBHRVQgb24gIi8i LiAgVGhpcyBwcm9oaWJpdHMgdXNlIG9mDQo+ID4+IHRoZSByZXNvdXJjZSBmb3Igb3RoZXIgcHVy cG9zZXMuICBJdCBzZWVtcyByZWFzb25hYmxlIHRvIGFjY2VwdCBQT1NUDQo+ID4+IG1lc3NhZ2Vz IGFzIGRlZmluZWQgaW4gUkZDIDY1NDYsIGJ1dCB0aGlzIHJlcXVpcmVtZW50IGlzIG92ZXJseQ0K PiA+PiBzdHJpY3QgKGFuZCBmdXJ0aGVyIGVudHJlbmNoZXMgdGhlIHZpb2xhdGlvbiBvZiBSRkMg NzMyMCkuICBJZiwgZm9yDQo+ID4+IGluc3RhbmNlLCB0aGUgc2VydmVyIG9wZXJhdG9yIHdpc2hl cyB0byBwcm92aWRlIEhUTUwgaW4gcmVzcG9uc2UgdG8gYQ0KPiA+PiBHRVQgcmVxdWVzdCB0byAi LyIsIHRoaXMgd291bGQgcHJvaGliaXQgdGhhdC4gIFRoZSByZXF1aXJlbWVudCB0bw0KPiA+PiBy ZXR1cm4gNDA0IGlmIFJGQyA2NTQ2IGlzIG5vdCBzdXBwb3J0ZWQgaXMgd29yc2U7IG5vdCBzdXBw b3J0aW5nIFJGQw0KPiA+PiA2NTQ2IG1pZ2h0IGJlIGEgY2hvaWNlIHRoYXQgYSBkZXBsb3ltZW50 IG1ha2VzIHRvIGF2b2lkIHRoZSBuZWVkIHRvDQo+IHJlc2VydmUgIi8iIGZvciB0aGF0IHByb3Rv Y29sLg0KPiA+Pg0KPiA+PiBBbGV4ZXk6IFRoZSB0ZXh0IGluIC0xMiBpcyBhbiBpbXByb3ZlbWVu dCwgYnV0IEkgdGhpbmsgaXQgaXMgc3RpbGwgY29uZnVzaW5nLg0KPiA+PiBNYXliZSBtZW50aW9u IHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YgTWFydGluJ3Mgc3VnZ2VzdGlvbiBmb3INCj4g Pj4gdGhlIGNhc2Ugd2hlbiBSRkMgNjU0NiBpcyBub3Qgc3VwcG9ydGVkIChvciBhdCBsZWFzdCBu b3QgZm9sbG93ZWQgYXMgZmFyIGFzDQo+IHRoZSAiLyINCj4gPj4gcmVzb3VyY2UgaXMgY29uY2Vy bmVkKS4NCj4gPj4NCj4gPj4gNS41LiAgLyAoZm9yd2FyZCBzbGFzaCkgUmVzb3VyY2UgVVJMDQo+ ID4+DQo+ID4+ICAgICBJZiB0aGUgIi8iIHJlc291cmNlIGlzIHVuc3VwcG9ydGVkLCB0aGVuIGEg cmVxdWVzdCBmb3IgdGhpcyByZXNvdXJjZQ0KPiA+PiAgICAgTUFZIGJlIGhhbmRsZWQgYXMgZGVl bWVkIGFwcHJvcHJpYXRlIGJ5IHRoZSBzZXJ2ZXIuDQo+ID4+DQo+ID4+IE5pdDogWW91IGhhdmVu J3QgZXhwcmVzc2VkIGFueSByZXF1aXJlbWVudCBvbiBpbXBsZW1lbnRhdGlvbnMgaGVyZSwNCj4g Pj4gc28gdXNlIG9mIE1BWSBkb2VzIG5vdCBzZWVtIGFwcHJvcHJpYXRlLiBXaGF0IGFyZSB5b3Ug YWN0dWFsbHkNCj4gPj4gc3VnZ2VzdGluZyBoZXJlPw0KPiA+IFRoaXMgbGFzdCBzZW50ZW5jZSB3 YXMgbWVhbnQgdG8gYmUgYWRkcmVzc2luZyB0aGUgY2FzZSB3aGVyZSBSRkMgNjU0NiBpcw0KPiBu b3Qgc3VwcG9ydGVkLiBJJ3ZlIHJlbW92ZWQgdGhlIG5vcm1hdGl2ZSByZXF1aXJlbWVudCBhbmQg dXBkYXRlZCB0aGUNCj4gc2VudGVuY2U6DQo+ID4NCj4gPiAiSWYgUkZDIDY1NDYgaXMgdW5zdXBw b3J0ZWQsIHRoZW4gYSByZXF1ZXN0IGZvciB0aGUgIi8iIHJlc291cmNlIG1heSBiZQ0KPiBoYW5k bGVkIGFzIGRlZW1lZCBhcHByb3ByaWF0ZSBieSB0aGUgc2VydmVyLiINCj4gPg0KPiA+IEFuZCB0 byBoZWxwIGNsYXJpZnkgSSBoYXZlIGFkZGVkIHRoaXMgc2VudGVuY2UgdG8gdGhlIGZpcnN0IHBh cmFncmFwaDoNCj4gPg0KPiA+ICJUaGUgZm9sbG93aW5nIHJlcXVpcmVtZW50cyBhcHBseSBvbmx5 IHRvIGltcGxlbWVudGF0aW9ucyBzdXBwb3J0aW5nIFJGQw0KPiA2NTQ2LiINCj4gPg0KPiA+IERv ZXMgdGhpcyBhZGRyZXNzIHlvdXIgY29uY2VybnM/IEknZCBsaWtlIHRvIGZ1bGx5IGFkZHJlc3Mg TWFydGluJ3Mgb3JpZ2luYWwNCj4gY29tbWVudHMsIGFzIEkgYWdyZWUgdGhhdCByZXN0cmljdGlu ZyB0aGUgIi8iIHJlc291cmNlIG9uIGFsbCBzZXJ2ZXJzIGlzDQo+IGRldHJpbWVudGFsLg0KPiBX b3JrcyBmb3IgbWUuDQo+ID4+IDMpIEkgdGhpbmsgc29tZSBvZiB0aGUgdGV4dCBpbiA2LjEuMiBp cyBtaXNsZWFkaW5nIChvciBJIG1pZ2h0IGJlIHdyb25nKToNCj4gPj4NCj4gPj4gICAgIEJhc2Vk IG9uIFJGQzUwMDUgc2VjdGlvbiAzIFtSRkM1MDA1XSwgbGluaw0KPiA+PiAgICAgZWxlbWVudHMg U0hPVUxEIGJlIGluY2x1ZGVkIGluIGFsbCBGZWVkcyB0byBzdXBwb3J0IHBhZ2luZyB1c2luZyB0 aGUNCj4gPj4gICAgIGZvbGxvd2luZyBsaW5rIHJlbGF0aW9uIHR5cGVzOg0KPiA+Pg0KPiA+PiAg ICAgbyAgImZpcnN0IiAtIEluZGljYXRlcyB0aGF0IHRoZSBocmVmIGF0dHJpYnV0ZSB2YWx1ZSBv ZiB0aGUgbGluaw0KPiA+PiAgICAgICAgaWRlbnRpZmllcyBhIHJlc291cmNlIFVSSSBmb3IgdGhl IGZ1cnRoZXN0IHByZWNlZGluZyBwYWdlIG9mIHRoZQ0KPiA+PiAgICAgICAgRmVlZC4NCj4gPj4N Cj4gPj4gICAgIG8gICJsYXN0IiAtIEluZGljYXRlcyB0aGF0IHRoZSBocmVmIGF0dHJpYnV0ZSB2 YWx1ZSBvZiB0aGUgbGluaw0KPiA+PiAgICAgICAgaWRlbnRpZmllcyBhIHJlc291cmNlIFVSSSBm b3IgdGhlIGZ1cnRoZXN0IGZvbGxvd2luZyBwYWdlIG9mIHRoZQ0KPiA+PiAgICAgICAgRmVlZC4N Cj4gPj4NCj4gPj4gICAgIG8gICJwcmV2aW91cyIgLSBJbmRpY2F0ZXMgdGhhdCB0aGUgaHJlZiBh dHRyaWJ1dGUgdmFsdWUgb2YgdGhlIGxpbmsNCj4gPj4gICAgICAgIGlkZW50aWZpZXMgYSByZXNv dXJjZSBVUkkgZm9yIHRoZSBpbW1lZGlhdGVseSBwcmVjZWRpbmcgcGFnZSBvZg0KPiA+PiAgICAg ICAgdGhlIEZlZWQuDQo+ID4+DQo+ID4+ICAgICBvICAibmV4dCIgLSBJbmRpY2F0ZXMgdGhhdCB0 aGUgaHJlZiBhdHRyaWJ1dGUgdmFsdWUgb2YgdGhlIGxpbmsNCj4gPj4gICAgICAgIGlkZW50aWZp ZXMgYSByZXNvdXJjZSBVUkkgZm9yIHRoZSBpbW1lZGlhdGVseSBmb2xsb3dpbmcgcGFnZSBvZg0K PiA+PiAgICAgICAgdGhlIEZlZWQuDQo+ID4+DQo+ID4+IE9yaWdpbmFsIGRlZmluaXRpb25zIG9m IHRoZXNlIGxpbmsgcmVsYXRpb25zIGRvbid0IGluY2x1ZGUgdGhlIHdvcmQNCj4gPj4gInBhZ2Ui LiBJIHNob3VsZCBkb3VibGUgY2hlY2sgd2l0aCBNYXJrIE5vdHRpZ2hhbSwgYnV0IEkgdGhpbmsg dGhleQ0KPiA+PiByZWZlcmVuY2UgdGhlIG5leHQvcHJldmlvdXMsIGZpcnN0L2xhc3QgZW50cnks IG5vdCBwYWdlLiAoQW5kIGEgcGFnZQ0KPiA+PiBtYXkgY29udGFpbiBzZXZlcmFsDQo+ID4+IGVu dHJpZXMuKSBJZiBJIGFtIGNvcnJlY3QsIEkgZG9uJ3QgdGhpbmsgaXQgaXMgT2sgdG8gcmVkZWZp bmUgbWVhbmluZw0KPiA+PiBvZiBleGlzdGluZyBsaW5rIHJlbGF0aW9ucyB0aGUgd2F5IHlvdSBk by4NCj4gPiBTZWN0aW9uIDMgKCJQYWdlZCBGZWVkcyIpIGluIFJGQyA1MDA1IGRlZmluZXMgcGFn ZWQgZmVlZHMgYXMgYSBzZXQgb2YNCj4gbGlua2VkIGZlZWQgZG9jdW1lbnRzLCB3aGVyZSBlYWNo IGZlZWQgZG9jdW1lbnQgY29udGFpbnMgYSBzdWJzZXQgb2YNCj4gZW50cmllcy4gVGhlIGV4cGxp Y2l0IHdvcmRpbmcgdXNlZCBpbiB0aGUgbGluayByZWxhdGlvbnMgaXMgYXMgZm9sbG93czoNCj4g Pg0KPiA+ICAgICBvICAiZmlyc3QiIC0gQSBVUkkgdGhhdCByZWZlcnMgdG8gdGhlIGZ1cnRoZXN0 IHByZWNlZGluZyBkb2N1bWVudCBpbg0KPiA+ICAgICAgICBhIHNlcmllcyBvZiBkb2N1bWVudHMu DQo+ID4NCj4gPiAgICAgbyAgImxhc3QiIC0gQSBVUkkgdGhhdCByZWZlcnMgdG8gdGhlIGZ1cnRo ZXN0IGZvbGxvd2luZyBkb2N1bWVudCBpbiBhDQo+ID4gICAgICAgIHNlcmllcyBvZiBkb2N1bWVu dHMuDQo+ID4NCj4gPiAgICAgbyAgInByZXZpb3VzIiAtIEEgVVJJIHRoYXQgcmVmZXJzIHRvIHRo ZSBpbW1lZGlhdGVseSBwcmVjZWRpbmcNCj4gPiAgICAgICAgZG9jdW1lbnQgaW4gYSBzZXJpZXMg b2YgZG9jdW1lbnRzLg0KPiA+DQo+ID4gICAgIG8gICJuZXh0IiAtIEEgVVJJIHRoYXQgcmVmZXJz IHRvIHRoZSBpbW1lZGlhdGVseSBmb2xsb3dpbmcgZG9jdW1lbnQNCj4gPiAgICAgICAgaW4gYSBz ZXJpZXMgb2YgZG9jdW1lbnRzLg0KPiA+DQo+ID4gV2UndmUgc3dhcHBlZCBpbiB0aGUgd29yZCAi cGFnZSIgaW5zdGVhZCBvZiAiZG9jdW1lbnQiIGluIG91cg0KPiBkb2N1bWVudCwgYXMgd2UgZmVs dCB0aGF0ICJwYWdlIiBtYWRlIG1vcmUgaW5oZXJlbnQgc2Vuc2Ugd2l0aG91dCB0aGUNCj4gY29u dGV4dCBvZiB0aGUgcmVzdCBvZiBSRkMgNTAwNS4gSSBiZWxpZXZlIHRoYXQgd2UgaGF2ZSBub3Qg Y2hhbmdlZCB0aGUNCj4gZGVmaW5pdGlvbiBvZiB0aGUgbGluayByZWxhdGlvbnMgaW4gYW55IHdh eSwgc28gY2hhbmdpbmcgdGhlIHdvcmRpbmcgYmFjayB0bw0KPiB0aGUgb3JpZ2luYWwgd291bGQg bm90IGJlIGEgaHVnZSBwcm9ibGVtIGZvciB1cyBpZiB5b3UgdGhpbmsgaXQgaXMgbmVlZGVkLg0K PiBMZXQgbWUgZm9sbG93aW5nIHdpdGggTWFyayBOb3R0aW5naGFtIG9uIHRoaXMuDQo+ID4+IDQp IEluIFNlY3Rpb24gOC4zOg0KPiA+Pg0KPiA+PiAgICAgUmVnaXN0cmF0aW9uIGluIHRoZSBST0xJ RSBVUk4gUGFyYW1ldGVycyByZWdpc3RyeSBpcyB2aWEgdGhlDQo+ID4+ICAgICBTcGVjaWZpY2F0 aW9uIFJlcXVpcmVkIHBvbGljeSBbUkZDODEyNl0uICBEZXNpZ25hdGVkIEV4cGVydCByZXZpZXdz DQo+ID4+ICAgICBzaG91bGQgYmUgcm91dGVkIHRocm91Z2ggdGhlIE1JTEUgV0cgbWFpbGluZyBs aXN0LiAgRmFpbGluZyB0aGlzLCB0aGUNCj4gPj4gICAgIERlc2lnbmF0ZWQgRXhwZXJ0IHdpbGwg YmUgYXNzaWduZWQgYnkgdGhlIElFU0cuDQo+ID4+DQo+ID4+IEFzIG90aGVyIHBlb3BsZSBhbHJl YWR5IHBvaW50ZWQgb3V0LCB0aGUgbGFzdCAyIHNlbnRlbmNlcyBhcmUgY29uZnVzaW5nLg0KPiA+ PiBBcmUgeW91IHRyeWluZyB0byBzYXkgdGhhdCByZWdpc3RyYXRpb24gcmVxdWVzdHMgbXVzdCBi ZSBzZW50IHRvIHRoZQ0KPiA+PiBNSUxFIG1haWxpbmcgbGlzdCBvciB0aGF0IHRoZXkgbXVzdCBi ZSByZXZpZXdlZCB0aGVyZT8gVGhpcyBpcw0KPiA+PiBhY3R1YWxseSBzaWduaWZpY2FudCBmb3Ig SUFOQSB3b3JrZmxvdy4NCj4gPj4NCj4gPj4gT25lIHBvc3NpYmlsaXR5IGlzIHRoYXQgYWxsIHJl cXVlc3RzIGFyZSBzZW50IHRvIHRoZSBNSUxFIG1haWxpbmcNCj4gPj4gbGlzdCBhbmQgdGhlbiB0 aGUgZGVzaWduYXRlZCBleHBlcnQgZm9yd2FyZHMgYXBwcm92ZWQgcmVxdWVzdHMgdG8NCj4gPj4g SUFOQS4gSW4gdGhpcyBjYXNlIGlmIGEgRGVzaWduYXRlZCBFeHBlcnQgbWlzc2VzIGEgcmVxdWVz dCwgSUFOQQ0KPiA+PiB3b3VsZG4ndCBldmVuIGtub3cgdGhhdCB0aGUgcmVxdWVzdGVyIGlzIHdh aXRpbmcgZm9yIHRoZSBEZXNpZ25hdGVkDQo+IEV4cGVydC4NCj4gPj4NCj4gPj4gQW5vdGhlciBw b3NzaWJpbGl0eSBpcyBmb3IgYWxsIHJlcXVlc3RzIHRvIGJlIHN1Ym1pdHRlZCB0byBJQU5BDQo+ ID4+IGRpcmVjdGx5LCB0aGVuIElBTkEgY2FuIHRyYWNrIHRoZW0uIElBTkEgbWlnaHQgZWl0aGVy IGZvcndhcmQNCj4gPj4gcmVxdWVzdHMgdG8gdGhlIE1JTEUgbWFpbGluZyBsaXN0IG9yIHJlcXVp cmUgdGhhdCBhbGwgcmVxdWVzdCBiZWluZw0KPiA+PiBzdWJtaXR0ZWQgdG8gdGhlIE1JTEUgbWFp bGluZyBsaXN0IGZpcnN0IGJlZm9yZSBiZWluZyBzZW50IHRvIElBTkEuDQo+ID4+DQo+ID4+IFNv IHBsZWFzZSBjbGFyaWZ5Lg0KPiA+IE91ciBvcmlnaW5hbCBpbnRlbnQgaGVyZSB3YXMgdG8gaGF2 ZSBJQU5BIHJlY2VpdmUgYW5kIHRyYWNrIHJlcXVlc3RzLCB0aGVuDQo+IHNlbmQgdGhlIHJlcXVl c3RzIHRvIHRoZSBNSUxFIG1haWxpbmcgbGlzdCwgYW5kIHRoZW4gaWYgdGhlcmUgaXMgbm8gcmVz cG9uc2UsDQo+IGZhbGwgYmFjayB0byBwcmUtbmFtZWQgRGVzaWduYXRlZCBFeHBlcnRzICh0aGUg YXV0aG9ycykuDQo+IElBTkEgZG9lc24ndCB0cmFjayBjb21tZW50cywgYmVjYXVzZSB0aGV5IGxh Y2sgdGVjaG5pY2FsIHNraWxscyB0byBldmFsdWF0ZQ0KPiByZXF1ZXN0LiBTbyBhIERlc2lnbmF0 ZWQgRXhwZXJ0IG11c3QgYWx3YXlzIGJlIGludm9sdmVkLg0KPiA+IFdlIGFyZSBoYXZpbmcgdHJv dWJsZSBjb3JyZWN0bHkgcHV0dGluZyB0b2dldGhlciB0ZXh0IHRvIGV4cHJlc3MgdGhpcy4NCj4g TWF5YmUgc2F5IHNvbWV0aGluZyBsaWtlIHRoaXM6DQo+IA0KPiBPTEQ6DQo+IA0KPiAgICAgRGVz aWduYXRlZCBFeHBlcnQgcmV2aWV3cw0KPiAgICAgc2hvdWxkIGJlIHJvdXRlZCB0aHJvdWdoIHRo ZSBNSUxFIFdHIG1haWxpbmcgbGlzdC4gIEZhaWxpbmcgdGhpcywgdGhlDQo+ICAgICBEZXNpZ25h dGVkIEV4cGVydCB3aWxsIGJlIGFzc2lnbmVkIGJ5IHRoZSBJRVNHLg0KPiANCj4gTkVXOg0KPiAg ICAgUmVnaXN0cmF0aW9uIHJlcXVlc3RzIG11c3QgYmUgc2VudCB0byBib3RoIHRoZSBNSUxFIFdH IG1haWxpbmcgbGlzdA0KPiAobWlsZUBpZXRmLm9yZykNCj4gICAgIGFuZCBJQU5BLiBJQU5BIHdp bGwgZm9yd2FyZCByZWdpc3RyYXRpb24gcmVxdWVzdHMgdG8gdGhlIERlc2lnbmF0ZWQNCj4gRXhw ZXJ0Lg0KPiANCj4gDQo+IE9yIHlvdSBjYW4gYXNrIElBTkEgaWYgdGhleSBhcmUgaGFwcHkgdG8g anVzdCByZWNlaXZlIGFuZCBmb3J3YXJkIGFsbA0KPiByZWdpc3RyYXRpb24gcmVxdWVzdHMgdG8g bWlsZUBpZXRmLm9yZy4NCj4gDQo+IChUaGVyZSBpcyBubyBuZWVkIHRvIHNheSAiRGVzaWduYXRl ZCBFeHBlcnQgd2lsbCBiZSBhc3NpZ25lZCBieSB0aGUgSUVTRyIsDQo+IGJlY2F1c2UgdGhpcyBp cyB0aGUgZGVmYXVsdC4pDQoNClRoYW5rIHlvdSwgd2UgaGF2ZSBhY2NlcHRlZCB5b3VyIG5ldyB0 ZXh0LiBXZSdsbCBjb250YWN0IElBTkEgdG8gdmVyaWZ5IHRoZSBjaGFuZ2VzIHdpdGggdGhlbS4N Cg0KDQpUaGFua3MsDQpTdGVwaGVuDQoNCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4g Q09NTUVOVDoNCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gIMKgKHNuaXApDQo+ID4+IElu IDYuMi4zIChvbiBwYWdlIDE3KQ0KPiA+Pg0KPiA+PiAgICAgVGhlIFVSSSB1c2VkIGZvciB0aGUg Im5zIiBhdHRyaWJ1dGUgdmFsdWUgTVVTVCBiZSBhbiBhYnNvbHV0ZQ0KPiA+PiAgICAgb3Igb3Bh cXVlIFVSSS4NCj4gPj4NCj4gPj4gV2hhdCBpcyAib3BhcXVlIiBVUkk/IFRoZSBzZW50ZW5jZSBt YWtlIGl0IHNvdW5kIGFzIGlmIGl0IGlzIGEgdGVybSwNCj4gPj4gb3Bwb3NpdGUgdG8gYWJzb2x1 dGUgVVJJLiBPciBhcmUgeW91IHRyeWluZyB0byBzYXkgdGhhdCBub24NCj4gPj4gcmVzb2x2YWJs ZSBVUk5zIGFyZSBPayBoZXJlPw0KPiA+PiBJIHN1Z2dlc3QgZGVsZXRpbmcgIm9yIG9wYXF1ZSIg ZnJvbSB0aGUgYWJvdmUgc2VudGVuY2Ugb3IgcmVwbGFjaW5nDQo+ID4+IGl0IHdpdGggc29tZXRo aW5nIGNsZWFyZXIuDQo+ID4gSSd2ZSBkZWxldGVkIHRoZSAib3Igb3BhcXVlIiwgYXMgdGhlIGlu dGVudCB3YXMgdG8gZGlzYWxsb3cgcmVsYXRpdmUgVVJJcy4gSQ0KPiB0aGluayB0aGF0IHRoZSBj dXJyZW50IHJlcXVpcmVtZW50IGZvbGxvd2VkIGJ5IHRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoZQ0K PiBwYXJhZ3JhcGggKFRoZSByZXNvdXJjZSBpZGVudGlmaWVkIGJ5IHRoZSBVUkkgbmVlZCBub3Qg YmUgcmVzb2x2YWJsZS4pDQo+IHByb3ZpZGUgZW5vdWdoIGluZm9ybWF0aW9uLg0KPiBBZ3JlZWQu DQo+ID4+IEluIDYuMi40LiAgVXNlIG9mIHRoZSByb2xpZTpwcm9wZXJ0eSBFbGVtZW50DQo+ID4+ DQo+ID4+ICAgICBJbXBsZW1lbnRhdGlvbnMgTUFZIHVzZSBsb2NhbGx5IGRlZmluZWQgYW5kIG5h bWVzcGFjZWQgZWxlbWVudHMgaW4NCj4gYW4NCj4gPj4gICAgIEVudHJ5IGluIG9yZGVyIHRvIHBy b3ZpZGUgYWRkaXRpb25hbCBpbmZvcm1hdGlvbi4gIENsaWVudHMgdGhhdCBkbw0KPiA+PiAgICAg bm90IHJlY29nbml6ZSBhIHByb3BlcnR5IHdpdGggYW4gdW5yZWdpc3RlcmVkIG5hbWUgYXR0cmli dXRlIE1BWQ0KPiA+PiAgICAgaWdub3JlIHRoZSByb2xpZTpwcm9wZXJ0eS4NCj4gPj4NCj4gPj4g VGhlIHNlY29uZCAiTUFZIjogb3IgZG8gd2hhdD8gU2hvdWxkIHRoZSBNQVkgYmUgY2hhbmdlZCB0 byBhIE1VU1Q/DQo+ID4+DQo+ID4gWWVzLCB0aGlzIHdhcyBpbnRlbmRlZCB0byBiZSBhIE1VU1Qu IFRoZSBjbGllbnQgTVVTVCBOT1QgZmFpbCBwYXJzaW5nDQo+IGNvbnRlbnQgdGhhdCBjb250YWlu cyBhbiB1bnJlY29nbml6ZWQgcHJvcGVydHkuIEkgY2hhbmdlZCB0aGUga2V5d29yZCB0bw0KPiBN VVNUIGFuZCBwcm92aWRlZCBzb21lIGFkZGl0aW9uYWwgdGV4dCB0byBjbGFyaWZ5Og0KPiA+DQo+ ID4gIlRoZSBjbGllbnQgTVVTVCBOT1QgZmFpbCBwYXJzaW5nIGNvbnRlbnQgdGhhdA0KPiA+ICAg ICAgICAgICAgICBjb250YWlucyBhbiB1bnJlY29nbml6ZWQgcHJvcGVydHkuIg0KPiBNdWNoIGJl dHRlciwgdGhhbmsgeW91Lg0KDQo= From nobody Fri Oct 27 11:30:59 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692CB13F5BE for ; Fri, 27 Oct 2017 11:30:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 enCndWr-c2MW for ; Fri, 27 Oct 2017 11:30:55 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0113.outbound.protection.outlook.com [23.103.201.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6EC113F43F for ; Fri, 27 Oct 2017 11:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Kum7EzI0VWQf+xTdp8C3vTllq8rvalfTyEjEIXwtzvU=; b=dIBz/BqBLyE/pjOJfU8ioXI7rV0Up2PXU25u29ipFqVVKEwcvSq4Q9MGjtpr1/+sxLMCA1daQdJZRJi6rO87mshMaPWDygZ10GxymDao0eDh8z+xExIhsE8r40lkvgjCEi4DB23FdDTnlX4LIi4vFsdrY9+3x6Q1sRyXsLvymR8= Received: from MWHPR09MB1197.namprd09.prod.outlook.com (10.172.49.143) by MWHPR09MB1198.namprd09.prod.outlook.com (10.172.49.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Fri, 27 Oct 2017 18:30:53 +0000 Received: from MWHPR09MB1197.namprd09.prod.outlook.com ([10.172.49.143]) by MWHPR09MB1197.namprd09.prod.outlook.com ([10.172.49.143]) with mapi id 15.20.0178.007; Fri, 27 Oct 2017 18:30:53 +0000 From: "Banghart, Stephen A. (Fed)" To: "mile@ietf.org" Thread-Topic: [IANA #985228] expert review for draft-ietf-mile-rolie (well-known-uris) Thread-Index: AdNPUaY0UMvU9re9y0qz2yC1kmyIEQ== Date: Fri, 27 Oct 2017 18:30:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.251.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR09MB1198; 6:NZ5WEsabfuQ3OLw0fIJSopso5R/m2REfiv87rsZTcFBuUnPdjnbIgdl3s2pUv4rEFu/hCmvH1DlQMsGEPHN6DuWmVkIDXkuZmS7h4R72BrQNlJgNkMmZl/Lvj4gM6jUSQYvutz9M8PsDqbxC6moEhbbhNX3RcuyujfCSO+yJL/8jJce5O5QbaLh1z3cobTUBAfJgbp1pCmHru8pckSMQKHelU4eP4sK89Ps2+XVNdw6ZR9TGgBy8I/Txnbt8YIhq/XR7cW06ua8Sh7LMPL3BYEf9cf3eYcXrh8K37BEVQIitZIaH2myaa21nCtul4y0fAt4hduAZJ6F+7oAaEkRTRtNz0i8AwqLESBUK81shl6A=; 5:67JOVgk57TKPCTzft5jr+iMlKw4DxkvGHavGiRzrKwMYcYvMrWNY4IicLq/t0NuA6qWRkiYMJk8BbPwx/6XRdR2654IiBbXBXO58yf5KcMFLe1HmcsFpsdycRyZKNLRUpUZ6fhQhke/DtE1YLjlKUFX3iaBMjLQSL5f3rcYFhf4=; 24:kVWUSaagizcLFNcrApLwFxeucCwpOLLeDFXJa7rmclJCnPDMHWw2/sTGtrO6jmK0CuZ5SR1nex6y4nL+gFXEk8ElRW2gv575kGrVbnJp4aQ=; 7:EBFzCvceYWRZaqj43rx8n59snHtEF//6DnoMkBq5vJ5EqM7b4+dynq6xYXRt7TDIalxQAoMe6Ofg5Xb+cV5v1Cy/L6zQeBvToGc0ZQLJK3V8R+WWeT3uI/zk7uweS17QFkOVhOpsqbO3gfAmqXHoPRUUuch/R1FtAvJq7DkCRrGGRN0tYQLuQw2k1Tw72KBRB57zYQOkwdUBlPXqXGiqyfBGuf+OaHQm5Ve2EdZ5pXDoTFzlJmZ1JYUWX/CETktb x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 855b0aee-1768-4446-0003-08d51d68db72 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603199); SRVR:MWHPR09MB1198; x-ms-traffictypediagnostic: MWHPR09MB1198: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(150554046322364)(95692535739014); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231020)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR09MB1198; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR09MB1198; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(199003)(85644002)(13464003)(189002)(25786009)(9686003)(81166006)(74316002)(66066001)(8676002)(99286003)(6116002)(102836003)(106356001)(3846002)(55016002)(97736004)(105586002)(8936002)(2501003)(86362001)(1730700003)(316002)(53936002)(81156014)(68736007)(478600001)(229853002)(50986999)(54356999)(305945005)(230783001)(101416001)(53546010)(189998001)(14454004)(2906002)(6506006)(2900100001)(6916009)(5640700003)(7696004)(6436002)(33656002)(5660300001)(77096006)(7736002)(2351001)(6246003)(3280700002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1198; H:MWHPR09MB1197.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 855b0aee-1768-4446-0003-08d51d68db72 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 18:30:53.6872 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1198 Archived-At: Subject: Re: [mile] [IANA #985228] expert review for draft-ietf-mile-rolie (well-known-uris) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 18:30:58 -0000 VGhpcyB3YXMgY2F1Z2h0IGJ5IHRoZSBNSUxFIGZpbHRlciBmb3IgaGF2aW5nIHRvbyBtYW55IHJl Y2lwaWVudHMuIEknbSBmb3J3YXJkaW5nIGl0IGRpcmVjdGx5IHRvIE1JTEUgZ2V0IGl0IHRocm91 Z2guIEFwb2xvZ2llcyBpZiB0aGlzIGFwcGVhcnMgdHdpY2UgaW4gdGhlIGxpc3QuDQoNClN0ZXBo ZW4gQmFuZ2hhcnQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJhbmdoYXJ0 LCBTdGVwaGVuIEEuIChGZWQpIA0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDI3LCAyMDE3IDI6MTQg UE0NClRvOiAnZHJhZnRzLWV4cGVydC1yZXZpZXdAaWFuYS5vcmcnIDxkcmFmdHMtZXhwZXJ0LXJl dmlld0BpYW5hLm9yZz4NCkNjOiBqZmllbGRAcGl2b3RhbC5pbzsgV2FsdGVybWlyZSwgRGF2aWQg QS4gKEZlZCkgPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+OyBuY2Ftd2luZ0BjaXNjby5jb207 IHRha2VzaGlfdGFrYWhhc2hpQG5pY3QuZ28uanA7IEthdGhsZWVuLk1vcmlhcnR5LmlldGZAZ21h aWwuY29tOyBla3JAcnRmbS5jb207IG1pbGUtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBtaWxlQGll dGYub3JnOyAnQmVuIENhbXBiZWxsJyA8YmVuQG5vc3RydW0uY29tPjsgJ0FkYW0gUm9hY2gnIDxh ZGFtQG5vc3RydW0uY29tPg0KU3ViamVjdDogUkU6IFtJQU5BICM5ODUyMjhdIGV4cGVydCByZXZp ZXcgZm9yIGRyYWZ0LWlldGYtbWlsZS1yb2xpZSAod2VsbC1rbm93bi11cmlzKQ0KDQpTYWJyaW5h LA0KDQpXZSBoYXZlIG1hZGUgc2V2ZXJhbCBjaGFuZ2VzIHRvIHRoZSBJQU5BIHNlY3Rpb24gdG8g YWRkcmVzcyBib3RoIHlvdXIgY29tbWVudHMgYW5kIElFU0cgY29tbWVudHMuIEkndmUgbGlzdGVk IHRoZW0gaGVyZToNCg0KV2UndmUgY2hhbmdlZCB0aGUgLy53ZWxsLWtub3duIHJlZ2lzdHJhdGlv biBmcm9tICJyb2xpZS9zZXJ2aWNlZG9jdW1lbnQgdG8gInJvbGllIiBpbiBvcmRlciB0byBjb25m b3JtIHRvIFJGQzU3ODUgcmVnaXN0cmF0aW9uIHJlcXVpcmVtZW50cy4NCg0KV2UndmUgcmVtb3Zl ZCB0aGUgLy53ZWxsLWtub3duIHJlZ2lzdHJhdGlvbiBmb3IgInJvbGllL2NhdGVnb3J5ZG9jdW1l bnQiIGZvbGxvd2luZyBJRVNHIHJldmlldy4NCg0KV2UndmUgdXBkYXRlZCB0ZXh0IGluIHRoZSBS T0xJRSBVUk4gUGFyYW1ldGVycyBTZWN0aW9uLiBUaGUgZmlyc3QgcGFyYWdyYXBoIHJlY2VpdmVk IGNsYXJpZnlpbmcgdGV4dHVhbCBjaGFuZ2VzIGZvbGxvd2luZyBJRVNHIHJldmlldy4gVGhlIHNl Y29uZCBwYXJhZ3JhcGggKHJlZ2FyZGluZyBEZXNpZ25hdGVkIEV4cGVydHMpIGhhcyBiZWVuIGNo YW5nZWQgdG8gdGhlIGZvbGxvd2luZzogDQoNCiJSZWdpc3RyYXRpb24gaW4gdGhlIFJPTElFIFVS TiBQYXJhbWV0ZXJzIHJlZ2lzdHJ5IGlzIHZpYSB0aGUNCiAgICAgICAgICBTcGVjaWZpY2F0aW9u IFJlcXVpcmVkIHBvbGljeSA8eHJlZiB0YXJnZXQ9IlJGQzgxMjYiLz4uDQogICAgICAgICAgUmVn aXN0cmF0aW9uIHJlcXVlc3RzIG11c3QgYmUgc2VudCB0byBib3RoIHRoZSBNSUxFIFdHIG1haWxp bmcNCiAgICAgICAgICBsaXN0IChtaWxlQGlldGYub3JnKSBhbmQgSUFOQS4gSUFOQSB3aWxsIGZv cndhcmQgcmVnaXN0cmF0aW9uDQogICAgICAgICAgcmVxdWVzdHMgdG8gdGhlIERlc2lnbmF0ZWQg RXhwZXJ0LiINCg0KV2l0aCByZWdhcmRzIHRvIHRoZSAvLndlbGwta25vd24gcmVnaXN0cmF0aW9u IGZvciAicm9saWUiLCB3ZSBiZWxpZXZlIHRoYXQgdGhlIHJlZ2lzdHJhdGlvbiBkb2VzIHByb3Zp ZGUgc2l0ZS13aWRlIG1ldGFkYXRhIGFuZCBVUkkgbGlua3MgdG8gYWRkaXRpb25hbCBtZXRhZGF0 YS4gVGhlIFNlcnZpY2UgRG9jdW1lbnQgdGhhdCBpcyByZXRyaWV2ZWQgZnJvbSB0aGUgLndlbGwt a25vd24gbG9jYXRpb24gYWxsb3dzIGNvbnN1bWVycyB0byByZXRyaWV2ZSB0aGUgdG9wLWxldmVs IFJPTElFIG1ldGFkYXRhIGZvciB0aGUgc2l0ZSwgYW5kIHByb3ZpZGVzIHRoZSBoZWFkIGZvciBs aW5raW5nIGludG8gdGhlIHJlc3Qgb2YgdGhlIFJPTElFIHJlcG9zaXRvcnkuDQoNClJPTElFIGlz IGludGVuZGVkIHRvIGJlIHVzZWQgYnkgYXV0b21hdGVkIHN5c3RlbXMsIGZvciB0aGVzZSBzeXN0 ZW1zLCBsb2NhdGluZyBhIFVSTCBjYW4gYmUgcGFydGljdWxhcmx5IGRpZmZpY3VsdC4gVGhpcyBy ZWdpc3RyYXRpb24gcHJvdmlkZXMgYSBjb25zaXN0ZW50IGFuZCBzdGFuZGFyZCB3YXkgZm9yIGF1 dG9tYXRlZCBzeXN0ZW1zIHRvIGxvY2F0ZSBST0xJRSByZXBvc2l0b3JpZXMgZ2l2ZW4gYSBob3N0 bmFtZSBhbmQgcG9ydC4NCg0KVGhlIEROUyBTUlYgcmVjb3JkcyBhcmUgYSBwb3RlbnRpYWwgc29s dXRpb24gZm9yIGZ1bGx5IGF1dG9tYXRlZCBkaXNjb3ZlcnksIHdlJ3ZlIGFkZGVkIHRleHQgdG8g dGhlIGRyYWZ0IGNsYXJpZnlpbmcgdGhhdCB3ZSB3aWxsIHN0YW5kYXJkaXplIHRoaXMgZmVhdHVy ZSBpbiB0aGUgZnV0dXJlLiBXZSd2ZSBhbHNvIGFkZGVkIHRleHQgdGhhdCBjb3ZlcnMgdGhlIGp1 c3RpZmljYXRpb25zIGZvciB0aGUgLndlbGwta25vd24gcmVnaXN0cmF0aW9uLg0KDQpJIGhvcGUg dGhpcyBjbGVhcnMgdXAgeW91ciBjb21tZW50cy9jb25jZXJucy4NCg0KVGhhbmtzLA0KU3RlcGhl biBCYW5naGFydA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2Fi cmluYSBUYW5hbWFsIHZpYSBSVCBbbWFpbHRvOmRyYWZ0cy1leHBlcnQtcmV2aWV3QGlhbmEub3Jn XQ0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMTYsIDIwMTcgMzo0MiBQTQ0KPiBDYzogamZpZWxk QHBpdm90YWwuaW87IEJhbmdoYXJ0LCBTdGVwaGVuIEEuIChGZWQpIA0KPiA8c3RlcGhlbi5iYW5n aGFydEBuaXN0Lmdvdj47IFdhbHRlcm1pcmUsIERhdmlkIEEuIChGZWQpIA0KPiA8ZGF2aWQud2Fs dGVybWlyZUBuaXN0Lmdvdj47IG5jYW13aW5nQGNpc2NvLmNvbTsgDQo+IHRha2VzaGlfdGFrYWhh c2hpQG5pY3QuZ28uanA7IEthdGhsZWVuLk1vcmlhcnR5LmlldGZAZ21haWwuY29tOyANCj4gZWty QHJ0Zm0uY29tOyBtaWxlLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgbWlsZUBpZXRmLm9yZw0KPiBT dWJqZWN0OiBbSUFOQSAjOTg1MjI4XSBleHBlcnQgcmV2aWV3IGZvciBkcmFmdC1pZXRmLW1pbGUt cm9saWUgDQo+ICh3ZWxsLWtub3duLQ0KPiB1cmlzKQ0KPiANCj4gRGVhciBBdXRob3JzL0NoYWly cy9BRHM6DQo+IA0KPiBQbGVhc2Ugc2VlIHRoZSBjb21tZW50cyBmcm9tIHRoZSBkZXNpZ25hdGVk IGV4cGVydCBiZWxvdy4NCj4gDQo+IFRoYW5rIHlvdSwNCj4gDQo+IFNhYnJpbmEgVGFuYW1hbA0K PiBJQU5BIFNlcnZpY2VzIFNwZWNpYWxpc3QNCj4gDQo+IC0tLQ0KPiANCj4gVGhpcyBkcmFmdCBw cm9wb3NlcyByZWdpc3RyYXRpb24gb2YgYSB3ZWxsLWtub3duIFVSSSwgDQo+ICJyb2xpZS9zZXJ2 aWNlZG9jdW1lbnQiLg0KPiANCj4gVGhhdCBzeW50YXggZG9lcyBub3QgY29uZm9ybSB0byB0aGUg cmVxdWlyZW1lbnRzIG9mIFJGQzU3ODUsIFNlY3Rpb24gMzoNCj4gDQo+ICIiIg0KPiBSZWdpc3Rl cmVkIG5hbWVzIE1VU1QgY29uZm9ybSB0byB0aGUgc2VnbWVudC1ueiBwcm9kdWN0aW9uIGluW1JG QzM5ODZdLg0KPiAiIiINCj4gDQo+IEknZCBzdWdnZXN0IHJlZ2lzdGVyaW5nIGp1c3QgInJvbGll IiBhbmQgc3BlY2lmeWluZyB0aGF0ICIvc2VydmljZWRvY3VtZW50Ig0KPiB1bmRlciBpdCBpcyB1 c2VkIGZvciB0aGlzIHB1cnBvc2UsIGFuZCB0aGF0IG90aGVyIHBhdGhzIHVuZGVyICJyb2xpZSIg DQo+IGNhbiBiZSByZXNlcnZlZCB1c2luZyBvdGhlciBzdGFuZGFyZHMtdHJhY2sgZG9jdW1lbnRz Lg0KPiANCj4gSG93ZXZlciwgaXQgaXMgbm90IGNsZWFyIHdoeSBzdWNoIGEgd2VsbC1rbm93biBV UkkgaXMgbmVlZGVkLiBSRkM1Nzg1DQo+IHN0YXRlczoNCj4gDQo+ICIiIg0KPiBbV11lbGwta25v d24gVVJJcyBhcmUgbm90IGludGVuZGVkIGZvciBnZW5lcmFsIGluZm9ybWF0aW9uIHJldHJpZXZh bCANCj4gb3IgZXN0YWJsaXNobWVudCBvZiBsYXJnZSBVUkkgbmFtZXNwYWNlcyBvbiB0aGUgV2Vi LiBSYXRoZXIsIHRoZXkgYXJlIA0KPiBkZXNpZ25lZCB0byBmYWNpbGl0YXRlIGRpc2NvdmVyeSBv ZiBpbmZvcm1hdGlvbiBvbiBhIHNpdGUgd2hlbiBpdCANCj4gaXNuJ3QgcHJhY3RpY2FsIHRvIHVz ZSBvdGhlciBtZWNoYW5pc21zOyBmb3IgZXhhbXBsZSwgd2hlbiBkaXNjb3ZlcmluZyANCj4gcG9s aWN5IHRoYXQgbmVlZHMgdG8gYmUgZXZhbHVhdGVkIGJlZm9yZSBhIHJlc291cmNlIGlzIGFjY2Vz c2VkLCBvciANCj4gd2hlbiB1c2luZyBtdWx0aXBsZSByb3VuZC0gdHJpcHMgaXMganVkZ2VkIGRl dHJpbWVudGFsIHRvIHBlcmZvcm1hbmNlLg0KPiANCj4gQXMgc3VjaCwgdGhlIHdlbGwta25vd24g VVJJIHNwYWNlIHdhcyBjcmVhdGVkIHdpdGggdGhlIGV4cGVjdGF0aW9uIA0KPiB0aGF0IGl0IHdp bGwgYmUgdXNlZCB0byBtYWtlIHNpdGUtd2lkZSBwb2xpY3kgaW5mb3JtYXRpb24gYW5kIG90aGVy IA0KPiBtZXRhZGF0YSBhdmFpbGFibGUgZGlyZWN0bHkgKGlmIHN1ZmZpY2llbnRseSBjb25jaXNl KSwgb3IgcHJvdmlkZSANCj4gcmVmZXJlbmNlcyB0byBvdGhlciBVUklzIHRoYXQgcHJvdmlkZSBz dWNoIG1ldGFkYXRhLg0KPiAiIiINCj4gDQo+IFRoaXMgZHJhZnQgZG9lc24ndCBleHBsYWluIHdo eSB1c2luZyBhIFVSTCB0byBsb2NhdGUgYSBzZXJ2aWNlIA0KPiBkb2N1bWVudCBpc24ndCBzdWZm aWNpZW50OyBpbiBvdGhlciB3b3Jkcywgd2h5IGlzIGl0IG5lY2Vzc2FyeSB0byANCj4gcmVzZXJ2 ZSBuYW1lIHNwYWNlIG9uIGV2ZXJ5IFdlYiBzZXJ2ZXIgZXhpc3RlbnQgZm9yIHRoaXMgZnVuY3Rp b24/DQo+IA0KPiBUaGUgZHJhZnQgZG9lcyBtZW50aW9uOg0KPiANCj4gIiIiDQo+IEEgbWVjaGFu aXNtIHRvIGRldGVybWluZSB3aGljaCBob3N0IGFuZCBwb3J0IHRvIHVzZSBpcyBub3Qgc3BlY2lm aWVkIA0KPiBpbiB0aGlzIGRvY3VtZW50LiBVc2Ugb2YgYSBtZWNoYW5pc20gc3VjaCBhcyBETlMg U1JWIFJlY29yZHMgW1JGQzI3ODJdIA0KPiBjYW4gcHJvdmlkZSBhIHNlY3VyZSBhbmQgcmVsaWFi bGUgZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZGV0ZXJtaW5pbmcgDQo+IGEgc3BlY2lmaWMgaG9z dCBhbmQgcG9ydCB0byB1c2UgZm9yIHJldHJpZXZpbmcgYSBTZXJ2aWNlIERvY3VtZW50IGZvciAN Cj4gYSBnaXZlbiBETlMgZG9tYWluLg0KPiAiIiINCj4gDQo+IC4uLiBidXQgaXQgZG9lcyBub3Qg c3BlY2lmeSBob3cgdG8gdXNlIEROUyBTUlYgdG8gYWNoaWV2ZSB0aGlzIGdvYWwsIA0KPiBsZWFk aW5nIG1lIHRvIGJlbGlldmUgdGhhdCB0aGlzIGlzIHVuZGVyc3BlY2lmaWVkIGFuZCBub3QgYSBz dHJvbmcgDQo+IG1vdGl2YXRpb24gZm9yIHRoZSB3ZWxsLSBrbm93biBVUkkuDQo+IA0KPiBJcyB0 aGVyZSBzb21lIGNvbnRleHQgYWJvdXQgdGhpcyBwcm9wb3NlZCB1c2UgdGhhdCBJJ3ZlIG92ZXJs b29rZWQ/DQo+IC0tLTg8LS0tDQo= From nobody Fri Oct 27 13:29:32 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F9813946F; Fri, 27 Oct 2017 13:29:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mile@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150913617168.22127.13921557564325634679@ietfa.amsl.com> Date: Fri, 27 Oct 2017 13:29:31 -0700 Archived-At: Subject: [mile] I-D Action: draft-ietf-mile-rolie-13.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 20:29:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Managed Incident Lightweight Exchange WG of the IETF. Title : Resource-Oriented Lightweight Information Exchange Authors : John P. Field Stephen A. Banghart David Waltermire Filename : draft-ietf-mile-rolie-13.txt Pages : 46 Date : 2017-10-27 Abstract: This document defines a resource-oriented approach for security automation information publication, discovery, and sharing. Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources. Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on- demand information exchange network for restricted internal use or public access repositories. This specification extends the Atom Publishing Protocol and Atom Syndication Format to transport and share security automation resource representations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mile-rolie-13 https://datatracker.ietf.org/doc/html/draft-ietf-mile-rolie-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mile-rolie-13 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 Fri Oct 27 13:29:47 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D358C13F5CC; Fri, 27 Oct 2017 13:29:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , "Nancy Cam-Winget" X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150913617185.22127.151179730341057352.idtracker@ietfa.amsl.com> Date: Fri, 27 Oct 2017 13:29:31 -0700 Archived-At: Subject: [mile] New Version Notification - draft-ietf-mile-rolie-13.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 20:29:32 -0000 A new version (-13) has been submitted for draft-ietf-mile-rolie: https://www.ietf.org/internet-drafts/draft-ietf-mile-rolie-13.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-mile-rolie-13 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. IETF Secretariat. From nobody Fri Oct 27 14:44:59 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BA2139567 for ; Fri, 27 Oct 2017 14:44:56 -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, 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 QtkePbV6dGlJ for ; Fri, 27 Oct 2017 14:44:54 -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 C792F13F5E3 for ; Fri, 27 Oct 2017 14:44:54 -0700 (PDT) Received: from [10.0.1.82] (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 v9RLimDw047050 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 27 Oct 2017 16:44:49 -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.82] From: Ben Campbell Message-Id: <34CB9DBA-2969-48BA-BC28-3916B160A87A@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_394ABC07-F2F1-4EDC-AE1F-4453A6683B67"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Date: Fri, 27 Oct 2017 16:44:47 -0500 In-Reply-To: Cc: "ncamwing@cisco.com" , "mile-chairs@tools.ietf.org" , "draft-ietf-mile-rolie@ietf.org" , The IESG , "mile-chairs@ietf.org" , "mile@ietf.org" To: "Banghart, Stephen A. (Fed)" References: <150889744468.4711.7690332098961761471.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [mile] Ben Campbell's Discuss on draft-ietf-mile-rolie-11: (with DISCUSS and COMMENT) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 21:44:56 -0000 --Apple-Mail=_394ABC07-F2F1-4EDC-AE1F-4453A6683B67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 26, 2017, at 10:06 AM, Banghart, Stephen A. (Fed) = wrote: >=20 > Ben, >=20 > My responses are inline. >=20 > Thanks, > Stephen >=20 >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, October 25, 2017 11:35 PM >> To: Banghart, Stephen A. (Fed) >> Cc: ncamwing@cisco.com; mile-chairs@tools.ietf.org; mile@ietf.org; = The >> IESG ; mile-chairs@ietf.org; = draft-ietf-mile-rolie@ietf.org >> Subject: Re: Ben Campbell's Discuss on draft-ietf-mile-rolie-11: = (with DISCUSS >> and COMMENT) >>=20 >> Thanks for the response. Comments also inline: >>=20 >>> On Oct 25, 2017, at 3:10 PM, Banghart, Stephen A. (Fed) >> wrote: >>>=20 >>> Ben, >>>=20 >>> Thanks for the review, I've put my comments/changes inline. >>>=20 >>> Thanks, >>> Stephen >>>=20 >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>> Sent: Tuesday, October 24, 2017 10:11 PM >>>> To: The IESG >>>> Cc: draft-ietf-mile-rolie@ietf.org; mile@ietf.org; >>>> mile-chairs@tools.ietf.org; Nancy Cam-Winget ; >>>> mile-chairs@ietf.org; ncamwing@cisco.com; mile@ietf.org >>>> Subject: Ben Campbell's Discuss on draft-ietf-mile-rolie-11: (with >>>> DISCUSS and COMMENT) >>>>=20 >>=20 >> [=E2=80=A6] >>=20 >>>>=20 >>>> = --------------------------------------------------------------------- >>>> - >>>> DISCUSS: >>>> = --------------------------------------------------------------------- >>>> - >>>>=20 >>>> -5.1.3: >>>>=20 >>>> I don't think Martin's ART-ART review concern (and Mark's support) >>>> about the .well-known URL registration has been fully resolved. = While >>>> version 11 removed some of the well-known registrations, it still >>>> leaves the one. Mark pointed out that RFC 5785 offers explicit >>>> guidance that .well-known URLs are intended to offer site-wide = policy >>>> or metadata, and are not intended for general information = retrieval, >>>> or to establish a namespace. This usage seems to me to be exactly = the >> sort of thing that the RFC advises against. >>>>=20 >>>> I recognize that security information is important, but I don't >>>> understand why it's discovery needs to be fundamentally different >>>> than for other stuff on using ATOM. I'm willing to be convinced, = but >>>> if there's been a convincing argument so far I've missed it. >>>=20 >>> I replied to Martin's concern on this issue in an earlier e-mail and = I >>> think we've reached agreement on the justification for the = well-known >>> registration >>> (https://mailarchive.ietf.org/arch/msg/mile/gbG5nC8Oh4q76P-0dXHwM- >> ztMP >>> Y) >>>=20 >>> ROLIE is largely intended to be handled by automated systems that = cannot >> reliably locate links given by front-facing sites. In these cases, = the ROLIE >> clients need a reliable way of finding a ROLIE repository hosted by a = given >> server. The well-known registration provides a standardized place for = the >> head of the ROLIE repository to be retrieved, making it possible for = an >> automated system to function when only given a host name and port. >>>=20 >>> We've added the following additional justification text to the = specification >> to help clarify our reasoning. >>>=20 >>> "ROLIE repositories are largely intended to be consumed by automated >> systems. While humans may be able to navigate a web page or receive = an >> email to find a link to the repository, automated systems struggle = with such >> tasks. By creating a standardized location for the Service Document, = ROLIE >> clients need only a host name and port in order to locate a ROLIE = repository. >> This lower barrier to entry reduces the amount of human intervention >> required for ROLIE clients to begin reading Feeds.=E2=80=9D >>=20 >> It=E2=80=99s not clear to me why its substantially easier to learn = name and port than it >> is to learn a URL. As Adam pointed out in his separate DISCUSS, = there=E2=80=99s no >> discovery mechanism (yet) for the hostname and port=E2=80=94that is, = someone will >> have to tell that automated system what name and port to use. Adam = also >> pointed out that there are potential design paths (e.g. NAPTR) for = discovery >> mechanisms that would give you a URL. >>=20 >> .well-known URLs are intended for when no other discovery mechanisms >> make sense. >=20 > We are considering the use case where a vendor wants to provide = security automation information through ROLIE, such as public disclose = of vulnerabilities, or software metadata. Potential consumers know the = hostname and port of the vendor already, but need to know where to find = the ROLIE repository. In this case, providing a tool with a hostname and = port is substantially easier than tracking down a ROLIE Service Document = URL. I think we are talking past each other. I understand the use case. I = haven=E2=80=99t seen an explanation about why you think that use case = fits the guidance from section 1.1 of RFC 5785. (I note the expert = reviewer for the .well-known URL registry gave the same feedback.) >=20 > For example, if I want to have my ROLIE client tool check to see if = Microsoft is hosting a ROLIE repository, I need only to provide it with = "http://microsoft.com" and it'll do the rest. Why do you assume that the ROLIE data is at at microsoft.com and not = rolie.microsoft.com? Do you assume the data is at the default HTTPS = port? (I don=E2=80=99t recall seeing either in the draft, but may have = missed it.) I think this was the sort of questions Adam had in mind when = he described this as =E2=80=9Cguessing=E2=80=9D. (You could learn the port via DNS SRV, but as you clarified, that=E2=80=99= s not specified yet.) >=20 > Additionally, we feel that a well-known registration will be needed = for a full discovery system, and as such, this is laying the foundation = for that work in the future. It=E2=80=99s laying that foundation based on an assumption that may or = may not be well founded. Do you have a mechanism in mind? More to the point, RFC 5785 says =E2=80=9C[well-known URLs] are designed = to facilitate discovery of information on a site when it isn't practical = to use other mechanisms=E2=80=9D You could fairly easily specify a = discovery system that doesn=E2=80=99t require a well-known registration. = Adam=E2=80=99s comment about DNS NAPTR is an existence proof. Is there a = reason why that would not be practical? If the justification for the well-known registration is that the = discovery mechanism will likely need it, then I propose the registration = be done as part of the spec for the discovery mechanism. >=20 >=20 >>>=20 >>> We've dropped the well-known registration for the Category Document, = as >> it is locatable from the Service Document where applicable. >>=20 >>>>=20 >>>> I'm not sure what to make of the second paragraph. It says DNS SRV >>>> can be used to determine the host and port. Is the expectation that >>>> people can just do that without further specification, or that >>>> someone could specify it in the future? >>>> The former is generally not true. If the intent is the latter, = please >>>> clarify that in the text. >>>=20 >>> The intent was the latter. I've changed the end of that paragraph to = further >> clarify as follows: >>>=20 >>> "Use of a mechanism such as DNS SRV Records can provide a secure = and >> reliable discovery mechanism for determining a specific host and port = to use >> for retrieving a Service Document for a given DNS domain. This is a = feature >> that may be standardized in the future.=E2=80=9D >>=20 >> That would resolve my concern. >>=20 >>>=20 >>>>=20 >>>> = --------------------------------------------------------------------- >>>> - >>>> COMMENT: >>>> = --------------------------------------------------------------------- >>>> - >>>>=20 >>>> Substantive: >>>>=20 >>>> -2: There are a number of lower case versions of 2119 keywords. If >>>> those are intentional, please use the updated boilerplate from RFC >>>> 8174. That being said, the following paragraph says the keywords = are used >> for conformance. >>>> 2219/8174 keywords are not about conformance. They are about >>>> interoperability. If you want to use them for conformance, that's >>>> okay--but that means they are no longer being used as intended by >>>> 2119, and the boilerplate should be adjusted accordingly. >>>=20 >>> The lower case keywords are intentional. We've switched the = boilerplate >> text to the updated 8174 version. >>=20 >> Okay. >>=20 >>>=20 >>>> -3.2: I'm confused by the idea the schema is informative. I expect >>>> that at least some implementors will implement to the schema. We >>>> have a perennial problem where implementors implement the examples >>>> rather than the text. It seems like a non-normative schema is even >>>> more of an attractive hazard in that regard. >>>=20 >>> We found that available schema languages cannot express the same >> complexities we could express in text. There are difficult = conditional >> requirements that are poorly expressed in schemas but can be fit into = a neat >> sentence. In order to support the places where we do that, we decided = that >> making the text normative was the only way to ensure that the >> requirements were expressed clearly. >>>=20 >>> Additionally, Atom Syndication and the Atom Publishing Protocol both >> specify that the text is normative, not the included schemas. By = making the >> schema informative, we are keeping with this practice. >>=20 >> Do you believe an implementer could reasonably code this just from = the text >> without looking at the schema? >>=20 >> The problem of needing additional constraints over what can be = expressed in >> a formal language, whether that=E2=80=99s a schema, ABNF, etc, is = common. It=E2=80=99s >> typical to still consider the normative definition to include both = the formal >> definition and those additional constraints. >=20 > Given that an implementer would need to carefully read the plain text = in either case, we feel that using the most expressive option for the = normative requirement is the best way of doing it. >=20 > Having written an implementation of Atom Pub (Which uses normative = plain text) and of ROLIE, I wish I could just copy and paste some schema = and be done, but given that it isn=E2=80=99t possible, using the plain = text to implement wasn't bad. Just to make sure my point is clear: The fact that a schema is = incomplete does not normally make it non-normative. Do you believe the = ROLIE spec would be complete without the schema? If the answer is no, = then the schema is effectively normative. If the answer is yes, then why = include it at all? Thanks! Bne. --Apple-Mail=_394ABC07-F2F1-4EDC-AE1F-4453A6683B67 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlnzqM8ACgkQgFZKbJXz 1A2B2RAAvzs1lUhKvViGTswazobh2ggQlZ4gfTZMDMrvUV7ty/Hae1F3PrU5ge1/ aJIKupTucBtP8p+lWkBwUQx2A43WkDU96HaEOJQ9Qqn+JrZzEldDPR6k+Dflz2kQ //RZIUSjsS6BjT+7cq8Dzz5UPBBIzgXSbw28yXTJSyAMMaNB2yNaoa5AOb7gKjUp hSP8qiEiJWc28x4Ke7tKIVmhDE/Jdr2RNrEduSIjkyVQ3zp/uxnWZEVKzA97TNKF 3TgNqyTScpGtqaw/qOC+Yacf9t28szcawUNMp8s1nxt8umFX1w6tggrO36eSdmFY fwyr6gKOW770wbVpvESJ+rZmRf6qFF0AdrYygt+Sjv4oNLJdthEijuS/QwOAMkY3 4NICH6qdgfIij08mFyxNLkXL+ezD1FvENUOKBXYpOC9jmNRH/h3gs+H20MDcqGw8 NOrDBtgJgMB8OZ5AaCAcJf65G1fkZThvuwHf6eZFmpZ/PPcNNP5nA6qaWYhJ9AJW ADRA30PkGx4/YtwRFhbA8luzGcKUklCIg67HI2HMnLTYYrTBdVzjQ8jG4pi1Yl6/ cW1P28OYHEjSXnHBJjqkvsswXbr8o5S9gOaR95lsrWvEbv7SPyIHTn1EkR9k1c2d Y2O40dIkqP6NfcVIxMtf0+b++XPbE1cRxTbmLn1emLKgIvTQb1A= =UcZ7 -----END PGP SIGNATURE----- --Apple-Mail=_394ABC07-F2F1-4EDC-AE1F-4453A6683B67-- From nobody Sat Oct 28 09:33:47 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1B513A65C for ; Fri, 27 Oct 2017 11:13:57 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 CVQwvQOPOFS6 for ; Fri, 27 Oct 2017 11:13:55 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0109.outbound.protection.outlook.com [23.103.201.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56AC713F088 for ; Fri, 27 Oct 2017 11:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7xrbYc5U2U0oOkbRs3JWcLJrlp4kMLaiN/BBtKKT4aE=; b=kM6tCxg0eKqrNBJg94mfty++Xt8yRiFA18p4TgFFYv1FyQDESKkHdlAbsWMYJJTrFcUixppXg191/wUR+bQfsONYIitzPfYKkvbTc2JLeGAHrWVhURXI93sqjkdnrLHZsHAOqG82Md1Z79wgGzqroLRpG0mVbd9OnJse3rICpuw= Received: from MWHPR09MB1197.namprd09.prod.outlook.com (10.172.49.143) by MWHPR09MB1503.namprd09.prod.outlook.com (10.173.50.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Fri, 27 Oct 2017 18:13:53 +0000 Received: from MWHPR09MB1197.namprd09.prod.outlook.com ([10.172.49.143]) by MWHPR09MB1197.namprd09.prod.outlook.com ([10.172.49.143]) with mapi id 15.20.0178.007; Fri, 27 Oct 2017 18:13:52 +0000 From: "Banghart, Stephen A. (Fed)" To: "drafts-expert-review@iana.org" CC: "jfield@pivotal.io" , "Waltermire, David A. (Fed)" , "ncamwing@cisco.com" , "takeshi_takahashi@nict.go.jp" , "Kathleen.Moriarty.ietf@gmail.com" , "ekr@rtfm.com" , "mile-chairs@tools.ietf.org" , "mile@ietf.org" , Ben Campbell , Adam Roach Thread-Topic: [IANA #985228] expert review for draft-ietf-mile-rolie (well-known-uris) Thread-Index: AQHTRrboUMvU9re9y0qz2yC1kmyIEaL0ux+A Date: Fri, 27 Oct 2017 18:13:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.251.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR09MB1503; 6:O9TAzxo5ODPTXEQPQkVSuPwF8v3IjaACRnZRDij6ps4SqvgdjFkWUpztmpZon9HdfQbsUlMNjNuqem+JFUcGJ21p8tFdlU5TM2biso92Y3cR9JcH4bvbshpsnM9w9f9NbPIX/l/jCBWxCKg4o1Za2wHDZ6wZ5oemYgDMihCF8myUzwL1xKLH0QEaN1uTfK+6q1nP++Yi0jjeCrxTbUcX/QWLaTVntWmE2yxySUEnBhFY04PT4UwUMexeyXSN9buX60ALMqw2Ae7w5WbH6Or3rHEAt2yC+TzNdXvqV9Oclh1gGgvVVkCj9Eds15oEUUhA2504FY4nzaZfkaAKRcP4um6/AgW7Y+7Cnd4U4tMTsR8=; 5:wSw42jcklniZcAWr4bPnwd+StphPasmAi6gPHvi5yqSRTmx9cqGSpyQcwDAQJ11O99Dqp4TNB1XDZDunD+ssmL79w023zV8GTKOsnasl1KLguQklN0G69gqTpd/eWN+DYqfLCGBiYgNOKQZdx4id6nnLQmsWhr8nPodRMBM1FQ8=; 24:HDtI3EP0jtqxzfL4Qq4WkXs0DU3uvEba8drNcT+zeupj8cu6vtySLg1dyApUvDcOHplv87jAfim3wK+ffS89MCvLtRXPGk/xt84MoGGcBfc=; 7:xj/AW3OnPq4gFY+OHQPHOM2knwnUF6D58xV+0gR7V17Ug0Tt30jqz5fesTmCG31gWOa3Y3oHqy1mFdaPIjXv4EKcr2mbtsn2Foymk+W9Ekyxol9n8CTxrPVWUgkYAAyNVBnfLtvoZjzlH/8tw/KDx3YmT4xgDZ1M8n8CwSR20yWhbC/V5dmHsN8VfFF/3GzQPtfEUW4sqhMn+GG3ByXU8qMfbEA0n9uaI4oqpjG/FSDmVx3NGrOzBUtdAhtih4ZF x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(85644002)(13464003)(189002)(199003)(6116002)(106356001)(7696004)(3846002)(105586002)(102836003)(2351001)(5640700003)(5660300001)(478600001)(230783001)(97736004)(3660700001)(53936002)(39060400002)(3280700002)(4326008)(99286003)(55016002)(6246003)(9686003)(2906002)(189998001)(81166006)(6436002)(81156014)(6506006)(316002)(74316002)(2501003)(66066001)(8936002)(229853002)(6916009)(2950100002)(77096006)(86362001)(7736002)(54356999)(305945005)(76176999)(50986999)(101416001)(25786009)(8676002)(7416002)(33656002)(2900100001)(68736007)(14454004)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1503; H:MWHPR09MB1197.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: c965dcf0-e50c-4237-bfde-08d51d667ad9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603199); SRVR:MWHPR09MB1503; x-ms-traffictypediagnostic: MWHPR09MB1503: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(150554046322364)(95692535739014); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3231020)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR09MB1503; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR09MB1503; x-forefront-prvs: 0473A03F3F received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: c965dcf0-e50c-4237-bfde-08d51d667ad9 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 18:13:52.6972 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1503 Archived-At: X-Mailman-Approved-At: Sat, 28 Oct 2017 09:33:45 -0700 Subject: Re: [mile] [IANA #985228] expert review for draft-ietf-mile-rolie (well-known-uris) X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 18:13:58 -0000 U2FicmluYSwNCg0KV2UgaGF2ZSBtYWRlIHNldmVyYWwgY2hhbmdlcyB0byB0aGUgSUFOQSBzZWN0 aW9uIHRvIGFkZHJlc3MgYm90aCB5b3VyIGNvbW1lbnRzIGFuZCBJRVNHIGNvbW1lbnRzLiBJJ3Zl IGxpc3RlZCB0aGVtIGhlcmU6DQoNCldlJ3ZlIGNoYW5nZWQgdGhlIC8ud2VsbC1rbm93biByZWdp c3RyYXRpb24gZnJvbSAicm9saWUvc2VydmljZWRvY3VtZW50IHRvICJyb2xpZSIgaW4gb3JkZXIg dG8gY29uZm9ybSB0byBSRkM1Nzg1IHJlZ2lzdHJhdGlvbiByZXF1aXJlbWVudHMuDQoNCldlJ3Zl IHJlbW92ZWQgdGhlIC8ud2VsbC1rbm93biByZWdpc3RyYXRpb24gZm9yICJyb2xpZS9jYXRlZ29y eWRvY3VtZW50IiBmb2xsb3dpbmcgSUVTRyByZXZpZXcuDQoNCldlJ3ZlIHVwZGF0ZWQgdGV4dCBp biB0aGUgUk9MSUUgVVJOIFBhcmFtZXRlcnMgU2VjdGlvbi4gVGhlIGZpcnN0IHBhcmFncmFwaCBy ZWNlaXZlZCBjbGFyaWZ5aW5nIHRleHR1YWwgY2hhbmdlcyBmb2xsb3dpbmcgSUVTRyByZXZpZXcu IFRoZSBzZWNvbmQgcGFyYWdyYXBoIChyZWdhcmRpbmcgRGVzaWduYXRlZCBFeHBlcnRzKSBoYXMg YmVlbiBjaGFuZ2VkIHRvIHRoZSBmb2xsb3dpbmc6IA0KDQoiUmVnaXN0cmF0aW9uIGluIHRoZSBS T0xJRSBVUk4gUGFyYW1ldGVycyByZWdpc3RyeSBpcyB2aWEgdGhlDQogICAgICAgICAgU3BlY2lm aWNhdGlvbiBSZXF1aXJlZCBwb2xpY3kgPHhyZWYgdGFyZ2V0PSJSRkM4MTI2Ii8+Lg0KICAgICAg ICAgIFJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBtdXN0IGJlIHNlbnQgdG8gYm90aCB0aGUgTUlMRSBX RyBtYWlsaW5nDQogICAgICAgICAgbGlzdCAobWlsZUBpZXRmLm9yZykgYW5kIElBTkEuIElBTkEg d2lsbCBmb3J3YXJkIHJlZ2lzdHJhdGlvbg0KICAgICAgICAgIHJlcXVlc3RzIHRvIHRoZSBEZXNp Z25hdGVkIEV4cGVydC4iDQoNCldpdGggcmVnYXJkcyB0byB0aGUgLy53ZWxsLWtub3duIHJlZ2lz dHJhdGlvbiBmb3IgInJvbGllIiwgd2UgYmVsaWV2ZSB0aGF0IHRoZSByZWdpc3RyYXRpb24gZG9l cyBwcm92aWRlIHNpdGUtd2lkZSBtZXRhZGF0YSBhbmQgVVJJIGxpbmtzIHRvIGFkZGl0aW9uYWwg bWV0YWRhdGEuIFRoZSBTZXJ2aWNlIERvY3VtZW50IHRoYXQgaXMgcmV0cmlldmVkIGZyb20gdGhl IC53ZWxsLWtub3duIGxvY2F0aW9uIGFsbG93cyBjb25zdW1lcnMgdG8gcmV0cmlldmUgdGhlIHRv cC1sZXZlbCBST0xJRSBtZXRhZGF0YSBmb3IgdGhlIHNpdGUsIGFuZCBwcm92aWRlcyB0aGUgaGVh ZCBmb3IgbGlua2luZyBpbnRvIHRoZSByZXN0IG9mIHRoZSBST0xJRSByZXBvc2l0b3J5Lg0KDQpS T0xJRSBpcyBpbnRlbmRlZCB0byBiZSB1c2VkIGJ5IGF1dG9tYXRlZCBzeXN0ZW1zLCBmb3IgdGhl c2Ugc3lzdGVtcywgbG9jYXRpbmcgYSBVUkwgY2FuIGJlIHBhcnRpY3VsYXJseSBkaWZmaWN1bHQu IFRoaXMgcmVnaXN0cmF0aW9uIHByb3ZpZGVzIGEgY29uc2lzdGVudCBhbmQgc3RhbmRhcmQgd2F5 IGZvciBhdXRvbWF0ZWQgc3lzdGVtcyB0byBsb2NhdGUgUk9MSUUgcmVwb3NpdG9yaWVzIGdpdmVu IGEgaG9zdG5hbWUgYW5kIHBvcnQuDQoNClRoZSBETlMgU1JWIHJlY29yZHMgYXJlIGEgcG90ZW50 aWFsIHNvbHV0aW9uIGZvciBmdWxseSBhdXRvbWF0ZWQgZGlzY292ZXJ5LCB3ZSd2ZSBhZGRlZCB0 ZXh0IHRvIHRoZSBkcmFmdCBjbGFyaWZ5aW5nIHRoYXQgd2Ugd2lsbCBzdGFuZGFyZGl6ZSB0aGlz IGZlYXR1cmUgaW4gdGhlIGZ1dHVyZS4gV2UndmUgYWxzbyBhZGRlZCB0ZXh0IHRoYXQgY292ZXJz IHRoZSBqdXN0aWZpY2F0aW9ucyBmb3IgdGhlIC53ZWxsLWtub3duIHJlZ2lzdHJhdGlvbi4NCg0K SSBob3BlIHRoaXMgY2xlYXJzIHVwIHlvdXIgY29tbWVudHMvY29uY2VybnMuDQoNClRoYW5rcywN ClN0ZXBoZW4gQmFuZ2hhcnQNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IFNhYnJpbmEgVGFuYW1hbCB2aWEgUlQgW21haWx0bzpkcmFmdHMtZXhwZXJ0LXJldmlld0Bp YW5hLm9yZ10NCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDE2LCAyMDE3IDM6NDIgUE0NCj4gQ2M6 IGpmaWVsZEBwaXZvdGFsLmlvOyBCYW5naGFydCwgU3RlcGhlbiBBLiAoRmVkKQ0KPiA8c3RlcGhl bi5iYW5naGFydEBuaXN0Lmdvdj47IFdhbHRlcm1pcmUsIERhdmlkIEEuIChGZWQpDQo+IDxkYXZp ZC53YWx0ZXJtaXJlQG5pc3QuZ292PjsgbmNhbXdpbmdAY2lzY28uY29tOw0KPiB0YWtlc2hpX3Rh a2FoYXNoaUBuaWN0LmdvLmpwOyBLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTsNCj4g ZWtyQHJ0Zm0uY29tOyBtaWxlLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgbWlsZUBpZXRmLm9yZw0K PiBTdWJqZWN0OiBbSUFOQSAjOTg1MjI4XSBleHBlcnQgcmV2aWV3IGZvciBkcmFmdC1pZXRmLW1p bGUtcm9saWUgKHdlbGwta25vd24tDQo+IHVyaXMpDQo+IA0KPiBEZWFyIEF1dGhvcnMvQ2hhaXJz L0FEczoNCj4gDQo+IFBsZWFzZSBzZWUgdGhlIGNvbW1lbnRzIGZyb20gdGhlIGRlc2lnbmF0ZWQg ZXhwZXJ0IGJlbG93Lg0KPiANCj4gVGhhbmsgeW91LA0KPiANCj4gU2FicmluYSBUYW5hbWFsDQo+ IElBTkEgU2VydmljZXMgU3BlY2lhbGlzdA0KPiANCj4gLS0tDQo+IA0KPiBUaGlzIGRyYWZ0IHBy b3Bvc2VzIHJlZ2lzdHJhdGlvbiBvZiBhIHdlbGwta25vd24gVVJJLA0KPiAicm9saWUvc2Vydmlj ZWRvY3VtZW50Ii4NCj4gDQo+IFRoYXQgc3ludGF4IGRvZXMgbm90IGNvbmZvcm0gdG8gdGhlIHJl cXVpcmVtZW50cyBvZiBSRkM1Nzg1LCBTZWN0aW9uIDM6DQo+IA0KPiAiIiINCj4gUmVnaXN0ZXJl ZCBuYW1lcyBNVVNUIGNvbmZvcm0gdG8gdGhlIHNlZ21lbnQtbnogcHJvZHVjdGlvbiBpbltSRkMz OTg2XS4NCj4gIiIiDQo+IA0KPiBJJ2Qgc3VnZ2VzdCByZWdpc3RlcmluZyBqdXN0ICJyb2xpZSIg YW5kIHNwZWNpZnlpbmcgdGhhdCAiL3NlcnZpY2Vkb2N1bWVudCINCj4gdW5kZXIgaXQgaXMgdXNl ZCBmb3IgdGhpcyBwdXJwb3NlLCBhbmQgdGhhdCBvdGhlciBwYXRocyB1bmRlciAicm9saWUiIGNh biBiZQ0KPiByZXNlcnZlZCB1c2luZyBvdGhlciBzdGFuZGFyZHMtdHJhY2sgZG9jdW1lbnRzLg0K PiANCj4gSG93ZXZlciwgaXQgaXMgbm90IGNsZWFyIHdoeSBzdWNoIGEgd2VsbC1rbm93biBVUkkg aXMgbmVlZGVkLiBSRkM1Nzg1DQo+IHN0YXRlczoNCj4gDQo+ICIiIg0KPiBbV11lbGwta25vd24g VVJJcyBhcmUgbm90IGludGVuZGVkIGZvciBnZW5lcmFsIGluZm9ybWF0aW9uIHJldHJpZXZhbCBv cg0KPiBlc3RhYmxpc2htZW50IG9mIGxhcmdlIFVSSSBuYW1lc3BhY2VzIG9uIHRoZSBXZWIuIFJh dGhlciwgdGhleSBhcmUNCj4gZGVzaWduZWQgdG8gZmFjaWxpdGF0ZSBkaXNjb3Zlcnkgb2YgaW5m b3JtYXRpb24gb24gYSBzaXRlIHdoZW4gaXQgaXNuJ3QgcHJhY3RpY2FsDQo+IHRvIHVzZSBvdGhl ciBtZWNoYW5pc21zOyBmb3IgZXhhbXBsZSwgd2hlbiBkaXNjb3ZlcmluZyBwb2xpY3kgdGhhdCBu ZWVkcw0KPiB0byBiZSBldmFsdWF0ZWQgYmVmb3JlIGEgcmVzb3VyY2UgaXMgYWNjZXNzZWQsIG9y IHdoZW4gdXNpbmcgbXVsdGlwbGUgcm91bmQtDQo+IHRyaXBzIGlzIGp1ZGdlZCBkZXRyaW1lbnRh bCB0byBwZXJmb3JtYW5jZS4NCj4gDQo+IEFzIHN1Y2gsIHRoZSB3ZWxsLWtub3duIFVSSSBzcGFj ZSB3YXMgY3JlYXRlZCB3aXRoIHRoZSBleHBlY3RhdGlvbiB0aGF0IGl0DQo+IHdpbGwgYmUgdXNl ZCB0byBtYWtlIHNpdGUtd2lkZSBwb2xpY3kgaW5mb3JtYXRpb24gYW5kIG90aGVyIG1ldGFkYXRh DQo+IGF2YWlsYWJsZSBkaXJlY3RseSAoaWYgc3VmZmljaWVudGx5IGNvbmNpc2UpLCBvciBwcm92 aWRlIHJlZmVyZW5jZXMgdG8gb3RoZXIgVVJJcw0KPiB0aGF0IHByb3ZpZGUgc3VjaCBtZXRhZGF0 YS4NCj4gIiIiDQo+IA0KPiBUaGlzIGRyYWZ0IGRvZXNuJ3QgZXhwbGFpbiB3aHkgdXNpbmcgYSBV UkwgdG8gbG9jYXRlIGEgc2VydmljZSBkb2N1bWVudCBpc24ndA0KPiBzdWZmaWNpZW50OyBpbiBv dGhlciB3b3Jkcywgd2h5IGlzIGl0IG5lY2Vzc2FyeSB0byByZXNlcnZlIG5hbWUgc3BhY2Ugb24N Cj4gZXZlcnkgV2ViIHNlcnZlciBleGlzdGVudCBmb3IgdGhpcyBmdW5jdGlvbj8NCj4gDQo+IFRo ZSBkcmFmdCBkb2VzIG1lbnRpb246DQo+IA0KPiAiIiINCj4gQSBtZWNoYW5pc20gdG8gZGV0ZXJt aW5lIHdoaWNoIGhvc3QgYW5kIHBvcnQgdG8gdXNlIGlzIG5vdCBzcGVjaWZpZWQgaW4gdGhpcw0K PiBkb2N1bWVudC4gVXNlIG9mIGEgbWVjaGFuaXNtIHN1Y2ggYXMgRE5TIFNSViBSZWNvcmRzIFtS RkMyNzgyXSBjYW4NCj4gcHJvdmlkZSBhIHNlY3VyZSBhbmQgcmVsaWFibGUgZGlzY292ZXJ5IG1l Y2hhbmlzbSBmb3IgZGV0ZXJtaW5pbmcgYSBzcGVjaWZpYw0KPiBob3N0IGFuZCBwb3J0IHRvIHVz ZSBmb3IgcmV0cmlldmluZyBhIFNlcnZpY2UgRG9jdW1lbnQgZm9yIGEgZ2l2ZW4gRE5TDQo+IGRv bWFpbi4NCj4gIiIiDQo+IA0KPiAuLi4gYnV0IGl0IGRvZXMgbm90IHNwZWNpZnkgaG93IHRvIHVz ZSBETlMgU1JWIHRvIGFjaGlldmUgdGhpcyBnb2FsLCBsZWFkaW5nIG1lDQo+IHRvIGJlbGlldmUg dGhhdCB0aGlzIGlzIHVuZGVyc3BlY2lmaWVkIGFuZCBub3QgYSBzdHJvbmcgbW90aXZhdGlvbiBm b3IgdGhlIHdlbGwtDQo+IGtub3duIFVSSS4NCj4gDQo+IElzIHRoZXJlIHNvbWUgY29udGV4dCBh Ym91dCB0aGlzIHByb3Bvc2VkIHVzZSB0aGF0IEkndmUgb3Zlcmxvb2tlZD8NCj4gLS0tODwtLS0N Cg== From nobody Mon Oct 30 15:56:27 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2355413FC5B; Mon, 30 Oct 2017 15:56:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mile@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940418008.28278.5416683225694929593@ietfa.amsl.com> Date: Mon, 30 Oct 2017 15:56:20 -0700 Archived-At: Subject: [mile] I-D Action: draft-ietf-mile-xmpp-grid-04.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 22:56:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Managed Incident Lightweight Exchange WG of the IETF. Title : Using XMPP for Security Information Exchange Authors : Nancy Cam-Winget Syam Appala Scott Pope Peter Saint-Andre Filename : draft-ietf-mile-xmpp-grid-04.txt Pages : 21 Date : 2017-10-30 Abstract: This document describes how to use the Extensible Messaging and Presence Protocol (XMPP) as a transport for collecting and distributing security-relevant information between network-connected devices. To illustrate the principles involved, this document describes such a usage for the Incident Object Description Exchange Format (IODEF). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mile-xmpp-grid-04 https://datatracker.ietf.org/doc/html/draft-ietf-mile-xmpp-grid-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mile-xmpp-grid-04 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 Mon Oct 30 15:56:38 2017 Return-Path: X-Original-To: mile@ietf.org Delivered-To: mile@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BDAC557; Mon, 30 Oct 2017 15:56:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940418026.28278.12653349422793669641.idtracker@ietfa.amsl.com> Date: Mon, 30 Oct 2017 15:56:20 -0700 Archived-At: Subject: [mile] New Version Notification - draft-ietf-mile-xmpp-grid-04.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 22:56:20 -0000 A new version (-04) has been submitted for draft-ietf-mile-xmpp-grid: https://www.ietf.org/internet-drafts/draft-ietf-mile-xmpp-grid-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-mile-xmpp-grid-04 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. IETF Secretariat. From nobody Tue Oct 31 14:43:42 2017 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF83613F428 for ; Tue, 31 Oct 2017 14:43:40 -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=stpeter.im header.b=I3iwQMWb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fXcgwllZ 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 fjxDS890OnwI for ; Tue, 31 Oct 2017 14:43:39 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E70139553 for ; Tue, 31 Oct 2017 14:43:39 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 56B70207D7; Tue, 31 Oct 2017 17:43:38 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 31 Oct 2017 17:43:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=KMd+zbrTXIwvAglOE+7yhRzFxpOCRgD+I/JE4trDKIU=; b=I3iwQMWb Aq76X0MAsj2WIDPiuqbPvSsHoPIhN0gsBak8UkU1G8RSumBljSRs62mFh4Ox/mpg KZRTNO8r3iUDnSHWocH62XKgP+P6zsGrNXmlYL/ysHLwipwlrvykpjsdrqb8lfO+ ipO37V5w+Ez9Q/zgkPhlf8cu6Hb1pdG3k2DOyDxsiHvZvQjKl2VzXuZz7NHp+TLK PpX2ry+aRyc/0rRxvo6CJVXHevqVXR8nx8hTyfXlm3pzWayI6LuDAk4XJWdkVnUK xdTw2tX5xRUKCmXjytoznyoCwWku1OPPisBbSV05PeYNkX48ZMkdj5oae3DD6Ety pyj8c1spJrd/jg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=KMd+zbrTXIwvAglOE+7yhRzFxpOCR gD+I/JE4trDKIU=; b=fXcgwllZFGQ22zGLHCvZCAp2Me+JdvsBowSDJteonGI96 lCN/+ezSBuFBzX/W9nraCPwvwQqaM/y/S54+XUVAmTw1ltm8m497mZNWDCcfP8Pq bYEWbMU1qpmpPEl6ltbnBVmA+ewJVCXZTkAiYhGOF0dM8Kk2fn30vK/6tLRQtnw3 XzE6QYcfEd3ZPInk2H3jfiD+IDoK1QwDLPYjmapsyUPbaFlza0K+UP/grP4GkyEZ gvI80tKeiOjArjX+J8UdOV8hN1sEkhiY3Q+Y6uguuibu52+bhaq97TkEZUMqEX1Z vC+HMAZKBOmsvPCxrrT68Lkzguz4hHhGTNq1pdqsw== X-ME-Sender: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id E21782432A; Tue, 31 Oct 2017 17:43:37 -0400 (EDT) To: mile@ietf.org References: <150940418008.28278.5416683225694929593@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: <15317e65-19f4-e9b7-88aa-bcdc80260544@stpeter.im> Date: Tue, 31 Oct 2017 15:43:36 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <150940418008.28278.5416683225694929593@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hR8gQsEoLCNFIGGJw2f2ptoPoOhlEGLcX" Archived-At: Subject: Re: [mile] I-D Action: draft-ietf-mile-xmpp-grid-04.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 21:43:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hR8gQsEoLCNFIGGJw2f2ptoPoOhlEGLcX Content-Type: multipart/mixed; boundary="vrKSLwhdOTbxTaHXpfjiPApbNBWJwbM7k"; protected-headers="v1" From: Peter Saint-Andre To: mile@ietf.org Message-ID: <15317e65-19f4-e9b7-88aa-bcdc80260544@stpeter.im> Subject: Re: [mile] I-D Action: draft-ietf-mile-xmpp-grid-04.txt References: <150940418008.28278.5416683225694929593@ietfa.amsl.com> In-Reply-To: <150940418008.28278.5416683225694929593@ietfa.amsl.com> --vrKSLwhdOTbxTaHXpfjiPApbNBWJwbM7k Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable The authors convinced me to help with this document, so I'm now a co-author. My perspective on the changes: 1. We clarified the use of SACM terms and their mapping to XMPP terms 2. We tightened the focus on the broker (pubsub) flow 3. We removed a lot of excess text 4. We still need to add multiple examples and explain how to publish different kinds of payloads (e.g., IODEF vs. other formats) Unfortunately we ran out of time to address all the issues, so expect version -05 soon after the IETF meeting. Peter On 10/30/17 4:56 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Managed Incident Lightweight Exchange = WG of the IETF. >=20 > Title : Using XMPP for Security Information Exchange > Authors : Nancy Cam-Winget > Syam Appala > Scott Pope > Peter Saint-Andre > Filename : draft-ietf-mile-xmpp-grid-04.txt > Pages : 21 > Date : 2017-10-30 >=20 > Abstract: > This document describes how to use the Extensible Messaging and > Presence Protocol (XMPP) as a transport for collecting and > distributing security-relevant information between network-connected= > devices. To illustrate the principles involved, this document > describes such a usage for the Incident Object Description Exchange > Format (IODEF). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mile-xmpp-grid-04 > https://datatracker.ietf.org/doc/html/draft-ietf-mile-xmpp-grid-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mile-xmpp-grid-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile >=20 --vrKSLwhdOTbxTaHXpfjiPApbNBWJwbM7k-- --hR8gQsEoLCNFIGGJw2f2ptoPoOhlEGLcX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAln47ogACgkQ6gakkSvF ramrJhAAjo8bM6v2X+gZ/CvEerCisuHS2VxbmYyySA8lymQ01WvBTZmQN6TAo2s5 dGEP3NqgW8hE4EaQdkT+RDNj1h/gvub0MwKqzcXcyXmXUngXQd61ttLsSL53Y+UI bLObJA6aWkzXH2cGIdmB3/zAzQIGguJmFAxe7NCJKe7bVatY61XX31LKAeoAKEJz hdomTymdP5ReZlGJSW1fBTEYpY5UpwUvp3USeW5eiNaZFONAquV7fjkFIkuv/GsQ Bp7Vgv6C3wLttgow0ftsZoHGJ1cIbM+j1gCXp4FfL0Q5u/aMuST5xIfq7rP37FNJ 9Jh+0eMGtxqrpNrsO24kfxr0+hAUJacWtCzfKffPgt5TY9jXA5jqvb0NHKrWlFbU m2Q0idriRaoTXP79T1IZswnUitFPtfaU5ct8b4oCos6qMGjp//hqrzs5ML1DdIoK et0ayRdiUfifIYZR6idGDVUY6Q197kBhLRegutZy6QHSSd3kb5GrZVF14QVChN+C WizE84HARVSmgyrbveURnaPNNri/tsI15761vKdiJywP+hM23jCuf3l1aq4ape7S NfcHCztVWy7yVzMeXLL9IOInbnXWPfWb7NZTcirZb4Kd1ByyW0vj+qvn56ha23xX CaTQl/0rZVQvxA4Q995cA103pMJNQT9FLwhx0i0tESSaF4lkBuI= =+oQX -----END PGP SIGNATURE----- --hR8gQsEoLCNFIGGJw2f2ptoPoOhlEGLcX--