Subject: [6tisch] #36 (architecture): Last call comments: MCR comments

From: "6tisch issue tracker" <[email-masked]>
Date: Tue, 07 Apr 2015 07:12:38 -0000

#36: Last call comments: MCR comments

 If it is going to proceed in volumes (I suggest "editions" is the correct
 term), then I think that most things which are speculation should either
 be removed to a later edition, or something specific should be said, with
 the understanding that it might change later. Presciption rather than
 speculation should be the goal.

 1) I find it odd that there is so much emphasis of the backbone router
 function... IN THE ABSTRACT. I suggest that the last sentence: Backbone
 Routers perform proxy Neighbor Discovery operations over the backbone on
 behalf of the wireless devices, so they can share a same subnet and appear
 to be connect= ed to the same backbone as classical devices. be removed
 from the abstract. Probably by the end of this review that I'll suggest a
 different thing that could be included.

 2) end of section 1, what does it mean: "in the round of this document."?

 3) I don't think that [I-D.ietf-roll-rpl-industrial-applicability] will
 ever get published. If there is terminology there that we still need, I
 think it should be extracted into the 6tisch-terminology document. While
 it is an informative reference, the fewer references to IDs the better in
 my opinion.

 4) section 4, seems to ignore the possibility to simply run RPL across the
 subnet backbone. I understand why the ND mechanism are nice, because they
 permit the backbone to just be ethernet, but the case where the backbone
 is really dedicated (and given VLANs, it's hard to know why you'd do
 anything else), one can just run RPL across it. I think that this
 ultimately matters to any of the later architecture, but I wouldn't want
 to later argue with someone who might claim that the newer ND mechanisms
 are REQUIRED.

 5) the security words include: "will be studied in the next round of this
 document." and I'm not sure what a reader should make of this. Perhaps it
 should simply summarize section 13 in one sentence and say that PANA is a
 possibility, but that the choice of protocol is out of scope for this
 document. (well, 5.0 then explains about volumes. So perhaps the
 explanation about volumes should go much earlier, most probably into the
 abstract as well. Also, will the volumes build on the previous work, or
 will they replace it? if they will replace it, then I think correct word
 is "edition")

 6) I don't think that the Note: about DETNET really still belongs in a
 document that might be read in 5-10 years. Maybe a reference to the
 charter for DETNET would make more sense.

 7) I don't understand why PANA lives above ACE in figure 3. I think that
 ACE lives above CoAP/DICE (DTLS is missing, but perhaps understood by
 DICE). I think that while technically PANA lives on top of UDP, there is
 of course a layer of EAP, and TLS above it, and perhaps a layer of ACE as
 well. So I'm not saying that this picture needs to be changed, just to
 observe this.

 8) I think remove: "COMI and the dependent specifications are still work
 in progress, but getting stable enough at the time of this writing."

 9) I am happy with the paragraph on join security in section 5.

 10) I think that this is confused (bottom of page 9, section 6):

     This architecture expects that a 6LoWPAN node can connect as a leaf to
 a RPL network, where the leaf support is the minimal functionality to
 connect as a host to a RPL network without the need to participate to the
 full routing protocol. The support of leaf can be implemented as a minor
 increment to 6LoWPAN ND, with the additional capability to carry a
 sequence number that is used to track the movements of the device, and
 optionally some information about the RPL topology that this device will
 join.

 I think that either a minimal RPL permits leaf attachment OR the EARO
 6lowPAN ND. I don't think that both are needed?

 I'm also think that some may confuse this with the join process
 requirements, which maybe this started out describing, but I don't think
 that does that. It might describe how nodes which have already joined
 (been imprinted upon the newtork) can form a network.

 Figure 4 seems to do it all without RPL, even though RPL is mentioned, and
 I don't understand that.

 11) Reading section 6.1/6.2, I wonder if this just too much detail for an
 architecture. I also don't see how VLANID is involved (we are talking
 802.1q here, right?). I am not saying that the TID and EARO aren't good
 things; I'm just finding that they just JUMP out here, and I'm not sure a
 reader has any idea why they are here yet. I think that 6.3 should be far
 more specific: proxy-ND? LISP? or MIPv6? which is going to be used... I
 think that reviewers will push back here a lot.

 12) I think that 6.4 needs be prescriptive, not speculative/suggestive.
 6.5 needs to say, "the 6LBR and RPL root functionality are to be co-
 located in order that the address of the 6LBR be indicated by RPL DIO
 messages"

 13) I think that 6.6 is saying that SEND can not be applied. I think it
 should be clearer in saying something like: "The threats against IPv6 ND
 as described in RFC3971 apply as well, but the solution can not work as
 the route over network does not permit direct peer to peer communication.
 As can be seen in Figure 4..."

 14) I think that the relevant parts of [I-D.ietf-roll-rpl-industrial-
 applicability] need to imported into this document, since this sure looks
 like a normative reference to me.

 15) section 8 seems to be really the key aspects of the architecture. I
 think that rather than say, "if the scheduling entity explicitely..." =3D>
 "hard". I think that it should instead say that there are hard cells and
 soft cells, and say that 6top can not move hard cells. (but, how would the
 PCE set them up, if 6top can't move them?)

 "6top contains a monitoring process which monitors the performance of
 cells, and can move a cell in the TSCH schedule when it performs bad."

 this seems pretty important an architectural thing, and I think it at
 least deserves it's own section number.

 16) 8.2, insert something to the effect: Most RPL Objective Functions
 require metrics about reachability, such as the ETX. 6top creates and
 maintains an abstract neighbor table, and this may be leveraged. ... This
 information ...

 " 6top also enables the RPL OF to influence the MAC behaviour, for
 instance by configuring the periodicity of IEEE802.15.4e Extended Beacons
 (EB's). By augmenting the EB periodicity, it is possible to change the
 network dynamics so as to improve the support of devices that may change
 their point of attachment in the 6TiSCH network. "

 But, we aren't using the Enhanced Beacons (they are enhanced, not
 extended, aren't they? or did I get that backwards again?) for production
 network use...

 I would write: Consideration was given towards finding a way to embed the
 Route Advertisements and the RPL DIO messages (both of which are
 multicast) into the IEEE802.15.4e Enhanced Beacons. It was determined that
 this produced undue timer coupling among layers, that the resulting packet
 size was potentially too large, and required it is not yet clear that
 there is any need for Enhanced Beacons in a production network.

 [and then go on to explain how to configure the LinkType, however, I think
 that this is too much detail for the architecture, and it needs to say
 something like: The 6TISCH adaptation document will explain the details of
 confuring a broadcast channel that can accomodate EB, RPL DIOs and Router
 Advertisements ]

 but, maybe I mis-understand the entire section.

 17) I think that 8.3 should actually say how the TSGI should be created,
 and also how the various layers can be synchronized such that the RPL
 management traffic can provide for the needed frame-based synchronization.
 I expect that this simply means that 6top needs to be able to
 trigger(override) the trickle timer if no other traffic has occured in
 "too long" a time.

 "After consultation with IEEE authors, it was asserted that 6TiSCH can
 make a full use of the octet to carry an integer value up to 0xFF."

 -> does this need some kind of clear liason statement?

 I think that the concepts introduced in section 6.4 and 6.5 should perhaps
 be more clearly. While not trying to duplicate the terminology document, I
 found the way that the CDU concept is introduced was awkward. Perhaps this
 isn't very important. Maybe moving figure 5 earlier?

 18) I think that the 4 scheduling paradigms should be mentioned in the
 introduction as well! To first order, I think that is perhaps the most
 important thing in the document.

 " If the size of a bundle is configured to fit an average amount of
 bandwidth, peak emissions will be destroyed."

 (I don't think the word you want is "destroyed". I think that it means
 that packets will be dropped, but I don't think that describing the
 dropped packets as destroyed is the correct IETF idiom here, even though
 it might be grammatically correct)

 19) 6TiSCH supports three different forwarding model, G-MPLS Track
 Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 Forwarding
 (6F).

 also should be mentioned in the introduction...

 20) last comment on section 13. (the bullet (*) has become an ASCII "A",
 the high bit was likely removed)

 Device Authentication: The JN and the JA mutually authenticate each other
 and establish a shared key, so as to ensure on-going authenticated
 communications. This may involve a server as a third party.

 I again say that this is incorrect, the JA will never be able to
 authenticate itself to the JN. It may be able to present some
 authorization from the network owner, that the JA is authorized to act on
 behalf of the network owner.

 Unless you consider un-authenticated DH exchange "authentication", or you
 decide that it's okay for the JA to just not accept any public (some kind
 of leap of faith), the JA will not have an identity that a JN will accept.

 I have also repeatedly complained that figure 10 is inaccurate, because it
 fails to depict that authorization begins before authentication finishes.
 Perhaps the second two unidirectional arrows are part of the
 authentication phase, I don't know.

 I suggest that the sentence:

 "The join protocol consists of three phases:"

 be replaced with:

 "The join protocol has three major activities:" ("phases" implies some
 ordering such that one phase might finish before the next begins, while
 activities implies no such ordering)

 I suggest that figure 10 be omitted.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-6tisch-
  [email-masked]     |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:               |    Version:
  architecture           |   Keywords:
 Severity:  In WG Last   |
  Call                   |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/36>
6tisch <http://tools.ietf.org/6tisch/>

---

From: "6tisch issue tracker" <[email-masked]>
Date: Tue, 07 Apr 2015 17:10:41 -0000

Comment (by [email-masked]):

 Replying to [ticket:36 shwethab@…]:
 >  If it is going to proceed in volumes (I suggest "editions" is the
 correct term), then I think that most things which are speculation should
 either be removed to a later edition, or something specific should be
 said, with the understanding that it might change later. Presciption
 rather than speculation should be the goal.

 We agreed on volume after all, since this is effectively volume 1 of a
 story to be continued

 This text is commented out in the abstract

 > 2) end of section 1, what does it mean: "in the round of this
 document."?

 Means volume, fixed. Says now
      " Hints are provided on a security framework that will be completed
 in
        an upcoming volume of this architecture."

 But this one is really key on why we do RPL on TSCH at 6TiSCH. I'd rather
 keep it.

 > 4) section 4, seems to ignore the possibility to simply run RPL across
 the subnet backbone. I understand why the ND mechanism are nice, because
 they permit the backbone to just be ethernet, but the case where the
 backbone is really dedicated (and given VLANs, it's hard to know why you'd
 do anything else), one can just run RPL across it. I think that this
 ultimately matters to any of the later architecture, but I wouldn't want
 to later argue with someone who might claim that the newer ND mechanisms
 are REQUIRED.

 I agree, anything goes. Routing, MIP/NEMO, ND proxy. Can be anything. New
 text says:

    " The Backbone
    Routers may perform proxy IPv6 Neighbor Discovery (ND) [RFC4861]
    operations over the backbone on behalf of the wireless devices (also
    called motes), so they can share a same IPv6 subnet and appear to be
    connected to the same backbone as classical devices.  The Backbone
    Routers may alternatively redistribute the registration in a routing
    protocol such as OSPF [RFC5340] or BGP [RFC2545], or inject them in a
    mobility protocol such as MIPv6 [RFC6275], NEMO [RFC3963], or LISP
    [RFC6830]."

 > 5) the security words include: "will be studied in the next round of
 this document." and I'm not sure what a reader should make of this.
 Perhaps it should simply summarize section 13 in one sentence and say that
 PANA is a possibility, but that the choice of protocol is out of scope for
 this document. (well, 5.0 then explains about volumes. So perhaps the
 explanation about volumes should go much earlier, most probably into the
 abstract as well. Also, will the volumes build on the previous work, or
 will they replace it? if they will replace it, then I think correct word
 is "edition")

 I suggest we remove the term debate and say this as follows:

 "
    PANA (Layer-3), IEEE802.1x (Layer-2) or some light weight variation
    of those could be used in the join process.  Regardless, the security
    model must ensure that, prior to a join process, packets from a
    untrusted device are controlled in volume and in reachability.
    This piece of the architecture is also deferred to a subsequent
    volume of the architecture.  A status of the work can be found in
    Section 13.
 "

 But there is no charter published at the IETF since there is not even a WG
 forming BoF
 I reworded as follows

 "
       The 6TiSCH Architecture extends the concepts of Deterministic
 Networking
       on a Layer-3 network. At the time of this writing, work has started
 on
       this general problem under the name DetNet. The 6TiSCH Architecture
 should
       inherit from that work and thus depends on it. In turn, DetNet is
 expected
       to integrate and maintain consistency with the work that has taken
 place
       and is continuing at IEEE802.1TSN and AVnu.
 "

 I suggested one, but please come back to me. I think ultimately we need to
 move all to COMI, including PANA if we adopt it, but none of that is clear
 now.

 OK, removed the whole sentence including the words on DICE. It is really
 unclear to me where DICE is going at this time.

 >     This architecture expects that a 6LoWPAN node can connect as a leaf
 to a RPL network, where the leaf support is the minimal functionality to

 changed to

 "
         This architecture expects that a 6LoWPAN node can connect as a
         leaf to a RPL network, where the leaf support is the minimal
         functionality to connect as a host to a RPL network without the
 need to
         participate to the full routing protocol.
         The architecture also expects that a 6LoWPAN node that is not
 aware
         at all of the RPL protocol may also connect as a host. This can be
         achieved with an extension to 6LoWPAN ND, adding the capability to
 carry
         a sequence number that is used to track the movements of the
 device,
         and optionally some abstract information about the RPL instance
         (topology) that this device will be reachable over.
 "

 Yes the suggestion above removes up the term "join"

 > Figure 4 seems to do it all without RPL, even though RPL is mentioned,
 and I don't understand that.

 It also says DAR and then DAO. That's because a DAR/DAC is needed to carry
 the unique ID, that must be cached at the root. The DAO takes over after
 that first exchange, but has only the sequenceNB, but not the ID.

 >
 > 11) Reading section 6.1/6.2, I wonder if this just too much detail for
 an architecture. I also don't see how VLANID is involved (we are talking

 Yes, I commented a lot out

    On the backbone, the InstanceID is expected to be mapped
    onto a an overlay that matches the instanceID, for instance a VLANID.

    <!-- out goes:

           Neither WiFi nor Efficient ND do provide a mapping
    to VLANIDs, and it is unclear, when a wireless node attaches to a
    backbone where VLANs are defined, which VLAN the wireless device
    attaches to. Considering that a VLAN is effectively the IP link on
    the backbone, adding the InstanceID to both specifications could be
    a welcome addition.

    -->

 OK, the section becomes:

 "

    When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL root
 functionalities
    are co-located in order that the address of the 6LBR be indicated by
 RPL
    DIO messages and to associate the unique ID from the DAR/DAC exchange
 with
    the state that is maintained by RPL. The DAR/DAC exchange becomes a
    preamble to the DAO messages that are used from then on to reconfirm
 the
    registration, thus eliminating a duplication of functionality between
 DAO
    and DAR messages.
 "

 What about

 "
    A typical attack against IPv6 ND is address spoofing, whereby a rogue
    node claims the IPv6 Address of another node in and hijacks its
    traffic.  The threats against IPv6 ND as described in SEcure Neighbor
    Discovery (SEND) [RFC3971] are applicable to 6LoPWAN ND as well, but
    the solution can not work as the route over network does not permit
    direct peer to peer communication.

    Additionally SEND requires considerably enlarged ND messages to carry
    cryptographic material, and requires that each protected address is
    generated cryptographically, which implies the computation of a
    different key for each Cryptographically Generated Address (CGA).
    SEND as defined in [RFC3971] is thus largely unsuitable for
    application in a LLN.

    With 6LoWPAN ND, as illustrated in Figure 4, it is possible to
    leverage the registration state in the 6LBR, which may store
    additional security information for later proof of ownership.  If
    this information proves the ownership independently of the address
    itself, then a single proof may be used to protect multiple
    addresses.

 "

 I agree that this spec is fundamental to us. But importing it?

 "
  The architecture defines "soft" cells and "hard" cells. "Hard" cells
  are owned and managed by an separate scheduling entity (e.g. a PCE)
  that specifies the slotOffset/channelOffset of the cells to be
  added/moved/deleted, in which case 6top can only act as instructed,
  and may not move hard cells in the TSCH schedule on its own.

 "
 done

 >
 > I would write: Consideration was given towards finding a way to embed
 the Route Advertisements and the RPL DIO messages (both of which are
 added
 >
 > [and then go on to explain how to configure the LinkType, however, I
 think that this is too much detail for the architecture, and it needs to
 say something like: The 6TISCH adaptation document will explain the
 details of confuring a broadcast channel that can accomodate EB, RPL DIOs
 and Router Advertisements ]
 > I think that the concepts introduced in section 6.4 and 6.5 should
 perhaps be more clearly. While not trying to duplicate the terminology
 document, I found the way that the CDU concept is introduced was awkward.
 Perhaps this isn't very important. Maybe moving figure 5 earlier?
 >
 > Device Authentication: The JN and the JA mutually authenticate each
 other and establish a shared key, so as to ensure on-going authenticated
 communications. This may involve a server as a third party.
 >
 > Unless you consider un-authenticated DH exchange "authentication", or
 you decide that it's okay for the JA to just not accept any public (some
 kind of leap of faith), the JA will not have an identity that a JN will
 accept.
 >
 > I have also repeatedly complained that figure 10 is inaccurate, because
 it fails to depict that authorization begins before authentication
 finishes. Perhaps the second two unidirectional arrows are part of the
 authentication phase, I don't know.

  architecture           |  Resolution:
 Keywords:               |

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/36#comment:1>
6tisch <http://tools.ietf.org/6tisch/>

---

From: "6tisch issue tracker" <[email-masked]>
Date: Tue, 07 Apr 2015 18:36:46 -0000

> I suggest that figure 10 be omitted.

 So far, the changes per Michael's review are as follow (from the most
 recent):
 https://bitbucket.org/6tisch/draft-ietf-6tisch-
 architecture/commits/5b7d36254d62eb4aa0f12e7b3767a2f7347e975a
 https://bitbucket.org/6tisch/draft-ietf-6tisch-
 architecture/commits/ae7ea789ac066cb6b31fcdf9e6e8fdc2f6cf667e
 https://bitbucket.org/6tisch/draft-ietf-6tisch-
 architecture/commits/62b2606b48d14cb83f4d1d87c600c3f333cc8f66
 https://bitbucket.org/6tisch/draft-ietf-6tisch-
 architecture/commits/2b296269f964eae8a7d47216ed90cf969c405a9d
 https://bitbucket.org/6tisch/draft-ietf-6tisch-
 architecture/commits/f59c94f6abd62b946f70ac6d2aa7e01d0f770298

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/36#comment:2>
6tisch <http://tools.ietf.org/6tisch/>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Apr 2015 08:57:09 -0400

>  ever get published. If there is terminology there that we still need,
    > I think it should be extracted into the 6tisch-terminology
    > document. While it is an informative reference, the fewer references to
    > IDs the better in my opinion.

    >  But this one is really key on why we do RPL on TSCH at 6TiSCH. I'd
    > rather keep it.

okay.

    >  " PANA (Layer-3), IEEE802.1x (Layer-2) or some light weight variation
    > untrusted device are controlled in volume and in reachability.  This
    > piece of the architecture is also deferred to a subsequent volume of
    > the architecture.  A status of the work can be found in Section 13.  "

okay.

    > DICE). I think that while technically PANA lives on top of UDP, there
    > is of course a layer of EAP, and TLS above it, and perhaps a layer of
    > ACE as well. So I'm not saying that this picture needs to be changed,
    > just to observe this.

    >  I suggested one, but please come back to me. I think ultimately we
    > need to move all to COMI, including PANA if we adopt it, but none of
    > that is clear now.

It might be best to remove items from the picture rather than give wrong
impressions.

    > to the full routing protocol.  The architecture also expects that a
    > 6LoWPAN node that is not aware at all of the RPL protocol may also
    > connect as a host. This can be achieved with an extension to 6LoWPAN
    > ND, adding the capability to carry a sequence number that is used to
    > track the movements of the device, and optionally some abstract
    > information about the RPL instance (topology) that this device will be
    > reachable over.  "

I'm uncomfortable with things that say, "we can do X by extending Y".
That's always true. ("We can extend 1950s telephone service to do web browsing
by extending circuit switched networks to do IPv6...")

Do we need/want to do X?  Is extending Y in our charter already?

    > functionalities are co-located in order that the address of the 6LBR be
    > indicated by RPL DIO messages and to associate the unique ID from the
    > DAR/DAC exchange with the state that is maintained by RPL. The DAR/DAC
    > exchange becomes a preamble to the DAO messages that are used from then
    > on to reconfirm the registration, thus eliminating a duplication of
    > functionality between DAO and DAR messages.  "

good.

    >  should be clearer in saying something like: "The threats against IPv6
    > ND as described in RFC3971 apply as well, but the solution can not work
    > as the route over network does not permit direct peer to peer
    > communication.  As can be seen in Figure 4..."
    >>

    >  " A typical attack against IPv6 ND is address spoofing, whereby a
    > rogue node claims the IPv6 Address of another node in and hijacks its

good.

    >     Additionally SEND requires considerably enlarged ND messages to
    > carry cryptographic material, and requires that each protected address
    > is generated cryptographically, which implies the computation of a
    > different key for each Cryptographically Generated Address (CGA).  SEND
    > as defined in [RFC3971] is thus largely unsuitable for application in a
    > LLN.

    > leverage the registration state in the 6LBR, which may store additional
    > security information for later proof of ownership.  If this information
    > proves the ownership independently of the address itself, then a single
    > proof may be used to protect multiple addresses.

good.

    >  applicability] need to imported into this document, since this sure
    > looks like a normative reference to me.
    >>

    >  I agree that this spec is fundamental to us. But importing it?

If it's important, then it needs to be a normative reference. Otherwise, it
will be a downref that will break publication.

    >  " The architecture defines "soft" cells and "hard" cells. "Hard" cells
    > added/moved/deleted, in which case 6top can only act as instructed, and
    > may not move hard cells in the TSCH schedule on its own.

    >  cells, and can move a cell in the TSCH schedule when it performs bad."

s/performs bad/performs poorly/

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 Apr 2015 15:59:55 +0000

Hello Michael

Please see inline (I removed all the full agreements

> -----Original Message-----

.

>     >> 7) I don't understand why PANA lives above ACE in figure 3. I think

>     >> that

> impressions.

I removed ACE and DICE from the picture,

unsure where they are going at this point

            +-----+-----+

            | PCEP|TEAS/|

            | PCE |CCAMP|

      +-----+-----+-----+-----+-------+-----+

      |     (COMI)      |PANA |6LoWPAN| RPL |

      | CoAP  / DTLS    |     |   ND  |     |

      +-----+-----+-----+-----+-------+-----+

      |       UDP       |          ICMP     |

      +-----+-----+-----+-----+-------+-----+-----+

      |                 IPv6                      |

      +-------------------------------------------+

      |  6LoWPAN adaptation and compression (HC)  |

      +-------------------------------------------+

      |                   6top                    |

      +-------------------------------------------+

      |             IEEE802.15.4e   TSCH          |

      +-------------------------------------------+

I also changed the language on PANA as follows, merging with René's comment:

"

   Similarly, the Protocol for Carrying Authentication for Network

   access (PANA) [RFC5191] is represented as an example of a protocol

   that could be leveraged to secure the join process, as a Layer-3

   alternate to IEEE802.1x/EAP.  Work resulting from [ACE] could be

   considered as well.  Regardless, the security model must ensure that,

   prior to a join process, packets from a untrusted device are

   controlled in volume and in reachability.  An overview of the

   security aspects of the join process can be found in Section 13.

   Related contributions are presented in Appendix A.

"

> That's always true. ("We can extend 1950s telephone service to do web

> browsing by extending circuit switched networks to do IPv6...")

> Do we need/want to do X?  Is extending Y in our charter already?

Agreed, let us merge that text down to section 6, and make that a suggestion:

"

6.  6LoWPAN (and RPL)

  The architecture expects that a 6LoWPAN node that is not aware at all

   of the RPL protocol may still connect as a host.  It suggests to

   extend 6LoWPAN ND [RFC6775] to carry the sequence number that is

   needed by RPL to track the movements of the device, and optionally

   some abstract information about the RPL instance (topology) that the

   device will be reachable over.

   In this design, the root of the RPL network is integrated with the

   6LoWPAN ND 6LBR, but it is logically separated from the Backbone

   Router (6BBR) that is used to connect the RPL topology to the

   backbone.  This way, the root has all information from 6LoWPAN ND and

   RPL about the LLN devices attached to it.

   This architecture also expects that the root of the RPL network

   (proxy-)registers the LLN devices on their behalf to the 6BBR, for

   whatever operation the 6BBR performs on the backbone, such as ND

   proxy, or redistribution in a routing protocol.  It suggests to use an

   extension of the mixed mode of Efficient ND

   [I-D.chakrabarti-nordmark-6man-efficient-nd] for the registration as

   described in [I-D.thubert-6lowpan-backbone-router].

"

> If it's important, then it needs to be a normative reference. Otherwise, it will be

> a downref that will break publication.

? If I make it a normative then it will be a downref. But I hardly see a requirement draft normative.

> s/performs bad/performs poorly/

Done

Please look up for an update on the bucket

These changes are specifically in https://bitbucket.org/6tisch/draft-ietf-6tisch-architecture/src/dcb5772198557b9fe08af9443b7fc04dfcbd548a/draft-ietf-6tisch-architecture-07.txt?at=master

Thanks a bunch for all!

Pascal

---

From: "6tisch issue tracker" <[email-masked]>
Date: Thu, 09 Apr 2015 16:05:43 -0000

okay.

 okay.

 good.

     >> 13) I think that 6.6 is saying that SEND can not be applied. I
 think
     >> it

 good.

     > different key for each Cryptographically Generated Address (CGA).
 SEND

     > leverage the registration state in the 6LBR, which may store
 additional

 good.

     >  I agree that this spec is fundamental to us. But importing it?

 If it's important, then it needs to be a normative reference. Otherwise,
 it will be a downref that will break publication.

     > added/moved/deleted, in which case 6top can only act as instructed,
 and

 --
 Michael Richardson <[email-masked]>, Sandelman Software Works  -=
 IPv6 IoT consulting =-

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/36#comment:3>
6tisch <http://tools.ietf.org/6tisch/>

---

From: "6tisch issue tracker" <[email-masked]>
Date: Thu, 09 Apr 2015 16:06:05 -0000

okay.

 okay.

 good.

 think

 good.

 SEND

 additional

 good.

 and

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/36#comment:4>
6tisch <http://tools.ietf.org/6tisch/>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Apr 2015 13:17:10 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > I also changed the language on PANA as follows, merging with René’s
    > comment:

    > Related contributions are presented in Appendix A.

Good.

    > “

    > device will be reachable over.

Good.

    > RPL about the LLN devices attached to it.

I like this very much.

    > a requirement draft normative.

So, just to be clear, if it's informative, I don't ever need to read it :-)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "6tisch issue tracker" <[email-masked]>
Date: Fri, 10 Apr 2015 15:23:24 -0000

Comment (by [email-masked]):

 I believe that edits have dealt with all my points here.

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/36#comment:5>
6tisch <http://tools.ietf.org/6tisch/>

---

From: "6tisch issue tracker" <[email-masked]>
Date: Thu, 23 Apr 2015 05:05:14 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-6tisch-
  [email-masked]     |  [email-masked]
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:
Component:               |     Version:
  architecture           |  Resolution:  fixed
 Severity:  In WG Last   |
  Call                   |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/36#comment:6>
6tisch <http://tools.ietf.org/6tisch/>

---

From: "6tisch issue tracker" <[email-masked]>
Date: Thu, 23 Apr 2015 05:05:47 -0000

Comment (by [email-masked]):

 Micheal confirmed that -07 addresses all these points

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/36#comment:7>
6tisch <http://tools.ietf.org/6tisch/>