Dear Carsten and Geoff,
You and the group members did a great job in preparing all the works
necessary for rechartering.
Although I have been working quite sometime for "mesh under" within IEEE
802.15.5, 6lowpan is relatively new to me.
Nevertheless, I find that the categories of the work items are well done,
which would develop into a set of RFCs useful for the services envisioned in
the charter.
Few comments are added inline below.
Thank you,
Myung Lee
[EMAIL PROTECTED]
-------------------------------------------------------
A) is the timeline, which was too tight, now too relaxed? (Obviously,
the chairs don't think so, but what do you think?)
==> I think the timeline is reasonable.
B) should there be work on a "minimal 6lowpan/IPv6 profile"? (We had
envisioned each of the use cases to explain what protocols are used
in implementing that particular use case, not the generation of a
unified minimal profile that would apply to all use cases.)
==> A unified profile would necessarily be fat and the other extreme would
pose interoperability problem. Thus, we may need to narrow down the use
cases into a few MAJOR categories according to some measures, for instance,
with/without line power, mobility, number of nodes, etc. Also, if there is a
urgent and strong market need, it should be taken care of first.
C) Daniel has reminded us that there needs to be a management solution
at some point. We're not sure that simply defining a MIB is the
right way to provide this (SNMPv3 on sensor nodes?). Instead, we
could add "management method" to the subjects of the architecture
document before actually creating the solution. Is that the right
place?
==> Yes, we need management solution. Currently, 15.5 solution permits MAC
and Mesh MIB access via primitives in management plane.
D) The discussions about multicast have reminded us that 4944 alone
does not provide a solution beyond a single radio range. MANET's
SMF provides one, but presupposes some support from the routing
protocol. The BbR approach reminds me of 802.11, where all
multicast is unicast to the AP which then sends it back into the
wireless network (which might allow a simplified flooding based on
something like RPF).
==> In view of performance, I believe any functions and services slanted
towards applications, they are to be placed at higher layers, but simple
common services to all layers may be placed lower.
E) There were some comments during the meeting that we already were
taking on a sizable amount of work. I'm not sure we want to take
on all of the other points Daniel raised:
[...] I guess we should consider how to improve the quality of RFC
4944, especially Global Address HC, TCP operation, ICMPv6 operation
and etc. RFC 4944-bis is one of options.
===> We may work on specific requirements for reliable e2e protocol for WSN,
since TCP doesn't fit for error prone and band stricken 6lowpan environment.
[...] how to dig out *mobility issue* from the proposed charter. I
guess some of requirements of mobility for 6lowpan networks is
doable for the initial activity at this stage except specific
mobility solutions.
==> The mobility issue may be undertaken in conjunction with the profiles
above, considering use cases that need mobility. I am interested in this
area.
F) Going through each of the documents, the following contributions
have been promised recently:
3a "Routing requirements" (which needs its own milestone entry) has a
draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann. During
the RL2N BOF, a similar document was proposed as a result of the
RL2N-followup WG to be formed. We need to understand whether the two
documents (the 6lowpan one and the rl2n++ one) are sufficiently
different or whether we simply need to cooperate on one document,
which would then have to include the 6lowpan-specific aspects
including mesh-under.
==> I am interested in this area.
4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest.
Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs"
might provide a basis, but we need more input, in particular from
implementors of each of these scenarios that we actually want to use
as use cases.
==> I am interested in contributing some in this area.
Gruesse, Carsten and Geoff
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
