Re: [idn] Re: [JET-member 464] Re: Fw: Re: new membersinvitation

[John C Klensin <klensin@jck.com>]

--On Monday, 29 October, 2001 11:29 +0800 "James Seng/Personal"
<jseng@pobox.org.sg> wrote:

> You are confusing me too. So let me put it in another way.
> 
> There are many different kind of 'cost'. 'scaling cost' like
> what you described and 'economy cost' like what deng/tseng.
> 
> I am saying 'scaling cost' is an engineering considering, but
> not 'economy cost'.
> 
> Is this better?

James, Eric, and others,

I suspect that what I'm about to say is similar to what others
have been saying, but there is apparently sufficient confusion
that perhaps a different way to say it will help.

I'm not sure the distinction you are trying to make above helps.
But, more important, we are getting into areas here that are not
only not within WG scope, but are not even IETF issues.  

Let's distinguish between two types of economic issues.  In one
case, there is a protocol choice in which one option is
_inherently_ more expensive than another.  For example, suppose
we had one way of doing something that was vastly more costly to
develop or operate than another but, presumably, offered some
technical benefits.   It would be reasonable, and necessary, for
the IETF to consider the tradeoffs involved.  And, if we get it
wrong, we presumably get punished in the market.  

By contrast, assume there is a choice that depends on a
difference in pricing, not on costs.   Pricing is not our
problem, although we might offer some advice to registrars,
registries, or to ICANN.  To take the present situation as an
example, someone (presumably not an IETF WG) could possibly
convince some registrar that, if they offered a two-for-one deal
on TC and SC registrations, they could sufficiently increase
their volume on such registrations to make up any losses on
costs and, therefore, that doing so would be in their economic
interest.  No protocol changes needed.  Or one might try to
convince ICANN to presuade registries to adopt a similar rule.

There are potential IETF issues here, but they aren't within
IDN's scope.  For example, if one wanted to make a "TC and SC
for price of one" strategy cheap and easy, it might be sensible
to put some specific features to support that option into a
registrar-registry protocol (I'd hope we do not go down that
path  until and unless we have clear direction from either ICANN
or some ccTLD registries that they want such a thing).  Or one
might want to think about facilitating such matching by
registering and installing, e.g., the SC name normally, but
putting in the TC name as a DNAME RR, rather than series of NS
RRs.  I'd want to get advice from DNSEXT or some other
collection of DNS experts, but it might help with the solution
in the registrar/ registry space.  But, again, it is not an IDN
decision matter.

To oversimplify this a bit, my financial and economist friends
make a very strong distinction between cost issues and pricing
ones.  Cost issues may well be constraints on protocols, and
hence are something IETF should, IMO, carefully consider.  But
pricing issues are another matter, since prices are determined
by policies -- about what one can get away with, about the
allocation of costs, and so on.    Pricing issues are not an
IETF matter and, realistically, we could not directly influence
them if we try.  And a conversation about what some registry or
registrar will charge for various services is clearly a pricing
issue.

That one should be taken somewhere else.  I'd suggest the ICANN
DNSO, or their new IDN committee.  And perhaps this is an area
in which MINC should organize a lobbying and educational effort.

But it does not appear to me to be within the scope of the IDN
WG.

    john