Message-ID: <4C2B9097.4060009@isi.edu>
Date: Wed, 30 Jun 2010 11:44:39 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Alfred_=3F?= <ah@TR-Sys.de>
CC: namedroppers@ops.ietf.org, apps-discuss@ietf.org, tsvwg@ietf.org,
 draft-ietf-tsvwg-iana-ports@tools.IETF.ORG
Subject: [dnsext] Re: [port-srv-reg] New Version Notification for
 draft-gudmundsson-dnsext-srv-clarify-00
References: <201006301801.UAA26017@TR-Sys.de>
In-Reply-To: <201006301801.UAA26017@TR-Sys.de>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig11C26585775D6B3276946C7B"
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig11C26585775D6B3276946C7B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, Alfred,

Alfred ? wrote:
=2E..
> 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.
>=20
> 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.
>=20
> 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.

I don't understand this position. Sec 5 of that doc allows aliases. The o=
nly
constraint is that one be designated primary so that reverse lookups can
determine when aliasing occurs.

draft-ietf-tsvwg-iana-ports is updating the length of service names. Havi=
ng this
document concurrently undermine that update, especially in a "non-normati=
ve"
appendix seems inconsistent at best.

I'd expect that a substantive change to the specification of SRV names - =
i.e.,
introducing a hierarchical namespace - would require a standards-track do=
cument
whose main body focused on the changes proposed, and that they need to be=

coordinated with draft-ietf-tsvwg-iana-ports.

Can you clarify?

Joe



--------------enig11C26585775D6B3276946C7B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkwrkJcACgkQE5f5cImnZrsQAgCgjZzZyltk1ACWtltxbYPW2xX5
y34AnAoVdL+G3tDzkAM6FUAWHgvI3ZfB
=3qtd
-----END PGP SIGNATURE-----

--------------enig11C26585775D6B3276946C7B--