< draft-ietf-rtgwg-yang-key-chain-02.txt		draft-ietf-rtgwg-yang-key-chain-03.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: September 16, 2016 Cisco Systems		Expires: December 29, 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
	March 15, 2016		June 27, 2016
	Routing Key Chain YANG Data Model		Routing Key Chain YANG Data Model
	draft-ietf-rtgwg-yang-key-chain-02.txt		draft-ietf-rtgwg-yang-key-chain-03.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 September 16, 2016.		This Internet-Draft will expire on December 29, 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 33 ¶		skipping to change at page 2, line 33 ¶
	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 . . . . . . . . . . . . . . . . . 17		5. Relationship to other Work . . . . . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. Normative References . . . . . . . . . . . . . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	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
	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 3, line 30 ¶		skipping to change at page 3, line 30 ¶
	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-		The module name was change from ietf-key-chain to ietf-routing-key-
	chain to avoid disambiguate it from the ietf-system-keychain module		chain to avoid disambiguate it from the ietf-system-keychain module
	defined in [NETCONF-SERVER-CONF].		defined in [NETCONF-SERVER-CONF]. However, due to popular demand,
			the module name has been restored to simply ietf-key-chain.
	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
	skipping to change at page 4, line 34 ¶		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-routing-key-chain module contains a list of one or more keys		The ietf-key-chain module contains a list of one or more keys indexed
	indexed by a Key ID. For some applications (e.g., OSPFv3		by a Key ID. For some applications (e.g., OSPFv3 [OSPFV3-AUTH]), the
	[OSPFV3-AUTH]), the Key-Id is used to identify the key chain entry to		Key-Id is used to identify the key chain entry to be used. In
	be used. In addition to the Key-ID, each key chain entry includes a		addition to the Key-ID, each key chain entry includes a key-string
	key-string and a cryptographic algorithm. Optionally, the key chain		and a cryptographic algorithm. Optionally, the key chain entries
	entries include send/accept lifetimes. If the send/accept lifetime		include send/accept lifetimes. If the send/accept lifetime is
	is unspecified, the key is always considered valid.		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 30 ¶		skipping to change at page 5, line 30 ¶
	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		module: ietf-key-chain
			+-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
	skipping to change at page 6, line 16 ¶		skipping to change at page 6, line 17 ¶
	| | | +--rw start-date-time? yang:date-and-time		| | | +--rw start-date-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? 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
	| | +--rw accept-lifetime		| | +--rw accept-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? 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
	| +--ro lifetime-state		| +--ro lifetime-state
	| | +--ro send-lifetime		| | +--ro send-lifetime
	| | | +--ro (lifetime)?		| | | +--ro (lifetime)?
	| | | +--:(always)		| | | +--:(always)
	| | | | +--ro always? empty		| | | | +--ro always? empty
	| | | +--:(start-end-time)		| | | +--:(start-end-time)
	| | | +--ro start-date-time? yang:date-and-time		| | | +--ro start-date-time? yang:date-and-time
	| | | +--ro (end-time)?		| | | +--ro (end-time)?
	| | | +--:(infinite)		| | | +--:(infinite)
	| | | | +--ro no-end-time? empty		| | | | +--ro no-end-time? empty
	skipping to change at page 7, line 29 ¶		skipping to change at page 7, line 30 ¶
	| | | +--:(infinite)		| | | +--:(infinite)
	| | | | +--ro no-end-time? empty		| | | | +--ro no-end-time? empty
	| | | +--:(duration)		| | | +--:(duration)
	| | | | +--ro duration? uint32		| | | | +--ro duration? uint32
	| | | +--:(end-date-time)		| | | +--:(end-date-time)
	| | | +--ro end-date-time? yang:date-and-time		| | | +--ro end-date-time? yang:date-and-time
	| | +--ro accept-valid? boolean		| | +--ro accept-valid? boolean
	| +--rw crypto-algorithm		| +--rw crypto-algorithm
	| | +--rw (algorithm)?		| | +--rw (algorithm)?
	| | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}?		| | +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}?
	| | | +--rw hmac-sha1-12? empty		| | | +--rw hmac-sha1-12? empty
	| | +--:(aes-cmac-prf-128) {aes-cmac-prf-128}?		| | +--:(aes-cmac-prf-128) {aes-cmac-prf-128}?
	| | | +--rw aes-cmac-prf-128? empty		| | | +--rw aes-cmac-prf-128? empty
	| | +--:(md5)		| | +--:(md5)
	| | | +--rw md5? empty		| | | +--rw md5? empty
	| | +--:(sha-1)		| | +--:(sha-1)
	| | | +--rw sha-1? empty		| | | +--rw sha-1? empty
	| | +--:(hmac-sha-1)		| | +--:(hmac-sha-1)
	| | | +--rw hmac-sha-1? empty		| | | +--rw hmac-sha-1? empty
	| | +--:(hmac-sha-256)		| | +--:(hmac-sha-256)
	| | | +--rw hmac-sha-256? empty		| | | +--rw hmac-sha-256? empty
	| | +--:(hmac-sha-384)		| | +--:(hmac-sha-384)
	| | | +--rw hmac-sha-384? empty		| | | +--rw hmac-sha-384? empty
	| | +--:(hmac-sha-512)		| | +--:(hmac-sha-512)
	| | | +--rw hmac-sha-512? empty		| | | +--rw hmac-sha-512? empty
	| | +--:(clear-text) {clear-text}?		| | +--:(clear-text) {clear-text}?
	| | +--rw clear-text? empty		| | | +--rw clear-text? empty
			| | +--:(replay-protection-only) {replay-protection-only}?
			| | +--rw replay-protection-only? empty
	| +--ro crypto-algorithm-state		| +--ro crypto-algorithm-state
	| +--ro (algorithm)?		| +--ro (algorithm)?
	| +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}?		| +--:(hmac-sha-1-12) {crypto-hmac-sha-1-12}?
	| | +--ro hmac-sha1-12? empty		| | +--ro hmac-sha1-12? empty
	| +--:(aes-cmac-prf-128) {aes-cmac-prf-128}?		| +--:(aes-cmac-prf-128) {aes-cmac-prf-128}?
	| | +--ro aes-cmac-prf-128? empty		| | +--ro aes-cmac-prf-128? empty
	| +--:(md5)		| +--:(md5)
	| | +--ro md5? empty		| | +--ro md5? empty
	| +--:(sha-1)		| +--:(sha-1)
	| | +--ro sha-1? empty		| | +--ro sha-1? empty
	| +--:(hmac-sha-1)		| +--:(hmac-sha-1)
	| | +--ro hmac-sha-1? empty		| | +--ro hmac-sha-1? empty
	| +--:(hmac-sha-256)		| +--:(hmac-sha-256)
	| | +--ro hmac-sha-256? empty		| | +--ro hmac-sha-256? empty
	| +--:(hmac-sha-384)		| +--:(hmac-sha-384)
	| | +--ro hmac-sha-384? empty		| | +--ro hmac-sha-384? empty
	| +--:(hmac-sha-512)		| +--:(hmac-sha-512)
	| | +--ro hmac-sha-512? empty		| | +--ro hmac-sha-512? empty
	| +--:(clear-text) {clear-text}?		| +--:(clear-text) {clear-text}?
	| +--ro clear-text? empty		| | +--ro clear-text? empty
			| +--:(replay-protection-only) {replay-protection-only}?
			| +--ro replay-protection-only? empty
	+--rw aes-key-wrap {aes-key-wrap}?		+--rw aes-key-wrap {aes-key-wrap}?
	| +--rw enable? boolean		| +--rw enable? boolean
	+--ro aes-key-wrap-state {aes-key-wrap}?		+--ro aes-key-wrap-state {aes-key-wrap}?
	+--ro enable? boolean		+--ro enable? boolean
	4. Key Chain YANG Model		4. Key Chain YANG Model
	<CODE BEGINS> file "ietf-routing-key-chain@2016-03-15.yang"		<CODE BEGINS> file "ietf-routing-key-chain@2016-06-27.yang"
	module ietf-routing-key-chain {		module ietf-key-chain {
	namespace "urn:ietf:params:xml:ns:yang:ietf-routing-key-chain";		namespace "urn:ietf:params:xml:ns:yang:ietf-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 15 ¶
	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-06-27 {
			description
			"Rename module back to ietf-key-chain.
			Added replay-protection-only feature and algorithm.";
			reference
			"RFC XXXX: A YANG Data Model for key-chain";
			}
	revision 2016-03-15 {		revision 2016-03-15 {
	description		description
	"Rename module from ietf-key-chain to		"Rename module from ietf-key-chain to
	ietf-routing-key-chain.";		ietf-routing-key-chain.";
	reference		reference
	"RFC XXXX: A YANG Data Model for Routing key-chain";		"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
	skipping to change at page 10, line 44 ¶		skipping to change at page 11, line 8 ¶
	description		description
	"Support for AES Cipher based Message Authentication Code		"Support for AES Cipher based Message Authentication Code
	Pseudo Random Function.";		Pseudo Random Function.";
	}		}
	feature aes-key-wrap {		feature aes-key-wrap {
	description		description
	"Support for Advanced Encryption Standard (AES) Key Wrap.";		"Support for Advanced Encryption Standard (AES) Key Wrap.";
	}		}
			feature replay-protection-only {
			description
			"Provide replay-protection without any authentication
			as required by protocols such as Bidirectional
			Forwarding Detection (BFD).";
			}
	/* groupings */		/* groupings */
	grouping lifetime {		grouping lifetime {
	description		description
	"Key lifetime specification.";		"Key lifetime specification.";
	choice lifetime {		choice lifetime {
	default always;		default always;
	description		description
	"Options for specifying key accept or send lifetimes";		"Options for specifying key accept or send lifetimes";
	case always {		case always {
	leaf always {		leaf always {
	type empty;		type empty;
	description		description
	"Indicates key lifetime is always valid.";		"Indicates key lifetime is always valid.";
	}		}
	}		}
	case start-end-time {		case start-end-time {
	leaf start-date-time {		leaf start-date-time {
	type yang:date-and-time;		type yang:date-and-time;
	skipping to change at page 13, line 15 ¶		skipping to change at page 13, line 34 ¶
	description "HMAC-SHA-512 authentication algorithm.";		description "HMAC-SHA-512 authentication algorithm.";
	}		}
	}		}
	case clear-text {		case clear-text {
	if-feature clear-text;		if-feature clear-text;
	leaf clear-text {		leaf clear-text {
	type empty;		type empty;
	description "Clear text.";		description "Clear text.";
	}		}
	}		}
			case replay-protection-only {
			if-feature replay-protection-only;
			leaf replay-protection-only {
			type empty;
			description
			"Provide replay-protection without any authentication
			as required by protocols such as Bidirectional
			Forwarding Detection (BFD).";
			}
			}
	}		}
	}		}
	grouping key-chain {		grouping key-chain {
	description		description
	"key-chain specification grouping.";		"key-chain specification grouping.";
	leaf name {		leaf name {
	type string;		type string;
	description "Name of the key-chain.";		description "Name of the key-chain.";
	}		}
	skipping to change at page 17, line 40 ¶		skipping to change at page 18, line 19 ¶
	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-routing-key-chain		URI: urn:ietf:params:xml:ns:yang:ietf-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-		name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-key-
	routing-key-chain prefix: ietf-key-chain reference: RFC XXXX		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]
End of changes. 38 change blocks.
	44 lines changed or deleted		73 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/