Mathematical Mesh 3.0 Part VI: Mesh Discovery Service

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 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 6 May 2021.¶

Copyright Notice

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.¶

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:¶

• Mesh Names are intended to be the personal property of the assignee and use of the name MUST NOT require payment of ongoing rents, fees etc. of any kind.¶
• The DNS combines the functions of name delegation and discovery of services provided under those names into a single protocol. The MNS only supports name delegation.¶

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.¶

Unambiguous

The signifier should unambiguously identify the referent.¶

Consistent

The binding between the signifier and the signified should be consistent with the reasonable expectations of the user.¶

Freehold

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.¶

3. Architecture

4. Business Model

5. Security Considerations

6. IANA Considerations

This document requires no IANA actions.¶

7. Acknowledgements