Internet-Draft Mesh Discovery Service January 2021
Hallam-Baker Expires 17 July 2021 [Page]
Network Working Group
Intended Status:
P. M. Hallam-Baker

Mathematical Mesh 3.0 Part VI: Mesh Discovery Service


A naming service for the Mathematical Mesh is described. of this draft should take place on the MathMesh mailing list (, which is archived at .

Status of This Memo

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

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 17 July 2021.

Table of Contents

1. Introduction

The Mesh Discovery Service allows Mesh users to change Mesh Service Providers without the switching costs associated with usual naming schemes.

The Mesh Discovery System is distinct from the DNS in several important respects:

The limitation on scope allows MDS 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 discovery 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.

2. Definitions

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.

2.1. 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].

2.4. Implementation Status

The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer].

3. Architecture

3.1. Name Registry

The name registry is implemented as a Mesh Catalog.

3.1.1. Name Entries

A name entry consists of the following information:


The unique identifier the entry describes.

Profile Identifier

The UDF fingerprint of the profile to which the name is bound.

Assignment Type

Describes the means by which the name is assigned.

Mesh Service Provider

DNS or Mesh name of the Mesh Service Provider servicing the associated account.

DNS Resolver Addresses (Optional)

IP addresses of the authoritative name servers for a DNS server servicing the Mesh name.

Bindings (Optional)

A list of signed assertions binding additional names and/or logographical representations to the profile specified by the name.

3.2. Name syntax

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.

3.3. Name Assignment

The first time a name is assigned, the assignment type is 'Initial'.

4. Business Model

5. Security Considerations

6. IANA Considerations

This document requires no IANA actions.

7. Acknowledgements

8. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.

9. Informative References

Hallam-Baker, P., "Mathematical Mesh: Reference Implementation", Work in Progress, Internet-Draft, draft-hallambaker-mesh-developer-10, , <>.