<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-przygienda-rift-kv-registry-00"
     ipr="trust200902"
     obsoletes="" submissionType="IETF" updates="" xml:lang="en">
    <front>
        <title abbrev="draft-ietf-przygienda-kv-registry">
            RIFT Keys Structure and Well-Known Registry in Key Value TIE 
        </title>

        <author fullname="Tony Przygienda" initials="A." surname="Przygienda">
            <organization>Juniper</organization>
            <address>
                <postal>
                <street>1137 Innovation Way
                </street>
                <city>Sunnyvale</city>
                <region>CA
                </region>
                <code/>
                <country>USA
                </country>
                </postal>
                <phone/>
                <facsimile/>
                <email>prz@juniper.net
                </email>
                <uri/>
            </address>
        </author>

        <date year="2020"/>
        <abstract>
            <t>This document describes key structure of keys contained 
                within RIFT key-value TIEs. 
            </t>
        </abstract>
        <note title="Requirements Language">
            <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
                "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
                document are to be interpreted as described in <xref format="default"
                pageno="false" target="RFC2119">RFC 2119</xref>.
            </t>
        </note>
    </front>
    <middle>

        <section title="Description" toc="default">
            <t>
                <xref target="I-D.ietf-rift-rift"/> specifies a topology information element (TIE) 
                that can carry unstructured key value pairs of data. This document defines a registry
                for the keys to allow for vendor specific values being carried without risking a collision
                with future standardized values. 
            </t>
            <t>This document specifies also several well-known keys and their values including a registry 
            to allow for easier
            interoperability between implementations. 
            </t>
        </section>

        <section title="Key Type Registry">
        <t>The first octet of every key is a value from a "RIFT Key Types Registry" which may 
        specify the according key structure further. 
        </t>

        </section>

        <section title="OUI Key Type">

        <t>This section reserves a key type value to indicate a vendor specific key with 
        further indication via Organizationally Unique Identifier (OUI) which organization the 
        key belongs to. The value of that first octet is TBD1. The structure of the key is 
        indicated in the figure <xref target="f1"/>.
        </t>
				

            <figure align="left" alt="" height="" suppress-title="false" title="OUI Key" width="" anchor="f1">

                <artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve">
<![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       TBD1    |     Organizationally Unique Identifier        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Vendor Specific Key Part ... 

]]>
    </artwork>
            </figure>


        </section>

        <section title="Well-Known Key Type">
        <t>This section reserves a key type value in Key Type Registry to indicate a well-known key that 
        all implementations SHOULD support. The type is followed by a 3 octets value 
        from a "RIFT Well-Known Key" Registry describing the structure of the value 
        it carries. The resulting structure of the key is provided in <xref target="f2"/>.
        </t>


            <figure align="left" alt="" height="" suppress-title="false" title="Well-Known Key" width="" anchor="f2">

                <artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve">
<![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       TBD2    |     Well-Known Key Type Identifier            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
    </artwork>
            </figure>

        </section>


        <section anchor="IANA" title="IANA Considerations" toc="default">
		
        <t>
            This section requests registries that help govern RIFT key values via usual IANA registry
            procedures. 
            
            All values not suggested as to be
            considered available for assignment. 
            Allocation of new values is always performed via `Expert Review` action.

        </t>

            <section title="Key Type Registry">

            <t>This is registry for key types for keys contained in RIFT KV TIEs. The range of values is 0 .. 255</t>

                <section title="Requested Entries">
                <texttable style="none">
                <ttcol>Name</ttcol><ttcol align="right">Value</ttcol><ttcol align="right"></ttcol><ttcol>Description</ttcol>
                <c>OUI</c>	<c>TBD1</c>	<c></c>	<c>Followed by 3 octets of OUI.</c>
                <c>Well-Known Key</c>	<c>TBD2</c>	<c></c>	<c>Followed by 3 octets value from Well-Known Key Type Registry.</c>
                </texttable>
                </section>

            </section>

            <section title="Well-Known Key Type Registry">

            <t>This is registry for key types for well-known keys contained in RIFT KV TIEs. The range of values is 0 .. 2^24-1</t>

                <section title="Requested Entries">
                <texttable style="none">
                <ttcol>Name</ttcol><ttcol align="right">Value</ttcol><ttcol align="right"></ttcol><ttcol>Description</ttcol>
                <c>Illegal</c>	<c>0</c>	<c></c>	<c>Not allowed.</c>
                <c>MAC/IP Binding</c>	<c>TBD2</c>	<c></c>	<c>To be defined.</c>
                <c>FAM Security Roll-Over Key</c>	<c>TBD2</c>	<c></c>	<c>To be defined.</c>
                </texttable>
                </section>

            </section>
		</section>

        <section title="Security Considerations">
            <t>This document introduces no new security concerns to RIFT or other
                specifications referenced in this document given that key value 
                pairs are carried in TIEs that are already extensively secured by 
                RIFT specification itself. 
            </t>
        </section>

        <section title="Acknowledgements">
            <t>To be provided.</t>
        </section>

    </middle>
    <back>
        <references title="Normative References">
                   <?rfc include="reference.RFC.2119"?>
            <?rfc include="reference.I-D.ietf-rift-rift.xml"?>

        </references>

    </back>
</rfc>
