< draft-ietf-rtgwg-yang-key-chain-01.txt		draft-ietf-rtgwg-yang-key-chain-02.txt >
	Network Working Group A. Lindem, Ed.		Network Working Group A. Lindem, Ed.
	Internet-Draft Y. Qu		Internet-Draft Y. Qu
	Intended status: Standards Track D. Yeung		Intended status: Standards Track D. Yeung
	Expires: August 15, 2016 Cisco Systems		Expires: September 16, 2016 Cisco Systems
	I. Chen		I. Chen
	Ericsson		Ericsson
	J. Zhang		J. Zhang
	Juniper Networks		Juniper Networks
	Y. Yang		Y. Yang
	Cisco Systems		Cisco Systems
	February 12, 2016		March 15, 2016
	Key Chain YANG Data Model		Routing Key Chain YANG Data Model
	draft-ietf-rtgwg-yang-key-chain-01.txt		draft-ietf-rtgwg-yang-key-chain-02.txt
	Abstract		Abstract
	This document describes the key chain YANG data model. A key chain		This document describes the key chain YANG data model. A key chain
	is a list of elements each containing a key, send lifetime, accept		is a list of elements each containing a key, send lifetime, accept
	lifetime, and algorithm. By properly overlapping the send and accept		lifetime, and algorithm. By properly overlapping the send and accept
	lifetimes of multiple key chain elements, keys and algorithms may be		lifetimes of multiple key chain elements, keys and algorithms may be
	gracefully updated. By representing them in a YANG data model, key		gracefully updated. By representing them in a YANG data model, key
	distribution can be automated. Key chains are commonly used for		distribution can be automated. Key chains are commonly used for
	routing protocol authentication and other applications. In some		routing protocol authentication and other applications. In some
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 August 15, 2016.		This Internet-Draft will expire on September 16, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Graceful Key Rollover using Key Chains . . . . . . . . . 3		2.1. Graceful Key Rollover using Key Chains . . . . . . . . . 3
	3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 4		3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 4
	3.1. Key Chain Operational State . . . . . . . . . . . . . . . 5		3.1. Key Chain Operational State . . . . . . . . . . . . . . . 5
	3.2. Key Chain Model Features . . . . . . . . . . . . . . . . 5		3.2. Key Chain Model Features . . . . . . . . . . . . . . . . 5
	3.3. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 5		3.3. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 5
	4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 8		4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 8
	5. Relationship to other Work . . . . . . . . . . . . . . . . . 16		5. Relationship to other Work . . . . . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. Normative References . . . . . . . . . . . . . . . . . . 17		8.1. Normative References . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . 18
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	This document describes the key chain YANG data model. A key chain		This document describes the key chain YANG data model. A key chain
	is a list of elements each containing a key, send lifetime, accept		is a list of elements each containing a key, send lifetime, accept
	lifetime, and algorithm. By properly overlapping the send and accept		lifetime, and algorithm. By properly overlapping the send and accept
	lifetimes of multiple key chain elements, keys and algorithms may be		lifetimes of multiple key chain elements, keys and algorithms may be
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 28 ¶
	routing infrastructure as recommended in [IAB-REPORT].		routing infrastructure as recommended in [IAB-REPORT].
	A key chain is a list containing one or more elements containing a		A key chain is a list containing one or more elements containing a
	Key ID, key, send/accept lifetimes, and the associated authentication		Key ID, key, send/accept lifetimes, and the associated authentication
	or encryption algorithm. A key chain can be used by any service or		or encryption algorithm. A key chain can be used by any service or
	application requiring authentication or encryption. In essence, the		application requiring authentication or encryption. In essence, the
	key-chain is a reusable key policy that can be referenced where ever		key-chain is a reusable key policy that can be referenced where ever
	it is required. The key-chain construct has been implemented by most		it is required. The key-chain construct has been implemented by most
	networking vendors and deployed in many networks.		networking vendors and deployed in many networks.
			The module name was change from ietf-key-chain to ietf-routing-key-
			chain to avoid disambiguate it from the ietf-system-keychain module
			defined in [NETCONF-SERVER-CONF].
	A conceptual representation of a crypto key table is described in		A conceptual representation of a crypto key table is described in
	[CRYPTO-KEYTABLE]. The crypto key table also includes keys as well		[CRYPTO-KEYTABLE]. The crypto key table also includes keys as well
	as their corresponding lifetimes and algorithms. Additionally, the		as their corresponding lifetimes and algorithms. Additionally, the
	key table includes key selection criteria and envisions a deployment		key table includes key selection criteria and envisions a deployment
	model where the details of the applications or services requiring		model where the details of the applications or services requiring
	authentication or encryption permeate into the key database. The		authentication or encryption permeate into the key database. The
	YANG key-chain model described herein doesn't include key selection		YANG key-chain model described herein doesn't include key selection
	criteria or support this deployment model. At the same time, it does		criteria or support this deployment model. At the same time, it does
	not preclude it. The draft [YANG-CRYPTO-KEYTABLE] describes		not preclude it. The draft [YANG-CRYPTO-KEYTABLE] describes
	augmentations to the key chain YANG model in support of key selection		augmentations to the key chain YANG model in support of key selection
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 34 ¶
	4. At some point in the future, a new key chain with the old key		4. At some point in the future, a new key chain with the old key
	removed may be distributed to the network devices within the		removed may be distributed to the network devices within the
	domain of the key chain. However, this may be deferred until the		domain of the key chain. However, this may be deferred until the
	next key rollover. If this is done, the key chain will always		next key rollover. If this is done, the key chain will always
	include two keys; either the current and future key (during key		include two keys; either the current and future key (during key
	rollovers) or the current and previous keys (between key		rollovers) or the current and previous keys (between key
	rollovers).		rollovers).
	3. Design of the Key Chain Model		3. Design of the Key Chain Model
	The ietf-keychain module contains a list of one or more keys indexed		The ietf-routing-key-chain module contains a list of one or more keys
	by a Key ID. For some applications (e.g., OSPFv3 [OSPFV3-AUTH]), the		indexed by a Key ID. For some applications (e.g., OSPFv3
	Key-Id is used to identify the key chain entry to be used. In		[OSPFV3-AUTH]), the Key-Id is used to identify the key chain entry to
	addition to the Key-ID, each key chain entry includes a key-string		be used. In addition to the Key-ID, each key chain entry includes a
	and a cryptographic algorithm. Optionally, the key chain entries		key-string and a cryptographic algorithm. Optionally, the key chain
	include send/accept lifetimes. If the send/accept lifetime is		entries include send/accept lifetimes. If the send/accept lifetime
	unspecified, the key is always considered valid.		is unspecified, the key is always considered valid.
	Note that asymmetric keys, i.e., a different key value used for		Note that asymmetric keys, i.e., a different key value used for
	transmission versus acceptance, may be supported with multiple key		transmission versus acceptance, may be supported with multiple key
	chain elements where the accept-lifetime or send-lifetime is not		chain elements where the accept-lifetime or send-lifetime is not
	valid (e.g., has an end-time equal to the start-time).		valid (e.g., has an end-time equal to the start-time).
	Due to the differences in key chain implementations across various		Due to the differences in key chain implementations across various
	vendors, some of the data elements are optional. Additionally, the		vendors, some of the data elements are optional. Additionally, the
	key-chain is made a grouping so that an implementation could support		key-chain is made a grouping so that an implementation could support
	scoping other than at the global level. Finally, the crypto-		scoping other than at the global level. Finally, the crypto-
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 31 ¶
	Features are used to handle differences between vendor		Features are used to handle differences between vendor
	implementations. For example, not all vendors support configuration		implementations. For example, not all vendors support configuration
	an acceptance tolerance or configuration of key strings in		an acceptance tolerance or configuration of key strings in
	hexadecimal. They are also used to support of security requirements		hexadecimal. They are also used to support of security requirements
	(e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not implemented by		(e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not implemented by
	vendors or only a single vendor.		vendors or only a single vendor.
	3.3. Key Chain Model Tree		3.3. Key Chain Model Tree
	+--rw key-chains		+--rw key-chains
	+--rw key-chain-list* [name]		+--rw key-chain-list* [name]
	| +--rw name string		| +--rw name string
	| +--ro name-state? string		| +--ro name-state? string
	| +--rw accept-tolerance {accept-tolerance}?		| +--rw accept-tolerance {accept-tolerance}?
	| | +--rw duration? uint32		| | +--rw duration? uint32
	| +--ro accept-tolerance-state		| +--ro accept-tolerance-state
	| | +--ro duration? uint32		| | +--ro duration? uint32
	| +--rw key-chain-entry* [key-id]		| +--rw key-chain-entry* [key-id]
	| +--rw key-id uint64		| +--rw key-id uint64
	| +--ro key-id-state? uint64		| +--ro key-id-state? uint64
	| +--rw key-string		| +--rw key-string
	| | +--rw (key-string-style)?		| | +--rw (key-string-style)?
	| | +--:(keystring)		| | +--:(keystring)
	| | | +--rw keystring? string		| | | +--rw keystring? string
	| | +--:(hexadecimal) {hex-key-string}?		| | +--:(hexadecimal) {hex-key-string}?
	| | +--rw hexadecimal-string? yang:hex-string		| | +--rw hexadecimal-string? yang:hex-string
	| +--rw lifetime		| +--rw lifetime
	| | +--rw (lifetime)?		| | +--rw (lifetime)?
	| | +--:(send-and-accept-lifetime)		| | +--:(send-and-accept-lifetime)
	| | | +--rw send-accept-lifetime		| | | +--rw send-accept-lifetime
	| | | +--rw (lifetime)?		| | | +--rw (lifetime)?
	| | | +--:(always)		| | | +--:(always)
	| | | | +--rw always? empty		| | | | +--rw always? empty
	| | | +--:(start-end-time)		| | | +--:(start-end-time)
	| | | +--rw start-date-time?		| | | +--rw start-date-time? yang:date-and-time
	| | | | yang:date-and-time		| | | +--rw (end-time)?
	| | | +--rw (end-time)?		| | | +--:(infinite)
	| | | +--:(infinite)		| | | | +--rw no-end-time? empty
	| | | | +--rw no-end-time? empty		| | | +--:(duration)
	| | | +--:(duration)		| | | | +--rw duration? uint32
	| | | | +--rw duration? uint32		| | | +--:(end-date-time)
	| | | +--:(end-date-time)		| | | +--rw end-date-time?
	| | | +--rw end-date-time?		| | | yang:date-and-time
	| | | yang:date-and-time		| | +--:(independent-send-accept-lifetime)
	| | +--:(independent-send-accept-lifetime)		| | | {independent-send-accept-lifetime}?
	| | | {independent-send-accept-lifetime}?		| | +--rw send-lifetime
	| | +--rw send-lifetime		| | | +--rw (lifetime)?
	| | | +--rw (lifetime)?		| | | +--:(always)
	| | | +--:(always)		| | | | +--rw always? empty
	| | | | +--rw always? empty		| | | +--:(start-end-time)
	| | | +--:(start-end-time)		| | | +--rw start-date-time? yang:date-and-time
	| | | +--rw start-date-time?		| | | +--rw (end-time)?
	| | | | yang:date-and-time		| | | +--:(infinite)
	| | | +--rw (end-time)?		| | | | +--rw no-end-time? empty
	| | | +--:(infinite)		| | | +--:(duration)
	| | | | +--rw no-end-time? empty		| | | | +--rw duration? uint32
	| | | +--:(duration)		| | | +--:(end-date-time)
	| | | | +--rw duration? uint32		| | | +--rw end-date-time?
	| | | +--:(end-date-time)		| | | yang:date-and-time
	| | | +--rw end-date-time?		| | +--rw accept-lifetime
	| | | yang:date-and-time		| | +--rw (lifetime)?
	| | +--rw accept-lifetime		| | +--:(always)
	| | +--rw (lifetime)?		| | | +--rw always? empty
	| | +--:(always)		| | +--:(start-end-time)
	| | | +--rw always? empty		| | +--rw start-date-time? yang:date-and-time
	| | +--:(start-end-time)		| | +--rw (end-time)?
	| | +--rw start-date-time? yang:date-and-time		| | +--:(infinite)
	| | +--rw (end-time)?		| | | +--rw no-end-time? empty
	| | +--:(infinite)		| | +--:(duration)
	| | | +--rw no-end-time? empty		| | | +--rw duration? uint32
	| | +--:(duration)		| | +--:(end-date-time)
	| | | +--rw duration? uint32		| | +--rw end-date-time?
	| | +--:(end-date-time)		| | yang:date-and-time
	| | +--rw end-date-time?		| +--ro lifetime-state
	| | yang:date-and-time		| | +--ro send-lifetime
	| +--ro lifetime-state		| | | +--ro (lifetime)?
	| | +--ro send-lifetime		| | | +--:(always)
	| | | +--ro (lifetime)?		| | | | +--ro always? empty
	| | | +--:(always)		| | | +--:(start-end-time)
	| | | | +--ro always? empty		| | | +--ro start-date-time? yang:date-and-time
	| | | +--:(start-end-time)		| | | +--ro (end-time)?
	| | | +--ro start-date-time? yang:date-and-time		| | | +--:(infinite)
	| | | +--ro (end-time)?		| | | | +--ro no-end-time? empty
	| | | +--:(infinite)		| | | +--:(duration)
	| | | | +--ro no-end-time? empty		| | | | +--ro duration? uint32
	| | | +--:(duration)		| | | +--:(end-date-time)
	| | | | +--ro duration? uint32		| | | +--ro end-date-time? yang:date-and-time
	| | | +--:(end-date-time)		| | +--ro send-valid? boolean
	| | | +--ro end-date-time?		| | +--ro accept-lifetime
	| | | yang:date-and-time		| | | +--ro (lifetime)?
	| | +--ro send-valid? boolean		| | | +--:(always)
	| | +--ro accept-lifetime		| | | | +--ro always? empty
	| | | +--ro (lifetime)?		| | | +--:(start-end-time)
	| | | +--:(always)		| | | +--ro start-date-time? yang:date-and-time
	| | | | +--ro always? empty		| | | +--ro (end-time)?
	| | | +--:(start-end-time)		| | | +--:(infinite)
	| | | +--ro start-date-time? yang:date-and-time		| | | | +--ro no-end-time? empty
	| | | +--ro (end-time)?		| | | +--:(duration)
	| | | +--:(infinite)		| | | | +--ro duration? uint32
	| | | | +--ro no-end-time? empty		| | | +--:(end-date-time)
	| | | +--:(duration)		| | | +--ro end-date-time? yang:date-and-time
	| | | | +--ro duration? uint32		| | +--ro accept-valid? boolean
	| | | +--:(end-date-time)		| +--rw crypto-algorithm
	| | | +--ro end-date-time?		| | +--rw (algorithm)?
	| | | yang:date-and-time		| | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}?
	| | +--ro accept-valid? boolean		| | | +--rw hmac-sha1-12? empty
	| +--rw crypto-algorithm		| | +--:(aes-cmac-prf-128) {aes-cmac-prf-128}?
	| | +--rw (algorithm)?		| | | +--rw aes-cmac-prf-128? empty
	| | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}?		| | +--:(md5)
	| | | +--rw hmac-sha1-12? empty		| | | +--rw md5? empty
	| | +--:(aes-cmac-prf-128) {aes-cmac-prf-128}?		| | +--:(sha-1)
	| | | +--rw aes-cmac-prf-128? empty		| | | +--rw sha-1? empty
	| | +--:(md5)		| | +--:(hmac-sha-1)
	| | | +--rw md5? empty		| | | +--rw hmac-sha-1? empty
	| | +--:(sha-1)		| | +--:(hmac-sha-256)
	| | | +--rw sha-1? empty		| | | +--rw hmac-sha-256? empty
	| | +--:(hmac-sha-1)		| | +--:(hmac-sha-384)
	| | | +--rw hmac-sha-1? empty		| | | +--rw hmac-sha-384? empty
	| | +--:(hmac-sha-256)		| | +--:(hmac-sha-512)
	| | | +--rw hmac-sha-256? empty		| | | +--rw hmac-sha-512? empty
	| | +--:(hmac-sha-384)		| | +--:(clear-text) {clear-text}?
	| | | +--rw hmac-sha-384? empty		| | +--rw clear-text? empty
	| | +--:(hmac-sha-512)		| +--ro crypto-algorithm-state
	| | | +--rw hmac-sha-512? empty		| +--ro (algorithm)?
	| | +--:(clear-text) {clear-text}?		| +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}?
	| | +--rw clear-text? empty		| | +--ro hmac-sha1-12? empty
	| +--ro crypto-algorithm-state		| +--:(aes-cmac-prf-128) {aes-cmac-prf-128}?
	| +--ro (algorithm)?		| | +--ro aes-cmac-prf-128? empty
	| +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}?		| +--:(md5)
	| | +--ro hmac-sha1-12? empty		| | +--ro md5? empty
	| +--:(aes-cmac-prf-128) {aes-cmac-prf-128}?		| +--:(sha-1)
	| | +--ro aes-cmac-prf-128? empty		| | +--ro sha-1? empty
	| +--:(md5)		| +--:(hmac-sha-1)
	| | +--ro md5? empty		| | +--ro hmac-sha-1? empty
	| +--:(sha-1)		| +--:(hmac-sha-256)
	| | +--ro sha-1? empty		| | +--ro hmac-sha-256? empty
	| +--:(hmac-sha-1)		| +--:(hmac-sha-384)
	| | +--ro hmac-sha-1? empty		| | +--ro hmac-sha-384? empty
	| +--:(hmac-sha-256)		| +--:(hmac-sha-512)
	| | +--ro hmac-sha-256? empty		| | +--ro hmac-sha-512? empty
	| +--:(hmac-sha-384)		| +--:(clear-text) {clear-text}?
	| | +--ro hmac-sha-384? empty		| +--ro clear-text? empty
	| +--:(hmac-sha-512)		+--rw aes-key-wrap {aes-key-wrap}?
	| | +--ro hmac-sha-512? empty		| +--rw enable? boolean
	| +--:(clear-text) {clear-text}?		+--ro aes-key-wrap-state {aes-key-wrap}?
	| +--ro clear-text? empty		+--ro enable? boolean
	+--rw aes-key-wrap {aes-key-wrap}?
	| +--rw enable? boolean
	+--ro aes-key-wrap-state {aes-key-wrap}?
	+--ro enable? boolean
	4. Key Chain YANG Model		4. Key Chain YANG Model
	<CODE BEGINS> file "ietf-key-chain@2016-02-16.yang"		<CODE BEGINS> file "ietf-routing-key-chain@2016-03-15.yang"
	module ietf-key-chain {		module ietf-routing-key-chain {
	namespace "urn:ietf:params:xml:ns:yang:ietf-key-chain";		namespace "urn:ietf:params:xml:ns:yang:ietf-routing-key-chain";
	// replace with IANA namespace when assigned		// replace with IANA namespace when assigned
	prefix "key-chain";		prefix "key-chain";
	import ietf-yang-types {		import ietf-yang-types {
	prefix "yang";		prefix "yang";
	}		}
	organization		organization
	"IETF RTG (Routing) Working Group";		"IETF RTG (Routing) Working Group";
	contact		contact
	skipping to change at page 9, line 10 ¶		skipping to change at page 9, line 10 ¶
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
			revision 2016-03-15 {
			description
			"Rename module from ietf-key-chain to
			ietf-routing-key-chain.";
			reference
			"RFC XXXX: A YANG Data Model for Routing key-chain";
			}
	revision 2016-02-16 {		revision 2016-02-16 {
	description		description
	"Updated version. Added clear-text algorithm as a		"Updated version. Added clear-text algorithm as a
	feature.";		feature.";
	reference		reference
	"RFC XXXX: A YANG Data Model for key-chain";		"RFC XXXX: A YANG Data Model for key-chain";
	}		}
	revision 2015-10-15 {		revision 2015-10-15 {
	description		description
	"Updated version, organization, and copyright.		"Updated version, organization, and copyright.
	skipping to change at page 17, line 30 ¶		skipping to change at page 17, line 40 ¶
	peers using Bidirectional Forwarding Detection [BFD]). Keys used		peers using Bidirectional Forwarding Detection [BFD]). Keys used
	with the clear-text algorithm are considered insecure and SHOULD NOT		with the clear-text algorithm are considered insecure and SHOULD NOT
	be reused with more secure algorithms.		be reused with more secure algorithms.
	7. IANA Considerations		7. IANA Considerations
	This document registers a URI in the IETF XML registry		This document registers a URI in the IETF XML registry
	[XML-REGISTRY]. Following the format in RFC 3688, the following		[XML-REGISTRY]. Following the format in RFC 3688, the following
	registration is requested to be made:		registration is requested to be made:
	URI: urn:ietf:params:xml:ns:yang:ietf-key-chain		URI: urn:ietf:params:xml:ns:yang:ietf-routing-key-chain
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A, the requested URI is an XML namespace.		XML: N/A, the requested URI is an XML namespace.
	This document registers a YANG module in the YANG Module Names		This document registers a YANG module in the YANG Module Names
	registry [YANG].		registry [YANG].
	name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-key-		name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-
	chain prefix: ietf-key-chain reference: RFC XXXX		routing-key-chain prefix: ietf-key-chain reference: RFC XXXX
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.		[NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
	Bierman, "Network Configuration Protocol (NETCONF)", RFC		Bierman, "Network Configuration Protocol (NETCONF)", RFC
	6241, June 2011.		6241, June 2011.
	[NETCONF-SSH]		[NETCONF-SSH]
	skipping to change at page 18, line 40 ¶		skipping to change at page 18, line 48 ¶
	[CRYPTO-KEYTABLE]		[CRYPTO-KEYTABLE]
	Housley, R., Polk, T., Hartman, S., and D. Zhang,		Housley, R., Polk, T., Hartman, S., and D. Zhang,
	"Table of Cryptographic Keys", RFC 7210, April 2014.		"Table of Cryptographic Keys", RFC 7210, April 2014.
	[IAB-REPORT]		[IAB-REPORT]
	Andersson, L., Davies, E., and L. Zhang, "Report from the		Andersson, L., Davies, E., and L. Zhang, "Report from the
	IAB workshop on Unwanted Traffic March 9-10, 2006", RFC		IAB workshop on Unwanted Traffic March 9-10, 2006", RFC
	4948, August 2007.		4948, August 2007.
			[NETCONF-SERVER-CONF]
			Watsen, K. and J. Schoenwaelder, "NETCONF Server and
			RESTCONF Server Configuration Models", draft-ietf-netconf-
			server-model-08.txt (work in progress), October 2015.
	[NTP-PROTO]		[NTP-PROTO]
	Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network		Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
	Time Protocol Version 4: Protocol and Algorithms		Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, June 2010.		Specification", RFC 5905, June 2010.
	[OSPFV3-AUTH]		[OSPFV3-AUTH]
	Bhatia, M., Manral, V., and A. Lindem, "Supporting		Bhatia, M., Manral, V., and A. Lindem, "Supporting
	Authentication Trailer for OSPFv3", RFC 7166, March 2014.		Authentication Trailer for OSPFv3", RFC 7166, March 2014.
	[TCP-AO-ALGORITHMS]		[TCP-AO-ALGORITHMS]
End of changes. 14 change blocks.
	162 lines changed or deleted		174 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/