< draft-ietf-core-sid-08.txt		draft-ietf-core-sid-09.txt >
	Internet Engineering Task Force M. Veillette, Ed.		Internet Engineering Task Force M. Veillette, Ed.
	Internet-Draft Trilliant Networks Inc.		Internet-Draft Trilliant Networks Inc.
	Intended status: Standards Track A. Pelov, Ed.		Intended status: Standards Track A. Pelov, Ed.
	Expires: July 11, 2020 I. Petrov, Ed.		Expires: July 26, 2020 I. Petrov, Ed.
	Acklio		Acklio
	January 08, 2020		January 23, 2020
	YANG Schema Item iDentifier (SID)		YANG Schema Item iDentifier (SID)
	draft-ietf-core-sid-08		draft-ietf-core-sid-09
	Abstract		Abstract
	YANG Schema Item iDentifiers (SID) are globally unique 63-bit		YANG Schema Item iDentifiers (SID) are globally unique 63-bit
	unsigned integers used to identify YANG items. This document defines		unsigned integers used to identify YANG items. This document defines
	the semantics, the registration, and assignment processes of SIDs.		the semantics, the registration, and assignment processes of SIDs.
	To enable the implementation of these processes, this document also		To enable the implementation of these processes, this document also
	defines a file format used to persist and publish assigned SIDs.		defines a file format used to persist and publish assigned SIDs.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 July 11, 2020.		This Internet-Draft will expire on July 26, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 19 ¶		skipping to change at page 2, line 19 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3		2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
	3. ".sid" file lifecycle . . . . . . . . . . . . . . . . . . . . 4		3. ".sid" file lifecycle . . . . . . . . . . . . . . . . . . . . 4
	4. ".sid" file format . . . . . . . . . . . . . . . . . . . . . 5		4. ".sid" file format . . . . . . . . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	6.1. Register SID File Format Module . . . . . . . . . . . . . 9		6.1. Register SID File Format Module . . . . . . . . . . . . . 9
	6.2. Create new IANA Registry: "SID Mega-Range" registry . . . 9		6.2. Create new IANA Registry: "SID Mega-Range" registry . . . 9
	6.2.1. Structure . . . . . . . . . . . . . . . . . . . . . . 9		6.2.1. Structure . . . . . . . . . . . . . . . . . . . . . . 9
	6.2.2. Allocation policy . . . . . . . . . . . . . . . . . . 10		6.2.2. Allocation policy . . . . . . . . . . . . . . . . . . 10
	6.2.2.1. First allocation . . . . . . . . . . . . . . . . 10		6.2.2.1. First allocation . . . . . . . . . . . . . . . . 11
	6.2.2.2. Consecutive allocations . . . . . . . . . . . . . 11		6.2.2.2. Consecutive allocations . . . . . . . . . . . . . 11
	6.2.3. Initial contents of the Registry . . . . . . . . . . 11		6.2.3. Initial contents of the Registry . . . . . . . . . . 11
	6.3. Create a new IANA Registry: IETF SID Range Registry		6.3. Create a new IANA Registry: IETF SID Range Registry
	(managed by IANA) . . . . . . . . . . . . . . . . . . . . 11		(managed by IANA) . . . . . . . . . . . . . . . . . . . . 11
	6.3.1. Structure . . . . . . . . . . . . . . . . . . . . . . 11		6.3.1. Structure . . . . . . . . . . . . . . . . . . . . . . 11
	6.3.2. Allocation policy . . . . . . . . . . . . . . . . . . 11		6.3.2. Allocation policy . . . . . . . . . . . . . . . . . . 11
	6.3.3. Initial contents of the registry . . . . . . . . . . 12		6.3.3. Initial contents of the registry . . . . . . . . . . 13
	6.4. Create new IANA Registry: "IETF SID Registry" . . . . . . 13		6.4. Create new IANA Registry: "IETF SID Registry" . . . . . . 14
	6.4.1. Structure . . . . . . . . . . . . . . . . . . . . . . 13		6.4.1. Structure . . . . . . . . . . . . . . . . . . . . . . 14
	6.4.2. Allocation policy . . . . . . . . . . . . . . . . . . 14		6.4.2. Allocation policy . . . . . . . . . . . . . . . . . . 14
	6.4.3. Initial contents of the registry . . . . . . . . . . 14		6.4.3. Recursive Allocation of SID Range at Document
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		Adoption . . . . . . . . . . . . . . . . . . . . . . 15
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		6.4.4. Initial contents of the registry . . . . . . . . . . 16
	8.1. Normative References . . . . . . . . . . . . . . . . . . 14		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	8.2. Informative References . . . . . . . . . . . . . . . . . 15		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Appendix A. ".sid" file example . . . . . . . . . . . . . . . . 16		8.1. Normative References . . . . . . . . . . . . . . . . . . 17
	Appendix B. SID auto generation . . . . . . . . . . . . . . . . 25		8.2. Informative References . . . . . . . . . . . . . . . . . 17
	Appendix C. ".sid" file lifecycle . . . . . . . . . . . . . . . 25		Appendix A. ".sid" file example . . . . . . . . . . . . . . . . 18
	C.1. SID File Creation . . . . . . . . . . . . . . . . . . . . 26		Appendix B. SID auto generation . . . . . . . . . . . . . . . . 27
	C.2. SID File Update . . . . . . . . . . . . . . . . . . . . . 27		Appendix C. ".sid" file lifecycle . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28		C.1. SID File Creation . . . . . . . . . . . . . . . . . . . . 28
			C.2. SID File Update . . . . . . . . . . . . . . . . . . . . . 29
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
	1. Introduction		1. Introduction
	Some of the items defined in YANG [RFC7950] require the use of a		Some of the items defined in YANG [RFC7950] require the use of a
	unique identifier. In both NETCONF [RFC6241] and RESTCONF [RFC8040],		unique identifier. In both NETCONF [RFC6241] and RESTCONF [RFC8040],
	these identifiers are implemented using names. To allow the		these identifiers are implemented using names. To allow the
	implementation of data models defined in YANG in constrained devices		implementation of data models defined in YANG in constrained devices
	and constrained networks, a more compact method to identify YANG		and constrained networks, a more compact method to identify YANG
	items is required. This compact identifier, called SID, is encoded		items is required. This compact identifier, called SID, is encoded
	using a 63-bit unsigned integer. The reason not to use 64-bit		using a 63-bit unsigned integer. The limitation to 63-bit unsigned
	unsigned integers is that otherwise protocols doing arithmetical		integers allows SIDs to be manipulated more easily on platforms that
	operations with the SIDs could be very difficult to implement.		might otherwise lack native 64-bit unsigned arithmetic. The loss of
			a single bit of range is not significant given the size of the
			remaining space.
	The following items are identified using SIDs:		The following items are identified using SIDs:
	o identities		o identities
	o data nodes (Note: including those parts of a YANG template as		o data nodes (Note: including those parts of a YANG template as
	defined by the 'yang-data' extension.)		defined by the 'yang-data' extension.)
	o RPCs and associated input(s) and output(s)		o RPCs and associated input(s) and output(s)
	skipping to change at page 13, line 5 ¶		skipping to change at page 13, line 9 ¶
	| 0 | 1,000 | Reserved |		| 0 | 1,000 | Reserved |
	| 1,000 | 59,000 | Expert Review |		| 1,000 | 59,000 | Expert Review |
	| 60,000 | 40,000 | Experimental use |		| 60,000 | 40,000 | Experimental use |
	| 100,000 | 900,000 | Reserved |		| 100,000 | 900,000 | Reserved |
	+-------------+---------+------------------+		+-------------+---------+------------------+
	6.3.3. Initial contents of the registry		6.3.3. Initial contents of the registry
	Initial entries in this registry are as follows:		Initial entries in this registry are as follows:
	+-------------+------+------------------+----------------------+		+-----+-----+--------------------------+----------------------------+
	| Entry Point | Size | Module name | Document reference |		| Ent | Siz | Module name | Document reference |
	+-------------+------+------------------+----------------------+		| ry | e | | |
	| 1000 | 100 | ietf-comi | [I-D.ietf-core-comi] |		| Poi | | | |
	| 1100 | 50 | ietf-yang-types | [RFC6991] |		| nt | | | |
	| 1150 | 50 | ietf-inet-types | [RFC6991] |		+-----+-----+--------------------------+----------------------------+
	| 1200 | 50 | iana-crypt-hash | [RFC7317] |		| 100 | 100 | ietf-comi | [I-D.ietf-core-comi] |
	| 1250 | 50 | ietf-netconf-acm | [RFC8341] |		| 0 | | | |
	| 1300 | 50 | ietf-sid-file | RFCXXXX |		| 110 | 50 | ietf-yang-types | [RFC6991] |
	| 1500 | 100 | ietf-interfaces | [RFC8343] |		| 0 | | | |
	| 1600 | 100 | ietf-ip | [RFC8344] |		| 115 | 50 | ietf-inet-types | [RFC6991] |
	| 1700 | 100 | ietf-system | [RFC7317] |		| 0 | | | |
	| 1800 | 400 | iana-if-type | [RFC7224] |		| 120 | 50 | iana-crypt-hash | [RFC7317] |
	+-------------+------+------------------+----------------------+		| 0 | | | |
			| 125 | 50 | ietf-netconf-acm | [RFC8341] |
			| 0 | | | |
			| 130 | 50 | ietf-sid-file | RFCXXXX |
			| 0 | | | |
			| 150 | 100 | ietf-interfaces | [RFC8343] |
			| 0 | | | |
			| 160 | 100 | ietf-ip | [RFC8344] |
			| 0 | | | |
			| 170 | 100 | ietf-system | [RFC7317] |
			| 0 | | | |
			| 180 | 400 | iana-if-type | [RFC7224] |
			| 0 | | | |
			| 240 | 50 | ietf-voucher | [RFC8366] |
			| 0 | | | |
			| 245 | 50 | ietf-constrained-voucher | [I-D.ietf-anima-constraine |
			| 0 | | | d-voucher] |
			| 250 | 50 | ietf-constrained- | [I-D.ietf-anima-constraine |
			| 0 | | voucher-request | d-voucher] |
			+-----+-----+--------------------------+----------------------------+
	// RFC Ed.: replace XXXX with RFC number assigned to this draft.		// RFC Ed.: replace XXXX with RFC number assigned to this draft.
	For allocation, RFC publication of the YANG module is required as per		For allocation, RFC publication of the YANG module is required as per
	[RFC8126]. The YANG module must be registered in the "YANG module		[RFC8126]. The YANG module must be registered in the "YANG module
	Name" registry according to the rules specified in section 14 of		Name" registry according to the rules specified in section 14 of
	[RFC6020].		[RFC6020].
	6.4. Create new IANA Registry: "IETF SID Registry"		6.4. Create new IANA Registry: "IETF SID Registry"
	skipping to change at page 13, line 43 ¶		skipping to change at page 14, line 21 ¶
	6.4.1. Structure		6.4.1. Structure
	Each entry in this registry must include:		Each entry in this registry must include:
	o The YANG module name. This module name must be present in the		o The YANG module name. This module name must be present in the
	"Name" column of the "YANG Module Names" registry.		"Name" column of the "YANG Module Names" registry.
	o A link to the associated ".yang" file. This file link must be		o A link to the associated ".yang" file. This file link must be
	present in the "File" column of the "YANG Module Names" registry.		present in the "File" column of the "YANG Module Names" registry.
	o The link to the ".sid" file which defines the allocation.		o The link to the ".sid" file which defines the allocation. The
			".sid" file is stored by IANA.
	o The number of actually allocated SIDs in the ".sid" file.		o The number of actually allocated SIDs in the ".sid" file.
	The ".sid" file is stored by IANA.
	6.4.2. Allocation policy		6.4.2. Allocation policy
	The allocation policy is Expert review. The Expert MUST ensure that		The allocation policy is Expert review. The Expert MUST ensure that
	the following conditions are met:		the following conditions are met:
	o The ".sid" file has a valid structure:		o The ".sid" file has a valid structure:
	* The ".sid" file MUST be a valid JSON file following the		* The ".sid" file MUST be a valid JSON file following the
	structure of the module defined in RFCXXXX (RFC Ed: replace XXX		structure of the module defined in RFCXXXX (RFC Ed: replace XXX
	with RFC number assigned to this draft).		with RFC number assigned to this draft).
	skipping to change at page 14, line 30 ¶		skipping to change at page 15, line 5 ¶
	* All SIDs in this ".sid" file MUST be within the ranges		* All SIDs in this ".sid" file MUST be within the ranges
	allocated to this YANG module in the "IETF SID Range Registry".		allocated to this YANG module in the "IETF SID Range Registry".
	o If another ".sid" file has already allocated SIDs for this YANG		o If another ".sid" file has already allocated SIDs for this YANG
	module (e.g. for older or newer versions of the YANG module), the		module (e.g. for older or newer versions of the YANG module), the
	YANG items are assigned the same SIDs as in the the other ".sid"		YANG items are assigned the same SIDs as in the the other ".sid"
	file.		file.
	o SIDs never change.		o SIDs never change.
	6.4.3. Initial contents of the registry		6.4.3. Recursive Allocation of SID Range at Document Adoption
			Due to the difficulty in changing SID values during IETF document
			processing, it is expected that most documents will ask for SID
			allocations using Early Allocations [RFC7120]. The details of the
			Early Allocation should be included in any Working Group Adoption
			call. Prior to Working Group Adoption, an internet draft authors can
			use the experimental SID range (as per Section 6.3.2) for their SIDs
			allocations or other values that do not create ambiguity with other
			SID uses (for example they can use a range that comes from a non-IANA
			managed "SID Mega-Range" registry).
			After Working Group Adoption, any modification of a .sid file is
			expected to be discussed on the mailing list of the appropriate
			Working Groups. Specific attention should be paid to implementers'
			opinion after Working Group Last Call if a SID value is to change its
			meaning. In all cases, a .sid file and the SIDs associated with it
			are subject to change before the publication of an internet draft as
			an RFC.
			During the early use of SIDs, many existing, previously published
			YANG modules will not have SID allocations. For an allocation to be
			useful the included YANG modules may also need to have SID
			allocations made.
			The Expert Reviewer who performs the (Early) Allocation analysis will
			need to go through the list of included YANG modules and perform SID
			allocations for those modules as well.
			o If the document is a published RFC, then the allocation of SIDs
			for its referenced YANG modules is permanent. The Expert Reviewer
			provides the generated SID file to IANA for registration. This
			process may be time consuming during a bootstrap period (there are
			over 100 YANG modules to date, none of which have SID
			allocations), but should quiet down once needed entries are
			allocated.
			o If the document is an unprocessed Internet-Draft adopted in a WG,
			then an Early Allocation is performed for this document as well.
			Early Allocations require approval by an IESG Area Director. An
			early allocation which requires additional allocations will list
			the other allocations in it's description, and will be cross-
			posted to the any other working group mailing lists.
			o A YANG module which references a module in an document which has
			not yet been adopted by any working group will be unable to
			perform an Early Allocation for that other document until it is
			adopted by a working group. As described in [RFC7120], an AD
			Sponsored document acts as if it had a working group. The
			approving AD may also exempt a document from this policy by
			agreeing to AD Sponsor the document.
			Critically, the original document should never get through the IETF
			process and then be surprised to be referencing a document whose
			progress is not certain.
			A previously SID-allocated YANG module which changes its references
			to include a YANG module for which there is no SID allocation needs
			to repeat the Early Allocation process.
			Early Allocations are made with a one-year period, after which they
			are expired. [RFC7120] indicates that at most one renewal may be
			made. For the SID allocation a far more lenient stance is desired.
			1. An extension of a referencing documents Early Allocation should
			update any referenced Early Allocations to expire no sooner than
			the referencing document.
			2. The [RFC7120] mechanism allows the IESG to provide a second
			renewal, and such an event may prompt some thought about how the
			collection of documents are being processed.
			This is driven by the very generous size of the SID space and the
			often complex and deep dependencies of YANG modules. Often a core
			module with many dependencies will undergo extensive review, delaying
			the publication of other documents.
			[RFC7120] also says
			Note that if a document is submitted for review to the IESG and at
			the time of submission some early allocations are valid (not
			expired), these allocations should not be expired while the document
			is under IESG consideration or waiting in the RFC Editor's queue
			after approval by the IESG.
			6.4.4. Initial contents of the registry
	None.		None.
	7. Acknowledgments		7. Acknowledgments
	The authors would like to thank Andy Bierman, Carsten Bormann,		The authors would like to thank Andy Bierman, Carsten Bormann,
	Abhinav Somaraju, Laurent Toutain, Randy Turner and Peter van der		Michael Richardson, Abhinav Somaraju, Peter van der Stok, Laurent
	Stok for their help during the development of this document and their		Toutain and Randy Turner for their help during the development of
	useful comments during the review process.		this document and their useful comments during the review process.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 15, line 19 ¶		skipping to change at page 17, line 32 ¶
	[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",		[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
	RFC 7951, DOI 10.17487/RFC7951, August 2016,		RFC 7951, DOI 10.17487/RFC7951, August 2016,
	<https://www.rfc-editor.org/info/rfc7951>.		<https://www.rfc-editor.org/info/rfc7951>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	8.2. Informative References		8.2. Informative References
			[I-D.ietf-anima-constrained-voucher]
			Richardson, M., Stok, P., and P. Kampanakis, "Constrained
			Voucher Artifacts for Bootstrapping Protocols", draft-
			ietf-anima-constrained-voucher-07 (work in progress),
			January 2020.
	[I-D.ietf-core-comi]		[I-D.ietf-core-comi]
	Veillette, M., Stok, P., Pelov, A., Bierman, A., and I.		Veillette, M., Stok, P., Pelov, A., Bierman, A., and I.
	Petrov, "CoAP Management Interface", draft-ietf-core-		Petrov, "CoAP Management Interface", draft-ietf-core-
	comi-08 (work in progress), September 2019.		comi-08 (work in progress), September 2019.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010,
	<https://www.rfc-editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.
	skipping to change at page 16, line 23 ¶		skipping to change at page 18, line 39 ¶
	<https://www.rfc-editor.org/info/rfc8341>.		<https://www.rfc-editor.org/info/rfc8341>.
	[RFC8343] Bjorklund, M., "A YANG Data Model for Interface		[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
	Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,		Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
	<https://www.rfc-editor.org/info/rfc8343>.		<https://www.rfc-editor.org/info/rfc8343>.
	[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",		[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
	RFC 8344, DOI 10.17487/RFC8344, March 2018,		RFC 8344, DOI 10.17487/RFC8344, March 2018,
	<https://www.rfc-editor.org/info/rfc8344>.		<https://www.rfc-editor.org/info/rfc8344>.
			[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
			"A Voucher Artifact for Bootstrapping Protocols",
			RFC 8366, DOI 10.17487/RFC8366, May 2018,
			<https://www.rfc-editor.org/info/rfc8366>.
	Appendix A. ".sid" file example		Appendix A. ".sid" file example
	The following .sid file (ietf-system@2014-08-06.sid) have been		The following .sid file (ietf-system@2014-08-06.sid) have been
	generated using the following yang modules:		generated using the following yang modules:
	o ietf-system@2014-08-06.yang		o ietf-system@2014-08-06.yang
	o ietf-yang-types@2013-07-15.yang		o ietf-yang-types@2013-07-15.yang
	o ietf-inet-types@2013-07-15.yang		o ietf-inet-types@2013-07-15.yang
	o ietf-netconf-acm@2012-02-22.yang		o ietf-netconf-acm@2012-02-22.yang
	o iana-crypt-hash@2014-04-04.yang		o iana-crypt-hash@2014-04-04.yang
	{		{
	"assignment-ranges": [		"assignment-ranges": [
	{		{
	"entry-point": 1700,		"entry-point": 1700,
End of changes. 16 change blocks.
	44 lines changed or deleted		161 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/