Hi Michael, sorry for the late reply. Shortly: 1) we are checking with ETSI if we can publish the TS as Internet Draft. Maybe we will once we have the final version. 2) we have numbered the tests 3) the boilerplate text was a temporary one, we have cut it and kept ONLY the minimum needed info 4) we are paying attention to the set up/configuration (sniffers, pins, etc.)
Thanks for reading the document and giving your feedback! Maria Rita -----Original Message----- From: m...@sandelman.ca [mailto:m...@sandelman.ca] On Behalf Of Michael Richardson Sent: Tuesday, April 28, 2015 11:02 PM To: 6tisch@ietf.org Cc: Maria Rita PALATTELLA Subject: Re: [6tisch] TestSpecification for 6TiSCH PlugTests v0.2 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 =- _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
