idnits 2.17.00 (12 Aug 2021) /tmp/idnits46501/draft-banghart-mile-rolie-discovery-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 1531 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MILE Working Group S. Banghart 3 Internet-Draft D. Waltermire 4 Intended status: Informational NIST 5 Expires: September 6, 2018 March 5, 2018 7 ROLIE Discovery Mechanism 8 draft-banghart-mile-rolie-discovery-00 10 Abstract 12 This document specifies a mechanism that allows consistent discovery 13 of ROLIE repositories. This discovery is extremely important for 14 automated tools that cannot use out-of-band Service Document 15 discovery. Any human operators are also able to use this mechanism 16 to avoid relying on inconsistent human to human communication. This 17 document updates the ROLIE core specification. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 6, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. XML-related Conventions . . . . . . . . . . . . . . . . . . . 3 56 4. Requirements for Use of DNS Service Discovery . . . . . . . . 3 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 61 9. Normative References . . . . . . . . . . . . . . . . . . . . 4 62 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 4 63 A.1. Zone File . . . . . . . . . . . . . . . . . . . . . . . . 4 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 Discovery of a top-level resource is an important part of any RESTful 69 service. In order to begin navigating the web of information 70 available in ROLIE [RFC8322], a client must first locate the Service 71 Document. Without a well-defined discovery mechanism, clients must 72 use out-of-band methods to locate the Service Document, such as 73 crawling a web page or directly contacting website administrators. 75 The following goals are laid out for this mechanism: 77 Only requires domain name as input to locate an exact URL for 78 Service Document retrieval. 80 Fully automatable, but usable by human operators. 82 Supports multi-tenancy, that is, multiple ROLIE services hosted on 83 the same domain. 85 In order to meet these goals , this document updates ROLIE to require 86 the implementation of DNS-Based Service Discovery (DNS-SD) [RFC6763]. 88 DNS-SD provides a standardized mechanism built on top of existing DNS 89 processes that would allow for ROLIE clients to automatically 90 discover ROLIE services provided on a domain. DNS-SD is relatively 91 simple to understand and implement, and as it only uses existing 92 fields in DNS Zone Files, does not require any additional 93 implementation work by the DNS server. 95 The rest of the document assumes that the reader has a basic 96 understanding of both DNS-SD, and traditional DNS configuration, 97 including zone files. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 3. XML-related Conventions 109 Needed? Todo. 111 4. Requirements for Use of DNS Service Discovery 113 A ROLIE service MUST be registered to the relevant DNS Server using 114 the conventions and requirements laid out in DNS-SD ([RFC6763]. 116 A ROLIE service MUST use the service name "rolie" as registered to 117 the Service Names and Port Numbers registry. 119 TODO: Define a standarized composite service name (i.e. 120 _rolie_https._tcp) 122 5. IANA Considerations 124 This document registers a new entry in the Service Name and Port 125 Number Registry at . The registration 127 request is as follows: 129 +--------------------+-----------------------------+ 130 | Service Name | rolie | 131 | Transport Protocol | tcp | 132 | Assignee | Stephen Banghart | 133 | | | 134 | Contact | Stephen Banghart | 135 | | | 136 | Description | Resource-Oriented | 137 | | Lightweight Information | 138 | | Exchange (ROLIE) | 139 | Reference | This document, RFC8322 | 140 | Port Number | (Intentionally Blank) | 141 +--------------------+-----------------------------+ 143 6. Security Considerations 145 Todo. 147 7. Privacy Considerations 149 Todo. 151 8. Acknowledgements 153 9. Normative References 155 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 156 Requirement Levels", BCP 14, RFC 2119, 157 DOI 10.17487/RFC2119, March 1997, 158 . 160 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 161 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 162 . 164 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 165 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 166 May 2017, . 168 [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- 169 Oriented Lightweight Information Exchange (ROLIE)", 170 RFC 8322, DOI 10.17487/RFC8322, February 2018, 171 . 173 Appendix A. Examples 175 A.1. Zone File 177 In this section we will provide a nominal zone file that provides 178 DNS-SD for ROLIE and explain the various important pieces. 180 $ORIGIN example.com. 182 @ IN SOA example.com. unused-email ( 183 2017030300 ; serial 184 3600 ; refresh 185 1800 ; retry 186 604800 ; expire 187 600 ) ; ttl 189 @ IN NS example.com. 191 _dns-update._udp IN SRV 0 0 53 example.com. 193 b._dns-sd._udp IN PTR @ ; "b" = browse domain 194 lb._dns-sd._udp IN PTR @ ; "lb" = legacy browse domain 195 (include domain in empty-string browses) 196 r._dns-sd._udp IN PTR @ ; "r" = registration domain 198 _rolie_https._tcp PTR MyRolieService._rolie_https._tcp 199 MyRolieService._rolie_https._tcp SRV 0 0 227 rolie.example.com. 200 TXT path=/rolie 202 TODO: Explain each section. Correct example zone file to match 203 current implementation. 205 Authors' Addresses 207 Stephen A. Banghart 208 National Institute of Standards and Technology 209 100 Bureau Drive 210 Gaithersburg, Maryland 211 USA 213 Phone: (301)975-4288 214 Email: stephen.banghart@nist.gov 216 David Waltermire 217 National Institute of Standards and Technology 218 100 Bureau Drive 219 Gaithersburg, Maryland 20877 220 USA 222 Email: david.waltermire@nist.gov