[Rats] Re: Mohamed Boucadair's Discuss on draft-ietf-rats-network-device-subscription-13: (with DISCUSS and COMMENT)

[Henk Birkholz <[e-mail]>]

Thank you a lot for your review and feedback, Med!

we've applied the changes as outlined in PR #47.


Viele Grüße,

Henk

On 21.09.2026 15:49, [e-mail] wrote:
> Hi Eric,
> 
> Thank you for the follow-up and for preparing these PRs. I think this address main points.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Eric Voit (evoit) <[e-mail]>
>> Envoyé : jeudi 17 septembre 2026 18:41
>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
>> The IESG <[e-mail]>
>> Cc : [e-mail];
>> [e-mail]; [e-mail]; [e-mail]
>> Objet : RE: Mohamed Boucadair's Discuss on draft-ietf-rats-
>> network-device-subscription-13: (with DISCUSS and COMMENT)
>>
>>
>>
>> Hi Med,
>>
>> Thanks for the detailed review. I have added brief responses
>> inline only where we are proposing a change or clarification.
>> Comments already addressed or not being acted on are left without
>> a response. .  A new PR now exists for these changes in our
>> repository.
>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>> github.com%2Fietf-rats-wg%2Fdraft-ietf-rats-network-device-
>> subscription%2Fpulls&data=05%7C02%7Cmohamed.boucadair%40orange.com
>> %7Cd5526d0eb5b84854e53f08df14da78da%7C90c7a20af34b40bfbc48b9253b6f
>> 5d20%7C0%7C0%7C639252600735556834%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0
>> eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC
>> IsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hiiUzhq%2BxStfpw2GdYHB4MVjqW
>> PWLyndWr%2BXkY21lqs%3D&reserved=0
>>
>>> -----Original Message-----
>>> From: Mohamed Boucadair via Datatracker <[e-mail]>
>>>
>>> ----------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------
>>>
>>> Hi Henk, Eric, and Wei,
>>>
>>> Thank you for the effort put into this document.
>>>
>>> I must admit that it wasn't an easy read but that's OK as the
>> document have a discussion on how to glue this piece with other
>> RATS documents.
>>>
>>> I don't know if this was implemented or if issues such as the
>> ones carried in NETCONF WG (e.g., YP-Lite, support of other
>> transport mappings to accommodate (massive) distributed data) are
>> relevant for this work. No action is needed at this stage, but I
>> just wanted to let you know that work is happening.
>>>
>>> Pointes are ordered per their appearance order in the document.
>>>
>>> Please find below some comments for discussion:
>>>
>>> # I don't find where <pcr-indicies> in the doc.
>>>
>>> CURRENT:
>>>
>>>         These attestation
>>>         notifications MUST at least include all the <pcr-
>> indicies>
>>>         requested in the RPC.
>>>
>>> # Is this 10 seconds frozen or configurable? Also, given the
>> SHOULD out there, an implem may use a different value, how the
>> value actually in use can be retrieved using the module?
>>
>> Response: The 10-second interval is intended to be a fixed value
>> defined by this specification, not an implementation-configurable
>> timer. The SHOULD permits an implementation to deviate when there
>> is a specific justified reason, but such a deviation does not
>> establish or advertise a different timer value. We will clarify
>> that the 10-second value is fixed and non-configurable. Therefore,
>> there is no alternate timer value for the YANG module to expose or
>> for a Verifier to retrieve.
>>
>>>
>>> CURRENT:
>>>
>>>     * every time at least one PCR has changed from a previous
>>>       <tpm20-attestation>. In this case, the notification SHOULD
>> be
>>>       emitted within 10 seconds of the corresponding <pcr-extend>
>> being
>>>       sent:
>>>
>>> # Why the container is needed here? adding that level increases
>> the
>>> size of notifications
>>
>> Response: We agree that the additional container is not strictly
>> required to represent the information and that removing it could
>> slightly reduce the encoded notification size. However, the
>> current structure is valid YANG and is already part of the defined
>> notification schema. Removing it would change existing schema
>> paths and notification encoding without correcting an
>> interoperability or correctness problem. We therefore propose
>> retaining the existing structure and avoiding an unnecessary data-
>> model change at this stage.
>>
>>>
>>> CURRENT:
>>>
>>>         list attested-event {
>>>           description
>>>             "A set of events which extended an Attester PCR. The
>>>             sequence of elements represented in list must match
>> the
>>>             sequence of events placed into the TPM's PCR.";
>>>           container attested-event {
>>>             description
>>>               "An instance of an event which extended an Attester
>> PCR";
>>>
>>> # Correlation
>>>
>>> CURRENT:
>>>
>>>           leaf-list pcr-index {
>>>             type tpm:pcr;
>>>             min-elements 1;
>>>             description
>>>               "PCR index number.";
>>>           }
>>>           leaf-list pcr-value {
>>>             type binary;
>>>             description
>>>               "PCR value in a sequence which matches to the
>>>               'pcr-index'.";
>>>           }
>>>
>>> ## The description is not clear about the intended use.
>>
>> Response: Agreed that the intended use should be clearer. These
>> fields are unsigned convenience information intended to expose the
>> TPM 1.2 PCR indices and corresponding values to YANG-based
>> filtering and processing without requiring consumers to parse the
>> underlying TCG binary structures. They do not replace or redefine
>> the signed TPM 1.2 attestation Evidence, which remains
>> authoritative. We will clarify this in the description.
>>
>>>
>>> ## This structure imposes an ordering constraint that may lead
>> to correlation issues. Why a list is not used here?
>>
>> Response: We agree that the correlation must be unambiguous, but
>> propose retaining the existing TPM 1.2 representation. TPM 1.2
>> represents this information as a PCR selection associated with an
>> ordered sequence of PCR values rather than independently keyed
>> {PCR index, PCR value} objects. Converting it to the TPM 2.0-style
>> keyed representation would introduce a different abstraction
>> rather than simply clarify the existing one. We will instead state
>> explicitly that the two leaf-lists have equal cardinality and that
>> entry N in <pcr-value> corresponds to entry N in <pcr-index>,
>> following the TPM 1.2 PCR selection/value ordering.
>>
>>>
>>>               +--ro pcr-values* [pcr-index]
>>>                  +--ro pcr-index    pcr
>>>                  +--ro pcr-value?   binary
>>>
>>> # YANG Validation
>>>
>>> There are some points to fix:
>>>
>>> ./yang/ietf-tpm-remote-attestation-stream.yang:49: warning: RFC
>> 8407: 3.1:
>>> The IETF Trust Copyright statement seems to be missing or is not
>> correct (see pyang --ietf-help for details). ./yang/ietf-tpm-
>> remote-attestation-stream.yang:120:
>>> warning: the module seems to use RFC 2119 keywords, but the
>> required text from RFC 8174 is not found or is not correct (see
>> pyang --ietf-help for details).
>>> ./yang/ietf-tpm-remote-attestation-stream.yang:292: warning: RFC
>> 8407: 4.4:
>>> statement "config" is given with its default value "true"
>>>
>>> ## Some can fixed by following the template in 9907
>>>
>>> ## Add the keywords boilerplate to the description of the module
>>
>> Response: Agreed. These are mechanical module-hygiene issues
>> rather than changes to the information model. We will update the
>> module boilerplate to follow RFC 9907, add the BCP 14 keyword text
>> to the module description, and remove the redundant <config true>
>> statement. None of these changes alter the resulting YANG data
>> tree.
>>
>>>
>>> # I don't understand the following, especially how the intend of
>> this MUST and how it will be followed.
>>
>> Response: Agreed that the current wording makes the scope of the
>> MUST difficult to determine. The intent is that a specification
>> using this framework to define another RATS Conceptual Message
>> Event Stream identifies that extension through a YANG augmentation
>> of this module, including when the carried event content itself is
>> not YANG modeled. We will rewrite the requirement directly so that
>> it is clear what must be augmented and what an extending
>> specification is required to provide.
>>
>>>
>>> CURRENT:
>>>
>>>     It is possible to
>>>     use either YANG subscription methods to other YANG modules
>> for RATS
>>>     Conceptual Messages or to define Event Streams for other
>> none-YANG-
>>>     modeled data. In the context of RATS Conceptual Messages,
>> both
>>>     options MUST be a specified via YANG augments to this
>> specification.
>>>
>>> # BCP 216
>>>
>>> The document does not follow many of the templates in 9907. In
>>> particular, please follow the security template provided in
>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>> datatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9907%23name-security-
>> considerations-
>> sect&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd5526d0eb5b84
>> 854e53f08df14da78da%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
>> 39252600735579190%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs
>> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
>> 3D%7C0%7C%7C%7C&sdata=vzuhl2mmhIf9Cwdvqz%2Bnv5%2FtPfGs1U7DLGMnOABS
>> V0Q%3D&reserved=0.
>>
>> Response: Agreed. We will restructure the YANG security text
>> around the RFC 9907 template and explicitly identify the security-
>> sensitive writable and readable information introduced by this
>> module. We will also add the security considerations that arise
>> specifically from persistent streaming attestation, including
>> long-lived subscription resource consumption and the freshness
>> implications when expected attestation or heartbeat notifications
>> are delayed or absent. This also removes the current implication
>> that streaming introduces no additional considerations.
>>
>>>
>>>
>>> ----------------------------------------------------------------
>> ------
>>> COMMENT:
>>> ----------------------------------------------------------------
>> ------
>>>
>>> # PCR was used without being defined. Please update Section 2
>> accordingly.
>>>
>>> # Please avoid use "YANG model". Overall, refer to the guidance
>> in Section 2.5 of RFC9907.
>>>
>>> # Notations
>>>
>>> Please consider adding some text to explain how to read the
>> various notations our there (e.g., ? in the excerpt below):
>>>
>>> CURRENT:
>>>
>>> |    |<----------------- subscribe(nonce, TpmName,
>> ?PcrSelection) |    |
>>> |    | {nonce} -------------------------------------------------
>> ->|    |
>>>
>>> # Tree diagrams: RFC8340
>>>
>>> Please add a note early in the document about the tree diagrams.
>>>
>>> As a reminder, RFC9907 says:
>>>
>>>     If YANG tree diagrams are used, then an informative reference
>> to the
>>>     YANG tree diagrams specification MUST be included in the
>> document.
>>>
>>> # I don't parse this sentence:
>>
>> Response: Agreed. We will state that if either counter increments,
>> the existing subscription MUST terminate; if the Verifier intends
>> to continue receiving Evidence, it MUST establish a new
>> subscription.
>>
>>>
>>> CURRENT:
>>>
>>>     * If the <reset-counter>, <restart-counter> has incremented.
>> The
>>>       existing subscription MUST be terminated, and a new
>> <establish-
>>>       subscription> SHOULD be generated.
>>>
>>> # Likewise, I don't parse the following:
>>>
>>> CURRENT:
>>>
>>>     This is done via the augmentation of a <nonce-value> into
>>>     [RFC8639] the <establish-subscription> RPC.
>>>
>>> # Why both notifications will be provided? Shouldn't this be
>> "or"?
>>> (same comment for other similar constructs in the doc)
>>>
>>> CURRENT:
>>>
>>>     1. <tpm12-attestation> and <tpm20-attestation> notifications
>> which
>>>        include the provided <nonce-value>. These attestation
>>>        notifications MUST at least include all the <pcr-indicies>
>>>        requested in the RPC.
>>>
>>> # Consider adding an appendix with the full tree.
>>>
>>> # Please replace with the RFC number + title
>>
>> Response: Agreed. We will replace the draft reference with RFC
>> 9684 and its title.
>>
>>>
>>> CURRENT:
>>>
>>>       import ietf-tpm-remote-attestation {
>>>         prefix tpm;
>>>         reference
>>>           "draft-ietf-rats-yang-tpm-charra";
>>>       }
>>>
>>> # Add a reference statement
>>
>> Response: Agreed. We will add the RFC 9684 reference to the <ietf-
>> tcg-algs> import.
>>
>>>
>>> CURRENT:
>>>
>>>       import ietf-tcg-algs {
>>>         prefix taa;
>>>       }
>>>
>>> # Please update to follow the template at
>>>
>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>> data
>>> tracker.ietf.org%2Fdoc%2Fhtml%2Frfc9907%23name-template-for-
>> ietf-modul
>>>
>> es&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd5526d0eb5b8485
>> 4e53
>>>
>> f08df14da78da%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6392526
>> 0073
>>>
>> 5593700%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj
>> AuMD
>>>
>> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7
>> C&sd
>>> ata=e65terYgRMwhIQHJNCccBywkUoSiobY5ovvZDhNlZ9M%3D&reserved=0
>>
>> Response: Agreed. We will update the organization/contact
>> information and module boilerplate to follow the RFC 9907
>> template.
>>
>>>
>>> CURRENT:
>>>
>>>       organization "IETF";
>>>       contact
>>>         "WG Web:
>> <https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
>> tools.ietf.org%2Fwg%2Frats%2F&data=05%7C02%7Cmohamed.boucadair%40o
>> range.com%7Cd5526d0eb5b84854e53f08df14da78da%7C90c7a20af34b40bfbc4
>> 8b9253b6f5d20%7C0%7C0%7C639252600735604111%7CUnknown%7CTWFpbGZsb3d
>> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
>> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2Bx%2B%2BLF2GGAled
>> pzzCQky2RXDNA%2B21G9dNWSSSuqw8vg%3D&reserved=0>
>>>          WG List:  <mailto:[e-mail]>
>>>
>>>          Editor:   Eric Voit
>>>                    <mailto:[e-mail]>";
>>>
>>>       description
>>>         "This module contains YANG specification for subscribing
>>>          to attestation streams which contain events that have
>>>          been generated by TPM chips or equivalent hardware
>>>          implementations that include the protected capabilities
>>>          as provided by TPMs.
>>>
>>>          Copyright (c) 2024 IETF Trust and the persons identified
>>>          as authors of the code. All rights reserved.
>>>
>>>          Redistribution and use in source and binary forms, with
>>>          or without modification, is permitted pursuant to, and
>>>          subject to the license terms contained in, the
>> Simplified
>>>          BSD License set forth in Section 4.c of the IETF Trust's
>>>          Legal Provisions Relating to IETF Documents
>>>
>> (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Ftrustee.ietf.org%2Flicense-
>> info&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd5526d0eb5b84
>> 854e53f08df14da78da%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
>> 39252600735615173%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs
>> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
>> 3D%7C0%7C%7C%7C&sdata=sJrGsIO82UACE%2BC1T6r%2BoKvM6Kn1ubZ8Kls2uga6
>> yiU%3D&reserved=0).
>>>
>>>          This version of this YANG module is part of RFC XXXX
>>>
>> (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Fwww.rfc-
>> editor.org%2Finfo%2FrfcXXXX&data=05%7C02%7Cmohamed.boucadair%40ora
>> nge.com%7Cd5526d0eb5b84854e53f08df14da78da%7C90c7a20af34b40bfbc48b
>> 9253b6f5d20%7C0%7C0%7C639252600735637050%7CUnknown%7CTWFpbGZsb3d8e
>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MnigQDYKo5w7gk68h8eZx
>> BI336dO8KUU5JLHYey9bdY%3D&reserved=0); see the RFC
>>>          itself for full legal notices.";
>>>
>>> # The revision date MUST match the one used in the file name +
>> update
>>> reference to include the document title
>>
>> Response: Agreed. We will align the revision date with the module
>> filename and update the reference text to include the document
>> title.
>>
>>>
>>> CURENT:
>>>
>>>       revision 2024-07-06 {
>>>         description
>>>           "Initial version.";
>>>         reference
>>>           "draft-ietf-rats-network-device-subscription";
>>>
>>> # Please use meaningful description as the module will be
>> consumed out
>>> of the RFC
>>>
>>> CURRENT:
>>>
>>>       identity pcr-unsubscribable {
>>>         base sn:establish-subscription-error;
>>>         description
>>>           "Requested PCR is unsubscribable by the Attester.";
>>>       }
>>>
>>> # Add prefix
>>
>> Response: There is a related issue here. RFC 8639 <stream> is a
>> leafref to the stream name rather than an identityref, so
>> <derived-from-or-self()> is not the appropriate XPath function
>> even if an identity prefix is added. We will instead use a direct
>> comparison: when 'sn:stream = "attestation"';.
>>
>>>
>>> OLD:
>>>
>>>       augment "/sn:establish-subscription/sn:input" {
>>>         when 'derived-from-or-self(sn:stream, "attestation")';
>>>
>>> NEW:
>>>
>>>       augment "/sn:establish-subscription/sn:input" {
>>>         when 'derived-from-or-self(sn:stream,
>> "tras:attestation")';
>>>
>>> # binary instead of structured data
>>>
>>> Please consider adding some text to explain why binary is used
>> rather
>>> than a more structured data
>>>
>>> # List names
>>>
>>> RFC9907 says:
>>>
>>>   "List identifiers SHOULD be singular with the surrounding
>> container
>>> name  plural. Similarly, "leaf-list" identifiers SHOULD be
>> singular."
>>>
>>> Please make this change:
>>
>> Response: We propose retaining <unsigned-pcr-values>. The RFC 9907
>> naming guidance is a SHOULD, and RFC 9684 already uses this
>> identifier. Renaming it here would introduce an unnecessary schema
>> difference without changing the semantics.
>>
>>>
>>> OLD:
>>>
>>>         list unsigned-pcr-values {
>>>           description
>>>             "Allows notifications to be filtered by PCR number or
>>>             PCR value based on via YANG related mechanisms such
>> as PATH.
>>>
>>> NEW:
>>>
>>>         list unsigned-pcr-value {
>>>           description
>>>             "Allows notifications to be filtered by PCR number or
>>>             PCR value based on via YANG related mechanisms such
>> as PATH.
>>>
>>> # Missing units + reference for the default value
>>
>> Response: Agreed. We will add <units "seconds"> and a reference to
>> the section defining the default value and its behavior.
>>
>>>
>>> CURRENT:
>>>
>>>         leaf marshalling-period {
>>>           type uint8;
>>>           default 5;
>>>           description
>>>             "The maximum number of seconds between the time an
>> event
>>>             extends a PCR, and the 'tpm-extend' notification
>> which
>>>             reports it to a subscribed Verifier. This period
>> allows
>>>             multiple extend operations bundled together and
>> handled as a
>>>             group.";
>>>         }
>>>
>>> ## Please add units statement
>>>
>>> ## Also, can we have a reference where the default value is
>> defined?
>>>
>>> # Other as Security Consideration
>>>
>>> CURRENT:
>>>
>>> 8.3. Other
>>>
>>>     There are no additional security considerations introduced by
>> this
>>>     document.
>>>
>>> I suggest to remove this as it is misleading.
>>
>> Response: Agreed. We will remove this statement as part of the RFC
>> 9907 and streaming-security update.
>>
>>>
>>> # IANA
>>>
>>> Please update IANA requests to follow the template in
>>>
>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>> data
>>> tracker.ietf.org%2Fdoc%2Fhtml%2Frfc9907%23name-iana-template-
>> for-docum
>>>
>> ents&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd5526d0eb5b84
>> 854e
>>>
>> 53f08df14da78da%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63925
>> 2600
>>>
>> 735656277%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw
>> LjAu
>>>
>> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C
>> %7C&
>>>
>> sdata=%2FG1JqmE9wjiTpBoeT2dMyUbILu6VUu8Slenb94x%2FrI8%3D&reserved=
>> 0
>>>
>>> # Missing Examples
>>>
>>> RFC9907 says:
>>>
>>>     Each specification that defines one or more modules SHOULD
>> contain
>>>     usage examples, either throughout the document or in an
>> appendix.
>>>
>>> Consider adding some examples to illustrate the use of the
>> module.
>>>
>>> # Nits
>>>
>>> ## s/such as a Verifiers or a Relying Parties/such as a Verifier
>> or a
>>> Relying Party
>>
>> Nits will be fixed
>>
>> Eric
>>
>>> ## Please fix the following
>>>
>>> CURRENT:
>>>
>>>     The second adverse effect stems from the use of nonces in the
>>>     challenge-response interaction model Section 7.1 of
>>>     [I-D.ietf-rats-reference-interaction-models] realized in
>> [RFC9684].
>>>
>>> ##
>>>
>>> OLD:
>>>
>>>     The
>>>     operational model and corresponding sequence diagram
>> described in
>>>     this section is based on [RFC9684]
>>>
>>> NEW:
>>>
>>>     The
>>>     operational model and corresponding sequence diagram
>> described in
>>>     this section are based on [RFC9684]
>>>
>>> # s/diagram focusses on matching/diagram focuses on matching
>>>
>>> #
>>>
>>> OLD:
>>>
>>>   at that time.Methods of doing this verification vary based on
>> the
>>>
>>> NEW:
>>>
>>>   at that time. Methods of doing this verification vary based on
>> the
>>>
>>> # Clarity
>>>
>>> OLD:
>>>
>>>     Therefore, a Verifier MUST periodically issue a new nonce and
>>>     receive this nonce within a TPM quote response in order to
>> ensure the
>>>     freshness of the results.
>>>
>>> NEW:
>>>
>>>     Therefore, a Verifier MUST periodically issue a new nonce and
>>>     MUST receive this nonce within a TPM quote response in order
>> to ensure the
>>>     freshness of the results.
>>>
>>> # s/Evidence to assists a Verifier/Evidence to assist a Verifier
>>>
>>> Cheers,
>>>
>>> Med
> ____________________________________________________________________________________________________________
> 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.
> 
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]