Subject: Re: [Lwip] guidelines for the LWIP BOF

From: Zhen Cao <[email-masked]>
Date: Fri, 1 Oct 2010 23:08:25 +0800

On Thu, Sep 30, 2010 at 12:15 AM, Jari Arkko <[email-masked]> wrote:
> Zhen,
>
>> We are working on have more people from these hands-on projects.
>>
>
> Great!
>
>
>> In some of our internet of things practice, we found the wireless
>> sensing devices have different layer2 technologies, and the current
>> 6lowpan (which is only based on 802.15.4-2006) would not be able to
>> serve.  And there are needs of a generic adaption layer for different
>> layer-2 techniques, lightweight naming service and lightweight
>> mobility solutions as well.  We are considering them right now and
>> will come up with more.
>>
>
> I think the generic adaptation layer is called IP... its pretty minimal :-)
>
> But I would indeed advice against bringing in lightweight versions of naming
> or mobility services to the BOF. Just to pick one item here, name service in
> the Internet is extremely simple already. I don't think we want to spend all
> of our time in the BOF in argument how necessary or unnecessary these things
> are. Perhaps if we do good work on the implementation advice then in the
> future we can talk about how that shows we need to provide some simplified
> versions of existing Internet mechanisms. However, that is a very
> significant step, given that the Internet architecture attempts to serve
> everyone with a single mechanism if at all possible (see RFC 1958, Section
> 3.2). And there would be interoperability problems if there were multiple
> mechanisms.
>
>>> On item 1, we already have many header compression mechanisms
>>> (often not implemented or not used), it would be necessary to understand
>>> why
>>> some new work is needed. On item 2, I suspect that if reliability and
>>> congestion avoidance are requirements, you cannot get much simpler than
>>> TCP.
>>> There is of course a great difference between a full-blown all-features
>>> implementation and something that is carefully tailored for small
>>> environments, parameter settings optimized for minimum memory usage, etc.
>>> I
>>> have some experience in building small implementations of var'ious things
>>> and it is surprising how much you can do. On item 3, it is unclear if
>>> this
>>> is an effort that the IETF should undertake. IEEE key exchange protocols
>>> such as 802.11i have traditionally been developed in the IEEE. On item 4,
>>> it
>>> is unclear whether this would be desirable if one Internet and global
>>> interoperability is the goal.
>>>
>>
>> On item 3, normally IEEE will take some IETF protocol as the basis for
>> their design (fill into the frame).
>
> Yes, they sometimes do. But in those cases there are typically very clear
> requirements and
> some level of separation between a general end-to-end protocol and its
> application in the IEEE context. For instance, IETF designed EAP and IEEE
> used it. However, related protocols needed to support EAP in the IEEE
> context (EAPOL, 802.11i) were all developed by IEEE. Are there requirements
> today for 802.15.4 keying? What is the IEEE itself doing in this space?
>
> Jari
>

IEEE has this specific requirement, and 802.15 has initiated an
Interest group this July (HIP-IG) where Bob is the proponent.  The
IEEE part wants to define the frame of carrying the keying protocol,
while IETF sides has only Diet-HIP available.  But this is work is not
finalized in IEEE until the HIP-IG related PAR and 5C are approved
their.