< draft-ietf-anima-grasp-10.txt		draft-ietf-anima-grasp-11A.txt >
	Network Working Group C. Bormann		Network Working Group C. Bormann
	Internet-Draft Universitaet Bremen TZI		Internet-Draft Universitaet Bremen TZI
	Intended status: Standards Track B. Carpenter, Ed.		Intended status: Standards Track B. Carpenter, Ed.
	Expires: September 11, 2017 Univ. of Auckland		Expires: September 29, 2017 Univ. of Auckland
	B. Liu, Ed.		B. Liu, Ed.
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
	March 10, 2017		March 28, 2017
	A Generic Autonomic Signaling Protocol (GRASP)		A Generic Autonomic Signaling Protocol (GRASP)
	draft-ietf-anima-grasp-10		draft-ietf-anima-grasp-11
	Abstract		Abstract
	This document establishes requirements for a signaling protocol that		This document establishes requirements for a signaling protocol that
	enables autonomic nodes and autonomic service agents to dynamically		enables autonomic nodes and autonomic service agents to dynamically
	discover peers, to synchronize state with them, and to negotiate		discover peers, to synchronize state with them, and to negotiate
	parameter settings with them. The document then defines a general		parameter settings with them. The document then defines a general
	protocol for discovery, synchronization and negotiation, while the		protocol for discovery, synchronization and negotiation, while the
	technical objectives for specific scenarios are to be described in		technical objectives for specific scenarios are to be described in
	separate documents. An Appendix briefly discusses existing protocols		separate documents. An Appendix briefly discusses existing protocols
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 11, 2017.		This Internet-Draft will expire on September 29, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 11		skipping to change at page 3, line 11
	3.9.1. Format of GRASP Options . . . . . . . . . . . . . . . 36		3.9.1. Format of GRASP Options . . . . . . . . . . . . . . . 36
	3.9.2. Divert Option . . . . . . . . . . . . . . . . . . . . 37		3.9.2. Divert Option . . . . . . . . . . . . . . . . . . . . 37
	3.9.3. Accept Option . . . . . . . . . . . . . . . . . . . . 37		3.9.3. Accept Option . . . . . . . . . . . . . . . . . . . . 37
	3.9.4. Decline Option . . . . . . . . . . . . . . . . . . . 37		3.9.4. Decline Option . . . . . . . . . . . . . . . . . . . 37
	3.9.5. Locator Options . . . . . . . . . . . . . . . . . . . 38		3.9.5. Locator Options . . . . . . . . . . . . . . . . . . . 38
	3.10. Objective Options . . . . . . . . . . . . . . . . . . . . 40		3.10. Objective Options . . . . . . . . . . . . . . . . . . . . 40
	3.10.1. Format of Objective Options . . . . . . . . . . . . 40		3.10.1. Format of Objective Options . . . . . . . . . . . . 40
	3.10.2. Objective flags . . . . . . . . . . . . . . . . . . 41		3.10.2. Objective flags . . . . . . . . . . . . . . . . . . 41
	3.10.3. General Considerations for Objective Options . . . . 41		3.10.3. General Considerations for Objective Options . . . . 41
	3.10.4. Organizing of Objective Options . . . . . . . . . . 42		3.10.4. Organizing of Objective Options . . . . . . . . . . 42
	3.10.5. Experimental and Example Objective Options . . . . . 43		3.10.5. Experimental and Example Objective Options . . . . . 44
	4. Implementation Status [RFC Editor: please remove] . . . . . . 44		4. Implementation Status [RFC Editor: please remove] . . . . . . 44
	4.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 44		4.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 44
	4.2. Python Implementation . . . . . . . . . . . . . . . . . . 44		4.2. Python Implementation . . . . . . . . . . . . . . . . . . 45
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 45		5. Security Considerations . . . . . . . . . . . . . . . . . . . 45
	6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 47		6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 48
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 52		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
	9.1. Normative References . . . . . . . . . . . . . . . . . . 52		9.1. Normative References . . . . . . . . . . . . . . . . . . 52
	9.2. Informative References . . . . . . . . . . . . . . . . . 53		9.2. Informative References . . . . . . . . . . . . . . . . . 53
	Appendix A. Open Issues [RFC Editor: This section should be		Appendix A. Open Issues [RFC Editor: This section should be
	empty. Please remove] . . . . . . . . . . . . . . . 56		empty. Please remove] . . . . . . . . . . . . . . . 56
	Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 57		Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 56
	Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 65		Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 65
	Appendix D. Example Message Formats . . . . . . . . . . . . . . 71		Appendix D. Example Message Formats . . . . . . . . . . . . . . 71
	D.1. Discovery Example . . . . . . . . . . . . . . . . . . . . 71		D.1. Discovery Example . . . . . . . . . . . . . . . . . . . . 72
	D.2. Flood Example . . . . . . . . . . . . . . . . . . . . . . 72		D.2. Flood Example . . . . . . . . . . . . . . . . . . . . . . 72
	D.3. Synchronization Example . . . . . . . . . . . . . . . . . 72		D.3. Synchronization Example . . . . . . . . . . . . . . . . . 72
	D.4. Simple Negotiation Example . . . . . . . . . . . . . . . 72		D.4. Simple Negotiation Example . . . . . . . . . . . . . . . 73
	D.5. Complete Negotiation Example . . . . . . . . . . . . . . 73		D.5. Complete Negotiation Example . . . . . . . . . . . . . . 73
	Appendix E. Capability Analysis of Current Protocols . . . . . . 74		Appendix E. Capability Analysis of Current Protocols . . . . . . 74
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77
	1. Introduction		1. Introduction
	The success of the Internet has made IP-based networks bigger and		The success of the Internet has made IP-based networks bigger and
	more complicated. Large-scale ISP and enterprise networks have		more complicated. Large-scale ISP and enterprise networks have
	become more and more problematic for human based management. Also,		become more and more problematic for human based management. Also,
	operational costs are growing quickly. Consequently, there are		operational costs are growing quickly. Consequently, there are
	increased requirements for autonomic behavior in the networks.		increased requirements for autonomic behavior in the networks.
	General aspects of autonomic networks are discussed in [RFC7575] and		General aspects of autonomic networks are discussed in [RFC7575] and
	[RFC7576].		[RFC7576].
	skipping to change at page 17, line 10		skipping to change at page 17, line 10
	The protocol SHOULD always run within a secure Autonomic Control		The protocol SHOULD always run within a secure Autonomic Control
	Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The ACP is		Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The ACP is
	assumed to carry all messages securely, including link-local		assumed to carry all messages securely, including link-local
	multicast when it is virtualized over the ACP. A GRASP instance MUST		multicast when it is virtualized over the ACP. A GRASP instance MUST
	verify whether the ACP is operational.		verify whether the ACP is operational.
	If there is no ACP, one of the following alternatives applies:		If there is no ACP, one of the following alternatives applies:
	1. The protocol instance MUST use another form of strong		1. The protocol instance MUST use another form of strong
	authentication and SHOULD use a form of strong encryption. An		authentication and a form of strong encryption MUST be
	exception is that during initialization of nodes there will be a		implemented. An exception is that during initialization of nodes
	transition period during which it might not be practical to run		there will be a transition period during which it might not be
	with strong encryption. This period MUST be as short as		practical to run with strong encryption. This period MUST be as
	possible, changing to a fully secure setup as soon as possible.		short as possible, changing to a fully secure setup as soon as
	See Section 3.5.2.1 for further discussion.		possible. See Section 3.5.2.1 for further discussion.
	2. The protocol instance MUST operate as described in		2. The protocol instance MUST operate as described in
	Section 3.5.2.2 or Section 3.5.2.3.		Section 3.5.2.2 or Section 3.5.2.3.
	Network interfaces could be at different security levels, for example		Network interfaces could be at different security levels, for example
	being part of the ACP or not. All the interfaces supported by a		being part of the ACP or not. All the interfaces supported by a
	given GRASP instance MUST be at the same security level.		given GRASP instance MUST be at the same security level.
	The ACP, or in its absence another security mechanism, sets the		The ACP, or in its absence another security mechanism, sets the
	boundary within which nodes are trusted as GRASP peers. A GRASP		boundary within which nodes are trusted as GRASP peers. A GRASP
	skipping to change at page 17, line 45		skipping to change at page 17, line 45
	This section describes some cases where additional instances of GRASP		This section describes some cases where additional instances of GRASP
	subject to certain constraints are appropriate.		subject to certain constraints are appropriate.
	3.5.2.1. No ACP		3.5.2.1. No ACP
	As mentioned in Section 3.3, some GRASP operations might be performed		As mentioned in Section 3.3, some GRASP operations might be performed
	across an administrative domain boundary by mutual agreement, without		across an administrative domain boundary by mutual agreement, without
	the benefit of an ACP. Such operations MUST be confined to a		the benefit of an ACP. Such operations MUST be confined to a
	separate instance of GRASP with its own copy of all GRASP data		separate instance of GRASP with its own copy of all GRASP data
	structures. Messages MUST be authenticated and SHOULD be encrypted.		structures. Messages MUST be authenticated and encryption MUST be
	TLS [RFC5246] and DTLS [RFC6347] based on a Public Key Infrastructure		implemented. TLS [RFC5246] and DTLS [RFC6347] based on a Public Key
	(PKI) [RFC5280] are RECOMMENDED for this purpose. Further details		Infrastructure (PKI) [RFC5280] are RECOMMENDED for this purpose.
	are out of scope for this document.		Further details are out of scope for this document.
	3.5.2.2. Discovery Unsolicited Link-Local		3.5.2.2. Discovery Unsolicited Link-Local
	Some services may need to use insecure GRASP discovery, response and		Some services may need to use insecure GRASP discovery, response and
	flood messages without being able to use pre-existing security		flood messages without being able to use pre-existing security
	associations. Such operations being intrinsically insecure, they		associations. Such operations being intrinsically insecure, they
	need to be confined to link-local use to minimize the risk of		need to be confined to link-local use to minimize the risk of
	malicious actions. Possible examples include discovery of candidate		malicious actions. Possible examples include discovery of candidate
	ACP neighbors [I-D.ietf-anima-autonomic-control-plane], discovery of		ACP neighbors [I-D.ietf-anima-autonomic-control-plane], discovery of
	bootstrap proxies [I-D.ietf-anima-bootstrapping-keyinfra] or perhaps		bootstrap proxies [I-D.ietf-anima-bootstrapping-keyinfra] or perhaps
	skipping to change at page 41, line 40		skipping to change at page 41, line 40
	either used for negotiation, or for dry-run negotiation. Mixing the		either used for negotiation, or for dry-run negotiation. Mixing the
	two modes in a single negotiation is not possible.		two modes in a single negotiation is not possible.
	3.10.3. General Considerations for Objective Options		3.10.3. General Considerations for Objective Options
	As mentioned above, Objective Options MUST be assigned a unique name.		As mentioned above, Objective Options MUST be assigned a unique name.
	As long as privately defined Objective Options obey the rules above,		As long as privately defined Objective Options obey the rules above,
	this document does not restrict their choice of name, but the entity		this document does not restrict their choice of name, but the entity
	or person concerned SHOULD publish the names in use.		or person concerned SHOULD publish the names in use.
			Names are expressed as UTF-8 strings for convenience in designing
			Objective Options for localized use. For generic usage, names
			expressed in the ASCII subset of UTF-8 are RECOMMENDED. Designers
			planning to use non-ASCII names are strongly advised to consult
			[RFC7564] or its successor to understand the complexities involved.
			Since the GRASP protocol compares names byte by byte, all issues of
			Unicode profiling and canonicalization MUST be specified in the
			design of the Objective Option.
	All Objective Options MUST respect the CBOR patterns defined above as		All Objective Options MUST respect the CBOR patterns defined above as
	"objective" and MUST replace the "any" field with a valid CBOR data		"objective" and MUST replace the "any" field with a valid CBOR data
	definition for the relevant use case and application.		definition for the relevant use case and application.
	An Objective Option that contains no additional fields beyond its		An Objective Option that contains no additional fields beyond its
	"loop-count" can only be a discovery objective and MUST only be used		"loop-count" can only be a discovery objective and MUST only be used
	in Discovery and Discovery Response messages.		in Discovery and Discovery Response messages.
	The Negotiation Objective Options contain negotiation objectives,		The Negotiation Objective Options contain negotiation objectives,
	which vary according to different functions/services. They MUST be		which vary according to different functions/services. They MUST be
	skipping to change at page 52, line 23		skipping to change at page 52, line 23
	Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Yu Fu, Zhenbin Li,		Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Yu Fu, Zhenbin Li,
	Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, Markus Stenberg,		Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, Markus Stenberg,
	Rene Struik, Dacheng Zhang, and other participants in the NMRG		Rene Struik, Dacheng Zhang, and other participants in the NMRG
	research group and the ANIMA working group.		research group and the ANIMA working group.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.greevenbosch-appsawg-cbor-cddl]		[I-D.greevenbosch-appsawg-cbor-cddl]
	Vigano, C. and H. Birkholz, "CBOR data definition language		Birkholz, H., Vigano, C., and C. Bormann, "CBOR data
	(CDDL): a notational convention to express CBOR data		definition language (CDDL): a notational convention to
	structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work		express CBOR data structures", draft-greevenbosch-appsawg-
	in progress), September 2016.		cbor-cddl-10 (work in progress), March 2017.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<http://www.rfc-editor.org/info/rfc3986>.		<http://www.rfc-editor.org/info/rfc3986>.
	skipping to change at page 53, line 30		skipping to change at page 53, line 30
	[I-D.chaparadza-intarea-igcp]		[I-D.chaparadza-intarea-igcp]
	Behringer, M., Chaparadza, R., Petre, R., Li, X., and H.		Behringer, M., Chaparadza, R., Petre, R., Li, X., and H.
	Mahkonen, "IP based Generic Control Protocol (IGCP)",		Mahkonen, "IP based Generic Control Protocol (IGCP)",
	draft-chaparadza-intarea-igcp-00 (work in progress), July		draft-chaparadza-intarea-igcp-00 (work in progress), July
	2011.		2011.
	[I-D.ietf-anima-autonomic-control-plane]		[I-D.ietf-anima-autonomic-control-plane]
	Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic		Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
	Control Plane", draft-ietf-anima-autonomic-control-		Control Plane", draft-ietf-anima-autonomic-control-
	plane-05 (work in progress), January 2017.		plane-06 (work in progress), March 2017.
	[I-D.ietf-anima-bootstrapping-keyinfra]		[I-D.ietf-anima-bootstrapping-keyinfra]
	Pritikin, M., Richardson, M., Behringer, M., Bjarnason,		Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
	S., and K. Watsen, "Bootstrapping Remote Secure Key		S., and K. Watsen, "Bootstrapping Remote Secure Key
	Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-		Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
	keyinfra-04 (work in progress), October 2016.		keyinfra-05 (work in progress), March 2017.
	[I-D.ietf-anima-reference-model]		[I-D.ietf-anima-reference-model]
	Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,		Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
	Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A		Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A
	Reference Model for Autonomic Networking", draft-ietf-		Reference Model for Autonomic Networking", draft-ietf-
	anima-reference-model-02 (work in progress), July 2016.		anima-reference-model-03 (work in progress), March 2017.
	[I-D.ietf-anima-stable-connectivity]		[I-D.ietf-anima-stable-connectivity]
	Eckert, T. and M. Behringer, "Using Autonomic Control		Eckert, T. and M. Behringer, "Using Autonomic Control
	Plane for Stable Connectivity of Network OAM", draft-ietf-		Plane for Stable Connectivity of Network OAM", draft-ietf-
	anima-stable-connectivity-02 (work in progress), February		anima-stable-connectivity-02 (work in progress), February
	2017.		2017.
	[I-D.liang-iana-pen]		[I-D.liang-iana-pen]
	Liang, P., Melnikov, A., and D. Conrad, "Private		Liang, P., Melnikov, A., and D. Conrad, "Private
	Enterprise Number (PEN) practices and Internet Assigned		Enterprise Number (PEN) practices and Internet Assigned
	skipping to change at page 56, line 11		skipping to change at page 56, line 11
	P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,		P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
	DOI 10.17487/RFC6887, April 2013,		DOI 10.17487/RFC6887, April 2013,
	<http://www.rfc-editor.org/info/rfc6887>.		<http://www.rfc-editor.org/info/rfc6887>.
	[RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault,		[RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault,
	"Requirements for Scalable DNS-Based Service Discovery		"Requirements for Scalable DNS-Based Service Discovery
	(DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558,		(DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558,
	DOI 10.17487/RFC7558, July 2015,		DOI 10.17487/RFC7558, July 2015,
	<http://www.rfc-editor.org/info/rfc7558>.		<http://www.rfc-editor.org/info/rfc7558>.
			[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
			Preparation, Enforcement, and Comparison of
			Internationalized Strings in Application Protocols",
			RFC 7564, DOI 10.17487/RFC7564, May 2015,
			<http://www.rfc-editor.org/info/rfc7564>.
	[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,		[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
	Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic		Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
	Networking: Definitions and Design Goals", RFC 7575,		Networking: Definitions and Design Goals", RFC 7575,
	DOI 10.17487/RFC7575, June 2015,		DOI 10.17487/RFC7575, June 2015,
	<http://www.rfc-editor.org/info/rfc7575>.		<http://www.rfc-editor.org/info/rfc7575>.
	[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap		[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap
	Analysis for Autonomic Networking", RFC 7576,		Analysis for Autonomic Networking", RFC 7576,
	DOI 10.17487/RFC7576, June 2015,		DOI 10.17487/RFC7576, June 2015,
	<http://www.rfc-editor.org/info/rfc7576>.		<http://www.rfc-editor.org/info/rfc7576>.
	skipping to change at page 56, line 37		skipping to change at page 56, line 43
	Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April		Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
	2016, <http://www.rfc-editor.org/info/rfc7788>.		2016, <http://www.rfc-editor.org/info/rfc7788>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<http://www.rfc-editor.org/info/rfc8040>.		<http://www.rfc-editor.org/info/rfc8040>.
	Appendix A. Open Issues [RFC Editor: This section should be empty.		Appendix A. Open Issues [RFC Editor: This section should be empty.
	Please remove]		Please remove]
	o 63. Should encryption be MUST instead of SHOULD in Section 3.5.1		o 68. (Placeholder)
	and Section 3.5.2.1?
	o 64. Should more security text be moved from the main text into
	the Security Considerations?
	o 65. Do we need to formally restrict Unicode characters allowed in
	objective names?
	o 66. Split requirements into separate document?
	o 67. Remove normative dependency on draft-greevenbosch-appsawg-
	cbor-cddl?
	Appendix B. Closed Issues [RFC Editor: Please remove]		Appendix B. Closed Issues [RFC Editor: Please remove]
	o 1. UDP vs TCP: For now, this specification suggests UDP and TCP		o 1. UDP vs TCP: For now, this specification suggests UDP and TCP
	as message transport mechanisms. This is not clarified yet. UDP		as message transport mechanisms. This is not clarified yet. UDP
	is good for short conversations, is necessary for multicast		is good for short conversations, is necessary for multicast
	discovery, and generally fits the discovery and divert scenarios		discovery, and generally fits the discovery and divert scenarios
	well. However, it will cause problems with large messages. TCP		well. However, it will cause problems with large messages. TCP
	is good for stable and long sessions, with a little bit of time		is good for stable and long sessions, with a little bit of time
	consumption during the session establishment stage. If messages		consumption during the session establishment stage. If messages
	skipping to change at page 65, line 10		skipping to change at page 64, line 48
	o 61. Is the SONN constrained instance really needed?		o 61. Is the SONN constrained instance really needed?
	RESOLVED: Retained but only as an option.		RESOLVED: Retained but only as an option.
	o 62. Is it helpful to tag descriptive text with message names		o 62. Is it helpful to tag descriptive text with message names
	(M_DISCOVER etc.)?		(M_DISCOVER etc.)?
	RESOLVED: Yes, done in various parts of the text.		RESOLVED: Yes, done in various parts of the text.
			o 63. Should encryption be MUST instead of SHOULD in Section 3.5.1
			and Section 3.5.2.1?
			RESOLVED: Yes, MUST implement in both cases.
			o 64. Should more security text be moved from the main text into
			the Security Considerations?
			RESOLVED: No, on AD advice.
			o 65. Do we need to formally restrict Unicode characters allowed in
			objective names?
			RESOLVED: No, but need to point to guidance from PRECIS WG.
			o 66. Split requirements into separate document?
			RESOLVED: No, on AD advice.
			o 67. Remove normative dependency on draft-greevenbosch-appsawg-
			cbor-cddl?
			RESOLVED: No, on AD advice. In worst case, fix at AUTH48.
	Appendix C. Change log [RFC Editor: Please remove]		Appendix C. Change log [RFC Editor: Please remove]
			draft-ietf-anima-grasp-11, 2017-03-28:
			Updates following IETF 98 discussion:
			Encryption changed to a MUST implement.
			Pointed to guidance on UTF-8 names.
	draft-ietf-anima-grasp-10, 2017-03-10:		draft-ietf-anima-grasp-10, 2017-03-10:
	Updates following IETF Last call:		Updates following IETF Last call:
	Protocol change: Specify that an objective with no initial value		Protocol change: Specify that an objective with no initial value
	should have its value field set to CBOR 'null'.		should have its value field set to CBOR 'null'.
	Protocol change: Specify behavior on receiving unrecognized message		Protocol change: Specify behavior on receiving unrecognized message
	type.		type.
End of changes. 22 change blocks.
	41 lines changed or deleted		76 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/