Hi Eunah, About deleting R17, which looked like this:
[R17] In case there are one or more nodes allocated to coordinator roles, the coordinators MAY take the role of keeping track of node association and de-association within the LoWPAN. There is already a list of device types and roles in the draft, but it does not include a coordinator type... so, in my opinion, either we add a coordinator type (if that exists in reality), or we delete R17. Greetings, Dominik On Tue, Feb 17, 2009 at 11:30 AM, Eunsook Eunah Kim <[email protected]> wrote: > Dominik, > I agree on your proposed changes, except deleting R17. > I would like to be careful to delete it. The requirement is added from > comment. > Can we think more if it is really not necessary requirement or if we > can rephrase it? > > -eunah > > On Tue, Feb 17, 2009 at 7:14 AM, Dominik Kaspar <[email protected]> > wrote: >> Dear list, >> >> In the attempt of resolving issue #1, I came accross the following >> references to PAN coordinators: >> >> (1) >> >> In order to ease routing table updates and reduce error control >> messages, it would be helpful if nodes leaving the network >> inform their coordinator about their intention to disassociate. >> >> proposed change: >> >> In order to ease routing table updates, reduce their size, and >> minimize error control messages, nodes leaving the network may >> announce their disassociation to the closest edge router. >> >> (2) >> >> [R17] In case there are one or more nodes allocated to coordinator >> roles, the coordinators MAY take the role of keeping track of node >> association and de-association within the LoWPAN. >> >> proposed change: delete R17 >> >> (3) >> >> [R18] If the routing protocol functionality includes enabling IP >> multicast, then it may want to employ coordinator roles, if any, as >> relay points of group-targeting messages instead of using link-layer >> multicast (broadcast). >> >> proposed change: >> >> [R17] If the routing protocol functionality includes enabling IP >> multicast, then it may want to employ relay points of group-targeting >> messages instead of using link-layer multicast (broadcast). >> >> I've committed the proposed changes into the SVN repository. >> >> Best regards, >> Dominik >> >> >> On Thu, Nov 20, 2008 at 4:03 PM, 6lowpan issue tracker >> <[email protected]> wrote: >>> #1: Make sure interface to 15.4 is clearly defined >>> ----------------------------------+----------------------------------------- >>> Reporter: [email protected] | Owner: [email protected] >>> Type: defect | Status: assigned >>> Priority: major | Milestone: >>> Component: routing-requirements | Version: >>> Severity: Active WG Document | Resolution: >>> Keywords: | >>> ----------------------------------+----------------------------------------- >>> >>> Comment(by [email protected]): >>> >>> - We should pay attention to whether we are assuming just 802.15.4 frame >>> format or the whole 802.15.4 protocol (including MAC features). >>> >>> -- >>> Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/1#comment:2> >>> 6lowpan <http://tools.ietf.org/6lowpan/> >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >> _______________________________________________ >> 6lowpan mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lowpan >> > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
