A good topic for discussion. Maybe we could designate a reflector channel or two for testing interconnections between linking systems (Echolink and IRLP). Much like the Western reflector (IRLP) uses 9258 for connecting to an Echolink conference bridge, we could agree that one of the channels on a US and another on a EU reflector might be used for this purpose. People using those channels would know that they would not be seeing the digital information we are used to with D-Star. It would be a decision of the reflector owners. Maybe someone interested in this could establish a reflector dedicated to that purpose.
The interconnections would be good for D-Star as users of the other systems will be impressed with audio and noise-free signals and may come on board. Since these interconnects generally use a dongle to connect to us, I would guess they could be kept out of other channels by restricting dongle use but that would not be an optimal solution. It would really depend on gentleman's agreements. I don't think we should attempt to deny access to the busier channels as emergency situations may make intercommunication desirable. Ernie W6KAP --- In dstar_digital@yahoogroups.com, "John D. Hays" <[EMAIL PROTECTED]> wrote: > > I am starting this topic (and cross posting to reach as many interested > parties as possible) to open what hopefully will be a cooperative dialog to > establish some guidelines and rules that will help foster experimentation > and innovation on D-STAR while respecting the wishes of system (repeaters, > gateways, and reflectors) operators. The result should be a mutally > agreeable set of terms that everyone can sign on to. > > Why is this necessary? > > To this point there have been a relatively few developers working on D-STAR > projects that have any significant impact on the infrastructure. There > currently are at least two gateway replacement projects underway (OpenDSTAR > and OpenBridge) and numerous active development projects, some open and some > closed that can reach into the network in new ways (for example rtp_dir, > which provides an alternative to DVTOOL for accessing the network using the > DV Dongle, but also has the capability to bridge in other networks such as > IRLP, Allstar/Asterisk, and Echolink). The development of some of these > tools can be disruptive to systems if not properly developed and vetted to > the community. > > It is hoped that we can get a spirit of cooperation on software and hardware > development to further D-STAR as the new Digital standard for Amateur Radio > local and linked communications. > > Here are my starting points. The guidelines should be short, to the point, > few and clear. > > Part 1 - D-STAR Reflectors > > 1. The owners of reflectors, repeaters, and gateways have a right to manage > their systems in the best interests of their respective user communities. > 1.1 Use of these resources for *testing *new software and/or hardware should > only be undertaken by the consent of the operator or their designated agent. > 1.2 *Linking* to D-STAR reflectors shall be treated equally by class of > connection. In other words if you permit software/hardware from one > developer/manufacturer, that has followed the principles of this agreement > on your reflector, you must treat all similar technology in the class > equally. You can discriminate based on regulatory requirements of your on > air licensing authority, illegal activity, or if the content is generally > and consistently offensive by connection source (operator) Example classes > include: > 1.2.1 Individual operators using Internet connections by a device like the > DV Dongle (Examples: DVTool, rtp_dir in non-bridged single operator mode) > 1.2.2 A native D-STAR gateway using G2, DPLUS, or similar linking > 1.2.3 A bridged native D-STAR reflector > 1.2.4 A non-native (e.g. Analog FM) repeater using a device like the DV > Dongle under automatic control. > 1.2.5 A non-native reflector (IRLP or EchoLink) using a device like the DV > Dongle under automatic control. > 1.2.6 A non-native repeater or reflector with a control operator actively > monitoring and managing the connection. > 1.3 Cross linking of non-native D-STAR and D-STAR gateways, reflectors, or > repeaters for routine networks will only be undertaken upon mutual agreement > of the operators of the respective systems. > 1.3.1 Immediate emergency communications (safety of Life or Property) does > not require prior agreement for short linking to facilitate that > communication. > 1.4 Short demonstrations by any accepted class of operation are permitted > without prior permission if the reflector is not in active use by a > scheduled net or operating activity. > 1.5 Operators of D-STAR reflectors will politely notify users, of any > connection class, if there is a problem with the use of the reflector. > 1.5.1 Operators of the connecting system will comply with published > standards for a reflector.. > 1.5.2 If the operator of a connecting system will not comply the operator of > the reflector may, at his own descrision implement methods and procedures to > stop the undesired connection. > 1.6 Operators of reflectors will publish their policies, by class of > connection/operation, and contact information, in a single repository on the > Internet (TBD - d-starusers.org?) > 1.6.1 A consumable XML standard shall be established to define these > operating rules so that software can query and automatically determine if > its class of connection/operation is permitted. > 1.7 The reflector community is encouraged to establish a test reflector for > use by developers to test their devices and software. > > > Part 2 - Developers > > 2. Developers will use good engineering practices to avoid introducing > instability into the D-STAR infrastructure. > 2.1 Developers will always obtain permission before testing against any > system; repeater, bridge, reflector, gateway, user radio, etc. > 2.1.1 If designated test systems exist, thorough testing should be completed > and reviewed on those test systems before testing against the "live" > infrastructure (gateways, repeaters, trust server, etc.) > 2.1.2 If designated test systems do not exist, the developer should submit > specifications of what protocols, interfaces, components, etc. will be > tested, the methodoogy of the tests, risks, and so forth to the operator of > any non-test system before a test is run against the "live" system. > 2.1.3 Developers must document all interoperation between their device or > software with the D-STAR infrastructure, including protocols, interfaces, > etc. > 2.2 Developers are encouraged to seek peer review of their developments. > 2.2.1 Open source projects are considered "safer" do to open peer review and > the opportunity for multiple developers to contribute their experience to > improbing the device or software. > 2.3 Developers are encouraged to share knowledge and experience, so that the > whole community can benefit from their work. > 2.4 Developers should seek to cooperate. If their project creates something > useful, they should expect that it may become a building block for another > project. > 2.4.1 One developer may not prevent another developer or user from using the > legally obtained work (whether open or closed source, purchased, free, or > donated) for any legal amateur radio use. > 2.4.2 Developers and users will honor the intellectual property rights of > the creator of technology. Patents, licensing agreements, etc. will be > fully honored. > > Part 3 - Gateways > > 3. Gateway operators understand that by connecting to the D-STAR network > they are open to connection from any of the types of connections listed in > Part 1. > 3.1 Gateway operators have a right to manage their systems in the best > interests of their respective user communities. > 3.2 Due to the number of gateways, individual permission to interoperate is > impractical. > 3.2.1 Gateways shall implement a similar publishing mechanism as outlined in > 1.2 and 1.6 in Part 1 > 3.2.2 Gateways shall have the same rights and responsibilities as outlined > in section 1.5 in Part 1 (substituting gateway for reflector) > 3.3 Gateway operators that are willing to be test sites for developers are > encouraged to let the developer community know of the interest, policies, > times, and systems available for testing. > > Part 4 - Trust Server > > 4. Trust server operators are requested to provide a test trust server for > both developers to test against and for new gateway and reflector operators > to test againgst. > 4.1 A set of specifications for connections to the trust server should be > published for developers working on gateway and gateway equivalent systems > will create software that is compatible and safe to use against the live > trust server. > 4.1.1 Acceptance into the gateway and reflector community as a peer shall be > based meeting the specifications and rigorous testing against the > interfaces, and not by the origin or manufacture of the enabling technology. > > Please discuss responses, respectfully, on this thread in the dstarsoftware > Yahoo! group. > > 73 DE K7VE > > > [Non-text portions of this message have been removed] >
