Carsten, Geoff, et. al.,
Thanks for all your hard work in getting the draft charter finalized
for WG discussion last week in Vancouver. I think it did a very good
job of incorporating the many opinions discussed on the list in the
last few months.
While there were always be room to massage details, I'm definitely in
favor of adopting the work items as described and look forward to
contributing to some of the deliverables.
Additional comments below.
On Dec 10, 2007, at 11:45 AM, Carsten Bormann wrote:
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 timelines are reasonable. I believe some of the items
depend on more empirical data which can only be gained from deployment
experience. The scenario descriptions help here, but I think we need
much more depth in the descriptions.
B) should there be work on a "minimal 6lowpan/IPv6 profile"? (I 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.)
I think there is value (if a useful unified set can be found) to a
single profile. We're pushing for interoperability and there's
nothing more frustrating that saying, "yes, it's 6lowpan, but not that
profile".
C) Daniel has reminded us that there needs to be a management solution
at some point. I'm 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?
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).
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:
For the current charter, I think we've set a good course. I think
there is merit to Daniel's comments, but I think we need to focus on
the initial items. If the priority changes or we find ourselves
incredibly efficient, we can always propose amending the charter.
[...] 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.
[...] 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.
F) Going through each of the documents, the following contributions
have been promised recently:
< -- document list clipped to save electrons -- >
Given that I'm in the midst of a Java implementation of IPv6/6lowpan
I'm really looking forward to contributing to the Implementer's guide
and interoperability drafts. I cut my networking teeth in the SNMP
space and wouldn't refreshing my cranial cache and pitching in on the
architecture spec if my time allows. Implementation and
interoperability are definitely my main concerns at this time.
...Pete
--
Pete St. Pierre
Sun Microsystems, Inc
http://www.sunspotworld.com
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
