<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
  <!ENTITY RFC8322 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8322.xml">
  <!ENTITY RFC6763 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml">
  <!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
]>
<?xml-stylesheet type="text/css" href="rfc7749.css"?>
<rfc ipr="trust200902" category="info"
  docName="draft-banghart-mile-rolie-discovery-00">
  <?rfc compact="yes"?>
  <?rfc subcompact="no"?>
  <?rfc toc="yes"?>
  <?rfc symrefs="yes"?>

  <front>
    <title abbrev="ROLIE Discovery">ROLIE Discovery Mechanism</title>
    <author initials="S.A." surname="Banghart"
      fullname="Stephen A. Banghart">
      <organization abbrev="NIST">National Institute of Standards and
        Technology</organization>
      <address>
        <postal>
          <street>100 Bureau Drive</street>
          <city>Gaithersburg</city>
          <region>Maryland</region>
          <country>USA</country>
        </postal>
        <phone>(301)975-4288</phone>
        <email>stephen.banghart@nist.gov</email>
      </address>
    </author>
    <author fullname="David Waltermire" initials="D.W."
      surname="Waltermire">
      <organization abbrev="NIST">National Institute of Standards and
        Technology</organization>

      <address>
        <postal>
          <street>100 Bureau Drive</street>
          <city>Gaithersburg</city>
          <region>Maryland</region>
          <code>20877</code>
          <country>USA</country>
        </postal>
        <phone/>
        <email>david.waltermire@nist.gov</email>
      </address>
    </author>
    <date year="2018"/>

    <area>Security</area>
    <workgroup>MILE Working Group</workgroup>
    <keyword>rolie</keyword>
    <keyword>discovery</keyword>
    <keyword>DNS-SD</keyword>
    <abstract>
      <t>This document specifies a mechanism that allows consistent
        discovery of ROLIE repositories. This discovery is extremely
        important for automated tools that cannot use out-of-band Service
        Document discovery. Any human operators are also able to use this
        mechanism to avoid relying on inconsistent human to human
        communication. This document updates the ROLIE core
        specification.</t>
    </abstract>


  </front>
  <middle>
    <section title="Introduction" anchor="starting-intro">
      <t>Discovery of a top-level resource is an important part of any
        RESTful service. In order to begin navigating the web of
        information available in ROLIE <xref target="RFC8322"/>, a client must first locate the
        Service Document. Without a well-defined discovery mechanism,
        clients must use out-of-band methods to locate the Service
        Document, such as crawling a web page or directly contacting
        website administrators.</t>

      <t>The following goals are laid out for this mechanism: <list
        style="hanging">
        <t>Only requires domain name as input to locate an exact URL for
          Service Document retrieval.</t>
        <t>Fully automatable, but usable by human operators.</t>
        <t>Supports multi-tenancy, that is, multiple ROLIE services
          hosted on the same domain.</t>
        </list></t>

      <t>In order to meet these goals , this document updates ROLIE to
        require the implementation of DNS-Based Service Discovery
        (DNS-SD) <xref target="RFC6763"/>.</t>
      <t>DNS-SD provides a standardized mechanism built on top of
        existing DNS processes that would allow for ROLIE clients to
        automatically discover ROLIE services provided on a domain.
        DNS-SD is relatively simple to understand and implement, and as
        it only uses existing fields in DNS Zone Files, does not require
        any additional implementation work by the DNS server.</t>

      <t>The rest of the document assumes that the reader has a basic
        understanding of both DNS-SD, and traditional DNS configuration,
        including zone files.</t>

    </section>
    <section title="Terminology" anchor="ext-terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
        "MAY", and "OPTIONAL" in this document are to be interpreted as
        described in BCP 14 <xref target="RFC2119"/> <xref
        target="RFC8174"/> when, and only when, they appear in all
        capitals, as shown here.</t>
    </section>
    <section title="XML-related Conventions" anchor="xml">
      <t>Needed? Todo.</t>
    </section>

    <section title="Requirements for Use of DNS Service Discovery"
      anchor="DNSSD">
      <t>A ROLIE service MUST be registered to the relevant DNS Server
        using the conventions and requirements laid out in DNS-SD (<xref
        target="RFC6763"/>. </t>

      <t>A ROLIE service MUST use the service name "rolie" as registered
        to the Service Names and Port Numbers registry.</t>

      <t>TODO: Define a standarized composite service name (i.e.
        _rolie_https._tcp)</t>
    </section>


    <section title="IANA Considerations" anchor="iana">
      <t>This document registers a new entry in the Service Name and Port
        Number Registry at <eref
        target="https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml"
        />. The registration request is as follows:</t>
      <figure>
        <artwork><![CDATA[
           +--------------------+-----------------------------+
           | Service Name       | rolie                       |
           | Transport Protocol | tcp                         |
           | Assignee           | Stephen Banghart            |
           |                    | <stephen.banghart@nist.gov> |
           | Contact            | Stephen Banghart            |
           |                    | <stephen.banghart@nist.gov> |
           | Description        | Resource-Oriented           |
           |                    | Lightweight Information     |
           |                    | Exchange (ROLIE)            |
           | Reference          | This document, RFC8322      |
           | Port Number        | (Intentionally Blank)       |
           +--------------------+-----------------------------+
      ]]></artwork>
      </figure>

    </section>
    <section title="Security Considerations" anchor="security">
      <t>Todo.</t>
    </section>
    <section title="Privacy Considerations" anchor="privacy">
      <t>Todo.</t>
    </section>
    <section title="Acknowledgements" anchor="acknowledgements">
    </section>
  </middle>
  <back>
    <references title="Normative References"> &RFC8322; &RFC6763;
      &RFC2119; &RFC8174; 
    </references>

    
    <section title="Examples" anchor="appendix-ex">
      <section title="Zone File" anchor="appendix-ex-zone">
        <t>In this section we will provide a nominal zone file that
          provides DNS-SD for ROLIE and explain the various important
          pieces. </t>
        <figure height="" suppress-title="false" width="" alt="" title=""
          align="left">
          <artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve"><![CDATA[
$ORIGIN example.com.

@   IN SOA example.com. unused-email (
    2017030300 ; serial
    3600       ; refresh
    1800       ; retry
    604800     ; expire
    600 )      ; ttl
    
@ IN NS example.com.

_dns-update._udp IN SRV 0 0 53 example.com.

b._dns-sd._udp  IN PTR @   ;  "b" = browse domain
lb._dns-sd._udp IN PTR @   ; "lb" = legacy browse domain 
                            (include domain in empty-string browses)
r._dns-sd._udp  IN PTR @   ;  "r" = registration domain

_rolie_https._tcp PTR MyRolieService._rolie_https._tcp
MyRolieService._rolie_https._tcp SRV 0 0 227 rolie.example.com.
                                 TXT path=/rolie

]]></artwork>
        </figure>
        <t>TODO: Explain each section. Correct example zone file to match
          current implementation.</t>
      </section>
    </section>

  </back>
</rfc>
