Thank you for this initial document. I'm reading the document PDF: any chance you can post URLs for the document, as that makes my reading list manager easier? Sure, I can find the URL of the file attachment from the mail archives, and point my reader at that,... Even better if you can just post this as an Internet Draft...
Can the tests in section 4.4 be numbered?
It starts to get interesting at part 4.4, I see the first test as being:
Synchronization on EB
I see that one is going to attach probes of an oscilloscope to the golden
device, which will operate as the DAGroot.... I'm a little shocked by that.
I would think that the device would have a serial ("craft") console of some
kind, reachable by TTL interface.
None of the devices I'm bringing will have "OSC" pins, but all have some way
of getting debug output, even if it requires me to solder a header on.
I read through the tests, and had some small comments on the ones that are
more filled in, but I think it's premature to care too much.
As far as I can see everything before 4.4 is boilerplate.
I would think that the process at the plugfest would be something on the
order of:
0) unpack and verify operation of devices under test with self.
1) visit network sniffer "cage", and verify that the sniffer can
"hear" some traffic (any traffic) from the device under test.
That might require the DUT operate with "self"
2) visit EB "cage", and verify that DUT can hear EB to synchronize,
and that it emits something useful.
3) visit DODAG root "cage", and verify that DUT can do a basic
DIO/DAO in Aloha slots.
4) bigger trees, etc.
I write "cage", because I think that we will seriously need some radio opaque
rooms/spaces/dividers in order be able to get work done.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
