Re: [Drip] New Version Notification for draft-ietf-drip-arch-21.txt

[[e-mail]]

Hi Bob, Shuai, all,

What about proceeding with this change:

OLD:
   Further, gateways with additional sensors (e.g., smartphones with
   cameras) can provide independent information on the UA type and size,
   confirming or refuting those claims made in the UAS RID messages.
   This Crowd Sourced Remote ID (CS-RID) would be a significant
   enhancement, beyond baseline DRIP functionality; if implemented, it
   adds two more entity types.

NEW:
   Further, gateways with additional sensors (e.g., smartphones with
   cameras) can provide independent information on the UA type and size,
   confirming or refuting those claims made in the UAS RID messages.

   Sections 6.1 and 6.2 define two additional entities that are required
   to provide this Crowd Sourced Remote ID (CS-RID).

I suggest to also make the following changes:


* s/One obvious opportunity/One opportunity

* s/a TBD interface to a CS-RID SDSP/a new interface to a CS-RID SDSP

Thank you.

Cheers,
Med

De : Robert Moskowitz <[e-mail]>
Envoyé : dimanche 13 mars 2022 02:43
À : Card, Stu <[e-mail]>
Cc : shuai zhao <shuai.zhao=[e-mail]>rg>; [e-mail]; Robert Moskowitz <[e-mail]>om>; Adam Wiethuechter <[e-mail]>om>; Laura Welch <[e-mail]>om>; Andrei Gurtov <[e-mail]>rg>; Eric Vyncke (evyncke) <[e-mail]>om>; BOUCADAIR Mohamed INNOV/NET <[e-mail]>om>; Daniel Migault <[e-mail]>
Objet : Re: [Drip] New Version Notification for draft-ietf-drip-arch-21.txt


On 3/11/22 19:01, Card, Stu wrote:
I was referring to 7.1 Finders & 7.2 CS-RID SDSP.

I did not think I caught that....



SDSP (generically) is a term listed in the RFC 9153 glossary but CS-RID SDSP is introduced in -arch.

So a "see below" would be sufficient.


Non-participating UA are indeed entities but they have no _protocol_ interactions in DRIP.

Good point so they do not, as such, belong in arch.




On Fri, Mar 11, 2022, 08:16 Robert Moskowitz <[e-mail]<mailto:[e-mail]>> wrote:

On 3/10/22 15:08, shuai zhao wrote:

Dear DRIP,



Thanks AD’s detailed review to help us produce a solid draft.



Arch-21 addresses more than 30+ comments. Many thanks to co-author’s dedication.  Also, great appreciation for Laura’s help for text improvement.



See inline confirmations (SZ/)  regarding which comments have been addressed in 21.



There are only two items left which need a bit more explanations. @[e-mail]<mailto:[e-mail]>



1.       Sec 7 " it adds two more entity types." Which ones ?

SZ/ @[e-mail]<mailto:[e-mail]> Please specify.

I don't think these are the exact words I used on whatever comment, but that is probably not important.

Actually 3 entity types:

Entity 1:

Finders

Entity 2:

Although 9153 does define SDSP, it is not in the DRIP architecture.  CS-RID specifically defines a SDSP that correlates the harvested information, performs multilateration when possible and feeds the information into the UTM.

Entity 3:

The second is non-broadcasting UA discovered by 'visual' harvesting (via camera, LIDAR, etc.).


So the added entity types are:  SPDP and non-RID UA.

So how to say that here.


... it adds the following entity types:

*   Remote ID Finders
*   A Supplemental Data Service Provider (SDSP) to correlate UA observations and forward to UTM.
*   non-RID UA or "hidden" UA.






2.       Sec 10 is very light and mainly focus on the private keys except for the false flag issue (which deserves its own paragraph). Nothing is said about privacy

SZ/ Does it mean we should remove this section? @[e-mail]<mailto:[e-mail]> anything new you can add?

I missed this.  I could have added more, basically lifting text from drip-rid.  Let's see what I might do here and not open a whole can of worms for review and comments.

================

The security provided by asymmetric cryptographic techniques depends
upon protection of the private keys.  It may be necessary for the GCS
to have the key pair to register the HHIT to the USS.  Thus it may be the GCS
that generates the key pair and delivers it to the UA, making the GCS a part of
the key security boundary.  Leakage of the private key either from the UA or GCS
to the component manufacturer is a valid concern and steps need to be in
place to ensure safe keeping of the private key.

The size of the public key hash in the HHIT is also of concern.  It is well within
current server array technology to compute another key pair that hashes to the
same HHIT.  Thus an adversary could impersonate a validly registered UA.
This attack would only be exposed when the HI in DRIP authentication message
is checked back to the USS and found not to match.

Finally, the RID sender of a small harmless UA (or the entire UA) could be carried
by a larger dangerous UA as a "false flag."  Compromise of a registry private key
could do widespread harm.  Key revocation procedures are as yet to be
determined.  These risks are in addition to those involving Operator
key management practices.

============================

There is probably more I can extract from drip-rid security considerations, but this may be enough for the highlights here.







Best,

Shuai





-----Original Message-----

From: "Eric Vyncke (evyncke)" <[e-mail]><mailto:&lt;[e-mail]&gt;>

Date: Wednesday, February 2, 2022 at 02:42

To: "Stuart W. Card" <[e-mail]><mailto:&lt;[e-mail]&gt;>om>, "[e-mail]"<mailto:&quot;[e-mail]&quot;> <[e-mail]><mailto:&lt;[e-mail]&gt;>

Cc: "[e-mail]"<mailto:&quot;[e-mail]&quot;> <[e-mail]><mailto:&lt;[e-mail]&gt;>om>, "[e-mail]"<mailto:&quot;[e-mail]&quot;> <[e-mail]><mailto:&lt;[e-mail]&gt;>om>, "shuaiizhao(Shuai Zhao)" <[e-mail]><mailto:&lt;[e-mail]&gt;>om>, "[e-mail]"<mailto:&quot;[e-mail]&quot;> <[e-mail]><mailto:&lt;[e-mail]&gt;>

Subject: [Internet]Re: [Drip] AD review for draft-ietf-drip-arch-20



    Hello Stu, and thanks for your quick reply.



    Elided the text where we agree, and comments added with EV>



    Regards



    -éric



    On 02/02/2022, 04:37, "Stuart W. Card" <[e-mail]><mailto:&lt;[e-mail]&gt;> wrote:



        Thanks Eric!



        I agree with 90% of what you have written, and thanks for catching not

        only several nits but also several areas where we were unclear.



        It won't surprise you that I'll offer friendly rebuttal on a few points

        as well as answers to a few questions.



    EV> it was expected and happy to read them



       Abstract: try to add RFC 9153 after the "requirements document" else put I-D.ietf-drip-reqs



SZ/ Added RFC9153 as a normative reference.  Or is it okay to change all reference from "I-D.ietf-drip-reqs" to "RFC 9153" since RFC9153 is published? @Eric Vyncke (evyncke)

SZ/ -21 has addressed this issue. Consider this is closed.



        On 2/1/2022 11:29 AM, Eric Vyncke (evyncke) wrote:

        > ...

        > Sec 1: s/Unmanned Aircraft System Remote Identification and tracking

        > (UAS RID)/ Unmanned Aircraft System (UAS) Remote Identification (RID)/

        > to be consistent with the title of section 1.1



        The acronym UAS RID really does expand with "and tracking" in most of

        the key documents, including the original Aviation Rulemaking Committee

        final report (on which almost everyone based their subsequent efforts)

        and ASTM F3411.



    EV> feel free to keep "and tracking"; my point was rather to introduce UAS and RID acronyms just after their expansion, not globally



SZ/ agreed with @Eric Vyncke (evyncke), added as recommended.

SZ/ -21 has addressed this issue. Consider this is closed.





       Sec 1.1: prefix "FAA" with "USA-based" ?



SZ/ I Don’t think that is necessary. Not like EASA that Europe comes with its acronym. FAA should be well-known to person who is in aerospace domain. Let me know what others option and we can definitely emphasis on that.

SZ/ -21 has addressed this issue. Consider this is closed.





       Sec 1.1: the use of "commercial" is usually understand as for consumer (i.e., recreative use) while I afraid that here it is more for commercial aviation activities as opposed to recreative ones. Worth clarifying or using a different word than commercial



SZ/ I understood the question. However here we pretty much copy/paste from FAA final rule. In FAA document, the definition of commercial, non-commercial, amateur-build UAS and recreational are not well defined. I would suggest we keep the FAA languages.

SZ/ -21 has addressed this issue. Consider this is closed.



        > ...

        > Sec 1.2.1 is it "received UAS ID" or "received UAS RID" ? If "ID", is it

        > worth explaining why "ID" is used here?



        RID is the _process_, not the identity, not the identifier. In F3411,

        the identifier is the "UAS ID".



    EV> fair point, the difference is clear in the -reqs document. Now, I wonder whether the reader would benefit from a repetition of the definitions of ID vs. RID in this document. Perhaps in § 3.3 ?



SZ/ I suggest adding the following clarification in 1.1. Since that is where arch- starts to introduce some more details about RID, not the ID itself.

SZ/ -21 has addressed this issue. Consider this is closed.





Currently

"

1.1.  Overview of Unmanned Aircraft System (UAS) Remote ID (RID) and

      Standardization



   UAS Remote Identification (RID) is an application enabler for a UAS

   to be identified by Unmanned Aircraft Systems Traffic Management

   (UTM) and UAS Service Supplier (USS) (Appendix A) or third parties

   entities such as law enforcement.  Many considerations (e.g., safety)

   dictate that UAS be remotely identifiable.

"



Suggested changes

"

1.1.  Overview of Unmanned Aircraft System (UAS) Remote ID (RID) and

      Standardization



   UAS Remote Identification (RID) is an application enabler which consists of UAS ID verification process for a UAS

   to be identified by Unmanned Aircraft Systems Traffic Management

   (UTM) and UAS Service Supplier (USS) (Appendix A) or third parties

   entities such as law enforcement.  Many considerations (e.g., safety)

   dictate that UAS be remotely identifiable.

"



        Sec 1.2.1 please expand LOS at first use in " RF LOS" (perhaps also expand "RF") at the expanse of readability



SZ/ updated in -21.

SZ/ -21 has addressed this issue. Consider this is closed.





        Sec 1.2.1 " link based ID" same question about "ID" vs. "RID" (there should also be a '-' as in "link-based")



SZ/ updated to "link-based".  Later comments regarding not using RID/ID alone should clarify

SZ/ -21 has addressed this issue. Consider this is closed.





        Sec 1.2.2 " GNSS" expand at first use

SZ/ updated to "e.g. their respective Global Navigation Satellite System (GNSS) derived locations."

SZ/ -21 has addressed this issue. Consider this is closed.





        Sec 1.2.2 add a note somewhere about the "4-D airspace" as not everyone is aware of the change of rules based on time of the day



SZ/ @Card, Stu, I am looking for input from you about this comment.  "4-D" was defined in RFC9153, should we repeat the definition here? So maybe I did not understand Eric's concern.

SZ/ -21 has addressed this issue. Consider this is closed.





        Sec 1.2.2 increment the year in " currently (in the year of 2021)"



SZ/ Make sense to me.  Updated to 2022

SZ/ -21 has addressed this issue. Consider this is closed.





        > ...

        > Section 1.2: this section appears as FAA-only. While this is not too

        > good for the IETF, this could be OK but the document must be clear that

        > section 1.2 is the US FAA position, not a global one.



        It was based on F3411 and intended to be generic. Indeed, FAA does not

        yet permit Network RID as a means of compliance with its RID rule. Is

        there something specific here that conflicts with a European or other

        non-US concept?



    EV> my concern is about the applicability of an IETF document, which needs to be defined. May I suggest to add some pre-amble in sec 1.2 stating that the following sub-sections are applicable / related to F3411 ? The title of section 1.2 could also include F3411 to be clear about its applicability.



SZ/ How about changing the title of section 1.2, from "Overview of Types of UAS Remote ID" to "Overview of Types of UAS Remote ID from FAA"

SZ/ -21 has addressed this issue. Consider this is closed.





         Sec 3: I would move this section as a sub-section of 1.2.2



SZ/ I assume Eric meant section 1.3 here, not Section 3.  So, if it is Section 1.3, I have no issues of moving it under section 1.2, since the assumption of Section 1.3 is under the network RID.



SZ/ -21 has addressed this issue. Consider this is closed.



         Sec 1.4 is " general UAS RID usage scenario" really general ? I.e., is it applicable outside of US FAA/CA CAA ?



SZ/ I believe that’s what we think DRIP architecture should look like. Should be change the sentence from " general UAS RID usage scenario "  to " DRIP UAS RID usage scenario"? @Card, Stu?

 SZ/ -21 has addressed this issue. Consider this is closed.





         Sec 1.4: please expand V2I, V2V, and DAA



SZ/ updated the following definitions for Figure 4 and removed "(for brevity in this figure)".



"

DAA:  Detect And Avoid

GPOD: General Public Observer Device

PSOD: Public Safety Observer Device

V2I:  Vehicle-to-Infrastructure

V2V:  Vehicle-to-Vehicle

"

SZ/ -21 has addressed this issue. Consider this is closed.



        > ...

        > Sec 3.1: why only crypto abbreviations ? There are so many aeronautical

        > acronyms that they should be there as well and this § 3.1 should be

        > moved ahead just after §1 (assuming that §1.1 and others become

        > top-level sections)



        We weren't focusing specifically on crypto, but listed only those

        acronyms that weren't defined in -reqs, which is the DRIP terminology

        reference.



    EV> text of sec 3.3 should then be included in this section for consistency



SZ/ I think its fine to move current section 3 "Terms and Definitions" up to section 2, which is what I have done in -21. Please let me know if that is going to be an issue for you all. I have also added " This document uses terms defined in [I-D.ietf-drip-reqs]." At the beginning of abbreviation to address Eric's comment.

SZ/ -21 has addressed this issue. Consider this is closed.





        Sec 3.2 add reference to HIP



SZ/ I am not sure section 3.2 is the right place to add HIP reference since HIP was not even mentioned.  The place where we should is in section 4.



" It justifies and explains the use of Hierarchical Host Identity Tags  (HHITs) [RFC7401] as self-asserting IPv6 addresses suitable as a UAS ID type  and more generally as trustworthy multipurpose remote identifiers."

SZ/ -21 has addressed this issue. Consider this is closed.





         Sec 4: please specify that this section is only applicable to US FAA (if so)



SZ/ I don’t have a clear answer for that. I am assuming the design of DRIP RID is for "general" purpose, which is not only for FAA-based RID. @Card, Stu?

SZ/ -21 has addressed this issue. Consider this is closed.





         Sec 4 at multiple places, the text is rather dense and dry, could there be some figures to help understanding ?



 SZ/ rewriting each of the sentence in this section might be tough. It might be better to point out which part needs some tuning/figures.



        Sec 4.1: the last paragraph is a single sentence of 7 lines...Please consider rewriting in an easier to read paragraph.

SZ/ updated as following:

" Likewise, the maximum ASTM RID {{F3411}} Authentication Message payload is 201 bytes for most authentication types. A type 5 is also added in this revision for IETF and other SDOs to develop Specific Authentication Methods as extensions to ASTM RID. One byte out of 201 bytes is consumed to index the sub-type which leaves only 200 for DRIP authentication payloads, including one or more DRIP entity identifiers and associated authentication data."

SZ/ -21 has addressed this issue. Consider this is closed.





        > ...

        > Sec 4.2: what is the difference between "RID" "Remote ID" and "ID" ?

        > please try to use a consistent vocabulary. Same later for "cryptographic ID"



        I'm not sure we were consistent. What we should be doing:

          "RID" never used alone

          "UAS RID" ::= "Unmanned Aircraft System[s] Remote Identification and

        tracking"

          "ID" never used alone

          "UAS ID" ::= "Unmanned Aircraft System Identifier"



    EV> happy if the document is reviewed to ensure that "ID" and "RID" are never used alone.



SZ/ based current comments, I think we agree to replace all "RID" with "UAS RID", "ID" with "UAS ID", right?  There are some places such as Net-RID, I don’t think we need to replace those right?

Currently in -21, I have done all the replacement, but I need second eyes to make sure all replacements are done correctly.

SZ/ -21 has addressed this issue. Consider this is closed.



        Sec 4.2: unsure whether "HI" was defined before



SZ/  It was expanded in its first usage for sure. Bu in -21, I also add "HI" in "abbreviations" section for completeness.

SZ/ -21 has addressed this issue. Consider this is closed.



       Sec 4.2: I cannot parse " This is in contrast to general IDs (...) as the subject in an X.509 certificate."

SZ/ @Robert Moskowitz@Robert Moskowitz I will need Bob's help here.



      Sec 4.2: " by avoiding an explicit encoding technology like ASN.1 or CBOR", so what encoding should be used ?

SZ/ @Robert Moskowitz@Robert Moskowitz Needs Bob's input.



        > ...

        > Sec 4.4: what is the meaning of "extant" ?



        "still in existence" which is probably not what we want here. Bob?



    EV> learned a new word, suggest using simple wording ;-)



SZ/ updated to "existing", let me know everyone knows a better word for replacement.  Or "obvious" or.......

SZ/ -21 has addressed this issue. Consider this is closed.



        > ...

        > Sec 5: what are "public and private UAS information" ? The different

        > types of info were not defined earlier in the document or provide a

        > forward reference to sec 5.1 & 5.2



        We should cite the definition in -reqs PRIV-1 "private information

        (i.e., any and all information designated by neither cognizant authority

        nor the information owner as public, e.g., personal data)."



    EV> indeed, easier for the reader

SZ/ Updated as " DRIP registries hold both public and private UAS information (See PRIV-1 in {{I-D.ietf-drip-reqs}}) resulting from the DRIP identifier registration process."

SZ/ -21 has addressed this issue. Consider this is closed.



       Sec 5.1.1 s/ public registry/ public information registry/



SZ/ Updated.

SZ/ -21 has addressed this issue. Consider this is closed.



        > ...

        > Sec 5.1.1 should "opaque" be used rather than "silent" in "they may be

        > silent to the Observer" ?



        What was meant was that an Observer might actually _see_ (with eyes) an

        aircraft, and if it was participating in RID, but Network RID only, not

        Broadcast, the Observer would not _receive_ any RID messages, instead

        would have to query a Net-RID DP for any aircraft in the vicinity.



    EV> then indeed 'opaque' is the wrong word but I am not sure that 'silent' is better. No proposal of mine though :(



SZ/ @Card, Stu, what is your final word choice? __

SZ/ -21 has addressed this issue. Consider this is closed.





      Sec 5.1.2 after reading this §, it is still unclear to me what are the private information...

SZ/ Do you mean section 5.2?  If it is 5.2, I updated the first paragraph of section 5 as Stu suggest above: " DRIP registries hold both public and private UAS information (See PRIV-1 in {{I-D.ietf-drip-reqs}}) resulting from the DRIP identifier registration process.". Does it solve the confusion?



        > ...

        > Sec 6: I was unable to find a definition of "trustworthiness" in

        > [I-D.ietf-drip-reqs]



        You got me. :-) We use the word in -reqs section 12 on page 10, we imply

        generally what we want but we never define it. I use the word frequently

        (not just in the context of UAS RID and DRIP), and I identify several

        dimensions of it (reliability, scalability, security, etc.), but I have

        never actually attempted to define it rigorously. I am afraid to try.

        Perhaps we should reword this so it doesn't imply that we have a formal

        definition?



    EV> good idea, simply enumerate (reliability, scalability, ...) rather than using "as specified in " ;-)

SZ/ @Card, Stu it seems to me you may have a solution for this comment?

SZ/ -21 has addressed this issue. Consider this is closed.





        Sec 6: " DET (DRIP Entity Tag which is an HHIT-based UA ID)" should be at least written as "DRIP Entity Tag (DET), which is an HHIT-based UAS RID." And it probably deserves a definition / introduction on its own (perhaps in § 3.1)

SZ/  I agree. Updated as suggested.

SZ/ -21 has addressed this issue. Consider this is closed.





        Sec 7 " One obvious opportunity is to enhance the architecture with gateways from Broadcast RID to Network RID.", while I do not disagree, this section is not the right place to open the discussion. This should be in the § 1 (with perhaps a forward reference to § 7)

SZ/ @Robert Moskowitz @Robert Moskowitzneed input from Bob.

SZ/ -21 has addressed this issue. Consider this is closed.





       Sec 7 " crowd-sourced" indeed many ADS-B receivers are run by amateurs (like my own) for flightradar24, flightaware, ... perhaps add a reference ?

SZ/ @Eric, do you have a specific reference to add? Not sure I understood your comment correctly.

SZ/ -21 has addressed this issue. Consider this is closed.



       Sec 7 " it adds two more entity types." Which ones ?

SZ/ @Robert Moskowitz @Robert Moskowitz Please specify.



> ...

        > Sec 7.1 this should really be part of the overall architecture of section 1



        The "CS-RID Finder" defined in 7.1 and the "CS-RID SDSP" defined in 7.2

        are _additions_: they are not part of UAS RID as contemplated by anyone

        other than the DRIP WG; they are not even part of basic DRIP, but an

        extension.



        > ...

        > Sec 8 "DRIP contact" is nice indeed but same comment as for the CS-RID:

        > this should really be part of the global architecture description and

        > not pushed at the end



        This is another extension relative to UAS RID but I think fundamental to

        our DRIP approach, so yes we should briefly introduce it earlier, before

        elaborating upon it here.



EV> yes, please introduce those parts (CS-RID & contact) earlier in the document.

SZ/ -21 has addressed this issue. Consider this is closed.





    EV> As F3411 is the basis this I-D, should those extensions be clearly identified as not included in F3411 ?



SZ/ @Card, Stu, I feel like more discussion is needed regarding how to address this section. Please let me know what is your thinking.

SZ/ -21 has addressed this issue. Consider this is closed.





        Sec 7.2 " multilateration" should briefly be described, perhaps in the terminology section

SZ/ @Card, Stu "multilateration" was not described in req. Should we do it here?

SZ/ -21 has addressed this issue. Consider this is closed.





        >

        > Sec 8: should be less descriptive and perhaps not even mention HIP & BEET



        This really goes back to what has been a fundamental recurring debate

        since we started DRIP: is it based on HHITs and thus related closely to

        (although not entirely dependent upon) HIP; or is it generic? So far, no

        one has come to the DRIP WG and proposed anything other than the HHIT

        based approach. We are far along with that approach. Given the use of

        that approach, the contact requirement is trivially satisfied by using a

        HIP initiated BEET; there is no need to reinvent any wheels.



    EV> I also like the HHIT approach and the extension of DRIP contact. But I believe that mentioning HIP & BEET is venturing too much in a detailed solution especially since there is not even a draft about it. HIP may be mentioned as a potential solution but no more as its mention puts constraints on the work of the DRIP WG. I strongly suggest to remove " An Observer equipped with HIP can... V2X communications (e.g., [MAVLink]), etc" and possibly also the last sentence.



        Thanks again. I will wait for responses from my co-authors and our

        editor before proposing any more replacement language to clarify these

        points where our meaning did not come through.



SZ/ @Card, Stu should we trim down the details regarding HIP/BEET?

SZ/ -21 has addressed this issue. Consider this is closed.



    EV> that is the goal of review by a pair of fresh eyes. As soon as a revised I-D is uploaded, then I will initiate the IETF Last Call. We can still hope to get this I-D approved by the IESG before IETF-113 (end of March 2022)



        Sec 10 is very light and mainly focus on the private keys except for the false flag issue (which deserves its own paragraph). Nothing is said about privacy

SZ/ Does it mean we should remove this section? @Robert Moskowitz@Robert Moskowitz anything new you can add?




--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      [e-mail]<mailto:[e-mail]>

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--
Tm-rid mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tm-rid

--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      [e-mail]<mailto:[e-mail]>

There's no limit to what can be accomplished if it doesn't matter who gets the credit

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.