RIPE object proposal

[davidk@isi.edu]

Hi Andrew,

> Andrew J. Hoag writes :
> 
> Just a few comments David. The proposal looks good and thank you David & Geert
> Jan for all your effort on this!

Thanks!

> > 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.

I will take this up in my proposal.

> 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.

This is a good one. I would say that we could also add the (optional)
'country:' attribute (will not help much in the US/Russia though ...). 

We could also change the syntax of loc-string to:

RFC1712|[Free text describing location]

Software should be smart enough to make the distinction ;-).

Or give the advise to describe your location in the 'descr:' field since
this 'location description' will not be computer readable anyway.

I am just not very sure if we should add another 'free text' attribute.

> > - 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?

Yes. I didn't add it since the whole object is IPv6 specific but if you
think that it is 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?

This would be difficult since it would mean touching other people's
objects.

My idea was to do this referencing dynamically at lookup time. However,
it might be better to start with user supplied site information in the
object since this part of the implementation is a kind of trikey and
would delay deployment.

> >   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).

Agreed.

David K.
---