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

Reply via email to