Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC 9033 <draft-ietf-6tisch-msf-18.txt> NOW AVAILABLE

[Xavi Vilajosana Guillen <[e-mail]>]

Dear Jean,

I also approve the publication of this document in its current state.

kind regards

Missatge de Tengfei Chang <[e-mail]> del dia dv., 23 d’abr.
2021 a les 2:38:

> Hi Jean,
>
> It reads good for me and I state that:
>
> I approve the publication of this document in its current state.
>
> Tengfei
>
> On Thu, Apr 22, 2021 at 11:53 PM Jean Mahoney <[e-mail]> wrote:
>
>> Tengfei, Pascal, and *AD (Erik),
>>
>> * Erik, please review the newly added one-paragraph section in the
>> Introduction (Section 1.2, Related Documents), and let us know if you
>> approve of the addition.
>>
>> NEW:
>>
>> 1.2.  Related Documents
>>
>>    This specification uses messages and variables defined in IEEE Std
>>    802.15.4-2015 [IEEE802154].  It is expected that those resources will
>>    remain in the future versions of IEEE Std 802.15.4; in which case,
>>    this specification also applies to those future versions.  In the
>>    remainder of the document, we use [IEEE802154] to refer to IEEE Std
>>    802.15.4-2015 as well as future versions of IEEE Std 802.15.4 that
>>    remain compatible.
>>
>> https://www.rfc-editor.org/authors/rfc9033.html#name-related-documents
>>
>>
>> Tengfei and Pascal, thank you for your responses. We have updated the
>> document with your feedback:
>>
>>    https://www.rfc-editor.org/authors/rfc9033.txt
>>    https://www.rfc-editor.org/authors/rfc9033.pdf
>>    https://www.rfc-editor.org/authors/rfc9033.html
>>    https://www.rfc-editor.org/authors/rfc9033.xml
>>    https://www.rfc-editor.org/authors/rfc9033-diff.html (all changes)
>>    https://www.rfc-editor.org/authors/rfc9033-auth48diff.html (all
>> AUTH48 changes)
>>    https://www.rfc-editor.org/authors/rfc9033-lastdiff.html (these
>> changes)
>>    https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html (these
>> changes side by side)
>>
>> We will await further word from you and your coauthors regarding other
>> AUTH48 changes and/or approval.
>>
>> Best regards,
>>
>> RFC Editor/jm
>>
>>
>> On 4/21/21 10:15 PM, Tengfei Chang wrote:
>>
>> Hi Jean,
>>
>> I replied inline:
>>
>> On Thu, Apr 22, 2021 at 12:32 AM Jean Mahoney <[e-mail]> wrote:
>>
>>> Tengfei, Mališa, Diego, Xavi, and Pascal,
>>>
>>> Thank you for your quick responses! We have updated the document based
>>> on your feedback, and we have a few more questions below:
>>>
>>>    https://www.rfc-editor.org/authors/rfc9033.txt
>>>    https://www.rfc-editor.org/authors/rfc9033.pdf
>>>    https://www.rfc-editor.org/authors/rfc9033.html
>>>    https://www.rfc-editor.org/authors/rfc9033.xml
>>>    https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html (these
>>> changes side by side)
>>>    https://www.rfc-editor.org/authors/rfc9033-auth48diff.html (changes
>>> made during AUTH48)
>>>    https://www.rfc-editor.org/authors/rfc9033-diff.html (all changes
>>> made to the text)
>>>    https://www.rfc-editor.org/authors/rfc9033-xmldiff.html (all changes
>>> made to the XML)
>>>
>>>
>>> Tengfei, would you like to update your email address in the document? It
>>> is currently [e-mail].
>>>
>>
>> *TC: Thanks for pointing this out. The email will not be available in a
>> few months, could you change to [e-mail]
>> <[e-mail]> for me? Thanks! *
>>
>>>
>>>
>>> May we expand the 6TiSCH acronym in the abstract?
>>>
>>> Current:
>>>    This specification defines the 6TiSCH Minimal Scheduling Function
>>>    (MSF).
>>>
>>> Perhaps:
>>>    This specification defines the "IPv6 over the TSCH mode of
>>>    IEEE 802.15.4e" (6TiSCH) Minimal Scheduling Function (MSF).
>>>
>>>
>>> * TC: Yes, you may. *
>>
>> *  OLD:*
>>
>> *    This specification defines the 6TiSCH Minimal Scheduling Function*
>>
>> *    (MSF).  *
>>
>>
>> *NEW:*
>>
>> *   This specification defines the "IPv6 over the TSCH mode of *
>>
>> *    IEEE 802.15.4e" (6TiSCH) Minimal Scheduling Function (MSF).  *
>>
>> In Section 5.1, the hyperlinked "Step 2" in the following sentence goes
>>> to numbered item "2.  When the value of NumCellsElapsed reaches
>>> MAX_NUM_CELLS:"
>>>
>>>        *  Reset both NumCellsElapsed and NumCellsUsed to 0 and go to
>>>           Step 2.
>>>
>>> Should it instead go to Section 4.3 ("Step 2 - Receiving EBs")? If the
>>> link is correct (go to #2), then perhaps it should be
>>> rephrased as "restart #2"?
>>>
>>>        *  Reset both NumCellsElapsed and NumCellsUsed to 0 and restart
>>>           #2.
>>>
>>>
>>> *TC: Go to #2 is correct. Just to clarify, #2 indicates this
>> sentence: When the value of NumCellsElapsed reaches MAX_NUM_CELLS:*
>>
>> *  OLD:*
>>
>> *Reset both NumCellsElapsed and NumCellsUsed to 0 and go to*
>>
>> *           #2.  *
>>
>>
>> *NEW:*
>>
>> *   Reset both NumCellsElapsed and NumCellsUsed to 0 and restart*
>>
>> *           #2.  *
>>
>>
>>
>>> May we move the following citation tag in Section 8 to improve
>>> readability?
>>>
>>> Current:
>>>    If [IEEE802154] transmissions are observed ...
>>>
>>> Perhaps:
>>>    If transmissions that rely on [IEEE802154] are observed ... or
>>>    If transmissions that rely on LR-WPANs [IEEE802154] are observed ...
>>>
>>
>> *TC:  Yes, you may. I think the first choice is good. IEEE802154 already
>> indicates it's for LR-WPANs.*
>>
>> *  OLD:*
>>
>> *    If [IEEE802154] transmissions are observed ...*
>>
>>
>> * NEW:*
>>
>> *    If transmissions that rely on [IEEE802154] are observed ... *
>>
>>
>>
>>> And one more question inline marked with [JM] --
>>>
>>
>> *TC: Sorry I missed that one. The comment 6) also pointed to the same
>> sentence and my response is nearly the same as JM suggested :-) *
>> *Please use JM's suggestion here.*
>>
>> *OLD:  *
>>
>>
>>
>> *                                The node receives a valid frame from the
>> parent.                                 The counter increments only when
>> the frame is a valid [IEEE802.15.4] frame. *
>>
>> *NEW:*
>>
>> *The counter increments only when a valid frame per [IEEE802.15.4] is
>> received by the node from its parent. *
>>
>>
>>
>>> On 4/21/21 4:15 AM, Tengfei Chang wrote:
>>>
>>> Dear all,
>>>
>>> Thanks for the quick responses!
>>>
>>> Dear RFC editor,
>>>
>>> Thanks for editing the document!
>>> I have response each questions inline below starting with *TC: (in* *bold
>>> and Italic) *
>>>
>>> Please let me know if there are any further questions regarding to the
>>> document.
>>> Thanks!
>>>
>>> Tengfei
>>>
>>> On Wed, Apr 21, 2021 at 2:49 PM <[e-mail]> wrote:
>>>
>>>> Authors,
>>>>
>>>> While reviewing this document during AUTH48, please resolve (as
>>>> necessary) the following questions, which are also in the XML file.
>>>>
>>>> 1) <!-- [rfced] We note that the sortRefs attribute is missing in
>>>> rfc element. Would you like the citations in the References sorted
>>>> alphabetically or by first use in the document?
>>>> -->
>>>>
>>>> * TC: We would like the citations in the References sorted
>>> alphabetically. Thanks!*
>>>
>>>>
>>>> 2) <!--[rfced] Mališa, do you prefer that your name appear as
>>>> "Malisa Vucinic" or "Mališa Vučinić" in this document (and other
>>>> documents in this cluster)? We note the latter appears on this page:
>>>> https://datatracker.ietf.org/person/Mali%C5%A1a%20Vu%C4%8Dini%C4%87
>>>> -->
>>>>
>>>> * TC: please refer to Malisa's response.*
>>>
>>>>
>>>> 3) <!-- [rfced] Please insert any keywords (beyond those that appear
>>>> in the title) for use on https://www.rfc-editor.org/search.
>>>> -->
>>>>
>>>> * TC: please insert the following keywords, thanks!*
>>>
>>> *TSCH, communication schedule, 6P*
>>>
>>>
>>>> 4) <!-- [rfced] Does the following improve the readability of
>>>>  the sentence?
>>>>
>>>> Current:
>>>>    In case of a slot to transmit or receive, a channel is
>>>>    assigned to the time slot.
>>>>
>>>> Perhaps:
>>>>    For time slots for transmitting or receiving, a channel is
>>>>    assigned to the time slot.
>>>> -->
>>>>
>>>> *TC: Yes, please use the rephrased sentence: *
>>>
>>> *OLD:*
>>>
>>> *    In case of a slot to transmit or receive, a channel is*
>>>
>>> *    assigned to the time slot.  *
>>>
>>>
>>> * NEW:*
>>>
>>> *    For time slots for transmitting or receiving, a channel is*
>>>
>>> *    assigned to the time slot.    *
>>>
>>>
>>>> 5) <!-- [rfced]  We are having difficulty parsing the following:
>>>>
>>>> Current:
>>>>    For interoperability purposes, the values of those parameters
>>>>    can be referred from Appendix A.
>>>>
>>>> Purhaps:
>>>>    For interoperability purposes, Appendix A provides guidance
>>>>    on calculating the values of those parameters.
>>>> -->
>>>>
>>>> * TC: Please apply the following changes. The parameters' values are
>>> not calculated but arbitrary values, which are defined in Appendix A. *
>>> *So that two different implementations of MSF can interoperate by
>>> agreeing on same parameters values.*
>>>
>>>
>>> *OLD:*
>>>
>>> *    For interoperability purposes, the values of those parameters *
>>>
>>> *    can be referred from Appendix A.*
>>>
>>>
>>> * NEW:*
>>>
>>> *    For interoperability purposes, Appendix A provides the reference
>>> values of those parameters. *
>>>
>>>
>>>> 6) <!-- [rfced] Please consider rephrasing to make this more precise.
>>>> -->
>>>>
>>>> *TC: It's rephrased as following.*
>>>
>>> *OLD:  *
>>>
>>>
>>>
>>> *                                The node receives a valid frame from
>>> the parent.                                 The counter increments only
>>> when the frame is a valid [IEEE802.15.4] frame. *
>>>
>>> *NEW:*
>>>
>>> *The counter increments, only when a valid [IEEE802.15.4] frame is
>>> received by the node form its parent. *
>>>
>>>
>>>> [JM]  We have incorporated the new text but have moved the citation tag
>>> to improve readability. Please let us know if any other changes are
>>> necessary.
>>>
>>>    The counter increments only when a valid frame per [IEEE802154]
>>>    is received by the node from its parent.
>>>
>>>
>>> Best regards,
>>>
>>> RFC Editor/jm
>>>
>>>
>>> 7) <!-- [rfced] We are having difficulty parsing this passage.
>>>> Specifically, may the first sentence be rephrased as follows?
>>>> And, in the later sentence, should "absolved" be "alleviated"?
>>>>
>>>> Current:
>>>>    The 6P traffic overhead using a larger value of MAX_NUM_CELLS could
>>>>    be reduced as well... The latency caused by slight changes of
>>>> traffic
>>>>    load can be absolved by the additional scheduled cells.
>>>>
>>>> Perhaps:
>>>>    By using a larger value of MAX_NUM_CELLS, the 6P traffic overhead
>>>> could
>>>>    be reduced as well... The latency caused by slight changes of
>>>> traffic
>>>>    load can be alleviated by the additional scheduled cells.
>>>> -->
>>>>
>>>> *TC: The suggested sentence read good.*
>>>
>>> *  OLD:*
>>>
>>> *    The 6P traffic overhead using a larger value of MAX_NUM_CELLS could
>>> *
>>>
>>> *    be reduced as well... The latency caused by slight changes of
>>> traffic *
>>>
>>> *    load can be absolved by the additional scheduled cells.*
>>>
>>>
>>> * NEW:*
>>>
>>> *    By using a larger value of MAX_NUM_CELLS, the 6P traffic overhead
>>> could *
>>>
>>> *    be reduced as well... The latency caused by slight changes of
>>> traffic *
>>>
>>> *    load can be alleviated by the additional scheduled cells.   *
>>>
>>>
>>>
>>>>
>>>> 8) <!-- [rfced]  FYI, we have applied superscript formatting to the
>>>> following.
>>>> Please let us know if you would like to add a space on either side of
>>>> the
>>>> operators to improve readability.
>>>>
>>>> Current:
>>>>    ((2^MAXBE)-1)*MAXRETRIES*SLOTFRAME_LENGTH
>>>>
>>>> Perhaps:
>>>>    ((2^MAXBE) - 1) * MAXRETRIES * SLOTFRAME_LENGTH
>>>> -->
>>>>
>>>> *TC: We prefer add a space on * *either side ** of the operators to
>>> improve readability.*
>>>
>>>
>>> *OLD:*
>>>
>>> *  ((2^MAXBE)-1)*MAXRETRIES*SLOTFRAME_LENGTH  *
>>>
>>>
>>> *NEW: *
>>>
>>> *  ((2^MAXBE) - 1) * MAXRETRIES * SLOTFRAME_LENGTH *
>>>
>>>
>>>> 9) <!--[rfced] FYI, we have updated this reference as follows, as the
>>>> DOI
>>>> provided in the original is not functional, and it seems your intention
>>>> was to refer to IEEE 802.15.4-2015. (Please note that it was
>>>> "Superseded by IEEE Std 802.15.4-2020" as detailed at the provided URL.)
>>>>
>>>> Please review and let us know any updates; we will follow up
>>>> on this topic as this reference appears in several documents
>>>> in this cluster (C310).
>>>>
>>>> Original:
>>>>    [IEEE802154]
>>>>               IEEE standard for Information Technology, "IEEE Std
>>>>
>>>>               802.15.4 Standard for Low-Rate Wireless Personal Area
>>>>
>>>>               Networks (WPANs)", DOI 10.1109/IEEE P802.15.4-REVd/D01,
>>>>               <http://ieeexplore.ieee.org/document/7460875/>.
>>>>
>>>> Current:
>>>>    [IEEE802154]
>>>>               IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
>>>>               Standard 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875,
>>>>               April 2016,
>>>>               <https://ieeexplore.ieee.org/document/7460875>.
>>>> -->
>>>>
>>>> *TC: Thanks for updating the link. We prefer to use the IEEE
>>> 802.15.4-2015, which are referred during developing MSF.*
>>>
>>>>
>>>> 10) <!-- [rfced]  In the appendix, the term "mote" is used instead of
>>>> "node".
>>>> Is this intentional?
>>>> -->
>>>>
>>>> *TC: No. Please replace "mote" by "node".*
>>>
>>> *OLD:  *
>>>
>>> *String s is replaced by the mote EUI-64 address. The characters of the
>>> string, c0 through c7, are the eight bytes of the EUI-64 address.*
>>>
>>> *NEW: *
>>>
>>> *String s is replaced by the node EUI-64 address. The characters of the
>>> string, c0 through c7, are the eight bytes of the EUI-64 address.*
>>>
>>>
>>> *OLD: *
>>>
>>> *The appropriate values of l_bit and r_bit could vary depending on the
>>> set of motes' EUI-64 address.*
>>>
>>> *NEW: *
>>>
>>> *The appropriate values of l_bit and r_bit could vary depending on the
>>> set of nodes' EUI-64 address.*
>>>
>>>
>>>> 11) <!-- [rfced] FYI, we have updated the formatting of the Contributors
>>>> section to use <contact/> elements:
>>>>
>>>> Original:
>>>>    *  Beshr Al Nahas (Chalmers University, [e-mail])
>>>>    *  Olaf Landsiedel (Chalmers University, [e-mail])
>>>>    *  Yasuyuki Tanaka (Inria-Paris, [e-mail])
>>>>
>>>> Current:
>>>>    Beshr Al Nahas
>>>>    Chalmers University
>>>>
>>>>    Email: [e-mail]
>>>>
>>>>
>>>>    Olaf Landsiedel
>>>>    Chalmers University
>>>>
>>>>    Email: [e-mail]
>>>>
>>>>
>>>>    Yasuyuki Tanaka
>>>>    Inria-Paris
>>>>
>>>>    Email: [e-mail]
>>>> -->
>>>>
>>>> *TC: This looks good! Also please update the following contact info*
>>>
>>> *OLD: *
>>>
>>>
>>>
>>>
>>>
>>>
>>> *   Yasuyuki Tanaka    Inria-Paris    Email: [e-mail]
>>> <[e-mail]> *
>>>
>>>
>>> *NEW: *
>>>
>>> *   Yasuyuki Tanaka*
>>>
>>> *   Toshiba*
>>>
>>>
>>> *    Email: [e-mail] <[e-mail]>*
>>>
>>>
>>>> Thank you.
>>>>
>>>> RFC Editor/jm/ar
>>>>
>>>>
>>>> On Apr 20, 2021, [e-mail] wrote:
>>>>
>>>> *****IMPORTANT*****
>>>>
>>>> Updated 2021/04/20
>>>>
>>>> RFC Author(s):
>>>> --------------
>>>>
>>>> Instructions for Completing AUTH48
>>>>
>>>> Your document has now entered AUTH48.  Once it has been reviewed and
>>>> approved by you and all coauthors, it will be published as an RFC.
>>>> If an author is no longer available, there are several remedies
>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>>>
>>>> You and you coauthors are responsible for engaging other parties
>>>> (e.g., Contributors or Working Group) as necessary before providing
>>>> your approval.
>>>>
>>>> Planning your review
>>>> ---------------------
>>>>
>>>> Please review the following aspects of your document:
>>>>
>>>> *  RFC Editor questions
>>>>
>>>>   Please review and resolve any questions raised by the RFC Editor
>>>>   that have been included in the XML file as comments marked as
>>>>   follows:
>>>>
>>>>   <!-- [rfced] ... -->
>>>>
>>>>   These questions will also be sent in a subsequent email.
>>>>
>>>> *  Changes submitted by coauthors
>>>>
>>>>   Please ensure that you review any changes submitted by your
>>>>   coauthors.  We assume that if you do not speak up that you
>>>>   agree to changes submitted by your coauthors.
>>>>
>>>> *  Content
>>>>
>>>>   Please review the full content of the document, as this cannot
>>>>   change once the RFC is published. Please pay particular attention to:
>>>>   - IANA considerations updates (if applicable)
>>>>   - contact information
>>>>   - references
>>>>
>>>> *  Copyright notices and legends
>>>>
>>>>   Please review the copyright notice and legends as defined in
>>>>   RFC 5378 and the Trust Legal Provisions
>>>>   (TLP – https://trustee.ietf.org/license-info/).
>>>>
>>>> *  Semantic markup
>>>>
>>>>   Please review the markup in the XML file to ensure that elements of
>>>>   content are correctly tagged.  For example, ensure that <sourcecode>
>>>>   and <artwork> are set correctly.  See details at
>>>>   <https://xml2rfc.tools.ietf.org/xml2rfc-doc.html>.
>>>>
>>>> *  Formatted output
>>>>
>>>>   Please review the PDF, HTML, and TXT files to ensure that the
>>>>   formatted output, as generated from the markup in the XML file, is
>>>>   reasonable.  Please note that the TXT will have formatting
>>>>   limitations compared to the PDF and HTML.
>>>>
>>>>
>>>> Submitting changes
>>>> ------------------
>>>>
>>>> To submit changes, please reply to this email with one of the
>>>> following,
>>>> using ‘REPLY ALL’ as all the parties CC’ed on this message need to see
>>>> your changes:
>>>>
>>>> An update to the provided XML file
>>>> — OR —
>>>> An explicit list of changes in this format
>>>>
>>>> Section # (or indicate Global)
>>>>
>>>> OLD:
>>>> old text
>>>>
>>>> NEW:
>>>> new text
>>>>
>>>> You do not need to reply with both an updated XML file and an explicit
>>>> list of changes, as either form is sufficient.
>>>>
>>>> We will ask a stream manager to review and approve any changes that seem
>>>> beyond editorial in nature, e.g., addition of new text, deletion of
>>>> text,
>>>> and technical changes.  Information about stream managers can be found
>>>> in
>>>> the FAQ.  Editorial changes do not require approval from a stream
>>>> manager.
>>>>
>>>>
>>>> Approving for publication
>>>> --------------------------
>>>>
>>>> To approve your RFC for publication, please reply to this email s
>>>> tating that you approve this RFC for publication.  Please use ‘REPLY
>>>> ALL’
>>>> as all the parties CC’ed on this message need to see your approval.
>>>>
>>>>
>>>> Files
>>>> -----
>>>>
>>>> The files are available here:
>>>>   https://www.rfc-editor.org/authors/rfc9033.xml
>>>>   https://www.rfc-editor.org/authors/rfc9033.html
>>>>   https://www.rfc-editor.org/authors/rfc9033.pdf
>>>>   https://www.rfc-editor.org/authors/rfc9033.txt
>>>>
>>>> Diff file of the text:
>>>>   https://www.rfc-editor.org/authors/rfc9033-diff.html
>>>>
>>>> Diff of the XML:
>>>>   https://www.rfc-editor.org/authors/rfc9033-xmldiff.html
>>>>
>>>> Tracking progress
>>>> -----------------
>>>>
>>>> The details of the AUTH48 status of your document are here:
>>>>   https://www.rfc-editor.org/auth48/rfc9033
>>>>
>>>> Please let us know if you have any questions.
>>>>
>>>> Thank you for your cooperation,
>>>>
>>>> RFC Editor
>>>>
>>>> --------------------------------------
>>>> RFC9033 (draft-ietf-6tisch-msf-18)
>>>>
>>>> Title            : 6TiSCH Minimal Scheduling Function (MSF)
>>>> Author(s)        : T. Chang, Ed., M. Vucinic, X. Vilajosana, S.
>>>> Duquennoy, D. Dujovne
>>>> WG Chair(s)      : Pascal Thubert, Thomas Watteyne
>>>> Area Director(s) : Erik Kline, Éric Vyncke
>>>>
>>>>
>>>
>>> --
>>> ——————————————————————————————————————
>>> Stay healthy, stay optimistic!
>>>
>>> Dr. Tengfei, Chang
>>> Postdoctoral Research Engineer, Inria
>>>
>>> www.tchang.org/
>>> ——————————————————————————————————————
>>>
>>>
>>
>> --
>> ——————————————————————————————————————
>> Stay healthy, stay optimistic!
>>
>> Dr. Tengfei, Chang
>> Postdoctoral Research Engineer, Inria
>>
>> www.tchang.org/
>> ——————————————————————————————————————
>>
>>
>
> --
> ——————————————————————————————————————
> Stay healthy, stay optimistic!
>
> Dr. Tengfei, Chang
> Postdoctoral Research Engineer, Inria
>
> www.tchang.org/
> ——————————————————————————————————————
> --
> c310 mailing list
> [e-mail]
> https://www.rfc-editor.org/mailman/listinfo/c310
>


-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
([phone]
[e-mail] <[e-mail]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
[image: Universitat Oberta de Catalunya]
­

-- 



INFORMACIÓ SOBRE PROTECCIÓ DE DADES DE LA UNIVERSITAT OBERTA DE 
CATALUNYA (UOC)

Us informem que les vostres dades identificatives i les 
contingudes en els missatges electrònics i fitxers adjunts es poden 
incorporar a les nostres bases de dades amb la finalitat de gestionar les 
relacions i comunicacions vinculades a la UOC, i que es poden conservar 
mentre es mantingui la relació. Si ho voleu, podeu exercir el dret a 
accedir a les vostres dades, rectificar-les i suprimir-les i altres drets 
reconeguts normativament adreçant-vos a l'adreça de correu emissora o a 
[e-mail] <mailto:[e-mail]>.

Aquest missatge i qualsevol 
fitxer que porti adjunt, si escau, tenen el caràcter de confidencials i 
s'adrecen únicament a la persona o entitat a qui s'han enviat.

Així 
mateix, posem a la vostra disposició un delegat de protecció de dades que 
no només s'encarregarà de supervisar tots els tractaments de dades de la 
nostra entitat, sinó que us podrà atendre per a qualsevol qüestió 
relacionada amb el tractament de dades. La seva adreça de contacte és 
[e-mail] <mailto:[e-mail]>.
INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE 
LA UNIVERSITAT OBERTA DE CATALUNYA (UOC)
Os informamos de que vuestros 
datos identificativos y los contenidos en los mensajes electrónicos y 
ficheros adjuntos pueden incorporarse a nuestras bases de datos con el fin 
de gestionar las relaciones y comunicaciones vinculadas a la UOC, y de que 
pueden conservarse mientras se mantenga la relación. Si lo deseáis, podéis 
ejercer el derecho a acceder a vuestros datos, rectificarlos y suprimirlos 
y otros derechos reconocidos normativamente dirigiéndoos a la dirección de 
correo emisora o a [e-mail] <mailto:[e-mail]>.
Este mensaje y 
cualquier fichero que lleve adjunto, si procede, tienen el carácter de 
confidenciales y se dirigen únicamente a la persona o entidad a quien se 
han enviado.
Así mismo, ponemos a vuestra disposición a un delegado de 
protección de datos que no solo se encargará de supervisar todos los 
tratamientos de datos de nuestra entidad, sino que podrá atenderos para 
cualquier cuestión relacionada con el tratamiento de datos. Su dirección de 
contacto es [e-mail] <mailto:[e-mail]>.


UNIVERSITAT OBERTA DE 
CATALUNYA (UOC) DATA PROTECTION INFORMATION
Your personal data and the data 
contained in your email messages and attached files may be stored in our 
databases for the purpose of maintaining relations and communications 
linked to the UOC, and the data may be stored for as long as these 
relations and communications are maintained. If you so wish, you can 
exercise your rights to access, rectification and erasure of your data, and 
any other legally held rights, by writing to the sender’s email address or 
to [e-mail] <http://[e-mail]>.
This message and, where 
applicable, any attachments are confidential and addressed solely to the 
individual or organization they were sent to.
The UOC has a data protection 
officer who not only supervises the data processing carried out at the 
University, but who will also respond to any questions you may have about 
this data processing. You can contact our data protection officer by 
writing to [e-mail] <http://[e-mail]>.