On Apr 30, 2008, at 11:39 AM, Omprakash Gnawali wrote: > > > In summary, at least until now, net2's policy has been to put the TEP > in the standards track and software in the release track only through > membership in the group. For TEP, I can see the value of being more > flexible with this policy because someone could submit a TEP with some > nice observations about some protocols or best practices in network > protocol which we would be happy to sponsor.
Right -- to go to the steering committee, a TEP needs the blessing of the working group chair. It doesn't necessarily have to be written by a member of the WG, or even have a WG member as an author. The assumption, though, is that the chair won't forward a TEP to the committee unless the WG members are happy with it. > > > Back to AM IDs - the various entities involved are: protocols that are > distributed with the core, protocols with assigned AM IDs, protocols > that are in contrib, applications and protocols in apps, and finally > applications and protocols "users" want to write and test for their > experiments and deployments. > > For the protocols that are distributed with the core (lib/net), it is > clear that we want ID allocation and they MUST not conflict. > > The applications and protocols in apps directory distributed with the > core, should probably also use allocated IDs. > > What to do with the protocols in contrib? Although we don't want to > patrol, it would be good provide some guidelines for these protocols > and applications too. > > For the user applications and protocols, it is clear that they should > use the unassigned addresses. > > Can there be an "official" protocol with an assigned ID that is not a > member of one of these four classes of applications and protocols? There are two separate questions: 1) How do we prevent protocols in tinyos-2.x/ from conflicting with each other. 2) How do we provide guidance for making sure new protocols not in tinyos-2.x don't conflict with those that are. 1) is satisfied by assigning AM ids to protocols in tinyos-2.x/. 2) is satisfied by leaving a large swath of the AM id space unused by tinyos-2.x/ so it can be used however applications want. Phil _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
