idnits 2.17.1 draft-hallambaker-mesh-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 November 2020) is 1261 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. M. Hallam-Baker 3 Internet-Draft ThresholdSecrets.com 4 Intended status: Informational 2 November 2020 5 Expires: 6 May 2021 7 Mathematical Mesh 3.0 Part VI: Mesh Discovery Service 8 draft-hallambaker-mesh-discovery-00 10 Abstract 12 A naming service for the Mathematical Mesh is described. 14 https://mailarchive.ietf.org/arch/browse/mathmesh/ 15 (http://whatever)Discussion of this draft should take place on the 16 MathMesh mailing list (mathmesh@ietf.org), which is archived at . 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 6 May 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 51 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 52 2.3. Related Specifications . . . . . . . . . . . . . . . . . 4 53 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 4 54 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Name Registry . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1.1. Name Entries . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Name syntax . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.3. Name Assignment . . . . . . . . . . . . . . . . . . . . . 5 59 4. Business Model . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Names do not expire . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 64 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 65 9. Informative References . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 The Mesh Discovery Service allows Mesh users to change Mesh Service 70 Providers without the switching costs associated with usual naming 71 schemes. 73 The Mesh Discovery System is distinct from the DNS in several 74 important respects: 76 * Mesh Names are intended to be the personal property of the 77 assignee and use of the name MUST NOT require payment of ongoing 78 rents, fees etc. of any kind. 80 * The DNS combines the functions of name delegation and discovery of 81 services provided under those names into a single protocol. The 82 MNS only supports name delegation. 84 The limitation on scope allows MDS to provide all the functionality 85 of a traditional DNS TLD with almost none of the costs. While the 86 DNS functionality exposed by a DNS TLD is limited to information that 87 changes very rarely (i.e. discovery of the IP addresses of the 88 authoritative DNS servers), the protocol used to deliver that 89 functionality is designed to support real time publication of service 90 configurations. 92 Another costly aspect of the DNS design is that there is no mechanism 93 for invalidation of cached data. Instead every record has a 94 predetermined expiry time and TLDs advise relying parties of updates 95 to DNS records by publishing a new record. As a result, the vast 96 bulk of (valid) TLD traffic consists of requests to check if the 97 information has changed since the last time the party making the 98 request checked. This approach makes the DNS infrastructure 99 vulnerable to Denial of Service attack. If the DNS were ever to 100 suffer a prolonged outage, the cached records would expire and the 101 Internet would cease functioning. 103 The MNS Name Registry is an append only log containing a complete 104 history of every change made. Every registry update is authenticated 105 by means of a Merkle Tree, the apex of which is signed once a minute. 107 The Name Registry does not respond to discovery queries. Instead, 108 every Mesh Service Provider is required to maintain a 'reasonably 109 current' copy of the MNS Name Registry log and use this to respond to 110 queries from the community it serves. This approach eliminates the 111 almost all the costs associated with a DNS TLD registry and provides 112 a 'fail safe' approach to design. Should the Name Service cease 113 functioning for days or even weeks, only the ability to publish 114 updates to existing configurations would be lost. 116 Requirements for Mesh Names, should meet the expectations of the 117 user. 119 Unambiguous The signifier should unambiguously identify the 120 referent. 122 Consistent The binding between the signifier and the signified 123 should be consistent with the reasonable expectations of the user. 125 Freehold There MUST be no ongoing costs associated with the 126 continued use of an existing name under an existing configuration. 127 Charges for publishing changes to configurations should be 128 strictly limited to cost recovery. 130 2. Definitions 132 This section presents the related specifications and standard, the 133 terms that are used as terms of art within the documents and the 134 terms used as requirements language. 136 2.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2.2. Defined Terms 144 2.3. Related Specifications 146 2.4. Implementation Status 148 The implementation status of the reference code base is described in 149 the companion document [draft-hallambaker-mesh-developer]. 151 3. Architecture 153 3.1. Name Registry 155 The name registry is implemented as a Mesh Catalog. 157 3.1.1. Name Entries 159 A name entry consists of the following information: 161 Name The unique identifier the entry describes. 163 Profile Identifier The UDF fingerprint of the profile to which the 164 name is bound. 166 Assignment Type Describes the means by which the name is assigned. 168 Mesh Service Provider DNS or Mesh name of the Mesh Service Provider 169 servicing the associated account. 171 DNS Resolver Addresses (Optional) IP addresses of the authoritative 172 name servers for a DNS server servicing the Mesh name. 174 Bindings (Optional) A list of signed assertions binding additional 175 names and/or logographical representations to the profile 176 specified by the name. 178 3.2. Name syntax 180 A Mesh name consists of a sequence of Unicode characters. 182 To prevent homograph type attacks, only characters from selected 183 Unicode alphabet are permitted and mixing of characters from 184 different alphabet s is prohibited with the exception of special 185 characters that are permitted in any name. 187 The only special characters currently permitted are the digits 0-9, 188 underscore (_) and dash(-). 190 The only alphabet currently supported is Extended Latin. 192 Canonicalization rules are applied within an alphabet to avoid 193 ambiguity. For the Extended Latin alphabet, canonicalization causes 194 case to be ignored, and ligatures to be mapped according to the 195 prevailing rules applied in circumstances where accented characters 196 are unavailable. 198 3.3. Name Assignment 200 The first time a name is assigned, the assignment type is 'Initial'. 202 4. Business Model 204 4.1. Names do not expire 206 5. Security Considerations 208 6. IANA Considerations 210 This document requires no IANA actions. 212 7. Acknowledgements 214 8. Normative References 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, 218 DOI 10.17487/RFC2119, March 1997, 219 . 221 9. Informative References 223 [draft-hallambaker-mesh-developer] 224 Hallam-Baker, P., "Mathematical Mesh: Reference 225 Implementation", Work in Progress, Internet-Draft, draft- 226 hallambaker-mesh-developer-10, 27 July 2020, 227 .