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

[Alfred Hönes <[e-mail]>]

At Sat, 06 Feb 2010 14:46:05 -0800, Joe Touch wrote:
>
> 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

Joe and all,
my apologies for the delayed response.
Thanks to Joe for the detailed comments.

Summary response (please see more inline below):

Please do not neglect the criticism spelled out repeatedly for
draft-ietf-tsvwg-iana-ports but rejected by your team.  This
draft tries to accommodate the restrictions imposed by that memo.
Yet, to be useful for aligning previous RFCs now deemed non-
conformant with these rules and recent/ongoing work specifically
calling for multi-label hierarchical Service Prefixes, this
draft needs to show a uniform path that can be recommended
to the authors / WGs where these RFCs are originating from.

Thus, as a replacement mechanism for specifications using
Service Prefixes with non-transport protocol Protocol Labels
and/or more than two labels, the non-normative extension
mechanism proposed is an essential part of this memo.

Unless the restrictions imposed by draft-ietf-tsvwg-iana-ports
on the lenght of Service Names and the one-servie-name-per-
application rule are being relaxed substantially, this extension
mechanism will remain in this document.


NOTE:
  A slightly revised update to draft-gudmundsson-dnsext-srv-clarify
  has just been submitted: draft-gudmundsson-dnsext-srv-clarify-01.
  Due to time constraints, this version however does not yet contain
  all the edits planned.


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

The draft says "outmost utility" for this specific case.
For brevity in this part of the introduction, not all "important"
use cases are listed.

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

Please note that this historical perspective is presenting the
"state of the art" after publication of RFC 2782 and *before*
the current effort with this memo and tsvwg-iana-ports.
Thus, it refers to the pre-RFC 3232 situation and its evolution
by current practice in the past.

Will be clarified in the leading text above the bullets.


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

Again, these bullets describe the consequences of literally
following RFC 2782 text.
Thus, it is correct that "locally defined lists" of service and/or
protocol names (which indeed would be similar in content to the
"/etc/services" and "/etc/protocols" POSIX database files) would
"equally allow to list the full service information".
If such local lists (as suggested by RFC 2782) could contain all the
information contained in the SRV RDATA as well, they indeed would --
at first glance, and for local users -- make "SRV records redundant".


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

The primary point is to show that literally following the idea
spelled out in RFC 2782, to have service and/or protocol names
listed in a local repository, would be a step backward.


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

Of course, some documents describe such use cases for SRV.

We are not the Internet police and do not want to obsolete prior art,
nor interfere with work in progress in various WGs.
Thus, it does not make sense to impose a "MUST" on human behavior
that connot be controlled.  If a WG insists on using hierarchical,
multi-label Service Prefixes for a specific application (as it e.g.
currently is discusssed seriously for mass storage access protocols),
we cannot enforce the two-label rule with this document.
Pretending otherwise would IMO be foolish.

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

Again, implementation practice can diverge from written
specifications.  So, although the specs of an application do not
mention the use of SRV records, implementation and deployment
practice may have evolved to actually make use of them where they
are available.  In particular, a revised specification could be
in progress.
That would be reasons for escaping the "SHOULD NOT", isn't it?
Therefore, "MUST NOT" would not make sense and could not be enforced.
The "SHOULD NOT" above is rephrased literally from the "Applicability
Statement" on page 2 of RFC 2782.

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

A good "SHOULD NOT" needs to indicate what the possible exceptional
cases are.  Therefore, the "unless ..." clause is appropriate.
The last sentence is necessary as well, because we want the rules
in Sections 3 and 4 act as the "default specification" in such case;
and other parts of your comment indicate that you also prefer
these rules in favor of ad-hoc rules specific to such application or
implementation.


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

This concept is neither new nor introduced by this draft.
It can be found in various RFCs and other documents --
please refer to the expired draft-gudmundsson-dns-srv-iana-registry
for a list of related RFCs (look for "overlay protocols").
In Hiroshima it has been decided that using the Protocol Label to
indicate layered services is not the way to go, and we have agreed
to this point of view because otherwise the port number in such SRV
RDATA would be ambiguous or meaningless.  Therefore, when saying
"no no!" and thus "closing a road", we regard it as a duty to the
community to point out an alternative road leading to such goals.


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

That's part of the problem to be solved.
We admit these rules and present a method to maintain the
restrictions on Service Names, by suggesting a syntax that
unambiguously allows to recover the Service Name from the
Service Label, by using a separator character not allowed
in Service Names.

Again, we believe that a document that essentially makes other
work non-conformant after the fact would be ill-advised if not
presenting one or more alternate solutions.


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

The 15-char limit is artificial; the legacy IANA registry for
Protocols and Well-Known Services (for the DNS WKS RR) had a
40-char limit.

>                                       ... There are far too many
> current names that do not have this sort of syntax.

There are some service names following this model, and there are
very few existing service names using the hyphen for other purposes.
Thus it looks like that idea is not new and already adopted by
various communities.


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

But that's another way that you are opposing to.
Any changes to the SRV RDATA format would make it a new RR type.
Further, the IAB "Design Choices When Expanding the DNS" document
(RFC 5507) strongly recommends against selectors embedded within the
RDATA of new DNS RRs; you apparently are advocating to the contrary.

Example:
A mass storage application looking for a read/write instance of a
network based file system over a particular kind of secure channel
should not have to deal with the bulk of SRV RRs for read-only copies
of the same file system or those only supporting another security
layer, and vice versa.  This can easily be accommodated by the naming
scheme, but not by embedded selectors.

>
>>        One disadvantage of this solution is the length limitation
>>        imposed on the Service Name by [RFCyyyy] (15 characters, see
>>        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.

We now accept the 15-char limitation in the IANA ports doc,
and we do not expect it to support sub-layer information.
We also support the deprecation of non-transport protocol names
in the Protocol Labels.  Therefore, have to (at least) indicate
a method pointing forward for the specifications affected by these
restrictions.  The method specified in the Appendix is non-normative,
but it is intended to guide authors of replacement specifications
for the affected applications as well as developers of ne application
specifications that want to incorporate it and normatively fill in
the details in a manner suitable for their context.


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

Fallback rules are also common elements in service discovery
procedures.  (Recall the MX to A RR fallback for [E]SMTP!)

>                                               If such a default or
> fallback is assumed, then the SRV system should have a flag indicating
> that.

The fallback rule has to deal with the lack of specific DNS RRs.
(There are lots of reasons, ranging from inappropriate provisioning
systems and business rules down to human error.)
It does not make sense to expect the information on what to do in
the absence of DNS records being stored in such records!


>       Port numbers are not intended to have any hierarchy or alternates
> of services, so such a fallback is not appropriate to indicate there.

The IANA registered port numbers have always been the default port
numbers for a particular service; users/deployments have always
been free to use alternate ports.  For instance the URI standard
explicitly specifies that the absence of a port number in a URI (of
a scheme supporting host names and port numbers) is to be interpreted
as an indication of the default port number as registered at IANA.
Why should SRV usage introduce a different model?


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

Is a strong call for simplicity and specification of a working default
actually too much burden?  IIRC, that's what IAB statements have been
calling for over and over again.
Above, you have called for stronger "MUST" requirements for
documents specifying SRV usage for some application.
Why would the "SHOULD" here be too strong then?


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

Ooops!  Section 3 is essential!


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

Defaults -- that's what they are!
We have a Full Standard saying so (see the remark on URIs above).


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

There have been instances of protocol specifications changing
the recommendations over time, during their evolution!


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

This has been written when the IANA ports draft was not clear
with respect to formal syntax.  Will be modified as the latter
contains an ABNF that is consistent with the prose.


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

As stated repeatedly above, we would regard it as very poor service
to the community to have a document that makes existing RFCs non-
conformant and does not (at least) suggest n alternative.

However, if you agree to make a normative reference to such document
in the IANA ports draft to ensure coordinated publication of all these
drafts and the ADs agree having to deal with yet another I-D in the
IESG, that could be done, but it would simply be more work for all
and increase the delays.


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

This is observed behavior and documented in many specifications
(both published and work-in-progress).  It is the recommended way
to deal with service discovery in the APP area.
This is not a new requirement, and there's no RFC 2119 language here.


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

RFC 2782 did discuss some aspects,; the material here is largely
supplementary, and it contains corrections for errata in RFC 2782.

Your words seem to indicate that this actually is necessary text
for a clarification document.  We have introduced clarifying
terminology and want to provide a decription of the process in
these terms.

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

Delays by non-use of parallel DNS lookup are frequent complaints
(cf. recent threads on the DNSOP list!), and so emphasis on this
possibility seems very appropriate too.

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

No.  All prioritization given inside DNS RRs is always local,
i.e. relative to the RRset, not global in nature.
(See the DDDS specifications for more details.)
So there cannot be any assumed relationship between preference values
in SRV RRs for, say, TCP and SCTP because they have distinct owner
names.


>
>>    Absent such information, the following priority order SHOULD be used
>
> Absent what information? The "notes" aren't in the SRV records, so as

The "Notes" in the Service Names & Port Numbers registry
that implementers should follow ... -- as explained in the preceding
paragraph of our draft you have quoted above.


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

.. including the knowlegde built into the service discovery code
by their implementors, which in turn should be based on public
records (specification documents and the IANA registry), for
maximum interoperability.


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

RFC 2782 said that aliases for Service Names "SHOULD NOT" be used.
The distinction can only be made and this "SHOULD NOT" be followed
in practice iff the tsvwg-iana-ports registry indeed contains this
(primary/alias) information.

Unless you have a specified primary name, SRV RRs would have to be
entered in the DNS for all possible combinations in the Service Prefix.
Having an explictly marked 'canonical' name allows to restrict the
wealth and to implement fallback to it in the discovery code,
even if the service discovery documentation for a particular
application makes an exemption to the "SHOULD NOT" quoted above.

Note that this distinction is a common practice in the context of
the DNS; for instance MX RRs expect 'canonical' host names in their
target, not alias names introduced into the DNS via CNAME RRs.

These rules help to reduce to combinatorial explosion in the DNS
and to contain the effort needed for service discovery.
As the draft states ...

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

Again, as above, a good default to make success much more likely
in such scenarios (if there are SRV RRs present at all, of course!).

As indicated above, RFC 2782 was even more restrictive.

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

See above.


>>    If a service/application supports different well marked instances
>>    identified by different Service Names or a related specification has
>>    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.
> ...

No.  Deficiencies in the provisioning paths are among the most painful
hurdles in the use of "new" RRs (those not specified in RFCs 1034/1035).

If we did not spell out such considerations, SRV-based service
discovery would lag behind for many more years.

Application designers and users have called for RFC text they can point
to if DNS operators refuse to load valid DNS RRs.
A document elaborating on SRV RRs is a splendid opportunity to supply
such text.

Further, these deliberations are kinda "management considerations" --
as strongly encouraged by the OPS ADs.

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

Having documented rules gives justification to their deployment.
This avoids ad-hoc hacks to circumvent stubbornness.
Regular and uniform use of SRV RRs should foster operational practices
to derive filtering rules (for a service domain) from the SRV RRs
of that domain.  This in turn should promote use of native services
and help to reduce inappropriate application-layer tunneling practices.


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

It is common practice to point to security considerations
in closely related documents, and SecDir reviews and the IESG
regularly seem to call for such practice.
So we'll keep these short paragraphs unless SecDir/IESG statements
to the contrary will be received.

>
>>  ...
> AH: <snip/>



Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+