Pascal Thubert (pthubert) <[email protected]> wrote:
    > 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.

Good.

    > 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.

Good.


    > 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.

I like this very much.

    >> 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.

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 protected]  http://www.sandelman.ca/        |   ruby on rails    [

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



Attachment: signature.asc
Description: PGP signature

_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to