Re: [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 (fwd)

[Joe Touch <[e-mail]>]

Hi, all,

I completely agree with the abstract and the first bullet of section
1.1, and section 1.2 EXCEPT in proposing the extension (appendix A).

I don't think adding an extension "clarifies"; this doc ought to focus
on the clarification issue, and would be useful if doing so.

Specific comments below, though IMO the structural issues are worth
addressing *before* the specific comments indicated.

Joe

---------------

...
>                   Clarification of DNS SRV Owner Names
>                 draft-gudmundsson-dnsext-srv-clarify-00
...
> 1.1.  Problem Statement
> 
>    RFC 2782 says that the source of names for "Service" and "Proto" is
>    "Assigned Numbers" (STD2) or a locally defined repository.
> 
>    However, upon reflection, both alternatives do not seem to make
>    particular sense:
> 
>    o  The STD2 series of documents was obsoleted by RFC 3232 [RFC3232]
>       and IANA registration publication was handed over to on-line
>       registries maintained by IANA.  Unfortunately it is not explicitly
>       explained in RFC 2782 which section of STD2 it is referring to,
>       nor does RFC 3232 help.  By common knowledge, RFC 2782 referred to
>       the Keyword columns of the "Protocol Numbers" and "Port Numbers"
> 
> 
> 
> Gudmundsson & Hoenes      Expires July 1, 2010                  [Page 3]
> 
> Internet-Draft          SRV Prefix Clarifications          December 2009
> 
> 
>       IANA registries, respectively.
> 
>       As SRV records contain the port where each server provides the
>       service, the outmost utility of SRV RRs is for services that do
>       not have a registered port number. 

or where they are provided on ports other than the registered one.

> Also, the number of ports
>       available is small compared to the possible number of service
>       names that could be registered.  Therefore, the "Port Number"
>       registry needs a more strict registration policy and is not the
>       proper place for registering service names for use with SRV
>       resource records.

This implies that service names with assigned ports would not be used
with SRVs; this is not required by the SRV spec. It also implies that
SRV names are somehow independent of the port number registry, but the
IANA ports doc ID formalizes the unification of these two namespaces.

>    o  Having locally defined lists of service and/or protocol names
>       would equally allow to list the full service information in such
>       local databases and thus make the usage of SRV records redundant.

This language is awkward, and the logic is backwards. It's like saying
"you don't need the DNS because you can have hosts.txt". SRV can replace
/etc/services (with the appropriate changes to standards); the converse
is not true, so "equal" may be misleading.

>       In any case, this scenario is not applicable for publicly
>       available services where potential clients are not under the
>       control of the authority offering the services, and hence most
>       probably would have no access to the proper "locally provided"
>       information.  The reader is reminded that locally maintained
>       database solutions generally scale very poorly, and that this once
>       was the major momentum for the deployment of the Domain Name
replace 'momentum' with 'impetus' (or motivation?)
>       System.

As above, confusing and may need rewording. I'm not sure what you're
primary point is.


> 1.2.  Objective for this Document and its Companions

I completely agree with this section, but subsequent sections diverge
from this objective IMO.

...
> 2.  General Considerations for SRV Service Prefixes
> 
>    SRV Service Prefixes SHOULD consist of exactly two labels.

When do they not? Is it even possible they do not?

>    If the specification of a particular application/service indicates
>    that this service is to be provided at a specific registered port
>    number and does not mention DNS SRV based service discovery,
>    prospective clients SHOULD NOT assume the existence of SRV records

I'd go with "MUST NOT" assume (isn't that in the SRV spec?)

>    for this application, unless the client has hints available that
>    indicate otherwise -- for instance by means of configuration.  In
>    this case, only the rules of Sections 3 and 4 apply.

No need for the rest of the sentence (unless...); in that case, there is
no assumption.

>    If the specification of a particular application/service does mention
>    dynamic service discovery based on DNS SRV records but does not
>    specify otherwise in a precise and unambiguous manner, the rules of
>    Sections 3 and 4 apply.  In this case, a prospective client SHOULD
>    look up the DNS for the appropriate SRV records for the intended
>    Service Domain.

********

From here down (see trailing ********, i.e., all of the rest of section
3), the discussion diverges from the main point of this doc, and
introduces a new concept of layered services. That may be a useful
concept to explore, but belongs in a separate document, and IMO is
premature.

>    Some services can be carried equivalently in different encapsulations
>    using higher-level "substrate" protocols like HTTP, BEEP, SOAP, SIP,
>    XMPP, some of which in turn can be carried over different transport
>    protocols.  In this case, it is possible that certain servers for an
>    application only support specific protocol stacks, or that a Service
>    Domain provides a different set of servers for each protocol stack.
>    Consequently, there occasionally is a need to specify such details in
>    the SRV Service Prefix.  Since the Protocol Label is intentionally
>    restricted (Section 3), this information has to be carried in the
>    Service Label for this application.

Interesting idea, but currently SRVs and port numbers are assigned to
the entirety of layers 5-7 (and any shims therein).

This proposes a completely new structure for services that should be
considered as a separate issue, and IMO is far too premature to consider
for deployment.

>    There are two possibilities to achieve this goal:
> 
>    a.  If there is only a small number of "substrate" protocols to
>        distinguish, it is RECOMMENDED that the application designers
>        register multiple Service Names with IANA in the "Service Names
>        and Port Numbers" registry [RFCyyyy], which usually will start
>        with the same characters and contain a suffix attached with a
>        hyphen embedded in the name.

The 15-char limit doesn't support this option. There are far too many
current names that do not have this sort of syntax.

Finally, any structure in the service layering should be supported in
the SRV system, not in the syntax of the namespace.

>        One disadvantage of this solution is the length limitation
>        imposed on the Service Name by [RFCyyyy] (15 characters, see
> 
> 
> 
> Gudmundsson & Hoenes      Expires July 1, 2010                  [Page 6]
> 
> Internet-Draft          SRV Prefix Clarifications          December 2009
> 
> 
>        Section 4).  Also, [RFCyyyy] recommends that -- notwithstanding
>        some very popular, and mostly legacy cases -- each service ought
>        to be represented by a *single* Service Name.  If the service is
>        the same and only the substrate used is different, this solution
>        arguably is in conflict with [RFCyyyy].
> 
>    b.  If the number of substrate stacks to be supported is larger, or
>        if the 'canonical' labels that the application designers prefer
>        would result in exceeding the maximum length of Service Names, or
>        if multi-layer substrates shall be represented, or if the "unique
>        Service Name per service" argument is deemed important, an
>        extension scheme is needed for the construction of Service Labels
>        for such exceptional services.

This goes outside the scope of the IANA ports doc; service names are 15
chars in that doc, and that doc doesn't address extension services. This
is premature.

>        The non-normative Appendix A proposes a scheme for extended
>        Service Labels that does not pollute the namespace of Service
>        Names and hence adheres to the uniqueness and collision-freeness
>        requirements of [RFCyyyy].  The basic Service Name can be easily
>        extracted from these extended Service Labels, as they employ a
>        separator character not allowed in Service Names to attach
>        qualifier(s) to a 'basic' Service Label as specified in
>        Section 4.
> 
>        Application designers who want to make use of that scheme MUST
>        independently and unambiguously specify the application of that
>        scheme for their service and ensure that a reference to the
>        document containing this specification (if different from the
>        document specifying the basic service) is added to the entry for
>        that service in the "Service Names and Port Numbers" IANA
>        registry, following the registration procedures of [RFCyyyy].
> 
>        To re-iterate, absent such explicit, registered specification,
>        the rules of Section 4 (and, of course, Section 3 as well) still
>        apply in these cases.
> 
>    Application protocol designers ought to keep service discovery
>    simple.  The fewer alternatives a prospective client has to consider
>    and the fewer choices he has to find suitable SRV records, the faster
>    the service discovery can be performed, because it needs fewer DNS
>    queries on average and thus incurs less latency.  If alternative
>    transports and/or variations of the service are really needed to be
>    distinguished by service discovery, to foster interoperablity there
>    SHOULD always be defined a default version supported by all clients
>    and servers, and configured in the DNS, thus allowing an orderly
>    fallback in case client preferences cannot be accommodated.

Fallback is a property of a protocol; each service has different
requirements for such backward compatibility. If such a default or
fallback is assumed, then the SRV system should have a flag indicating
that. Port numbers are not intended to have any hierarchy or alternates
of services, so such a fallback is not appropriate to indicate there.
(each service group can do this, but it's not realistic to write a
SHOULD unless you know when it is violated and can enforce it; there's
no requirement to explain when protocols are grouped or have defaults,
so requiring application designers to do this begs the question of how).

******** (i.e., to end of section 3)

...
> 4.  Standard Service Labels
> 
>    Absent a normative document specifying otherwise, the SRV Service
>    Label for a specific service/application SHOULD be in the form of a
>    "Standard SRV Servcie Label" as specified in this section.
> 
>    Standard SRV Service Labels MUST be formed by prepending an
>    underscore character ("_") to the Service Name of an application
> 
> 
> 
> Gudmundsson & Hoenes      Expires July 1, 2010                  [Page 8]
> 
> Internet-Draft          SRV Prefix Clarifications          December 2009
> 
> 
>    protocol registered in the IANA "Service Names and Port Numbers"
>    registry [RFCyyyy].
> 
>    Note that in order to make use of DNS based service discovery using
>    SRV records, the application/service does *not* need an IANA-assigned
>    port number (which would also be filed in the IANA "Service Names and
>    Port Numbers" registry).
> 
>    The port numbers carried in the RDATA portion of the SRV records are
>    locally assigned within the Service Domain; in case the service
>    indeed has an IANA-assigned (default) port number, the locally

IANA-assigned is not indicated as "default". There's no mechanism that
specifies it as a default.

>    assigned port number MAY coincide with that default port number,
>    unless the documentation of the service specifies otherwise (it may
>    say "MUST", "SHOULD", or recommend *against* using the default).
> 
>    As all domain name labels, SRV Service Labels are matched in a case-
>    insensitive manner.
> 
>    [RFCyyyy] restricts IANA-registered Service Names to 15 characters in
>    "ldh-syntax", informally:

The rest of this section should be dropped. Just cite the IANA doc.
If/when the IANA spec changes, so should this. It's a bad idea to copy
requirements into a separate doc.

...
>    Appendix A offers a scheme for "Extended SRV Service Labels" that can
>    be adopted by service specifications that cannot contend with these
>    restrictions, and which seek for a versatile naming scheme not
>    violating the provisions of [RFCyyyy].

IMO this appendix should be offered and its necessity argued in a
separate document.

> 5.  Service Discovery Client Considerations
> 
>    Implementations making use of dynamic service discovery based on DNS
>    SRV records for a particular application/service will construct a
>    prioritized list of applicable Service Prefixes, following the
>    guidelines in the two subsections below.

This appears to be describing new user-side requirements for the use of
SRVs. This needs further discussion in the WG; I don't think such a
prioritized list should be required.

---

I don't understand why the remainder of this section (below) is needed;
you're just restating how to use SRVs, and the SRV spec should have said
that. Didn't it?

>    To form the QNAME(s) for DNS SRV lookup, each Service Prefix is
>    concatenated (with a period as the label separator character) to the
>    FQDN of the Service Domain the application is interested in.
> 
>    Depending on application strategy and perhaps local policy
>    (configuration), the DNS queries with QCLASS=IN and QTYPE=SRV can be
>    performed serially or in parallel -- to decrease the latency in the
>    case higher priority queries do not succeed in finding matching SRV
>    record(s).
>
>    The answers obtained are processed as specified in RFC 2782
>    [RFC2782], subject to the preferences of the service client for
>    transport and/or "substrate" protocols.  If necessary, the Target
>    domain names obtained are then queried for address records (i.e., at
>    the time of this writing, A and/or AAAA RRs) to determine the network
>    layer addresses to be contacted over the corresponding transport
>    protocol using the port number contained in the 'Port' element of the
>    respective SRV record.
> 
>    Note:  RFC 2782 [RFC2782] on page 7 imprecisely indicates the client
>       "[SHOULD] ... try to connect to the (protocol, address, service)"
>       tuple.  Since at the transport layer the port number needs to be
>       used, not the service (name?), and to let the order of the tuple
> 
> 
> 
> Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 10]
> 
> Internet-Draft          SRV Prefix Clarifications          December 2009
> 
> 
>       components follow the protocol layers, it should refer to
>       "(address, protocol, port)" tuples.
> 
> 5.1.  Protocol Label Selection
> 
>    Some services are defined to operate over only one transport
>    protocol.  In this case the application MUST use the appropriate
>    transport label in forming the Service Prefix for SRV record lookup.
> 
>    If a service can operate over multiple transport protocols, then the
>    specification of the service might indicate an order of preference,
>    or local policy may supply it.  Any service can provide a specific
>    order in the Notes section of the "Service Names and Port Numbers"
>    registry, during registration or via registration update [RFCyyyy].

I don't agree; prioritization should be a property of the SRV records,
not in the notes. This seems like an extension of the protocol.

>    Absent such information, the following priority order SHOULD be used

Absent what information? The "notes" aren't in the SRV records, so as
such they ought to always be absent at the endpoint - so the rest of
this is the only real recommendation here, and it's a tautology
(endpoints should use only what they can use).

>    as appropriate, based on what transports are defined and registered
>    for the service, and supported by the client: _udp, _tcp, _sctp,
>    _dccp.
> 
> 5.2.  Service Label Selection
> 
>    Absent service specific documentation saying otherwise or hints
>    available to the client (e.g., by configuration), the following
>    recommendations SHOULD be followed.
> 
>    If an application/service has a single registered Service Name, a
>    prospective client uses the Standard Service Label derived from it
>    according to Section 4.
> 
>    Contrary to the strong recommendation in RFC 2782 [RFC2782], several
>    legacy services have been assigned more than one Service Name in the
>    past.  For instance, the well-know "systat" service is also referred
>    to as "users" service, the DNS service, "domain", is also referred to
>    as "nameserver" or "dns", "rlp" is also denoted as "resource", the
>    WhoIs service is identified by "whois" and "nicname", the web service
>    uses "http" or "www", "kerberos" is also indicated by "kdc", and the
>    PCMail service has been assigned the equivalent Service Names
>    "pcmail-srv" and "pcmail".
>    In all these cases, the "Service Names and Port Numbers" registry
>    will clearly indicate which name is the primary one and which names
>    are considered aliases.

I don't see why this should be expected or is necessary, except for the
deprecated names whose syntax needed to change based on the IANA ports
doc. Please explain.

>    Unless a prospective client has specific hints available (e.g., by
>    configuration) indicating that a specific alias name ought to be
>    tried preferentially, the primary Service Name SHOULD be used, and it
>    also SHOULD be tried if the lookup of an alias name fails.

I don't see what this accomplishes. It seems an unnecessarily restriction.

The rest of this section should be moved to the separate doc arguing for
extended names...

>    If a service/application supports different well marked instances
>    identified by different Service Names or a related specification has
> 
> 
> 
> Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 11]
> 
> Internet-Draft          SRV Prefix Clarifications          December 2009
> 
> 
>    introduced the usage of extended Service Labels for discovery of this
>    service (e.g., making use of the scheme specified in Appendix A), the
>    specifications SHOULD always also define a single default service
>    instance, and hence a default Service Label or Service Name (that can
>    be used to construct the the corresponding Standard Service Label).
>    Prospective clients MAY follow any service instance selection policy
>    desired (by implementation, deployment, or configuration), but SHOULD
>    be prepared to fall back to the default service instance if the SRV
>    record lookup for preferred service instance(s) fails.
> 
> 
> 6.  Provisioning of SRV records
> 
>    DNS zone administrators SHOULD support (and encourage) the
>    provisioning of SRV records related to the basic domains they manage.
>    Dynamic DNS Update ([RFC2136], [RFC3007]) is an option, but this is
>    out of scope for this document.

IMO, SRV provisioning ought to be outside the scope of this doc
entirely. The rest of this section is not related to the indicated focus
of this doc, and if needed should be in another (third) document.
...
> 7.  Security Considerations
> 
>    This document does not have any specific security implications.

Agreed.

>    However it is hoped that the more orderly, and more frequent use of
>    SRV-based dynamic service discovery, based on the rules clarified in
>    this documents and the establishment of a unified service registry,
>    will provide valuable information for administrators and security
>    policy makers, to the benefit of the overall security of the
>    Internet.

I have no idea why this should be true; can you explain?

The rest of this section can be omitted; it does not add to the first
sentence of this entire section, which says it all IMO.

> 8.  IANA Considerations
> 
>    This document has no IANA actions.
> 
> 
> 9.  References
> 
> 9.1.  Normative References
> 
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
> 
>    [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
>               specifying the location of services (DNS SRV)", RFC 2782,
>               February 2000.
> 
>    [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
>               Specifications: ABNF", STD 68, RFC 5234, January 2008.
> 
>    [RFCyyyy]  Cotton, M., Eggert, L., Mankin, A., Touch, J., and M.
> 
> 
> 
> Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 13]
> 
> Internet-Draft          SRV Prefix Clarifications          December 2009
> 
> 
>               Westerlund, "Internet Assigned Numbers Authority (IANA)
>               Procedures for the Management of the Service Name and
>               Transport Protocol Port Number Registry",
>               draft-ietf-tsvwg-iana-ports-04 (work in progress),
>               December 2009.
> 
> 9.2.  Informative References
> 
>    [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
>               August 1980.
> 
>    [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
>               RFC 793, September 1981.
> 
>    [RFC2052]  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
>               location of services (DNS SRV)", RFC 2052, October 1996.
> 
>    [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
>               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
>               RFC 2136, April 1997.
> 
>    [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
>               Update", RFC 3007, November 2000.
> 
>    [RFC3232]  Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
>               an On-line Database", RFC 3232, January 2002.
> 
>    [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
>               G. Fairhurst, "The Lightweight User Datagram Protocol
>               (UDP-Lite)", RFC 3828, July 2004.
> 
>    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
>               Rose, "DNS Security Introduction and Requirements",
>               RFC 4033, March 2005.
> 
>    [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
>               Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
> 
>    [RFC4614]  Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
>               for Transmission Control Protocol (TCP) Specification
>               Documents", RFC 4614, September 2006.
> 
>    [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
>               RFC 4960, September 2007.
> 
>    [RFC5237]  Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
>               the Protocol Field", BCP 37, RFC 5237, February 2008.
> 
> 
> 
> 
> Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 14]
> 
> Internet-Draft          SRV Prefix Clarifications          December 2009
> 
> 
>    [RFC5507]  IAB, Faltstrom, P., Austein, R., and P. Koch, "Design
>               Choices When Expanding the DNS", RFC 5507, April 2009.
> 
> 
> Appendix A.  Extended SRV Service Labels
> 
>    This non-normative Section defines a versatile extension scheme for
>    SRV Service Labels that can be incorporated by reference in
>    specifications of service discovery procedures for applications that
>    cannot contend with Standard Service Labels as specified in
>    Section 4.
> 
> A.1.  Motivation and Solution Space
> 
>    Sections 2 and 4 identify scenarios of applications/services that
>    might reasonably wish to use an extended scheme for forming their
>    Service Labels, in particular to identify protocol layers
>    (encapsulation layers, "substrate" protocols) stacked between the
>    transport protocol and the application protocol itself, without
>    having to register a multitude of Service Names in the "Service Names
>    and Port Numbers" registry and hence being bound to the 15-character
>    name size limit.  Other scenarios with similar requirements have been
>    mentioned in recent work-in-progress in the IETF.
> 
>    For being useful, a scheme for extended Service Labels must allow (a)
>    to easily determine that a label obeys to this scheme and (b) to
>    unambiguously extract the underlying Service Name and the added
>    extension components (henceforth: Qualifiers) from the full label,
>    whereas at the same time the scheme needs to ensure that it does not
>    pollute the name space of Service Names and that thereby the
>    uniqueness of registered Service Names is not disturbed.
> 
>    As restated in Section 4, the syntax of Service Names from [RFCyyyy]
>    does not allow the underscore ("_") character, which in turn already
>    is used as a prefix character for SRV Service and Protocol Labels
>    serving to distinguish these labels from 'ordinary' domain name
>    components.  Therefore, a manifest method to construct extended
>    Service Labels is to concatenate the given Service Name and
>    Qualifiers, prepending each component by an underscore character.
> 
> A.2.  Specification
> 
>    Thus, we arrive at the following syntax for Extended Service Labels,
>    extending the ABNF from Section 4:
> 
> 
> 
> 
> 
> 
> 
> Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 15]
> 
> Internet-Draft          SRV Prefix Clarifications          December 2009
> 
> 
>          serv-label     =/ ext-serv-label
> 
>          ext-serv-label = USC service-name 1*( USC serv-qualifier )
>                           ; total size limited to 63 characters
> 
>          serv-qualifier = 1*(l-d-h)
>                           ; also conforming to the <token> rule
> 
>    Hypothetical example:
>       Assume an application with registered Service Name "foohoo" for
>       transport over SCTP is served for the domain "ext.example".  Also
>       assume that this service needs to be qualified by the keywords
>       (service qualifiers) (1) "barbar" and (2) "aanne".
>       Then the corresponding Extended SRV Service Label will be:
> 
>          _fooho_barbar_aanne
> 
>       and the full SRV owner name will be:
> 
>          _fooho_barbar_aanne._sctp.ext.example
> 
>    Application designers who want to make use of this scheme need to
>    precisely document the <serv-qualifier> values supported and refer
>    normatively to this section.  Any such specification SHOULD indicate
>    a mandatory-to-implement default form of the service that will be
>    represented by the Standard Service Label for this service, per
>    Section 4.  This allows for an easy fallback strategy for clients of
>    such service that are not interested in particular variants of the
>    service, or when the service variant preferred by the client is not
>    offered at a particular Service Domain and hence not represented by
>    an SRV record in the DNS.
>    Absent such application-specific documentation, always the Standard
>    Service Labels specified in Section 4 are used.
> 
> A.3.  Applicability
> 
>    Each application/service making use of this mechanism inherits from
>    its registered Service Name a distinct namespace, and its designers
>    must manage this 'private' namespace of valid Extended Service Labels
>    according to their needs.  For instance, there is no central IANA
>    registry for such namespaces.  The application is still identified by
>    its Service Name, and the related leading standard Service Label part
>    is to be used for policy decisions.
> 
>    If the service qualifiers are used to indicate intermediate layers,
>    the application-specific service discovery specification SHOULD
>    specify that the qualifiers be given in protocol stacking order; if
>    substrate protocols used have their own registered Service Name, it
> 
> 
> 
> Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 16]
> 
> Internet-Draft          SRV Prefix Clarifications          December 2009
> 
> 
>    is strongly RECOMMENDED that these Service Names be used to identify
>    the corresponding qualifiers.
> 
>    The companion document [TBD] contains examples of legacy use cases
>    specified in the IETF that preferably should migrate to this scheme
>    and thereby, it instantiates these recommendations.
> 
> 
> Authors' Addresses
> 
>    Olafur Gudmundsson
>    Shinkuro Inc.
>    4922 Fairmont Avenue, Suite 250
>    Bethesda, MD  20814
>    USA
> 
>    Email: [e-mail]
> 
> 
>    Alfred Hoenes
>    TR-Sys
>    Gerlinger Str. 12
>    Ditzingen  D-71254
>    Germany
> 
>    Email: [e-mail]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Gudmundsson & Hoenes      Expires July 1, 2010                 [Page 17]
>