| Internet-Draft | Mesh Name Service | September 2020 |
| Hallam-Baker | Expires 25 March 2021 | [Page] |
A naming service for the Mathematical Mesh is described.¶
https://mailarchive.ietf.org/arch/browse/mathmesh/Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at .¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 March 2021.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The Mesh Name Service allows Mesh users to change Mesh Service Providers without the switching costs associated with usual naming schemes.¶
The Mesh Name System is distinct from the DNS in several important respects:¶
The limitation on scope allows MNS to provide all the functionality of a traditional DNS TLD with almost none of the costs. While the DNS functionality exposed by a DNS TLD is limited to information that changes very rarely (i.e. discovery of the IP addresses of the authoritative DNS servers), the protocol used to deliver that functionality is designed to support real time publication of service configurations.¶
Another costly aspect of the DNS design is that there is no mechanism for invalidation of cached data. Instead every record has a predetermined expiry time and TLDs advise relying parties of updates to DNS records by publishing a new record. As a result, the vast bulk of (valid) TLD traffic consists of requests to check if the information has changed since the last time the party making the request checked. This approach makes the DNS infrastructure vulnerable to Denial of Service attack. If the DNS were ever to suffer a prolonged outage, the cached records would expire and the Internet would cease functioning.¶
The MNS Name Registry is an append only log containing a complete history of every change made. Every registry update is authenticated by means of a Merkle Tree, the apex of which is signed once a minute.¶
The Name Registry does not respond to name queries. Instead, every Mesh Service Provider is required to maintain a 'reasonably current' copy of the MNS Name Registry log and use this to respond to queries from the community it serves. This approach eliminates the almost all the costs associated with a DNS TLD registry and provides a 'fail safe' approach to design. Should the Name Service cease functioning for days or even weeks, only the ability to publish updates to existing configurations would be lost.¶
Requirements for Mesh Names, should meet the expectations of the user.¶
The signifier should unambiguously identify the referent.¶
The binding between the signifier and the signified should be consistent with the reasonable expectations of the user.¶
There MUST be no ongoing costs associated with the continued use of an existing name under an existing configuration. Charges for publishing changes to configurations should be strictly limited to cost recovery.¶
This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language.¶
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 [RFC2119].¶
The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer].¶
The name registry is implemented as a Mesh Catalog.¶
A name entry consists of the following information:¶
The unique identifier the entry describes.¶
The UDF fingerprint of the profile to which the name is bound.¶
Describes the means by which the name is assigned.¶
DNS or Mesh name of the Mesh Service Provider servicing the associated account.¶
IP addresses of the authoritative name servers for a DNS server servicing the Mesh name.¶
A list of signed assertions binding additional names and/or logographical representations to the profile specified by the name.¶
A Mesh name consists of a sequence of Unicode characters.¶
To prevent homograph type attacks, only characters from selected Unicode alphabet are permitted and mixing of characters from different alphabet s is prohibited with the exception of special characters that are permitted in any name.¶
The only special characters currently permitted are the digits 0-9, underscore (_) and dash(-).¶
The only alphabet currently supported is Extended Latin.¶
Canonicalization rules are applied within an alphabet to avoid ambiguity. For the Extended Latin alphabet, canonicalization causes case to be ignored, and ligatures to be mapped according to the prevailing rules applied in circumstances where accented characters are unavailable.¶
The first time a name is assigned, the assignment type is 'Initial'.¶
This document requires no IANA actions.¶