Hello Geoff, Zach and all in this thread of discussion: >From the discussion, it seems we want some sort of L2 indication from 802.15.4 for bootstrapping and comissioning, but IETF is not quite capable of defining those primitives.
I do agree that L2 primitives would be the easiest way to act for commissioning in number of cases. I think 6lowpan wg can do the following within the scope of IETF: 1. Identify the cases when L2 primitive is useful for commissioning 2. Provide a set of API which deals with L2 primitives or any other L2 specific methods to provide the necessary information to complete the commissioning part. Note that then we do not have to define the L2 primitives and it can be left with the implementation. Comments? Thanks, -Samita On 2/7/08, Zach Shelby <[EMAIL PROTECTED]> wrote: > Hi, > > Nice to see Geoff woke up the list, and that someone is really on > vacation (no jealousy ;-). > > I have to agree with Jonathan here. A set of attributes is the most > appropriate in this case, and this makes it much easier to use 6lowpan > over other link layers or minimal 802.15.4 implementations. For example > I would definitely avoid explicit use of association/disassociation in > beacon-enabled mode. Most deployments in our experience will use > beaconless mode where those primitives are not available. ICMP can be > used instead of MAC primitives for many purposes. I would prefer to > leave the link-layer topology construction details to the > implementation, some kind of network management entity separate from > 6lowpan and IETF standardization. For example with WiFi + IP > implementations, the IETF does not take a stand on whether or how you > configure your interface (ad-hoc mode, infrastructure mode, ap mode) nor > manage it. > > - Zach > > Jonathan Hui wrote: > > I'm not convinced that this WG (or the IETF in general) is the > > appropriate place to specify MAC protocols. Requiring the use of > > specific MAC protocols is tantamount to specifying the protocol. W.r.t > > commissioning/bootstrapping, the way I see it is that the link-layer/MAC > > simply has a set of attributes, some of which 6LoWPAN utilizes (e.g. > > short-addrs, EUI-64, etc.). These attributes must be configured > > somehow, but the specific way they get set is out of scope of this WG. > > > > -- > > Jonathan Hui > > > > > > Geoff Mulligan wrote: > >> We have not had any lively discussion on this list for quite some time > >> (actually we have not had ANY discussion on this list for quite some > >> time)! Vacation is over! > >> > >> Topic: What 15.4 MAC functions / features should be used or relied upon > >> or required by 6lowpan. > >> > >> Carsten reminded me that this was a topic of discussion at the last > >> IETF. > >> > >> There were some suggestions that we should utilize some of the 15.4 MAC > >> primitives for 6lowpan commissioning / bootstrapping. Others insisted > >> that we not require any of the 15.4 primitives. > >> > >> Let try to resolve this question. > >> > >> [ Carsten and I are reviewing the discussion on the charter text to see > >> where we are and if the text should be changed - next weeks topic!! ] > >> > >> geoff > >> > >> > >> > >> _______________________________________________ > >> 6lowpan mailing list > >> [email protected] > >> http://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > > 6lowpan mailing list > > [email protected] > > http://www.ietf.org/mailman/listinfo/6lowpan > > > -- > Zach Shelby | CTO | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > 6lowpan mailing list > [email protected] > http://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list [email protected] http://www.ietf.org/mailman/listinfo/6lowpan
