Re: New InterNIC Domain Dispute Policy

[Michael Dillon <[e-mail]>]

On Fri, 28 Jul 1995, Craig Metz wrote:

> In message <[e-mail]>, Karl Aue
> rbach writes:
> >> NSI DOMAIN DISPUTE RESOLUTION POLICY STATEMENT
> >
> >I would have had to search long and hard to find more unworkable
> >policy that that proposed.
> 
> 	The critical problem in my opinion is the lack of public review,
> comment, and consideration of this policy. I, for one, do not like the
> idea of the InterNIC, which purports to serve the Internet community in
> the spirit of cooperation, going and making such significant policy decisions
> themselves and then telling everyone what they decided, without any input
> from the Internet community.

The document as presented also seems rather US-centric. If the Internic 
is to truly function as an international registry for international 
domains then I think that it is time for it to be operated under the 
auspices of some existing international organization, perhaps a UN agency.

The current Internic organization could continue operating the .mil and 
.gov registries which are USA only or it could simply disband and hand 
off its name "the Internic" to a new international body.

While we are on the subject I suppose I should mention the fact that no 
new top-level domains are being created other than ISO 3166 domains. As 
far as I can see it is technically possible for disgruntled network 
operators to hijack the Internic by creating new toplevel domains, 
operating root name servers for these new top level domains in 
combination with existing domains, and then convincing people to use 
their root nameservers rather than the Internic's root nameservers.

Is the expansion of the root level in the domain tree being looked at?

.INC, .CORP, .BIZ, .LTD, .PTY, .OY, .GMBH, .FAMILY, .KLINGON, .EARTH

and so on. If domain real estate is no longer precious because the domain 
namespace is no longer artificially restricted, wouldn't turf battles 
cease to be a problem?

IMHO, the lack of variety in the root domain is one of two major factors 
causing these disputes in the first place. The second major factor is the 
lack of a .com.us domain and .com.state.us domains.

Sample domain rules:

.com.us  incorporated businesses with offices in more than one state
.com.state.us  incorporated businesses with offices in more than one
               city/county in a given state
.com.city/county.state.us  any business with offices in the city/county
.inc  any business in any country with the word incorporated (or 
      abbreviations thereof) in their name
.corp  any business in any country .... corporation ....
.ltd  any business in any country .... limited ....
.anon  any business in any country .... anonyomous ....
.biz  any unincorporated business in any country
.com  any commercially oriented enterprise anywhere (free for all)

The rules disallow a corporation like IBM from grabbing ibm.com, ibm.corp,
ibm.inc, ibm.ltd, ibm.biz ... hmmmm.... maybe not, they have lots of 
subsidiaries, but then we could just have a rule that you can only 
register in one of the new domains, on the other hand, how many companies 
actually DO have so many subsidiaries? maybe it's not a problem....

I believe there are architectural solutions to the problem that will be 
better than the legal solutions in the long run.

BTW, the hijacking proposal above was quite serious. If the Internic *IS* 
hijacked they would no longer have any control over the situation and 
with loss of control goes loss of legal liability. It would mean anyone 
could operate root level domains and only by cooperating with others 
could a company get what they want. It forces negotiation to be used 
rather than litigation.

Michael Dillon                                    Voice: [phone]
Memra Software Inc.                                 Fax: [phone]
http://www.memra.com                             E-mail: [e-mail]

d the Internet-Drafts  as a Proposed Standards:

1. Security Architecture for the Internet Protocol
	<draft-ietf-ipsec-arch-02.txt>
2. IP Authentication Header <draft-ietf-ipsec-auth-02.txt>
3. IP Encapsulating Security Payload (ESP) <draft-ietf-ipsec-esp-01.txt>
4. IP Authentication using Keyed MD5 <draft-ietf-ipsec-ah-md5-03.txt>
5. The ESP DES-CBC Transform <draft-ietf-ipsec-esp-des-cbc-04.txt>


These documents are the product of the IP Security Protocol Working
Group. The IESG contact person is Jeffrey Schiller.

Technical Summary

  These documents specify mechanisms for providing Authentication,
  Integrity, and Confidentiality of data traveling at the IP (both IPv4
  and IPv6) layer. Although not intended as a replacement for security
  services at other layers of the protocol stack, this technology
  provides significant benefit to the many applications that today use
  the network with little or no security protection.


Working Group Summary

  After an extended period of discussion and debate, the Working Group
  has come to consensus around these five documents. More work remains
  to be done, including the development of an Internet key management
  protocol, which the working group is currently addressing. Although
  an automated key management protocol is not yet specified, the above
  documents do not require a specific mechanism, by design. As such
  they are implementable as they stand.

Protocol Quality

  Jeff Schiller reviewed these protocols for the IESG. The need for
  security services on the Internet is now well known and these
  protocols provide an effective and in many cases transparent solution
  for many of the Internet Security problems we are experiencing today.
  Several implementations are currently underway and there is high
  confidence that these protocols will operate properly.

 Ballot: MIME Object Security Services to Proposed Standard
--------

Note: This is a multiple document set

Last Call to expire on: 07/06/1995

	Please return the full line with the vote.

		    Yes    No-Objection  Discuss *  Abstain

Harald Alvestrand   [ X ]     [   ]       [   ]      [   ]
Scott Bradner       [ X ]     [   ]       [   ]      [   ]
Joel Halpern        [   ]     [   ]       [   ]      [   ]
Frank Kastenholz    [   ]     [   ]       [   ]      [   ]
John Klensin        [ X ]     [   ]       [   ]      [   ]
Deirdre Kostick     [   ]     [   ]       [   ]      [   ]
Allison Mankin      [   ]     [   ]       [   ]      [   ]
Paul Mockapetris    [   ]     [   ]       [   ]      [   ]
Mike O'Dell         [   ]     [   ]       [   ]      [   ]
Joyce K. Reynolds   [   ]     [   ]       [   ]      [   ]
Jeff Schiller       [ X ]     [   ]       [   ]      [   ]
Susan Thomson       [   ]     [   ]       [   ]      [   ]

 Yes =>     I have read the spec and know it is good stuff.
 No Obj =>  I am familiar with the protocol and believe it to be OK.
	    Note: The ballot contains analysis from the AD which
		  may be adequate information to vote positively.
 Discuss => There is something fishy that may need clarification
	    or modification.  May be considered a "no" vote.
 Abstain => I am not familiar with the spec, have no
	    interest/expertise in the subject or otherwise feel
	    obliged to skip the voting.

 2/3 (8) Yes or No-Objection votes needed to pass.

 * Indicate reason if "Discuss".


The IESG has approved the following two Internet-Drafts as Proposed
Standards:

 1. MIME Object Security Services <draft-ietf-pem-mime-08.txt>
 2. Security Multiparts for MIME: Multipart/Signed and
    Multipart/Encrypted
	<draft-ietf-pem-sigenc-03.txt>

These documents are the product of the Privacy-Enhanced Electronic Mail
Working Group. The IESG contact person is Jeffrey Schiller.


Technical Summary

These documents describe a general framework for security within MIME
(draft-ietf-pem-sigenc-03.txt) and a specific proposal for offering
Privacy Enhanced Mail services within MIME(draft-ietf-pem-mime-08.txt).
Support is provided for digital signatures on MIME objects (both simple
and compound) as well as for confidentiality provided through data
encryption.

A key design goal is to provide a MIME parseable structure for signed
MIME objects (without requiring that signature verification occur prior
to complete parsing). Another important goal is to provide for "one
pass" processing of signed and/or encrypted MIME objects.

Working Group Summary

After extensive discussion and debate the PEM working group has come to
a rough consensus on these documents. One difference still outstanding
has to do with key/certificate hierarchies and how they are
structured.  One camp is in favor of a flexible approach that permits
implementors, site administrators and end-users to determine the key
trust mechanism appropriate for their environment. The other camp
insists that only X.509 certificates, issued by well defined
certification authorities, should be supported. This is to ensure the
ability to provide security services which scale to the whole
Internet.

The documents proposed for standardization here attempt to strike a
balance by providing for both X.509 certification as well as other
approaches that may be defined in the future. As written they can form
a basis for two different mail security services (represented by the
strict hierarchy approach on one side and the flexible mechanism
approach on the other) which share a common MIME interchange format.

Ultimately two mail efforts may be required because the requirements,
goals and potential user community for the two approaches are very
different.



Protocol Quality

Jeff Schiller reviewed these protocols for the IESG. The need for
security services on the Internet and the protection of sensitive
information exchanged via messaging systems in particular is acute.
These proposals provide a good solution for adding signatures and
encryption to MIME services in an environment where we desire the over
all structure to remain parseable where signature verification services
may not always be available.


Ballot: RPC: Remote Procedure Call Protocol Specification Version
	 2 to Proposed Standard
--------
Note: There are three documents in this set. See Writeup below

Last Call to expire on: 05/15/1995

	Please return the full line with the vote.

		    Yes    No-Objection  Discuss *  Abstain

Harald Alvestrand   [ X ]     [   ]       [   ]      [   ]
Scott Bradner       [   ]     [   ]       [   ]      [   ]
Joel Halpern        [   ]     [ X ]       [   ]      [   ]
Frank Kastenholz    [   ]     [   ]       [   ]      [   ]
John Klensin        [   ]     [   ]       [   ]      [   ]
Deirdre Kostick     [   ]     [   ]       [   ]      [   ]
Allison Mankin      [ X ]     [   ]       [   ]      [   ]
Paul Mockapetris    [   ]     [   ]       [   ]      [   ]
Mike O'Dell         [   ]     [   ]       [   ]      [   ]
Joyce K. Reynolds   [   ]     [   ]       [   ]      [   ]
Jeff Schiller       [   ]     [   ]       [   ]      [   ]
Susan Thomson       [   ]     [   ]       [   ]      [   ]

 Yes =>     I have read the spec and know it is good stuff.
 No Obj =>  I am familiar with the protocol and believe it to be OK.
	    Note: The ballot contains analysis from the AD which
		  may be adequate information to vote positively.
 Discuss => There is something fishy that may need clarification
	    or modification. May be considered a "no" vote.
 Abstain => I am not familiar with the spec, have no
	    interest/expertise in the subject or otherwise feel
	    obliged to skip the voting.

 2/3 (8) Yes or No-Objection votes needed to pass.

 * Indicate reason if "Discuss".


The IESG has approved the following three Internet-Drafts as Proposed
Standards:

 1. RPC: Remote Procedure Call Protocol Specification Version 2
	<draft-ietf-oncrpc-rpcv2-01.txt>
 2. XDR: External Data Representation Standard
	<draft-ietf-oncrpc-xdr-01.txt>
 3. Binding Protocols for ONC RPC Version 2
	<draft-ietf-oncrpc-bind-00.txt>


 These documents are the product of the ONC Remote Procedure Call
 Working Group. The IESG contact person is Allison Mankin.


Technical Summary

The protocols described in these three documents are a set of tools for
platform-independent distributed computing. The general Remote
Procedure Call model of distributed computing is the basis for many
networked applications. External Data Representation (XDR) is a simple
method of abstracting data types from their machine representations to
make RPCs possible.

(Open Network Computing) RPC Version 2, ONC XDR, and ONC RPC binding
are protocols developed by Sun Microsystems originally for supporting
the Network File System. NFS is widely ported and widely used in the
Internet, so there is benefit to the community for its underlying
transport and presentation support to be openly accessible and for
their evolution to be a matter of future, open engineering
discussions.

Other Remote Procedure Call approaches and protocols are also well
accepted and widely used. The IESG views ONC RPC as coexisting with
such peers, in a way that might be said to be parallel to TELNET and
RLOGIN.

In standardizing ONC XDR and ONC RPC, the IESG intends for the
community to gain added value from two useful distributed computing
protocols.

Working Group Summary

The Working Group reviewed initial specifications developed by Sun
Microsystems. The WG review resulted in a modest but substantial set
of changes. A spec of authentication binding protocols is not being
advanced at this time and the WG is chartered to rewrite and enhance it
in at least one future meeting. The WG contributed particularly as well
in the area of transport-independence, and the resulting specs provide
good support for the implementation of RPC over TCP that is finding
increasing use in some quarters of the Internet.

Protocol Quality

There are numerous implementations of the ONC XDR and RPC protocols. A
key question in the Transport Area's review of the specifications was
whether they accurately specified the protocols in use, and whether it
would be easy enough to implement from these specs as opposed to
implementing from others' example code. We concluded that they were
accurate and that they were complete and implementable.

The starting point of the WG was Sun Microsystems' request to transfer
control of ONC XDR and ONC RPC to the IETF. This starting point and
context for the WG was extensively reviewed as well.  The agreement
between Sun Microsystems and the Internet Society transferring the
protocols was published as an Internet-Draft, given a Last Call and
passed by the IESG. See RFC 1790 for this agreement.

Proposed WG: MessageWay (msgway)
	     -------------------

 Chair(s):
     Danny Cohen <[e-mail]>

 Internet Area Director(s):
     Frank Kastenholz  <[e-mail]>
     Susan Thomson  <[e-mail]>

 Area Advisor
     Frank Kastenholz  <[e-mail]>

 Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.isi.edu/msgway/msgway.mail

Description of Working Group:

THE APPROACH

Due to dramatic increases in circuits speed the traditional system
buses are limited in length (e.g., PCI is limited to 8") and cannot
provide the traditional system-wide support. Therefore, the system-wide
connectivity is provided by a high performance networks operating in
very close quarters, having the generic name System Area Networks
(SANs).

Many vendors today use such SANs inside computer platforms to connect
processors to IO devices, processors to memory, and processors to
processors. Most existing SANs are proprietary, and don't interoperate
with each other, not unsimilar to the early stages of LAN development.

In order to be able to interconnect Massively Parallel Processing
systems (MPPs) and to interconnect workstations into MPP-like clusters
there is a need to unify the SANs and to provide means for
interoperability among them.

MsgWay is designed to provide a uniform interface for a wide variety of
SANs, such that the higher levels (such as IP) would be able to use
SANs in a uniform manner. An IP driver for MsgWay would be able to use
MsgWay between heterogeneous processors as if they were all on a single
SAN.

MsgWay would be designed to provide interoperability among closely
located heterogeneous processors at high speed. Msgway will sacrifice
scalability and some generality for high performance. Hence, MsgWay
will supplement IP for high performance and for fine granularity of
processors.

802.1, the link level control protocol is above LANs, such as the
various Ethernets, FDDI, and Token Ring, at Level-2, and below IP, at
Level-3.

Similarly, MsgWay will be above the various SANs (such as RACEway and
Paragon) and below IP.

MsgWay will define separately:

   * End-to-End protocol (and packet format)
   * Router-to-Router protocol (and packet format)
   * Resource discovery and allocation

The members of the MsgWay-WG will design, specify, document, propose,
implement, and evaluate the above three protocols that define the
MsgWay operation.

The members of the WG will also produce reference software for MsgWay.

Based on initial reactions it is expected that the WG will include
members from academia, government, and industry, covering the software,
hardware, and communication aspects of MsgWay.


INTELLECTUAL PROPERTY

All the work that has been performed until now on MsgWay is in the
public domain. The MsgWay WG will only handle public domain
information. All the members of the MsgWay-WG will be notified that the
WG cannot guard any trade secrets, nor limit the distribution of any
proprietary information presented to it.

 Goals and Milestones:

   Jul 95 Submit initial draft specification for the MsgWay-EEP (End-to-End
	  Protocol) as an Internet-Draft.

   Oct 95 Conduct interoperability demo of the MsgWay-EEP (between 2 or 3
	  heterogeneous systems).

   Dec 95 Meet at 34th IETF to prepare final specification for the MsgWay-EEP
	  (End-to-End Protocol).

   Dec 95 Submit initial draft specification for the MsgWay-RRP
	  (Router-to-Router Protocol) as an Internet-Draft.

   Feb 96 Conduct Interoperability demo of the MsgWay-RRP between 2 or 3
	  heterogeneous systems.

   Mar 96 Submit final specification of the MsgWay-RRP (Router-to-Router
	  Protocol) as an Internet-Draft.

   Mar 96 Submit initial draft specification of the MsgWay-REDAP (Resource
	  Discovery and Allocation Protocol) as an Internet-Draft.

   May 96 Conduct interoperabililty demo of the MsgWay-REDAP between 2 or 3
	  heterogeneous systems.

   Jun 96 Submit final specification of the MsgWay-REDAP as an Internet-Draft.