RE: NATs *ARE* evil!

2000-12-15 Thread Pan Jung

How about this, practicality.  Let's say we can kill all NAT's by   sunset,
Sunday.  Who can make stop all the NAT's poping up Monday morning?  They
might be up all night building experimental network, with red eyes?

Pan Jung



-Original Message-
From: Iliff, Tina [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 15, 2000 10:48 AM
To: 'Dave Robinson'; Keith Moore
Cc: M Dev; Sean Doran; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: NATs *ARE* evil!


Yes!  TCP breaks due to the fact that "true" source/destination sockets
cannot be defined.  The destination would not know where to send a response
except in the case where DNS is used...unless I need to do more reading

Tina Iliff


-Original Message-
From: Dave Robinson [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 15, 2000 11:11 AM
To: Keith Moore
Cc: M Dev; Sean Doran; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: NATs *ARE* evil!


What's the problem with locally significant addresses?  Having thousands of
10 networks will never present a problem unless those networks at some point
would like to talk to each other.  Is that where this whole discussion is
going (or coming from) - that ultimately the more NAT'ing we do, the more
headaches we're creating for ourselves en route to true global connectivity?

Dave

-Original Message-
From: Keith Moore [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 15, 2000 10:56 AM
To: Dave Robinson
Cc: Keith Moore; M Dev; Sean Doran; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: NATs *ARE* evil!


because in a NATted network the same addresses are used in different
parts of the network.  addresses are meaningless.





RE: Internationalization and the IETF

2000-12-13 Thread Pan Jung

Hello,
I am new here but one note:
Even in long term, would "Services in Rich Application Classes" = directory
service
could be treated differently from "Services in System Operation Classes" =
DNS ?
Depending on the importance for systems operations? Maybe even as
sub-classes.

Pan Jung
Programmer/Consultant
[EMAIL PROTECTED]


-Original Message-
From: Kyle Lussier [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 13, 2000 10:11 AM
To: TOMSON ERIC; 'Gabriel Landowski'
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Dave
Crocker'; Durah, Kheder; Randy Bush; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: RE: Internationalization and the IETF



I hate to butt in here, I've been listening to these discussions for
some time.  (I am incredibly impressed with how smart everyone in these
IETF groups is).

But, what about NMS directories that contain devices (non-computer),
physical
location, automations, histories, provisioning, and acquisition information?

There seems to be a debate to split "DNS" from "Directory" services,
whereas, in long term, it is inevitable that DNS will merge with
Directory services, even if current technology isn't that way.
Pushing for a conceptual split in theory will slow the convergence
of DNS/Directory. I would argue, that this convergence is very valuable,
and is the natural progression (in long term).

The concept of a directory should be a large database, with pre-defined
standards for how different types of common knowledge is built in,
but should also allow for user defined types, for which no existing
standard exists.  DNS should ultimately become one standard data type
of this theoretical global directory.  As should what we want to do,
which is storing automations, configurations, and histories in the
directory.

The IETF community should be aware that it is probable that it is
impossible to predict *what* one would want to store in a Directory,
but that there is standard information that should be well-defined
to extract from the directory.

This is a passionate issue for us as no existing directory implementations
have supported all of the requirements for our NMS and we built on SQL
databases.

Ultimately, we believe a directory service should be just like a massive
SQL database, but include standard "Tables" for standard things, like
user accounts, DNS, computers, etc.  It should all be centrally accessible
in a common manner, but support custom user types, in addition to standards
for standard things.

It is dangerous to say "DNS is not Directory".  While in today's existing
implementations that is true, ask yourself the question, in the long
term, will this still be true?  And if it will be, is that good or bad?

I would argue, that in the long term, DNS *should* merge with Directory
services.

Kyle Lussier

 Directory service = a software system that responds to requests
 for information about entities, e.g. people in an organization.
 It's a system for managing access to computer resources, keeping
 track of the users of a network,... from a single point of
 administration. It allows a network administrator to set up and
 control a database of users and resources and manage them using a
 directory (by example with an easy-to-use GUI, Graphical User
 Interface). Users, computers, sites,... can be added, updated and
 managed centrally ; applications can be distributed electronically.

 Microsoft Active Directory, Network Information Service (NIS),
 Novell Directory Service (NDS) and X.500 are examples of
 directory services.
 --

 Address registry = a registry of numbers or addresses with some
 corresponding data, e.g. names. Such a registry helps maintain
 names, which are identifiers that are mapped to numbers or addresses.

 Let's say a Directory Service is multi-dimensional, in the sense
 it involves many types of data, many levels of information you
 have to search in, while an Address Registry has one dimension,
 in the sense it just maps addresses to their corresponding name,
 like a telephone registry, DNS, WINS, the "hosts" file or the
 "lmhosts" file.
 --

 So, what is DNS? In the TCP/IP world, the Domain Name System
 (DNS) is a distributed database that provides the mapping between
 IP addresses and hostnames. It's just an address registry.
 --