> On 4 Nov 2016, at 23:41, Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> > wrote: > >> Poor visibility and diagnostics of faults make the cost of supporting >> any service expensive and erode brand value > > Point. Indeed. I find it helpful to keep an eye on how the economics work as they drive poor behaviours and undermine the value of the standards. > >> So, would it be reasonable for devices that are not sure of the time, to >> report that fact, and their view of what the time is to the user for >> acceptance? > > Well, the obvious solution would be to define one or more HNCP TLV types > that devices MAY publish and that monitoring software SHOULD display in > purple and MAY display in dark red. I'm a little ambivalent on the subject: > > - on the one hand, HNCP requires every single bloody bit of data to be > flooded across every single bloody HNCP node in the network; that's > bloody quadratic scaling with the number of bloody lightbulbs; > - on the other hand, it's not too difficult to synchronise with HNCP > without participating in the protocol (one of my students did > a from-scratch implementation of a passive HNCP monitor last summer, > and she had no previous exposure to HNCP); > - on the gripping hand, this is only doable by binding port 8231, so > only one HNCP peer per host; > - I'm out of hands, but you probably want your lightbulbs to participate > in monitoring without being authorised to participate in HNCP. > > I definitely think that Homenet is the suitable place to define a lightweight > monitoring protocol that every lightbulb MAY participate in. > > -- Juliusz
That works for me as it at least gives something to base a commercial contract on that has the strength of independent standards. Tim _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
