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

[Simon Duquennoy <[e-mail]>]

Dear Jean,

I approve the document for publication in its current state.

Best regards,
Simon

> On 23 Apr 2021, at 05:13, Xavi Vilajosana Guillen <[e-mail]> wrote:
> 
> Dear Jean,
> 
> I also approve the publication of this document in its current state.
> 
> kind regards
> 
> Missatge de Tengfei Chang <[e-mail] <mailto:[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] <mailto:[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 <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.txt>
>    https://www.rfc-editor.org/authors/rfc9033.pdf <https://www.rfc-editor.org/authors/rfc9033.pdf>
>    https://www.rfc-editor.org/authors/rfc9033.html <https://www.rfc-editor.org/authors/rfc9033.html>
>    https://www.rfc-editor.org/authors/rfc9033.xml <https://www.rfc-editor.org/authors/rfc9033.xml>
>    https://www.rfc-editor.org/authors/rfc9033-diff.html <https://www.rfc-editor.org/authors/rfc9033-diff.html> (all changes)
>    https://www.rfc-editor.org/authors/rfc9033-auth48diff.html <https://www.rfc-editor.org/authors/rfc9033-auth48diff.html> (all AUTH48 changes)
>    https://www.rfc-editor.org/authors/rfc9033-lastdiff.html <https://www.rfc-editor.org/authors/rfc9033-lastdiff.html> (these changes)
>    https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html <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] <mailto:[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.txt>
>>    https://www.rfc-editor.org/authors/rfc9033.pdf <https://www.rfc-editor.org/authors/rfc9033.pdf>
>>    https://www.rfc-editor.org/authors/rfc9033.html <https://www.rfc-editor.org/authors/rfc9033.html>
>>    https://www.rfc-editor.org/authors/rfc9033.xml <https://www.rfc-editor.org/authors/rfc9033.xml>
>>    https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html <https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html> (these changes side by side)
>>    https://www.rfc-editor.org/authors/rfc9033-auth48diff.html <https://www.rfc-editor.org/authors/rfc9033-auth48diff.html> (changes made during AUTH48) 
>>    https://www.rfc-editor.org/authors/rfc9033-diff.html <https://www.rfc-editor.org/authors/rfc9033-diff.html> (all changes made to the text)
>>    https://www.rfc-editor.org/authors/rfc9033-xmldiff.html <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] <mailto:[e-mail]>.
>> 
>> 
>> TC: Thanks for pointing this out. The email will not be available in a few months, could you change to [e-mail] <mailto:[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] <mailto:[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 <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 <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/ <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 <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] <mailto:[e-mail]>)
>>>    *  Olaf Landsiedel (Chalmers University, [e-mail] <mailto:[e-mail]>)
>>>    *  Yasuyuki Tanaka (Inria-Paris, [e-mail] <mailto:[e-mail]>)
>>> 
>>> Current:
>>>    Beshr Al Nahas
>>>    Chalmers University
>>> 
>>>    Email: [e-mail] <mailto:[e-mail]>
>>> 
>>> 
>>>    Olaf Landsiedel
>>>    Chalmers University
>>> 
>>>    Email: [e-mail] <mailto:[e-mail]>
>>> 
>>> 
>>>    Yasuyuki Tanaka
>>>    Inria-Paris
>>> 
>>>    Email: [e-mail] <mailto:[e-mail]>
>>> -->
>>> 
>>> TC: This looks good! Also please update the following contact info
>>> 
>>> OLD: 
>>> 
>>>    Yasuyuki Tanaka 
>>>    Inria-Paris
>>> 
>>>    Email: [e-mail] <mailto:[e-mail]>
>>> 
>>> NEW: 
>>> 
>>>    Yasuyuki Tanaka
>>>    Toshiba
>>> 
>>>    Email: [e-mail] <mailto:[e-mail]>
>>> 
>>> Thank you.
>>> 
>>> RFC Editor/jm/ar
>>> 
>>> 
>>> On Apr 20, 2021, [e-mail] <mailto:[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/ <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/ <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 <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.xml>
>>>   https://www.rfc-editor.org/authors/rfc9033.html <https://www.rfc-editor.org/authors/rfc9033.html>
>>>   https://www.rfc-editor.org/authors/rfc9033.pdf <https://www.rfc-editor.org/authors/rfc9033.pdf>
>>>   https://www.rfc-editor.org/authors/rfc9033.txt <https://www.rfc-editor.org/authors/rfc9033.txt>
>>> 
>>> Diff file of the text:
>>>   https://www.rfc-editor.org/authors/rfc9033-diff.html <https://www.rfc-editor.org/authors/rfc9033-diff.html>
>>> 
>>> Diff of the XML: 
>>>   https://www.rfc-editor.org/authors/rfc9033-xmldiff.html <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 <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/ <http://www.tchang.org/>
>>> ——————————————————————————————————————
>>> 
>>> 
>> 
>> 
>> -- 
>> ——————————————————————————————————————
>> Stay healthy, stay optimistic!
>> 
>> Dr. Tengfei, Chang
>> Postdoctoral Research Engineer, Inria
>> 
>> www.tchang.org/ <http://www.tchang.org/>
>> ——————————————————————————————————————
> 
> 
> -- 
> ——————————————————————————————————————
> Stay healthy, stay optimistic!
> 
> Dr. Tengfei, Chang
> Postdoctoral Research Engineer, Inria
> 
> www.tchang.org/ <http://www.tchang.org/>
> ——————————————————————————————————————
> -- 
> c310 mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.rfc-editor.org/mailman/listinfo/c310 <https://www.rfc-editor.org/mailman/listinfo/c310>
> 
> 
> -- 
> Dr. Xavier Vilajosana
> Wireless Networks Lab
> Internet Interdisciplinary Institute (IN3)
> Professor
> ([phone]
> [e-mail] <mailto:[e-mail]>
> http://xvilajosana.org <http://xvilajosana.org/>
> http://wine.rdi.uoc.edu <http://wine.rdi.uoc.edu/>
> Parc Mediterrani de la Tecnologia 
> Av Carl Friedrich Gauss 5, B3 Building
> 08860 Castelldefels (Barcelona). Catalonia. Spain
>   
> 
> 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]/>.
> 
> -- 
> c310 mailing list
> [e-mail]
> https://www.rfc-editor.org/mailman/listinfo/c310