[C310] Fwd: [AD] Re: AUTH48 [JM]: RFC 9030 <draft-ietf-6tisch-architecture-30.txt> NOW AVAILABLE

[Alice Russo <[e-mail]>]

Forwarding to the list. (2 of 2)

> Begin forwarded message:
> 
> From: [e-mail]
> Subject: [AD] Re: AUTH48 [JM]: RFC 9030 <draft-ietf-6tisch-architecture-30.txt> NOW AVAILABLE
> Date: May 5, 2021 at 5:08:24 PM PDT
> To: [e-mail]
> Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
> 
> Pascal, Erik (as AD),
> 
> *Erik, please reply to #1 below.
> 
> While reviewing this document during AUTH48, please resolve
> the following questions, which are also in the XML file.
> 
> 1) <!-- [rfced] AD: Please review and let us know if you approve the
> changes made after -28 of this draft was approved. They are shown
> in this diff file (comparing -28 and -30):
> https://www.ietf.org/rfcdiff?url1=draft-ietf-6tisch-architecture-28&url2=draft-ietf-6tisch-architecture-30
> 
> FYI, in the questions that follow, "Original" refers to version 30.
> Also, version 30 was used for the original in the diff file
> for reviewing the RFC Editor's updates to the text.
> -->
> 
> 
> 2) <!-- [rfced]  FYI, the authors' comments in the XML file have been
> marked with [auth].  Please let us know if any updates are needed
> based on those comments; if not, they will be removed.
> -->
> 
> 
> 3) <!-- [rfced] Please insert any keywords (beyond those that 
> appear in the title) for use on https://www.rfc-editor.org/search.
> -->
> 
> 
> 4) <!--[rfced] We suggest all instances of "Layer-2" and "Layer-3" 
> be updated to "Layer 2" and "Layer 3" (no hyphen), in keeping with 
> common usage in RFCs including RFCs 8928 and 8929. Please let us 
> know if this change is acceptable.
> -->
> 
> 
> 5) <!-- [rfced]  The format of cell identification is inconsistent:
> [slotOffset, channelOffset] - 1 instance
> (slotOffset/channelOffset) - 1 instance
> slotOffset/channelOffset - 5 instances
> 
> How would you like it formatted?
> -->
> 
> 
> 6) <!-- [rfced] Section 2.1: May we remove "then" before"the IPv6 source 
> address" in this paragraph?
> 
> Original:
>   TrackID:  A TrackID is either globally unique, or locally unique to
>      the Track owner, in which case the identification of the owner
>      must be provided together with the TrackID to provide a full
>      reference to the Track. typically, the Track owner is the ingress
>      of the Track then the IPv6 source address of packets along the
>      Track can be used as identification of the owner and a local
>      InstanceID [RFC6550] in the namespace of that owner can be used as
>      TrackID.  If the Track is reversible, then the owner is found in
>      the IPv6 destination address of a packet coming back along the
>      Track. [...]
> 
> Perhaps (drop "then"):
>   TrackID:  A TrackID is either globally unique or locally unique to
>      the Track owner, in which case the identification of the owner
>      must be provided together with the TrackID to provide a full
>      reference to the Track.  Typically, the Track owner is the ingress
>      of the Track, the IPv6 source address of packets along the
>      Track can be used as identification of the owner, and a local
>      InstanceID [RFC6550] in the namespace of that owner can be used as
>      TrackID.  If the Track is reversible, then the owner is found in
>      the IPv6 destination address of a packet coming back along the
>      Track.  [...]
> -->
> 
> 
> 7) <!-- [rfced] We are having difficulty parsing the following 
> sentence in Section 3.2 ("...in turn perform proxy classical 
> ND operations..."): 
> 
> Current:
>   In the latter case, it leverages the
>   extended registration process defined in [RFC8505] to proxy the
>   6LoWPAN ND registration to the 6BBR on behalf of the LLN nodes, 
>   so that the 6BBR may in turn perform proxy classical ND 
>   operations over the backbone.
> 
> Perhaps:
>   In the latter case, it leverages the
>   extended registration process defined in [RFC8505] to proxy the
>   6LoWPAN ND registration to the 6BBR on behalf of the LLN nodes, 
>   so that the 6BBR may in turn perform classical ND operations 
>   over the backbone as a proxy.
> 
> Or perhaps:
>   In the latter case, it leverages the
>   extended registration process defined in [RFC8505] to proxy the
>   6LoWPAN ND registration to the 6BBR on behalf of the LLN nodes, 
>   so that the 6BBR may in turn proxy classical ND operations over
>   the backbone.
> -->
> 
> 
> 8) <!-- [rfced]  We have made the following change in Section 3.3 
> to improve readability (by rephrasing "lots of lesser importance 
> measurements" and the subsequent list).  Please let us know if 
> further changes are necessary.
> 
> Original:
>   Examples of such use cases in industrial environments include
>   plant setup and decommissioning, as well as monitoring of lots 
>   of lesser importance measurements such as corrosion and events 
>   and mobile workers accessing local devices.
> 
> Current:
>   Examples of such use cases in industrial environments include 
>   plant setup and decommissioning, as well as monitoring a 
>   multiplicity of minor notifications such as corrosion 
>   measurements, events, and access of local devices by mobile 
>   workers.
> -->
> 
> 
> 9) <!-- [rfced]  We have made the following changes in Section 3.4 
> to improve readability. Please let us know if other changes 
> are necessary.
> 
> Original:
>   A scheduling operation attributes cells in a Time-Division-
>   Multiplexing (TDM) / Frequency-Division Multiplexing (FDM) matrix
>   called the Channel distribution/usage (CDU) to either individual
>   transmissions or as multi-access shared resources.  
> 
> Current:
>   A scheduling operation allocates cells in a TDM/FDM matrix 
>   called a CDU either to individual transmissions or as 
>   multi-access shared resources.
> -->
> 
> 
> 10) <!-- [rfced] We have made the following changes in Section 3.4 
> to improve readability. Please let us know if other changes 
> are necessary. 
> 
> Original:
>   From the standpoint of a 6TiSCH node (at the MAC layer), 
>   its schedule is the collection of the timeslots at which 
>   it must wake up for transmission, and the channels to which 
>   it should either send or listen at those times. 
> 
> Current:
>   At the MAC layer, the schedule of a 6TiSCH node is the 
>   collection of the timeslots at which it must wake up for
>   transmission and of the channels to which it should either 
>   send or listen at those times. 
> -->
> 
> 
> 11) <!-- [rfced]  In the following, was "convergecast routing"
> intended as "convergent routing"?
> 
> Original:
>   Static Scheduling with minimal configuration one is the
>   only one that is expected in all implementations, since it 
>   provides a simple and solid basis for convergecast routing 
>   and time distribution.
> -->
> 
> 
> 12) <!-- [rfced] May "combination" be used here instead of "conjunction"? 
> The word choice seems odd, as the latter means things occurring at the 
> same point in time or space.
> 
> Current:
>   The reference stack presented in this document was implemented and
>   interop-tested by a conjunction of open source, IETF, and ETSI efforts.
> 
> Perhaps:
>   The reference stack presented in this document was implemented and
>   interop-tested by a combination of open source, IETF, and ETSI efforts.
> -->
> 
> 
> 13) <!-- [rfced]  Given that RPL specifies multiple sequence numbers,
> which sequence number is meant below?
> 
> Current:
>   The leaf indicates that it requires reachability services for
>   the Registered Address from a Routing Registrar by setting an 'R' flag
>   in the Extended Address Registration Option [RFC8505], and it
>   provides a TID that maps to a sequence number in Section 7 of RPL
>   [RFC6550].
> -->
> 
> 
> 14) <!-- [rfced] Please clarify "device Unique ID (from 6LoWPAN ND)".
> 
> Current (Section 4.2.2):
>   As detailed in
>   Section 4.1, the combined 6LoWPAN ND 6LBR and Root of the RPL network
>   learn information such as the device Unique ID (from 6LoWPAN ND) and
>   the updated Sequence Number (from RPL), and perform 6LoWPAN ND proxy
>   registration to the 6BBR on behalf of the LLN nodes.
> 
> Section 4.1.2 talks about associating the unique ID from the 
> EDAR/EDAC exchange.  There is no explicit "Unique ID" in 6LoWPAN ND. 
> Perhaps this was intended to be about the ROVR? It "[e]nables the 
> correlation between multiple attempts to register the same IPv6 
> Address" [RFC8505], which takes the place of an EUI-64 (IEEE 
> extended 64-bit address) in this updated EDA message format.
> 
> Current (Section 4.1.2):
>   When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL Root
>   functionalities are co-located in order that the address of the 6LBR
>   is indicated by RPL DODAG Information Object (DIO) messages and to
>   associate the unique ID from the Extended Duplicate Address Request/
>   Confirmation (EDAR/EDAC) exchange [RFC8505] with the state that is
>   maintained by RPL.
> -->
> 
> 
> 15) <!-- [rfced] "rendez-vous slot" is not mentioned in [RFC9033] 
> nor [RFC8180]. How should this be updated? Perhaps "timeslot"?
> 
> Original:
>   ... MSF uses the
>   rendez-vous slot from [RFC8180] for network discovery, neighbor
>   discovery, and any other broadcast.
> -->
> 
> 
> 16) <!--  [rfced]  Because "iterates" includes the meaning of repeatedly,
> we have updated this sentence as follows; please review.
> 
> Current:
>   A CDU matrix iterates over and over with a well-known channel rotation
>   called the hopping sequence.
> 
> Perhaps:
>   A CDU matrix iterates over a well-known channel rotation called the 
>   hopping sequence.
> -->
> 
> 
> 17) <!-- [rfced]  We are having difficulty parsing the following 
> sentence from Section 4.3.6, specifically "and preexists to".
> 
> Current:
>   This is as opposed to Static Scheduling, which refers to the 
>   preprogrammed mechanism that is specified in [RFC8180] and 
>   preexists to the distribution of the chunk formatting.
> 
> Perhaps:
>   This is as opposed to Static Scheduling, which refers to the 
>   preprogrammed mechanism specified in [RFC8180] and which 
>   existed before the distribution of chunk formatting.
> -->
> 
> 
> 18) <!-- [rfced]  When the text says "6top layer", should it say
> "6top sublayer" instead?
> 
> For example:
>   The aggregation of the cells between a node and a peer forms a 
>   bundle that the 6top layer uses to implement the abstraction of 
>   a link for IP. 
> -->
> 
> 
> 19) <!-- [rfced]  It is not clear what is meant by the slash between
> [RFC4080] and [RFC5974] in Section 4.4.4. Does it mean "and/or"?
> 
> Original:
>   This hop-by-hop reservation mechanism is expected to be similar in
>   essence to [RFC3209] and/or [RFC4080]/[RFC5974].
> -->
> 
> 
> 20) <!-- [rfced]  We are having difficulty parsing the following
> sentence in Section 4.5.2:  
> 
> Current:
>   For a given iteration of the device schedule, the effective 
>   channel of the cell is obtained by following in a loop a 
>   well-known hopping sequence that started at Epoch time at the 
>   channelOffset of the cell, which results in a rotation of the 
>   frequency that is used for transmission.  
> 
> Perhaps:
>   For a given iteration of the device schedule, the effective 
>   channel of the cell is obtained by looping through a well-known 
>   hopping sequence beginning at Epoch time and starting at the 
>   cell's channelOffset, which results in a rotation of the frequency 
>   that is used for transmission.  
> -->
> 
> 
> 21) <!-- [rfced]  FYI, we have updated the reference to draft-rahul-roll-mop-ext
> with draft-ietf-draft-ietf-roll-capabilities, which replaced it.  
> Please let us know if other changes are necessary.
> -->
> 
> 
> 22) <!-- [rfced] FYI, we have updated the reference to draft-selander-ace-cose-ecdhe
> with draft-ietf-lake-edhoc, which replaced it.
> Please let us know if other changes are necessary.
> -->
> 
> 
> 23) <!-- [rfced] How should this reference be updated?
> https://www.hartcomm.org currently does not exist, but it recently
> was redirecting to https://fieldcommgroup.org/. (The redirect page said 
> "HART Communication Foundation is now FieldComm Group".)
> 
> Is there a specific page from https://fieldcommgroup.org/ to reference,
> or perhaps change to IEC 62591 as shown below?
> 
> Original:
>   [WirelessHART]
>              www.hartcomm.org, "Industrial Communication Networks -            
>              Wireless Communication Network and Communication Profiles         
>              - WirelessHART - IEC 62591", 2010.
> 
> Perhaps (as in RFC 8578):
>   [WirelessHART]
>              International Electrotechnical Commission, "Industrial
>              networks - Wireless communication network and
>              communication profiles - WirelessHART(TM)",
>              IEC 62591:2016, March 2016.
> -->
> 
> 
> 24) <!-- [rfced]  Similar question as above. We have updated this
> reference as follows; please review.
> 
> Original:
>   [HART]     www.hartcomm.org, "Highway Addressable remote Transducer,         
>              a group of specifications for industrial process and              
>              control devices administered by the HART Foundation".
> 
> Current:
>   [HART]     FieldComm Group, "HART",
>              <https://fieldcommgroup.org/technologies/hart>.
> -->
> 
> 
> 25) <!-- [rfced] FYI, for [ISA100.11a] the provided URL 
> (http://www.isa.org/Community/SP100WirelessSystemsforAutomation) does not work.
> We have updated this to the following URL, which is a link to the standard:
> https://www.isa.org/products/ansi-isa-100-11a-2011-wireless-systems-for-industr 
> Please let us know any further updates.
> (The IEC number brings up the following: https://webstore.iec.ch/publication/65581)
> -->
> 
> 
> 26) <!-- [rfced] The URL that was provided for [IEC62439] shows that it's 
> withdrawn. Please let us know if any updates are needed. 
> 
> Current:
>   [IEC62439] IEC, "Industrial communication networks - High
>              availability automation networks - Part 3: Parallel
>              Redundancy Protocol (PRP) and High-availability Seamless
>              Redundancy (HSR)", IEC 62439-3, 2012,
>              <https://webstore.iec.ch/publication/7018>.
> -->
> 
> 
> 27) <!--[rfced] FYI, we have reordered the Acknowledgments and 
> Contributors sections to match RFC style (per RFC 7322). 
> This diff file compares an altered original so that it's easier 
> to review the changes in these sections:
> https://www.rfc-editor.org/authors/rfc9030-alt-diff.html
> 
> Original:
>   7.  Acknowledgments
>     7.1.  Contributors
>     7.2.  Special Thanks
>     7.3.  And Do not Forget
> 
> Current:
>   Acknowledgments
>     Special Thanks    [excluded from the Table of Contents]
>     And Do Not Forget [excluded from the Table of Contents]
>   Contributors
> -->
> 
> 
> Thank you.
> 
> RFC Editor/jm/ar
> 
> 
> On May 5, 2021, [e-mail] wrote:
> 
> *****IMPORTANT*****
> 
> Updated 2021/05/05
> 
> 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/rfc9030.xml
>  https://www.rfc-editor.org/authors/rfc9030.html
>  https://www.rfc-editor.org/authors/rfc9030.pdf
>  https://www.rfc-editor.org/authors/rfc9030.txt
> 
> Diff file of the text:
>  https://www.rfc-editor.org/authors/rfc9030-diff.html
> 
> Diff of the XML: 
>  https://www.rfc-editor.org/authors/rfc9030-xmldiff1.html
> 
> The following files are provided to facilitate creation of your own 
> diff files of the XML.  
> 
> Initial XMLv3 created using XMLv2 as input:
>  https://www.rfc-editor.org/authors/rfc9030.original.v2v3.xml 
> 
> XMLv3 file that is a best effort to capture v3-related format updates 
> only: 
>  https://www.rfc-editor.org/authors/rfc9030.form.xml
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>  https://www.rfc-editor.org/auth48/rfc9030
> 
> Please let us know if you have any questions.  
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9030 (draft-ietf-6tisch-architecture-30)
> 
> Title            : An Architecture for IPv6 over the Time-Slotted Channel Hopping (TSCH) Mode of IEEE 802.15.4
> Author(s)        : P. Thubert
> WG Chair(s)      : Pascal Thubert, Thomas Watteyne
> Area Director(s) : Erik Kline, Éric Vyncke
>