Re: [Blockchain-interop] New Version Notification for draft-chen-dlt-gateway-identification-00.txt

Thank Rafael for your comments.

Here are my 2-cents thoughts on your comments, also called comments on comments 😊

>isn't this still on the network layer, since it is relative to the participation on a DLN?

Yes, more preciously it is to bind a DLN to a specific blockchain gateway service/application operated by a specific BGSP.

>It looks like this corresponds to ODAP's first phase, on the gateway verification. Are we performing this on discovery + ODAP?

Except for the offline interactions, all the real-time interactions can be implemented/incorporated into ODAP's phase 1, I guess.

>I think we should add that gateways may not be DLN nodes but rather software components that connect to DLN nodes (e.g., Hyperledger Cactus ODAP plugin using a Fabric Connector).

It is subject to the value of the gateway service business and the corresponding trust requirement.

We can leave it to the BGSP to negotiate each other and configure their gateways as they agree.

>Essentially the verification comes up to trust a centralized party?

>The problem of verifying if a software component is indeed a gateway is deferred to those BGSPs, correct?

Yes, the same answer as the above, i.e. let markets/BGSPs decide which centralized certification party they trust, and what (network/hardware/software) level of certifications required for them to establish their business trust.

Cheers

-

Shiping

-----Original Message-----
From: Blockchain-interop <blockchain-interop-bounces@ietf.org> On Behalf Of Rafael Belchior
Sent: Friday, 18 June 2021 9:10 PM
To: blockchain-interop@ietf.org
Subject: Re: [Blockchain-interop] New Version Notification for draft-chen-dlt-gateway-identification-00.txt

Hello All,

Shipping, Thomas, thanks a lot for putting this together.

A few comments:

" (a) Application layer: At the application layer a gateway

    identification scheme is needed that permits an organization who

    participate in a given DLN to declare (advertise) one or more

    gateways into that DLN.  This permits organizations to establish

    peering agreements (contracts) based on the asset type, DLN and

    jurisdictions, identifying (specifying) the gateways that will be "

isn't this still on the network layer, since it is relative to the participation on a DLN?

On 4.1:

"  (iii) asset type transferability: verification that a remote gateway

    for a destination DLN is mechanically capable to receive the type of

    asset and that legally permitted to receive the type of asset.

"

It looks like this corresponds to ODAP's first phase, on the gateway verification. Are we performing this on discovery + ODAP?

On "Depending on the specific technical

    constraints of a given DLN (e.g. consensus model), not every node

    within the DLN may be designated to be a gateway capable of

    participating in an asset transfer between two DLNs.  As such, the

    service provider must nominate its nodes or systems specifically as

    gateways"

I think we should add that gateways may not be DLN nodes but rather software components that connect to DLN nodes (e.g., Hyperledger Cactus ODAP plugin using a Fabric Connector).

"   To ensure the safety of the transferred digital assets, blockchain

    gateway service providers (BGSP) must be trustworthy to clients who

    use the services.  As a result, they must meet a high standard to

    ensure security and trust at different levels, ranging from business

    to networking, from hardware device to software protocol.

"

Essentially the verification comes up to trust a centralized party?

The problem of verifying if a software component is indeed a gateway is deferred to those BGSPs, correct?

Cheers,

A 2021-06-07 22:26, Thomas Hardjono escreveu:

> Thanks Mike,

>

> RPKI is an good possibility, such as for cases when not all the

> Gateways (i.e. their IP addresses) are immediately visible from

> outside the network.

>

> Its certainly an easy way for an asset service provider (i.e. VASP) to

> declare ownership of a set of IP addresses for the gateways it owns.

>

>

> Best

>

> --thomas

>

> ________________________________________

> From: Michael McBride [mmcbride@futurewei.com]

> Sent: Monday, June 7, 2021 4:16 PM

> To: Thomas Hardjono; blockchain-interop@ietf.org<mailto:blockchain-interop@ietf.org>

> Subject: RE: New Version Notification for

> draft-chen-dlt-gateway-identification-00.txt

>

> Looks good Thomas.

>

> Since an AS/BGP will be required between gateways (correct? Or only

> when a BGSP is involved?) we can also leverage RPKI to help ensure the

> route being announced between gateways is coming from the legitimate

> route (and subsequent data) owner.

>

> mike

>

> -----Original Message-----

> From: Blockchain-interop <blockchain-interop-bounces@ietf.org<mailto:blockchain-interop-bounces@ietf.org>> On

> Behalf Of Thomas Hardjono

> Sent: Monday, June 07, 2021 7:53 AM

> To: blockchain-interop@ietf.org<mailto:blockchain-interop@ietf.org>

> Subject: [Blockchain-interop] FW: New Version Notification for

> draft-chen-dlt-gateway-identification-00.txt

>

>

> Folks,

>

> Here is a first-cut rough draft of the Gateway Identification &

> Discovery work.

>

> A couple of the diagrams are still missing, but will be added in the

> next revision.

>

> Best

>

>

> Shiping & Thomas

>

> ________________________________________

> From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [internet-drafts@ietf.org]

> Sent: Monday, June 7, 2021 10:49 AM

> To: Shiping Chen; Thomas Hardjono

> Subject: New Version Notification for

> draft-chen-dlt-gateway-identification-00.txt

>

> A new version of I-D, draft-chen-dlt-gateway-identification-00.txt

> has been successfully submitted by Thomas Hardjono and posted to the

> IETF repository.

>

> Name:           draft-chen-dlt-gateway-identification

> Revision:       00

> Title:          Gateway Identification and Discovery for Decentralized

> Ledger Networks

> Document date:  2021-06-08

> Group:          Individual Submission

> Pages:          13

> URL:

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-chen-dlt-gateway-identification-00.txt&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=0iyS9OXfeZzlemwyS2zq01YbrCsj1Y3Rtn7T8LapusM%3D&amp;reserved=0

> Status:

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-dlt-gateway-identification%2F&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=nmHNbDjw1CBAfpLzgNfRVRwOudemR7gjA5mcpDr6q28%3D&amp;reserved=0

> Htmlized:

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-chen-dlt-gateway-identification&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=1TxVwx0D6gMJJrfwtYydVD1YQJEenGVL%2BFe9%2F2Ytc7M%3D&amp;reserved=0

>

>

> Abstract:

>    Today there is a growth in the number of blockchain and

> decentralized

>    ledger networks (DLN) around the world, and interoperability across

>    different networks represents a challenge for the value proposition

>    of these networks.

>

>    One approach for blockchain interoperability to be achieved is to

>    employ gateways that permit assets to flow across the relevant

>    networks of blockchains.

>

>    However, a core requirement for interoperability is the correct

>    identification of computer systems that act as gateways and the

>    correct validation of the ownership of the gateway.  A secondary

>    requirement is for a gateway to inquire as to the existence of an

>    entity address (public key) within a given decentralized ledger

>    network.

>

>    This memo discusses options with regards gateway identification and

>    verification strategies.  It looks at addressing the problem from

> the

>    application layer and from the network layer.  It also discusses

>    other options, such as relying on a third-party

> blockchain-registered

>    identifiers and resolver services

>

>

>

>

> The IETF Secretariat

>

>

> --

> Blockchain-interop mailing list

> Blockchain-interop@ietf.org<mailto:Blockchain-interop@ietf.org>

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fblockchain-interop&amp;data=04%7C01%7Cmmcbride%40futurewei.com%7Cbd91c83d605b4c3881d508d929c3f4cb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637586743887921613%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6FtJXXNd0WfgssWVR%2F3Dc2nCXLiSUjgyo3rKeXCLvqc%3D&amp;reserved=0

--

-- Rafael Belchior

Ph.D. student in Computer Science and Engineering, Blockchain - Técnico

Lisboa

https://rafaelapb.github.io/

https://www.linkedin.com/in/rafaelpbelchior/

--

Blockchain-interop mailing list

Blockchain-interop@ietf.org<mailto:Blockchain-interop@ietf.org>

https://www.ietf.org/mailman/listinfo/blockchain-interop