Pascal, I did review 21.
Cheers, Andy On Sat, Jun 22, 2019 at 12:50 PM Pascal Thubert (pthubert) < [email protected]> wrote: > Hello Andrew > > Many thanks for the huge investment of time you spent on our technology. I > hope you found the context of interest. > > Gory provided a similar feedback and I published 21 to address the > specific point of references. Some were removed, some are now WG docs that > were not, and the language was clarified to indicate some references are > given as examples of how a particular feature could be achieved. > > Would you please pick 21 and reassess your main comment below in the light > of that update ? > > All the best, > > Pascal > > Le 22 juin 2019 à 18:17, Andrew G. Malis <[email protected]> a écrit : > > One quick follow-up to my review - I just noticed that while the draft's > intended status (in the draft) is Informational, the Datatracker lists it > as Proposed Standard. The Datatracker should be updated. > > Thanks, > Andy > > On Fri, Jun 21, 2019 at 5:28 PM Andrew G. Malis <[email protected]> wrote: > >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. >> The Routing Directorate seeks to review all routing or routing-related >> drafts as they pass through IETF last call and IESG review, and sometimes >> on special request. The purpose of the review is to provide assistance to >> the Routing ADs. For more information about the Routing Directorate, please >> see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Although these comments are primarily for the use of the Routing ADs, it >> would be helpful if you could consider them along with any other IETF Last >> Call comments that you receive, and strive to resolve them through >> discussion or by updating the draft. >> >> Document: draft-ietf-6tisch-architecture-21.txt >> Reviewer: Andy Malis >> Review Date: 21 June 2019 >> IETF LC End Date: 26 June 2019 >> Intended Status: Informational >> >> Summary: >> >> I have significant concerns about this document and recommend that the >> Routing ADs discuss these issues further with the authors. >> >> Overall comments: >> >> For this review, I was asked to "Focus on the impact/implications of the >> architecture on routing/forwarding." I will leave minor details such as >> editorial nits to others. >> >> This is a very long and detailed document, and I have no prior experience >> with IEEE 802.15.4, 6lowpan, 6tisch, RPL, and related technologies. To >> prepare for this review I did some basic background reading, such an online >> introduction to IEEE 802.15.4 and RFC 7554. So in this review, I really >> don't feel competent to comments on some of the more technical aspects >> related to those technologies. However, I do feel competent to comment from >> the viewpoint of a naive reader with a general background in routing. As a >> naive reader, I appreciated the introduction to the technology in sections >> 1-3. >> >> The primary editor of this draft is also active in the DetNet working >> group, and leverages the work being done there to support the work in this >> draft. The draft does reference some DetNet technologies that have not yet >> been completely specified to the point where they can be implemented such >> as PREOF (Packet Replication, Elimination and Ordering Functions), although >> such specifications are an expected deliverable in the DetNet WG. So a full >> implementation of this architecture may have to wait for the completion of >> the related DetNet specification work. >> >> With respect to routing and forwarding, this draft builds upon the work >> already done in the 6lowpan WG, such as RPL for routing and 6lowpan header >> compression. It adds the necessary scheduling and time synchronization >> functions needed to support the TSCH aspects of IEEE 802.15.4, which is the >> point of this work. But other than these new aspects, routing and >> forwarding should continue to work to the extent that they work in the >> 6lowpan specifications. My one concern regarding IPv6 forwarding is the use >> of draft-svshah-tsvwg-lln-diffserv-recommendations in section 4.7.2. See my >> major issues below for more on this concern. >> >> Major issues: >> >> I'm concerned with the number of references to individual drafts (even if >> informational) in a major architecture specification, since the rest of the >> work on this technology, including solution documents, will rest on the >> correctness and completeness of the architecture. If these references are >> essential, then I would recommend that publication of the architecture be >> delayed until it's more clear whether these individual drafts will be >> adopted by a WG, and any abandoned individual drafts be removed. Otherwise, >> how can a published architecture depend on unpublished, abandoned work? >> Speaking of which, I note that one of those referenced drafts, >> draft-svshah-tsvwg-lln-diffserv-recommendations, hasn't been updated in >> over four years, and should either be removed or adopted by the 6tisch WG. >> Another, draft-thubert-bier-replication-elimination, hasn't been updated in >> over a year. Is it still alive? At least the remaining individual drafts >> have fairly recent updates. >> >> A related concern is that this draft specifically depends on work to be >> done elsewhere in and outside of the IETF that is currently unchartered >> (see section A.2). Many of the individual drafts discussed in the previous >> paragraph are referenced in this section. To the extent that 6tisch depends >> on this work for its own eventual success, the WG may wish to evaluate if >> there are alternative ways to have the necessary work completed, such as >> using an alternative solution or rechartering the WG to include necessary >> work that looks unlikely to happen elsewhere. >> >> Minor issue: >> >> To the extent that this architecture makes use of centralized control >> mechanisms such as PCE, the security considerations should mention this >> dependency and perhaps have a short discussion of effects on the network if >> connectivity between the centralized controller and the network nodes is >> lost, either due to an outage or a deliberate attack, and how such effects >> could be mitigated. >> >> Thanks, >> Andy >> >>
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
