[nasr] Re: 回复: Re: Secure Routing Path Consideration- China Mobile-ietf120

["Liuchunchi(Peter)" <[e-mail]>]

>> mybe we need some addtional cases for meeting this kind of law, legal compliance?

This is not a use case I think, legal compliance is a policy driver. Use cases are business-specific scenarios that specifies clients, topology, needs and offerings. Like remote training transmission connectivity service (that prevents leakage) we discussed at this IETF.

VPN has its vulnerabilities, we discussed at the BOF too ¨C traffic analysis, deprecated crypto, ¡­

Germany TTDSG states a similar legal requirement of data sovereignty (¡°no go abroad¡±).


From: ÁõÅô»Ô <[e-mail]>
Sent: Tuesday, August 13, 2024 1:20 PM
To: Liuchunchi(Peter) <[e-mail]>
Cc: Meiling Chen <[e-mail]>; Michael Richardson <[e-mail]>; [e-mail]
Subject: Re:RE: [nasr] Re: »Ø¸´: Re: Secure Routing Path Consideration- China Mobile-ietf120


I mean beside the usecase for business secret protection, which already can be met by VPN,  mybe we need some addtional cases for meeting this kind of law, legal compliance?



Anyway, if there would be sufficient protective measures, GPDR allows for the transmission of data across borders. but we have no positive usecase for the ¡° no go abroad¡±£¬the related technology cannot evolve for long time....



At 2024-08-13 11:07:12, "Liuchunchi(Peter)" <[e-mail]<mailto:[e-mail]>> wrote:
> What is the exact significance of this demand of NASR, just meet this kind of law?......

It is for leakage prevention purposes, for both business secret protection and legal compliance considerations.


> the law may not be written in such detail, personally I think it should be the Terrestrial boundary...

By the time of lawmaking I think no technology permitting such promise was available.
By terrestrial boundary, I think meiling means it is not the ONLY factor when orchestrating a path¡ªdevice integrity and free of tampering for example is another key factor should be considered when orchestration.

PCL

From: ÁõÅô»Ô <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, August 13, 2024 10:30 AM
To: Meiling Chen <[e-mail]<mailto:[e-mail]>>
Cc: Michael Richardson <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [nasr] Re: »Ø¸´: Re: Secure Routing Path Consideration- China Mobile-ietf120


Large cloud vendors have different server regions in different countries and operate across borders, the law may not be written in such detail, personally I think it should be the Terrestrial boundary...



What is the exact significance of this demand of NASR, just meet this kind of law?......



At 2024-08-09 18:00:06, "Meiling Chen" <[e-mail]<mailto:[e-mail]>> wrote:
Indeed, after considering the example mentioned by Mic,
Terrestrial boundary is not the only determining attribute, need more properties for real no go abroad, right?

Best,
Meiling

From: Michael Richardson<mailto:[e-mail]>
Date: 2024-08-05 03:13
To: =?UTF-8?B?5YiY6bmP6L6J?=<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [nasr] Re: »Ø¸´: Re: Secure Routing Path Consideration- China Mobile-ietf120

I don't see anything in your summary of GDPR that says that encrypted PII can
not cross another territory.

At each end the GDPR clearly applies, but for example, I see nothing in your
description that prevents data from Geneva to Bern (both in Switzerland) from
travelling on fiber to the south of Lake Geneva/Leman.  That is, through
France. (is that a better route for fiber? Probably not. But a redundant
microwave link from mountain to mountain would make a lot of sense)
(Or: Zagreb to Bucharest, both EU countries, via Belgrade)
Does GDPR really apply here?

I'm sure such edicts exist, but if GDPR mandates this, it would be best to have
a very specific clause referenced.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]<mailto:[e-mail]>  http://www.sandelman.ca/        |   ruby on rails    [




[https://count.mail.163.com/beacon/webmail.gif?type=webmail_mailtrace&guid=pre_cac6aa139d88fd4620ae8fc6facaae9b]
[https://count.mail.163.com/beacon/webmail.gif?type=webmail_mailtrace&guid=pre_adbf418b320540ab18e030851aba19bf]