Hello Michael
Please see inline (I removed all the full agreements
> -----Original Message-----
.
>
> > 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. "
>
> okay.
>
> >> 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.
>
> > 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.
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.
"
>
> > 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?
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].
"
> >> 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.
> >>
>
> > 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.
? 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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
