Subject: [Drip] I-D Action: draft-ietf-drip-registries-00.txt

From: [email-masked]
Date: Thu, 27 Jan 2022 08:02:56 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Drone Remote ID Protocol WG of the IETF.

        Title           : DRIP Registries
        Authors         : Adam Wiethuechter
                          Stuart Card
                          Robert Moskowitz
                          Jim Reid
	Filename        : draft-ietf-drip-registries-00.txt
	Pages           : 37
	Date            : 2022-01-27

Abstract:
   This document creates the DRIP DET registration and discovery
   ecosystem.  This includes all components in the ecosystem (e.g., RAA,
   HDA, UA, GCS, USS).  The registration process will use the Extensible
   Provisioning Protocol (EPP) and other protocols.  The discovery
   process will leverage DNS and DNSSEC and related technology.  The
   DETs can be registered with as their "raw public keys" or in X.509
   certificates.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-drip-registries/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-drip-registries-00.html

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Adam Wiethuechter <[email-masked]>
Date: Thu, 27 Jan 2022 16:53:59 +0000

All,

After much delay I have finally gotten the -registries document up - sorry about that!

Things to note about this version now that it is adopted by WG:

  *   The abstract and introduction are filled in
  *   Various TODOs were also filled in for the boilerplate text items
  *   New Contributors section
  *   New auth Jim Reid (welcome!)

As Med said in a previous email this is a critical missing piece of DRIP and while the draft is not fully stable it is the best starting point we have.

I have been in discussion with Scott Hollenbeck about EPP/RDAP and he has given me some good pointers on how to specify EPP in the draft - this will probably involve some extensive reorganization of the document.

Any feedback is appreciated.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: Tm-rid <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Thursday, January 27, 2022 11:02 AM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [Drip] I-D Action: draft-ietf-drip-registries-00.txt

        Title           : DRIP Registries

Abstract:

--
Tm-rid mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tm-rid

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 27 Jan 2022 17:01:03 +0000

Just a thought: you might find it easier to create a new draft or drafts for the EPP/RDAP bits. Adding the needed info to -registries is going to inflate it a bit.

Scott

From: Tm-rid <[email-masked]> On Behalf Of Adam Wiethuechter
Sent: Thursday, January 27, 2022 11:54 AM
To: [email-masked]
Subject: [EXTERNAL] Re: [Drip] I-D Action: draft-ietf-drip-registries-00.txt

Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

All,

--------

73,

Adam T. Wiethuechter

  _____

From: Tm-rid <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, January 27, 2022 11:02 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [Drip] I-D Action: draft-ietf-drip-registries-00.txt

        Title           : DRIP Registries

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-drip-registries/<https://secure-web.cisco.com/1JENAyqfMT63opwBw0H6wrbt0Uvna4JFW6byV5uDKZNkcaC_Ia7knadBWJLsELJpIXOLoBY2ree4sifTV-MQ17QfLG5mflQp49HljquK-xgcVXxCWph8sBgGBCS_Y6UAnowujE2VNyWhXcaDWFxoVRZZPOtVzoyaleS5tkXYVTev5T14F5P_DI3fjoDM8ctBXMyDfMIYRENzYybeV54eBasxFaPt8Rt3q5Pry2HJng4xio1BJT1yXNO0YFU3KuJhjuiXVy7NT1N_AR4KjaieYMw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-drip-registries%2F>

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-drip-registries-00.html<https://secure-web.cisco.com/1mIzNtqT2dOhtb-G0J7w9kDdwBhrBePmJ_d4pvkI54FF7-ZlDRSptB-InKGdTchDCwVflS5G2jl-RdQB5jWk9Ep31dt_-VBy4WN2UnJzRL0Fod0fOU2jBDtREIqncOZyx-jiTsLzG7rAfM4Zjy7KG9a1WMNxuW7THfZC9avvVJ3sLsyEcxcpAlUwy6nMPgMmDRhoNptOUB-soSvg9QTds1yCK4ucGxdsy8Si_3jhO61eUjKJBYnXNyBerieuSKGm6ulps7oMiu5fhw7ZVzWjDDQ/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-drip-registries-00.html>

--
Tm-rid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tm-rid<https://secure-web.cisco.com/1hXEJoAo0DoWBAFX6IGsx7n7hqsxLQ5i4TWAx3TNGDdbVTdaPZ2Drzb7e1dGZC5WCYVBLlGbA3bVu-C0LJEZ0Xqromzcw6U2y_9vKln3WGvzC-7L2l_iljHRCRChPAyfkcWcvdweEQpgcaKVLfw6MMEiZTnyeaWZxO5wAvEIlfOgC79WmSY52mM8sBOHG2PjbQlrcqKeBPwCxMKMEPvmsBTU0fhKRvOk1Ult7ypCrf62iCY2DWJTJo07dObTgrzwex1mfKtRYF-twtXtdmufAjg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftm-rid>

---

From: Andrei Gurtov <[email-masked]>
Date: Fri, 28 Jan 2022 13:39:50 +0100

Hej,

Here is some input to the draft as suggested by WG chairs

Blockchain-based registry

The implementation of the registries and Network Remote Identification
(Network RID; identify a UA through the network) in DRIP
is yet to be determined. Blockchain, being synonymous with ledger,
is a technology that could naturally fulfil the role of a registry, while
simultaneously offering its benefits such as auditability, persistency
and decentralization. We suggest that blockchain is an
ample candidate to be used as registry within DRIP. We also show
that it can be used to effectively leverage Network RID in certain
scenarios. Thus 1) We propose a novel drone ID architecture based on 
Hyperledger
Iroha and describe its proof-of-concept implementation with DRIP.
2) Its performance and scalability is empirically evaluated. 3) We
perform an informal security analysis of the system against various
types of attacks [ref].

Figure 1: Architecture using blockchain as registry for DRIP

The proposed architecture is presented in Fig. 1. It consists of the
usual actors in a UAS network, along with the blockchain registry
based on Hyperledger Iroha. Key components:
• Authorized users (administrators) can register new UAs to
the network, and store with them any relevant data such as
public keys and certificates.

Drones can either send location updates directly to the blockchain,
given that they are connected to the Internet, or send location
updates to their connected Ground Control Station (GCS)
that forwards it on behalf of the drones.
• Observers can receive drone messages either through bluetooth
and WiFi broadcasts from drones, or by polling the
blockchain. They can also fetch the public key associated
with a drone in order to validate its messages.
• The blockchain network and its nodes are an entirely separate
entity, no other actor participates in the consensus of
new blocks.

Actors within DRIP (except observers) will be registered as accounts
on the blockchain network. Each of these accounts will have their
DRIP identities, certificates and public keys stored and available so
that they can be validated and used for validation by any account
on the blockchain. Note that DRIP crypto key-pairs are separate
from the blockchain crypto key-pairs. DRIP key-pairs are used to
sign, verify and validate DRIP identities and messages, while the
blockchain key-pairs are used to sign, verify and validate transactions
on the blockchain.

The DRIP requirements for a registry are the following:
(1) REG-1: Public lookup
(2) REG-2: Private lookup
(3) REG-3: Provisioning (of static/dynamic data of UAs)
(4) REG-4: AAA Policy

REG-1 & REG-2. In Hyperledger Iroha, accounts are created
on domains. The same account name can be used for multiple domains,
and these are seen as separate accounts on Iroha. PII for
an account can therefore be stored on a separate account (with
the same account name) existing on a separate domain, that only
allows certain accounts to view its account details. Accordingly, a
registry using Iroha would need at least two domains associated
with it for any given account, one for public lookup and one for
private lookup.

REG-3 & REG-4. The details for an account are set with a
key/value pair. Key/value pairs can not be removed once they are
set, values can only be modified through the corresponding key.
Furthermore, the account that sets a key/value pair is included in
the account details as a key/value pair itself, meaning one account
can not modify details set by another account. See Listing 1 for
clarification. Notice that both accounts have set the same key but
contain different values. This sort of implementation supports both
non-repudiation, but also trust in the sense that a drone (assuming
the drone is not compromised) can always trust its own data, and
does not have to interpret data coming from other accounts. Similarly,
other accounts accessing another account’s data can trust
that it is set by the corresponding account (e.g. fetching gps data).

[ref] Yousef Hashem, Elmedin Zildzic, and Andrei Gurtov. 2021. Secure Drone Identification with Hyperledger Iroha./Proceedings of the 11th ACM Symposium on Design and Analysis of 
Intelligent Vehicular Networks and Applications/. Association for Computing Machinery, New York, NY, USA, 11–18. DOI:https://doi.org/10.1145/3479243.3487305

More details to come...

br Andrei

On 2022-01-27 17:53, Adam Wiethuechter wrote:
> As Med said in a previous email this is a critical missing piece of 
> DRIP and while the draft is not fully stable it is the best starting 
> point we have.
>
> I have been in discussion with Scott Hollenbeck about EPP/RDAP and he 
> has given me some good pointers on how to specify EPP in the draft - 
> this will probably involve some extensive reorganization of the document.
>
> ------------------------------------------------------------------------
> *From:* Tm-rid <[email-masked]> on behalf of 
> [email-masked] <[email-masked]>
> *Sent:* Thursday, January 27, 2022 11:02 AM
> *To:* [email-masked] <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>
> *Subject:* [Drip] I-D Action: draft-ietf-drip-registries-00.txt
>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-drip-registries%2F&data=04%7C01%7Candrei.gurtov%40liu.se%7C98a84ab0f082484e41eb08d9e1b5a4b6%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637788993417354344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=h1oazyV9cBJI9cDdLLWgjsBo57kHSZcDCeD4G%2FAypj0%3D&reserved=0>
>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-drip-registries-00.html&data=04%7C01%7Candrei.gurtov%40liu.se%7C98a84ab0f082484e41eb08d9e1b5a4b6%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637788993417354344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=690WrTvX54cUmSen6xK6nX7ADY1REEZRGTSD%2Fl0k%2B28%3D&reserved=0>
>
>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftm-rid&data=04%7C01%7Candrei.gurtov%40liu.se%7C98a84ab0f082484e41eb08d9e1b5a4b6%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637788993417354344%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9aezawV4UAv%2FAXUyEgairx9OddKHI4sv%2FCT7tFayyTY%3D&reserved=0>
>

---

From: "Card, Stu" <[email-masked]>
Date: Fri, 28 Jan 2022 10:57:42 -0500

I wonder what is the appropriate way to lay out Distributed Ledger
Technology (DLT, inc. blockchains & smart contracts) as _one way_ to
implement DRIP registries, w/o specifying that as the exclusive approach in
this standards track document?

On Fri, Jan 28, 2022 at 7:40 AM Andrei Gurtov <[email-masked]> wrote:

> [ref] Yousef Hashem, Elmedin Zildzic, and Andrei Gurtov. 2021. Secure Drone Identification with Hyperledger Iroha. *Proceedings of the 11th ACM Symposium on Design and Analysis of Intelligent Vehicular Networks and Applications*. Association for Computing Machinery, New York, NY, USA, 11–18. DOI:https://doi.org/10.1145/3479243.3487305
>
>
> More details to come...
>
>
> br Andrei
>
>
>    - The abstract and introduction are filled in
>    - Various TODOs were also filled in for the boilerplate text items
>    - New Contributors section
>    - New auth Jim Reid (welcome!)
>
> As Med said in a previous email this is a critical missing piece of DRIP
> and while the draft is not fully stable it is the best starting point we
> have.
>
> I have been in discussion with Scott Hollenbeck about EPP/RDAP and he has
> given me some good pointers on how to specify EPP in the draft - this will
> probably involve some extensive reorganization of the document.
>
> ------------------------------
> *From:* Tm-rid <[email-masked]> <[email-masked]> on
> behalf of [email-masked] <[email-masked]>
> <[email-masked]>
> <[email-masked]>
> *Cc:* [email-masked] <[email-masked]> <[email-masked]>

---

From: Andrei Gurtov <[email-masked]>
Date: Fri, 28 Jan 2022 19:17:30 +0100

Well, it should not be exclusive, along with methods like DNS, ICAO PKI, 
DHT, Amazon Dynamo and similar storage services... the important thing 
is to keep record formats standardized so storage systems are interoperable.

br Andrei

On 28-Jan-22 16:57, Card, Stu wrote:
> implement DRIP registries, w/o specifying that as the exclusive 
> approach in this standards track document?
>
>
>     scenarios. Thus 1) We propose a novel drone ID architecture based
>     on Hyperledger
>     Intelligent Vehicular Networks and Applications/. Association for Computing Machinery, New York, NY, USA, 11–18. DOI:https://doi.org/10.1145/3479243.3487305  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1145%2F3479243.3487305&data=04%7C01%7Candrei.gurtov%40liu.se%7Cd874ec4011114a7bbc7c08d9e276f063%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637789823915179147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wLUaHKCsllUgR5ikuetk7q%2FkJj1%2BgZYa%2BpTtjhAR06E%3D&reserved=0>
>
>
>     More details to come...
>
>
>     br Andrei
>
>
>>     As Med said in a previous email this is a critical missing piece
>>     of DRIP and while the draft is not fully stable it is the best
>>     starting point we have.
>>
>>     I have been in discussion with Scott Hollenbeck about EPP/RDAP
>>     and he has given me some good pointers on how to specify EPP in
>>     the draft - this will probably involve some extensive
>>     reorganization of the document.
>>
>>     *From:* Tm-rid <[email-masked]>
>>     <mailto:[email-masked]> on behalf of
>>     <mailto:[email-masked]>
>>     <mailto:[email-masked]>
>>     *Cc:* [email-masked] <[email-masked]> <mailto:[email-masked]>
>>     <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-drip-registries%2F&data=04%7C01%7Candrei.gurtov%40liu.se%7Cd874ec4011114a7bbc7c08d9e276f063%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637789823915335375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Fzu6A%2FrBVj0Lu9EUQc%2B2CZ6ueNv%2BTskOZtKtU6G0reU%3D&reserved=0>
>>
>>     <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-drip-registries-00.html&data=04%7C01%7Candrei.gurtov%40liu.se%7Cd874ec4011114a7bbc7c08d9e276f063%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637789823915335375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jljJDpf6%2BWoAu2m6n6VIeCzMpuxuIEX7f%2BOotT6wVow%3D&reserved=0>
>>
>>
>>     <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftm-rid&data=04%7C01%7Candrei.gurtov%40liu.se%7Cd874ec4011114a7bbc7c08d9e276f063%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637789823915335375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=j9M5gOfaYNBAWXGCDTQoraRX4106jc08awQGVdfoZq4%3D&reserved=0>
>>
>     -- 
>     Tm-rid mailing list
>     [email-masked]
>     <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftm-rid&data=04%7C01%7Candrei.gurtov%40liu.se%7Cd874ec4011114a7bbc7c08d9e276f063%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637789823915335375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=j9M5gOfaYNBAWXGCDTQoraRX4106jc08awQGVdfoZq4%3D&reserved=0>
>

---

From: Adam Wiethuechter <[email-masked]>
Date: Fri, 28 Jan 2022 21:32:39 +0000

This lines up with what Scott was saying and having EPP/RDAP in separate documents.

But then what does this document become? Just the generic; here is what DNS looks like and here is what databases should contain and rules for how they are managed? Would it be like a Chinese menu of sorts where you pick and choose your methods (EPP/RDAP, DLT, etc. all in different drafts with a select few being marked as required for interop) and they give more specific details as to how?

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: Andrei Gurtov <[email-masked]>
Sent: Friday, January 28, 2022 1:17 PM
To: Card, Stu <[email-masked]>
Cc: Adam Wiethuechter <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Drip] I-D Action: draft-ietf-drip-registries-00.txt

Well, it should not be exclusive, along with methods like DNS, ICAO PKI, DHT, Amazon Dynamo and similar storage services... the important thing is to keep record formats standardized so storage systems are interoperable.

br Andrei

On 28-Jan-22 16:57, Card, Stu wrote:
I wonder what is the appropriate way to lay out Distributed Ledger Technology (DLT, inc. blockchains & smart contracts) as _one way_ to implement DRIP registries, w/o specifying that as the exclusive approach in this standards track document?

On Fri, Jan 28, 2022 at 7:40 AM Andrei Gurtov <[email-masked]<mailto:[email-masked]>> wrote:

Hej,

scenarios. Thus 1) We propose a novel drone ID architecture based on Hyperledger

[ref] Yousef Hashem, Elmedin Zildzic, and Andrei Gurtov. 2021. Secure Drone Identification with Hyperledger Iroha. Proceedings of the 11th ACM Symposium on Design and Analysis of Intelligent Vehicular Networks and Applications. Association for Computing Machinery, New York, NY, USA, 11–18. DOI:https://doi.org/10.1145/3479243.3487305<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1145%2F3479243.3487305&data=04%7C01%7Candrei.gurtov%40liu.se%7Cd874ec4011114a7bbc7c08d9e276f063%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637789823915179147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wLUaHKCsllUgR5ikuetk7q%2FkJj1%2BgZYa%2BpTtjhAR06E%3D&reserved=0>

More details to come...

br Andrei

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: Tm-rid <[email-masked]><mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Sent: Thursday, January 27, 2022 11:02 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [Drip] I-D Action: draft-ietf-drip-registries-00.txt

        Title           : DRIP Registries

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-drip-registries/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-drip-registries%2F&data=04%7C01%7Candrei.gurtov%40liu.se%7Cd874ec4011114a7bbc7c08d9e276f063%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637789823915335375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Fzu6A%2FrBVj0Lu9EUQc%2B2CZ6ueNv%2BTskOZtKtU6G0reU%3D&reserved=0>

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-drip-registries-00.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-drip-registries-00.html&data=04%7C01%7Candrei.gurtov%40liu.se%7Cd874ec4011114a7bbc7c08d9e276f063%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637789823915335375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jljJDpf6%2BWoAu2m6n6VIeCzMpuxuIEX7f%2BOotT6wVow%3D&reserved=0>

--
Tm-rid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tm-rid<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftm-rid&data=04%7C01%7Candrei.gurtov%40liu.se%7Cd874ec4011114a7bbc7c08d9e276f063%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637789823915335375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=j9M5gOfaYNBAWXGCDTQoraRX4106jc08awQGVdfoZq4%3D&reserved=0>

--
Tm-rid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tm-rid<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftm-rid&data=04%7C01%7Candrei.gurtov%40liu.se%7Cd874ec4011114a7bbc7c08d9e276f063%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637789823915335375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=j9M5gOfaYNBAWXGCDTQoraRX4106jc08awQGVdfoZq4%3D&reserved=0>

---

From: Andrei Gurtov <[email-masked]>
Date: Sat, 29 Jan 2022 18:07:15 +0100

Hi,

We can have a separate section in the end of the draft or an appendix to 
list potential implementation approaches.

I think implementors of standard track documents love to see some 
examples how it is done in practice. Also different systems can put 
restrictions e.g. on record format or length.

Having this as a separate individual submission would probably bury it, 
as those drafts are very slow to progress compared to WG docs.

Actually, I thought there was WG consensus to include this already in 
drip-registries-00.txt submissions as suggested by WG chairs.

br Andrei

On 28-Jan-22 22:32, Adam Wiethuechter wrote:
> But then what does this document become? Just the generic; here is 
> what DNS looks like and here is what databases should contain and 
> rules for how they are managed? Would it be like a Chinese menu of 
> sorts where you pick and choose your methods (EPP/RDAP, DLT, etc. all 
> in different drafts with a select few being marked as required for 
> interop) and they give more specific details as to how?
>
> --------
> 73,
> Adam T. Wiethuechter
> *From:* Andrei Gurtov <[email-masked]>
> *Sent:* Friday, January 28, 2022 1:17 PM
> *To:* Card, Stu <[email-masked]>
> *Cc:* Adam Wiethuechter <[email-masked]>; 
> [email-masked] <[email-masked]>
> *Subject:* Re: [Drip] I-D Action: draft-ietf-drip-registries-00.txt
>
> Well, it should not be exclusive, along with methods like DNS, ICAO 
> PKI, DHT, Amazon Dynamo and similar storage services... the important 
> thing is to keep record formats standardized so storage systems are 
> interoperable.
>
> br Andrei
>
>>     Intelligent Vehicular Networks and Applications/. Association for Computing Machinery, New York, NY, USA, 11–18. DOI:https://doi.org/10.1145/3479243.3487305  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1145%2F3479243.3487305&data=04%7C01%7Candrei.gurtov%40liu.se%7Cc062f430f43342d6039608d9e2a5b94b%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637790024595444280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=BQcudwbzQbLUdhql5YxKMSNnh8X9jeVdTk0IHKyHq1o%3D&reserved=0>
>>
>>
>>     More details to come...
>>
>>
>>     br Andrei
>>
>>
>>>     [email-masked] <mailto:[email-masked]>
>>>     <[email-masked]> <mailto:[email-masked]>
>>>     *To:* [email-masked] <mailto:[email-masked]>
>>>     <[email-masked]> <mailto:[email-masked]>
>>>     *Cc:* [email-masked] <mailto:[email-masked]> <[email-masked]>
>>>     <mailto:[email-masked]>
>>>     <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-drip-registries%2F&data=04%7C01%7Candrei.gurtov%40liu.se%7Cc062f430f43342d6039608d9e2a5b94b%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637790024595444280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ouo8AqgH3rN5F4YFVRoxCtEq6ZUArod41xRJ5W%2ByN%2FE%3D&reserved=0>
>>>
>>>     <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-drip-registries-00.html&data=04%7C01%7Candrei.gurtov%40liu.se%7Cc062f430f43342d6039608d9e2a5b94b%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637790024595444280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=la9schFi6uElfIjdd7bUiEDeOK%2FyT6cQrGlgcCmI86Q%3D&reserved=0>
>>>
>>>
>>>     [email-masked] <mailto:[email-masked]>
>>>     <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftm-rid&data=04%7C01%7Candrei.gurtov%40liu.se%7Cc062f430f43342d6039608d9e2a5b94b%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637790024595444280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=akdY4R2Pj24ljBPDvKeW%2BW%2BZD5lA8T1lY5FgPqegNiI%3D&reserved=0>
>>>
>>     -- 
>>     Tm-rid mailing list
>>     [email-masked] <mailto:[email-masked]>
>>     <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftm-rid&data=04%7C01%7Candrei.gurtov%40liu.se%7Cc062f430f43342d6039608d9e2a5b94b%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637790024595444280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=akdY4R2Pj24ljBPDvKeW%2BW%2BZD5lA8T1lY5FgPqegNiI%3D&reserved=0>
>>