Re: "so-called" keyword and layer 3

[John C Klensin <[e-mail]>]

--On Tuesday, 04 December, 2001 21:59 +0800 "James Seng/Personal"
<[e-mail]> wrote:

> I believe the norm of the IETF has not take existing business
> requirements into consideration. Their technical input,
> however, would be appreciated.

James, while you are correct about the norm, I think that, in
this situation, some things that we would normally think of as
business requirements have evolved into engineering constraints.
To ignore an engineering constraint --whether it is technical or
economic-- is, in my opinion, sloppy and irresponsible work at
best.

So, to the extent possible, let's avoid trying to categorize
things as a means of excluding or including them from the
conversation and concentrate on identifying and solving real
problems in a way that causes the solutions to be sensible when
viewed as a complete system.

See also below...

--On Tuesday, 04 December, 2001 23:38 +0800 "James Seng/Personal"
<[e-mail]> wrote:

> I think you got my point. IDN success or failure is really
> independent of IRNSS. We do know that whatever the case, there
> are certain limitation of IDN whereby IRNSS is designed to
> solve.

exactly.

> If there are Korean keyword providers (and there are many!) who
> have technical requirements to bring forward, please help them
> to bring them to this group. I undestand communication is going
> to be a problem but that is where you can help. I am sure John
> and others here are happy to hear them.
> 
> John's draft is unique in the sense that there is a "business
> model" section in it but it is definately not a norm. But lets
> try to keep business issues out of it unless of course John
> feels that he wants feedback on his "business plan section". If
> that is the case, I have no comments :-)

I think we can make a very fine, but important, distinction here.
True economic concerns that become engineering constraints are, I
would hope, very much on the table.  I would even suggest that
some of them always have been part of IETF considerations, e.g.,
"that way of doing something is just far too expensive to
implement and deploy" has, in my memory at least, always been
considered a legitimate form of argument.

The particular business plans of a particular business in a
particular country are not an IETF concern.  Questions about how
to design, or "fix" a protocol so as to enable one company to do
business, or put another company at a disadvantage have never
been an IETF consideration and I hope never will be.  But "is
there a viable way of doing this" includes costs and returns, not
just physics.    

In addition, marketplace experience that gives us information
about what users actually want and use should, I think, be very
important to us.  Most such experiences need to be evaluated
carefully, since the data are often subject to a wide range of
validity threats, but we should examine them.  And, whatever
those validity threats (including the notorious "what you already
know is better" one), experience with actual deployed systems
usually gives more useful results than asking users what they
would like without communicating an understanding of costs and
tradeoffs.

I guess a different way to say this is that I'm much more
interested in developing a good, general, and well-balanced
solution here than I am in purity or discussions about topics
IETF does and does not handle and how it does so.

    john