draft-ietf-anima-grasp-10.txt   draft-ietf-anima-grasp-11.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: October 1, 2017 Univ. of Auckland
B. Liu, Ed. B. Liu, Ed.
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
March 10, 2017 March 30, 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 October 1, 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-30:
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.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/