The primary reason for Thread being done in a closed way is to focus on 
the specification and implementation thereof in a tight and controlled 
manner. ZigBee IP, which we did in conjunction with the IETF, resulted 
in continually shifting sands as the specifications kept changing. This 
meant it took a long time, with implementers continually having to 
change code, retest etc. This resulted in a lengthy and drawn out 
development which frankly we can't afford to do in Thread. Sure, there 
are risks with this approach but the aim is to contribute back on the 
"rough consensus and running code" basis. This is not a criticism of the 
IETF at all; it is simply an approach to manage the unpredictability 
which will naturally occur in an open development process. A liaison 
agreement will certainly help and rest assured there are some veterans 
involved in the Thread development who will make sure it is not too weird.

It's no secret that Thread is already based on a number of accepted 
Internet standards (http://threadgroup.org/Downloads.aspx). We have 
already successfully demonstrated Thread running in conjunction with 
another 6LoWPAN implementation, using border routers to connect to a 
server, with end-to-end CoAP transactions taking place. "6LoWPAN" per se 
never has been, nor ever will be an interoperable standard, hence the 
need for activities like Thread and ZigBee IP to ensure that product 
certified as such can be interoperable.

Robert

On 04/03/2015 08:28, Hannes Tschofenig wrote:
> While I agree with you, Rene, I still think it is useful to look at
> other work that is being done (particularly if they appear relevant to
> this group).
>
> With regards to the security aspects, I believe at least the following
> efforts appear relevant:
>
>   * TR69
>   * OMA LWM2M
>   * Netconf Zerotouch
>   * Certificate management protocols like EST, CMP, etc.
>   * IEEE 802.1AR
>
> (Maybe there are others.)
>
> Looking at those examples provides ideas about what worked well and what
> didn't.
>
> Ciao
> Hannes
>
> On 03/04/2015 04:38 AM, Rene Struik wrote:
>> Hi Sheng:
>>
>> I think you quite misinterpreted my email: I was just commenting on
>> guessing games re what industry consortia or others may have up their
>> sleeves (not easy to control or influence). From the numerous emails, I
>> got the impression that "Thread" was actually spelled as "Threat". This
>> email exchange would never have happened if it would have been another
>> "Attic project X".
>>
>> Of course, all goodies re striving for convergence and for consensus
>> apply (where discussion re relative technical merit could be viewed as
>> competition of ideas [and what IETF often does quite liberally]).
>>
>> Rene
>>
>> On 3/3/2015 8:22 PM, Sheng Jiang wrote:
>>>> On 04/03/2015 10:29, Rene Struik wrote:
>>>>> Dear colleagues:
>>>>>
>>>>> I don't understand all the excitement here: everyone is free to draw up
>>>>> architectural blueprints and complete designs to their liking. This can
>>>>> be done in the attic, as company-internal project, with an industry
>>>>> consortium, or with SDOs, such as IETF. There is  no way of knowing
>>>>> what
>>>>> people dream up in their attic or in a "secret" project X type of
>>>>> effort. Or, is the fear that IETF will loose its lustre?
>>>> No. The fear (and it has been realised many times in the past) is
>>>> that a closed consortium will agree on and start shipping a solution
>>>> which does not mesh well with the rest of the Internet. A liaison
>>>> arrangement can help to avoid that.
>>> The IETF is mainly a standardization organization. Most of efforts in
>>> IETF is for interoperation. IETF produces a bunch of open standards,
>>> no secret at all. Then every company can implementation the interface
>>> following these standards. Of course, there are many internal
>>> implementation, which does not need interoperation with other devices,
>>> and they can be closed or secret. Devices can then interoperate with
>>> each other as long as the all following the same standards.
>>>
>>> Consequently, the main efforts of standardization actually compromise
>>> rather than competition. It is all participators to work together
>>> towards a consensus, which most of people could live with (in which
>>> maybe everybody have something unsatisfied.) So, people are encouraged
>>> to discuss, coordinate, merge and make compromises. Working along and
>>> producing several competition solutions would NOT be good in any
>>> standardization organizations.
>>>
>>>>      Brian
>>>>
>>>>> Competition (without bullying) is good and is an enticement to consider
>>>>> solid designs and thinking outside of the
>>>>> "we-did-this-20-years-ago-like-this-and-therefore-have-to-stick-to-this"
>>>>>
>>>>> box (the flaky ones will end up with marketing and PR departments of
>>>>> competing efforts to poke fun at).
>>>>>
>>>>> Best regards, Rene
>>>>>
>>>>>
>>>>> On 3/3/2015 2:34 PM, Brian E Carpenter wrote:
>>>>>> On 04/03/2015 05:36, Hannes Tschofenig wrote:
>>>>>>> At the moment the specifications are only available to Thread members
>>>>>>> since the specification is still work in progress.
>>>>>>>
>>>>>>> I don't know when it will be finalized and released to the wider
>>>>>>> public.
>>>>>>>
>>>>>>> Regarding the liaison I do not have an opinion about the value of it.
>>>>>> It is precisely to get access before the work is finalised, so that it
>>>>>> can be reviewed by all the right people. We know that closed standards
>>>>>> development produces bad standards.
>>>>>>
>>>>>>        Brian
>>>>>>
>>>>>>> Ciao
>>>>>>> Hannes
>>>>>>>
>>>>>>>
>>>>>>> On 02/26/2015 01:52 AM, Brian E Carpenter wrote:
>>>>>>>> On 26/02/2015 10:25, Behcet Sarikaya wrote:
>>>>>>>>
>>>>>>>> ...
>>>>>>>>>>> I know nothing about Thread, whatever and whoever it is.
>>>>>>>>>> Here is an intro document:
>>>>>>>>>> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf
>>>>>>>> Thanks for that. It seems to have all the downsides of secretive
>>>>>>>> ad hoc
>>>>>>>> membership-based consortia, except for the upside of a RAND-RF IPR
>>>>>>>> policy.
>>>>>>>>
>>>>>>>>> I think we need to clarify here that Thread Group is formed to deal
>>>>>>>>> with home environments.
>>>>>>>>>
>>>>>>>>> Enterprise or industrial environments seem to be excluded.
>>>>>>>> So far. The boundary between this and larger building services
>>>>>>>> networks is pretty fuzzy, isn't it?
>>>>>>>>
>>>>>>>> In any case, should we (the WGs on copy, and perhaps some others)
>>>>>>>> be asking the IAB to arrange a meaningful liaison with Thread?
>>>>>>>>
>>>>>>>> Back at Hannes: is there a spec for their approach to security
>>>>>>>> enrollment?
>>>>>>>>
>>>>>>>>       Brian
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Anima mailing list
>>>>>>>> Anima@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/anima
>>>>>>>>
>>>>>> _______________________________________________
>>>>>> 6tisch-security mailing list
>>>>>> 6tisch-security@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/6tisch-security
>>>> _______________________________________________
>>>> Anima mailing list
>>>> Anima@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/anima
>>> _______________________________________________
>>> Anima mailing list
>>> Anima@ietf.org
>>> https://www.ietf.org/mailman/listinfo/anima
>>