The chair noted that it was important to decide which case we are working on, since the requirements for each are different, and therefore the protocol might be different in each case. It was noted that even though we engineer the protocol to solve one of the cases, if it happens to be a good fit for one of the other ones, great, but we shouldn't engineer for it. In this case, the gateways are all owned by the same administrator. The gateway location protocol allows a number of location servers, also owned by this provider, to automatically learn about the gateways within the domain. In this case, issues such as policy and aggregation, and requirements for security, scalability, and robustness, are different than in the other cases.
Providers have location servers, which know about gateways within their own domains.
This information is exchanged with peers, and may be aggregated and further passed on to other peers. The protocol is independent of normal routing exchanges. In order to exchange information, a pre-established peering relationship must be built ahead of time between providers. However, it would be based on some kind of multicast model, so that a gateway provider would just advertise widely its gateway characteristics. Any location server or client could receive these advertisements and learn about remote gateways and gateway attributes in remote domains.