RIPE object proposal

[Andrew J. Hoag]

Just a few comments David. The proposal looks good and thank you David & Geert
Jan for all your effort on this!



> On Nov 19, 11:43am, davidk@ISI.EDU wrote:
> ...
>
> - loc-string: <LocatianString>
>
>   LocationString contains the coordinates of the IPv6 sites location.
>   Multiple location strings can be proovided on different lines for sites
>   that have multiple locations in the area.
>
>   Syntax:
>
>   Somebody can give me a pointer for the RFC standard

RFC1712 specifies the "GPOS" RR for DNS.  (excerpt below)

>   loc-string:     33 40 10n 117 49 20w 10m

Proposed syntax:

loc-string: <LONGITUDE> <LATITUDE> <ALTITUDE>

(from RFC1712)

   LONGITUDE The real number describing the longitude encoded as a
             printable string. The precision is limited by 256 charcters
             within the range -90..90 degrees. Positive numbers
             indicate locations north of the equator.

   LATITUDE The real number describing the latitude encoded as a
            printable string. The precision is limited by 256 charcters
            within the range -180..180 degrees. Positive numbers
            indicate locations east of the prime meridian.

   ALTITUDE The real number describing the altitude (in meters) from
            mean sea-level encoded as a printable string. The precision
            is limited by 256 charcters. Positive numbers indicate
            locations above mean sea-level.

It also would be helpful to require some sort of "Location:" string describing
the above lat-long... Since many people don't know their lat-long, they could
alternatively provide the location.

> - application: <service> <hostname> [port]
>
>  This attribute describes the different services available on the site.
>  The services are the same as described in the '/etc/services' plus the ping
>  application. More services might be added later on.
>
>  Hostname is the DNS hostname of the host that provides the service and
>  a port number may be specified for services that don't run on the
>  standard port.

Is it assumed that this is for IPv6 applications? Would a version/protocol
field here be useful?

> - tunnel:  <Protocol1> in <Protocol2> <src> -> <dst> [FreeText]
>
>   This attribute defines a tunnel of Protocol1 in Protocol2 from address
>   src to address dst. You only need to define your side of the tunnel.
>   The other end should be present in the object of the other party's site
>   object. Note that tunnels should in general be configured symmetrically
>   along both end-points.

Currently a lot of people are appending an "ipv6-site" tag after the <dst>.
This makes sense to me as a sanity check on where the tunnel is supposed to
point. Especially with a lot of tunnels being "phased in" or out and changed,
the IP address may end up being transient while the IPv6-Site tag would be
somewhat more permanent.

We discussed this earlier and you pointed out that the database can look up the
IP address, however with some of these tunnels moving around, the IP addresses
for all records don't get change when the tunnel endpoint changes, so we have
some records pointed to the old and some to the new. Would you be able to
automatically move all references to the old IP to the new?

>   Note for discussion:
>
>   It is may be better to use DNS domain names here instead of the raw IP
>   addresses.

If DNS is broken it may be hard to resolve hostname to addresses... I'd rather
just do the reverse lookup (at my own risk) if I need the hostname. OTOH, we do
use DNS for a reason and using host names may cure some of the problems I
mention in the paragraph above. My vote would be for hostnames with the caveat
that everyone would have to have DNS configured to tunnel (for the IPv4
endpoints at least).

>
>-- End of excerpt from davidk@ISI.EDU



-- 
| Andrew Hoag      | MS 258-6                | Voice: (415) 604-4972 |
| Network Engineer | Moffett Field, CA 94035 |   Fax: (415) 604-4377 |
| High-Speed LAN   +------------------------+---+--------------------+
| NAS Facility     | http://www.gac.edu/~ahoag/ | ahoag@nas.nasa.gov |
--