[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
Most comments which had been received against the previous IDUP draft
related to the parameter bundle construct. Meeting attendees
requested that "sign-and-encrypt" and "encrypt-and-sign" operations
(in both orders), be provided via IDUP_SE; Carlisle had planned that
this level of flexibility would be provided in the general, non-SE
interface, though it has not yet been incorporated there. It was
observed in discussion that the currently proposed nesting of
signature and encryption is incompatible with current PGP (though this
should change with PGP 3 packet formats) or with MOSS. Carlisle
accepted an action to add more options for protection modes. A strong
request was made that compatibility with S/MIME, PEM, MOSS, and PGP
should be possible.
FTP SECURITY AND KEY DERIVATION I-Ds
Marc Horowitz presented status on the recently updated FTP security
Internet-Draft; all but one of its changes relative to its predecessor
are clarifications which do not impact functional behavior. While
relatively few attendees had read the most recent version, a large
number were familiar with earlier versions. Our working position is
that, following the IETF meeting, the current version is to be placed
into WG Last-Call for advancement to Proposed Standard. Marc also
summarized the status of the recently-released key derivation
Internet-Drafts; some changes will be made based on comments received
from cryptographers, and additional comments (e.g., requests for test
vectors and improved clarifying text) were made. It was also noted
that key derivation would be reflected for Kerberos purposes in the
RFC-1510 update, in order to support triple-DES.
OTHER CAT-WG I-Ds
Work on the IDUP C bindings document is currently idle. The Windows
GSS bindings document is currently in Ted Ts'o's hands, pending
revision work.
SIMPLE AUTHENTICATION AND SESSION LAYER (SASL)
John Myers (CMU) presented brief comments on the latest SASL draft,
which includes description of an IANA registration facility; use of an
"X-" naming scheme had been suggested, but John argued rationale for
use of IANA registration instead. A SASL mailing list has been
established at ietf-sasl at imc.org; with requests to
ietf-sasl-request at imc.org; it was reported that some level of
discussion had taken place on that list. A Last-Call on SASL, which is
not a formal work item of an IETF WG, will be attempted on that list.
No GSS-API SASL implementation exists currently, but John stated that
he expects this status to change soon.
IDENT EXTENSIONS
A brief discussion was led by Bob Morgan (Stanford) re ident
extensions (draft-morgan-ident-ext-02.txt), an approach layered on
SASL and enabling an application server to call back to a client
system to request that strong authentication corresponding to an
inbound connection be delivered to the server across a path separate
from the connection itself.
--jl
Received: from ietf.org by ietf.org id aa16097; 17 Dec 96 15:03 EST
Received: from ietf.ietf.org by ietf.org id aa15654; 17 Dec 96 14:56 EST
To: ietf at ietf.org
Subject: Two new secure Internet mail BOFs
Sender:ietf-request at ietf.org
From: "Paul E. Hoffman" <phoffman at imc.org>
Date: Tue, 17 Dec 1996 14:56:08 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9612171456.aa15654 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
Greetings. At the IETF meeting in San Jose last week, two BOFs that relate
to Internet mail security had their first meetings. There was a significant
overlap in the attendance of the two BOFs. The two BOFs are discussing
different Internet mail security protocols (S/MIME and PGP/MIME), but many
developers are clearly interested in both protocols. The Internet Mail
Consortium (IMC) volunteered to sponsor mailing lists for each BOF. Both
BOFs will both hopefully become full IETF Working Groups.
People interested in developing the S/MIME protocol within the IETF will be
interested in "ietf-smime at imc.org". To subscribe, send email to:
ietf-smime-request at imc.org
with the single word
subscribe
in the body of the message.
People interested in developing the PGP/MIME protocol within the IETF will
be interested in "ietf-pgp-mime at imc.org". To subscribe, send email to:
ietf-pgp-mime-request at imc.org
with the single word
subscribe
in the body of the message.
The archives and related documents for each BOF are available through the
Web at <http://www.imc.org/ietf-smime/> and
<http://www.imc.org/ietf-pgp-mime/>, respectively.
--Paul E. Hoffman, Director
--Internet Mail Consortium
Received: from ietf.org by ietf.org id aa16100; 17 Dec 96 15:03 EST
Received: from ietf.ietf.org by ietf.org id aa15810; 17 Dec 96 14:57 EST
To: ietf at ietf.org
Subject: Re: Re[2]: Article re San Jose IETF in Sunday San Francisco pape
Sender:ietf-request at ietf.org
From: marshall eubanks <tme at casa.usno.navy.mil>
Date: Tue, 17 Dec 1996 14:57:24 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9612171457.aa15810 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
Maybe URN's should include a check-sum or the like to make sure that
it has been copied/typed correctly, much as crdit cards numbers, etc.,
do. This could even be in the URN label (as in, URN[XX]:yyyy, where
XX is a 2 character ascii code based on the yyyy field). The web
engine could then compare yyyy with XX and complain if they
don't match.
Regards
Marshall Eubanks
tme at casa.usno.navy.mil
Received: from ietf.org by ietf.org id aa20659; 17 Dec 96 17:01 EST
Received: from dsmd.dsmd.state.al.us by ietf.org id aa20551; 17 Dec 96 16:58 EST
Received: from dsmdmail.dsmd.state.al.us by dsmd.dsmd.state.al.us (AIX 3.2/UCB 5.64/4.03)
id AA27959; Tue, 17 Dec 1996 15:44:09 -0600
Received: from [10.2.1.17] by dsmdmail.dsmd.state.al.us (AIX 3.2/UCB 5.64/4.03)
id AA08603; Tue, 17 Dec 1996 15:54:57 -0600
Date: Tue, 17 Dec 96 16:56:55 PST
Sender:ietf-request at ietf.org
From: lspann at dsmd.dsmd.state.al.us
Subject:
To: ietf at ietf.org
X-Mailer: Chameleon ARM_55, TCP/IP for Windows, NetManage Inc.
Message-Id: <Chameleon.961217165714.lspann at lspann.dsmd.dsmd.state.al.us>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
unsubscribe
-------------------------------------
Name: Larry Spann
E-mail: lspann at 10.101.1.8 (Larry Spann)
Date: 12/17/96
Time: 16:56:55
This message was sent by Chameleon
-------------------------------------
Received: from ietf.org by ietf.org id aa07533; 18 Dec 96 1:54 EST
Received: from cnri by ietf.org id aa07318; 18 Dec 96 1:49 EST
Received: from hpsp1.nm.informatik.uni-muenchen.de by CNRI.Reston.VA.US
id aa03318; 18 Dec 96 1:49 EST
Received: from localhost (neumair at localhost) by hpsp1.nm.informatik.uni-muenchen.de (8.7.5/8.6.10) with SMTP id HAA06523; Wed, 18 Dec 1996 07:42:16 +0100 (MEZ)
Date: Wed, 18 Dec 1996 07:42:16 +0100 (MEZ)
Sender:ietf-request at ietf.org
From: Bernhard Neumair <neumair at nm.informatik.uni-muenchen.de>
To: kuvs-elg at fokus.gmd.de, sig-dsm at doc.ic.ac.uk, parva at uni-paderborn.de,
cabernet-events at ncl.ac.uk, comsoc.tac at tab.ieee.org,
end2end-interest at venera.isi.edu, rem-conf-request at es.net,
multicomm at cc.bellcore.com, globecom at signet.com.sg,
cnom at maestro.bellcore.com, enternet at bbn.com, ietf at CNRI.Reston.VA.US,
itc at fokus.gmd.de, tccc at cs.umass.edu, comsoc-tcii at ieee.com,
commsoft at cc.bellcore.com, comswtc at gmu.edu, ifip-nm at bbn.com,
nmf-members at nmf.com, ieee.announce at bellcore.com,
cellular at dfv.rwth-aachen.edu
cc: r.wies at ieee.org
Subject: CALL FOR PAPERS: JOURNAL OF NETWORK AND SYSTEMS MANAGEMENT
Message-ID: <Pine.HPP.3.95.961218073914.6497E-100000 at hpsp1.nm.informatik.uni-muenchen.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
[Apologies if you receive multiple copies of this.]
CALL FOR PAPERS
JOURNAL OF NETWORK AND SYSTEMS MANAGEMENT
Special Issue on
Managing Mobility and Mobile Computing Systems
Guest Editors:
Bernhard Neumair (University of Munich)
Rene Wies (TTI TECTRAN GmbH)
During the recent years Mobile Computing has become a very
important trend in the usage of computing systems. The advantages
of mobility and the increasing availability of adequate hardware
and software have promoted the development and deployment of
wireless LANs. Furthermore, with greater distances being bridged
by corporate networks, and with world-wide network access, mobile
computing systems can be increasingly used almost anywhere and any
time without a restriction on the available services (e.g., mail,
WWW, etc.).
Managing these mobile systems, the related services, data, and
networks as well as managing the mobility aspects of users (e.g.,
location of home directories, applications, etc.), however, are
still unsolved problems. This special issue is intended to
address these issues and to provide hints for future directions.
The focus of this special issue will be on, but is not limited to,
the following topics:
o Applicability of existing management concepts, tools,
platforms, architectures, etc. to mobile computing
o New concepts, tools, and protocols needed for the
management of mobility and mobile computing systems
o Aspects of dynamic management domains and management
policies incorporating mobile computing systems
o Management requirements imposed by new services and
applications, and new techniques supporting mobility
(e.g., replicating file systems, caching strategies)
o Management requirements imposed by new technologies and
standards (Wireless LANs, HIPERLAN, IEEE P802.11, Mobile
IP, etc.)
o Change and configuration management for mobile
systems (dynamic configuration, downloading and
customizing configurations), and integration aspects
o Security and accounting aspects for mobile systems
o Managing and integrating PDAs
Instructions to Authors:
Please submit four copies of your manuscript, not exceeding 20
double-spaced type-written pages, to one of the Guest Editors
(postscript files by e-mail are also welcome). Please prepare
manuscripts according to the Instructions to Contributors which
can be found in any copy of the Journal. An electronic copy of
this can be obtained by visiting JNSM www page at URL
http://www.cstp.umkc.edu/jnsm/.
Please include the authors' names, addresses, telephone and fax
numbers, and e-mail addresses.
Guest Editors:
Dr. Bernhard Neumair
Department of Computer Science
University of Munich
Oettingenstrasse 67, D-80538 Munich, Germany
Phone: +49-89-2178-2171
Fax: +49-89-2178-2262
E-Mail: neumair at informatik.uni-muenchen.de
Dr. Rene Wies
TTI TECTRAN GmbH
P.O. Box 251
D-82026 Gruenwald/Munich, Germany
Phone: +49-89-641-97040
Fax: +49-89-641-4299
E-Mail: r.wies at ieee.org
Schedule:
Manuscript due: February 28, 1997
Notification of Acceptance: July 30, 1997
Revised Manuscript due: September 30, 1997
Publication Date: First Quarter 1998
Received: from ietf.org by ietf.org id aa11404; 18 Dec 96 6:03 EST
Received: from cnri by ietf.org id aa11287; 18 Dec 96 5:58 EST
Received: from h192-127-251-11.NCR.COM by CNRI.Reston.VA.US id aa07308;
18 Dec 96 5:58 EST
Received: from ncrausl1.UUCP (ncrausl1 at localhost)
by ncrhub5.NCR.COM (8.7.6/8.7.3) with UUCP
id FAA23852 for cnri.reston.va.us!ietf; Wed, 18 Dec 1996 05:56:52 -0500 (EST)
Received: by ncrausl1.Australia.NCR.COM; 18 Dec 96 20:59:51 EST
Received: by ind1gate.india.ncr.com with Microsoft Mail
id <32B88C63 at ind1gate.india.ncr.com>; Wed, 18 Dec 96 16:29:23 PST
Sender:ietf-request at ietf.org
From: "Sanjeev Shanmugam @1119" <San at msm1ban.india.ncr.com>
To: 'ietf' <ietf at CNRI.Reston.VA.US>
Subject: Request for REGISTRATION
Date: Wed, 18 Dec 96 19:04:00 PST
Message-ID: <32B88C63 at ind1gate.india.ncr.com>
Return-Receipt-To: <San at msm1ban.india.ncr.com>
Encoding: 12 TEXT
X-Mailer: Microsoft Mail V3.0
Source-Info: From (or Sender) name not authenticated.
Dear Sir,
Could you please put me on your mailing list since I would like to subscribe
for papers published by IETF.
Thanking You,
Sanjeev
Received: from ietf.org by ietf.org id aa16439; 18 Dec 96 9:26 EST
Received: from vikram.doe.ernet.in by ietf.org id aa16107; 18 Dec 96 9:19 EST
Received: from recjai.UUCP by doe.ernet.in (4.1/SMI-4.1-MHS-7.0)
id AA01184; Wed, 18 Dec 96 19:51:18+050
Date: 18 Dec 96 13:02:30 IST (+0530)
Sender:ietf-request at ietf.org
From: M S Gaur <gaur at recjai.ernet.in>
To: ietf at ietf.org
Subject:
Message-Id: <A.850914220 at recjai.ernet.in>
X-Mail-Ref: 82
X-Mailer: XMAIL 3.0
Generate-Delivery-Report:
Request-Delivery-Notification: true
Source-Info: From (or Sender) name not authenticated.
unsubscribe gaur at recjai.ernet.in
Received: from ietf.org by ietf.org id aa18519; 18 Dec 96 9:53 EST
Received: from ietf.ietf.org by ietf.org id aa17074; 18 Dec 96 9:39 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-newman-url-imap-04.txt
Date: Wed, 18 Dec 1996 09:39:18 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9612180939.aa17074 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IMAP URL Scheme
Author(s) : C. Newman
Filename : draft-newman-url-imap-04.txt
Pages : 9
Date : 12/17/1996
IMAP [IMAP4] is a rich protocol for accessing remote message stores. It
provides an ideal mechanism for accessing public mailing list archives as
well as private and shared message stores. This document defines a URL
scheme for referencing objects on an IMAP server.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-newman-url-imap-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-newman-url-imap-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-newman-url-imap-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961217102434.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-newman-url-imap-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-newman-url-imap-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961217102434.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18507; 18 Dec 96 9:53 EST
Received: from ietf.ietf.org by ietf.org id aa17149; 18 Dec 96 9:39 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pppext-l2f-03.txt
Date: Wed, 18 Dec 1996 09:39:51 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9612180939.aa17149 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : Layer Two Forwarding (Protocol) "L2F"
Author(s) : A. Valencia, M. Littlewood, T. Kolar
Filename : draft-ietf-pppext-l2f-03.txt
Pages : 28
Date : 12/17/1996
Virtual dial-up allows many separate and autonomous protocol domains to
share common access infrastructure including modems, Access Servers, and
ISDN routers. Previous RFCs have specified protocols for supporting IP
dial-up via SLIP [1] and multiprotocol dial-up via PPP [2]. This document
describes the Layer Two Forwarding protocol (L2F) which permits the
tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of
higher level protocols. Using such tunnels, it is possible to divorce the
location of the initial dial-up server from the location at which the
dial-up protocol connection is terminated and access to the network
provided.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pppext-l2f-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2f-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-l2f-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961217164415.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-l2f-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-l2f-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961217164415.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18491; 18 Dec 96 9:53 EST
Received: from ietf.ietf.org by ietf.org id aa17117; 18 Dec 96 9:39 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rampal-flow-delay-service-00.txt
Date: Wed, 18 Dec 1996 09:39:35 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9612180939.aa17117 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Flow Grouping For Reducing Reservation Requirements for
Guaranteed Delay Service
Author(s) : S. Rampal
Filename : draft-rampal-flow-delay-service-00.txt
Pages : 11
Date : 12/17/1996
The guaranteed service class of the Integrated Services model is based on
the Weighted Fair Queueing model and requires rate reservation in order to
provide end-to-end delay guarantees. Often, the amount of reservation
needed to satisfy specified delay bounds can be quite high leading to low
network utilization. This draft demonstrates a property of the Weighted
Fair Queueing formulation which enables grouping of flows (which use the
guaranteed service and are routed over the same path) in such a way that a
lower reservation is needed than would be required if each flow were
treated individually, and the delay bounds of each flow can still be
provably satisfied.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rampal-flow-delay-service-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rampal-flow-delay-service-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rampal-flow-delay-service-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961217144712.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rampal-flow-delay-service-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rampal-flow-delay-service-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961217144712.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18515; 18 Dec 96 9:53 EST
Received: from ietf.ietf.org by ietf.org id aa17133; 18 Dec 96 9:39 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: confctrl at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mmusic-sip-01.txt, .ps
Date: Wed, 18 Dec 1996 09:39:45 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9612180939.aa17133 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Multiparty Multimedia
Session Control Working Group of the IETF.
Title : SIP: Session Initiation Protocol
Author(s) : M. Handley, H. Schulzrinne, E. Schooler
Filename : draft-ietf-mmusic-sip-01.txt, .ps
Pages : 30
Date : 12/17/1996
Many styles of multimedia conferencing are likely to co-exist on the
Internet, and many of them share the need to invite users to participate.
The Session Initiation Protocol (SIP) is a simple protocol designed to
enable the invitation of users to participate in such multimedia sessions.
It is not tied to any specific conference control scheme, providing
support for either loosely or tightly controlled sessions. In particular,
it aims to enable user mobility by relaying and redirecting invitations to
a user's current location.
This document is a product of the Multiparty Multimedia Session Control
(MMUSIC) working group of the Internet Engineering Task Force.
Comments are solicited and should be addressed to the working group's
mailing list at confctrl at isi.edu and/or the authors.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mmusic-sip-01.txt".
Or
"get draft-ietf-mmusic-sip-01.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-sip-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mmusic-sip-01.txt".
Or
"FILE /internet-drafts/draft-ietf-mmusic-sip-01.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961217163845.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-sip-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mmusic-sip-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961217163845.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18517; 18 Dec 96 9:53 EST
Received: from ietf.ietf.org by ietf.org id aa17057; 18 Dec 96 9:39 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ishiyama-gateway-traversal-00.txt
Date: Wed, 18 Dec 1996 09:39:15 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9612180939.aa17057 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Gateway Traversal for Mobile IP using IPSEC primitives
Author(s) : M. Ishiyama, A. Inoue, A. Shimbo, T. Okamoto
Filename : draft-ishiyama-gateway-traversal-00.txt
Pages : 25
Date : 12/17/1996
This memo describes an approach of security support for Mobile IP protocol.
IPSEC and Mobile IP modules are combined and implemented on gateways of all
networks and mobile nodes. Each component performs IPSEC packet
encryption/authentication, and Mobile IP processing. Using Next-hop
negotiation between security gateways, the packet from a mobile node in the
visiting network can be delivered to the home network through the security
gateways in an authenticated way. This mechanism allows minimal overhead
for traversing security gateways, and minimal information to be held on
each mobile node.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ishiyama-gateway-traversal-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ishiyama-gateway-traversal-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ishiyama-gateway-traversal-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961217095439.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ishiyama-gateway-traversal-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ishiyama-gateway-traversal-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961217095439.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18526; 18 Dec 96 9:53 EST
Received: from ietf.ietf.org by ietf.org id aa17165; 18 Dec 96 9:39 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: issll at mercury.lcs.mit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-issll-802-00.txt
Date: Wed, 18 Dec 1996 09:39:56 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9612180939.aa17165 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Services over
Specific Link Layers Working Group of the IETF.
Title : Integrated Services over IEEE 802.1D/802.1p Networks
Author(s) : M. Seaman, A. Smith, E. Crawley
Filename : draft-ietf-issll-802-00.txt
Pages : 19
Date : 12/17/1996
This document describes the support of IETF Integrated Services over LANs
built from IEEE 802 network segments which are interconnected by standard
IEEE 8021.D [1] switches.
It describes the practical capabilities and limitations of this technology
for supporting Controlled Load [8] and Guaranteed Service [9] using the
inherent capabilities the relevant 802 technologies [5],[6] etc. and the
proposed 802.1p queuing features in switches. It provides a functional
model for the layer 3 to layer 2 and user-to-network dialogue which
supports admission control and defines requirements for interoperability
between switches.
This scheme is consistent with the ISSLL over LANs framework discussed at
the October 1996 ISSLL interim meeting and described in [7].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-issll-802-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-issll-802-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-issll-802-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961217172946.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-issll-802-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-issll-802-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961217172946.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18509; 18 Dec 96 9:53 EST
Received: from ietf.ietf.org by ietf.org id aa17041; 18 Dec 96 9:39 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
cc: drums at cs.utk.edu
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-myers-mail-largesite-00.txt
Date: Wed, 18 Dec 1996 09:39:11 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9612180939.aa17041 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : DNS MX Record Deployment for Large Mail Sites
Author(s) : J. Myers
Filename : draft-myers-mail-largesite-00.txt
Pages : 6
Date : 12/17/1996
Domains which recieve a large number of incoming mail messages have a need
to distribute incoming requests over a large number of SMTP servers. The
most obvious method for advertising DNS records these SMTP servers leads to
undesirable behavior when certain network failures occur. For example,
on XXXX, 1996 [XXXREF] a single routing failure at a large site led to the
catastrophic failure of a large portion of mail systems on the Internet.
This document gives recommendations for how large sites should advertise
DNS records for their SMTP servers to avoid these problems and for how SMTP
client implementations should insulate themselves against large sites which
do not follow these recommendations.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-myers-mail-largesite-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-myers-mail-largesite-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-myers-mail-largesite-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961217094740.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-myers-mail-largesite-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-mail-largesite-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961217094740.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa21678; 18 Dec 96 11:01 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa14857;
18 Dec 96 11:01 EST
Received: (from daemon at localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12725 for uri-out; Wed, 18 Dec 1996 10:13:31 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12704; Wed, 18 Dec 1996 10:12:44 -0500
Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA01880 (mail destined for uri at services.bunyip.com); Wed, 18 Dec 96 10:12:42 -0500
Received: by privateer.windrose.omaha.ne.us; Wed Dec 18 09:11 CST 1996
Message-Id: <32B80993.5785 at ds.internic.net>
Date: Wed, 18 Dec 1996 09:11:15 -0600
From: Ryan Moats <jayhawk at ds.internic.net>
Organization: InterNIC Directory and Database Services
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c)
Mime-Version: 1.0
To: uri at bunyip.com
Cc: urn-ietf at bunyip.com
Subject: Potential inconsistency between URL and URN syntaxes...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-uri at bunyip.com
Precedence: bulk
Folks-
I was reminded this morning that there is a potential inconsistency
between the URL and URN syntax specifications
(draft-fielding-url-syntax-02.txt and draft-ietf-urn-syntax-01.txt).
Because of this, I am cross-posting this to both lists, so I apologize
to those folks that will see this multiple times (I know I will...)
The inconsistency arises from the following:
In the URL syntax draft the following statement is made:
> 1.1. URL, URN, and URI
>
> URLs are a subset of Uniform Resource Identifiers (URI), which also
> includes the notion of Uniform Resource Names (URN). A URN differs
> from a URL in that it identifies a resource in a location-independent
> fashion (see RFC 1737, [10]). URNs are defined by a separate set of
> specifications.
>
> Although this specification restricts its discussion to URLs, the
> syntax defined is that of URI in general. Any requirements placed on
> the URL syntax also apply to the URI syntax. This uniform syntax for
> all resource identifiers allows a URN to be used in any data field
> that might otherwise hold a URL.
However, in the latest draft URN syntax spec (circulating on the urn
mailing list), the syntax for a URN is
> "urn:" <NID> ":" <NSS>
I don't beleive that the URN specification "can be used in any data
field that might otherwise hold a URL" as it currently stands (If
somebody thinks otherwise, please let me know). Therefore, either the
syntax specs need to be aligned or the statements about the URL
specification refering to the URI syntax need to be modulated
(neither of which are pleasant topics...). My current preference
is to modulate the URL syntax specification to support the URN syntax
and move forward.
Ryan Moats
InterNIC Directory and Database Services
Received: from ietf.org by ietf.org id aa22211; 18 Dec 96 11:05 EST
Received: from cnri by ietf.org id aa21686; 18 Dec 96 11:01 EST
Received: from Turing.Stanford.EDU by CNRI.Reston.VA.US id aa14874;
18 Dec 96 11:01 EST
Received: from localhost (ole at localhost) by Turing.Stanford.EDU (8.8.4/8.8.3) with SMTP id HAA13373; Wed, 18 Dec 1996 07:58:13 -0800 (PST)
X-Authentication-Warning: Turing.Stanford.EDU: ole owned process doing -bs
Date: Wed, 18 Dec 1996 07:58:13 -0800 (PST)
Sender:ietf-request at ietf.org
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
X-Sender: ole at Turing.Stanford.EDU
To: Ole at csli.stanford.edu
Subject: ConneXions in transition
Message-ID: <Pine.GSO.3.95.961218075344.12828C-100000 at Turing.Stanford.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: QUOTED-PRINTABLE
Source-Info: From (or Sender) name not authenticated.
Dear colleagues,
This announcement is a little off the topic for the IETF list, but so
many of you have contributed to ConneXions over the years that I
thought this would be an easy way to reach you all.
After nearly 10 years, 117 issues and more than 3,600 printed pages,=20
ConneXions---The Interoperability Report will retire as a print publication=
=20
at the end of 1996. A new Web-based publication, ConneXions Online, will=20
emerge in early 1997. We will continue to publish in-depth technical=20
tutorials on all aspects of networking in this new medium. In addition, we=
=20
plan to make our entire collection of back issues available on the Web,=20
thus creating a large digital library of networking reference material.=20
Access to ConneXions Online and its collection of reference material will=
=20
be free of charge.
=20
Needless to say, the creation of this digital library and the=20
implementation of a suitable search front-end will not happen overnight,=20
but will evolve over a period of time. Key players in this project will be=
=20
our online development group WebSource assisted by myself as the editor,=20
and we hope a number of volunteers interested in such a project. The=20
collection will have links to other sources of information such as the=20
Request For Comments (RFC) document series, online glossaries and so on.=20
Special advisor on this project is Jack Kessler, kessler at well.sf.ca.us,=20
Internet Trainer and Consultant, who is an expert on digital libraries.
I would like to take this opportunity to thank all the people who have=20
contributed to ConneXions since it started publication in March 1987.=20
Several hundred authors have shared their expertise with our readers. Their=
=20
work is what makes ConneXions possible. Special thanks goes to the=20
Editorial Advisory Board as well as the crew at Globe Printing Company.=20
Countless readers have provided valuable feedback and suggestions. Last,=20
but not least, the folks at Seybold Publications, our subscription agency,=
=20
deserve a round of applause for all their customer service functions.
=20
I hope you will continue to support ConneXions Online and help us make it a=
=20
21st century publication. Comments, suggestions, and above all articles are=
=20
welcome as always. HTML is not the only acceptable format, but it would=20
obviously help ;=D0). Send your letters and articles to connexions at interop.=
com.
Happy holidays!
Ole
Ole J Jacobsen, Editor & Publisher, ConneXions--The Interoperability Report=
,
Interop Company, a division of SOFTBANK Expos, 303 Vintage Park Drive,
Foster City, CA 94404-1138, USA. Ph: +1 (415) 578-6988 Fax: +1 (415) 525-01=
94.
=20
Received: from cnri by ietf.org id aa23902; 18 Dec 96 11:34 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa17129;
18 Dec 96 11:34 EST
Received: (from daemon at localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA13428 for uri-out; Wed, 18 Dec 1996 11:05:06 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA13402; Wed, 18 Dec 1996 11:04:47 -0500
Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA02444 (mail destined for uri at services.bunyip.com); Wed, 18 Dec 96 11:04:41 -0500
Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.2/8.8.2) with ESMTP id KAA01432; Wed, 18 Dec 1996 10:03:59 -0600 (CST)
From: Daniel LaLiberte <liberte at ncsa.uiuc.edu>
Received: (from liberte at localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id JAA04091; Wed, 18 Dec 1996 09:59:50 -0600 (CST)
Date: Wed, 18 Dec 1996 09:59:50 -0600 (CST)
Message-Id: <199612181559.JAA04091 at void.ncsa.uiuc.edu>
To: Ryan Moats <jayhawk at ds.internic.net>
Cc: uri at bunyip.com, urn-ietf at bunyip.com
Subject: [URN] Potential inconsistency between URL and URN syntaxes...
In-Reply-To: <32B80993.5785 at ds.internic.net>
References: <32B80993.5785 at ds.internic.net>
Sender: owner-uri at bunyip.com
Precedence: bulk
Ryan Moats writes:
> However, in the latest draft URN syntax spec (circulating on the urn
> mailing list), the syntax for a URN is
>
> > "urn:" <NID> ":" <NSS>
>
> I don't beleive that the URN specification "can be used in any data
> field that might otherwise hold a URL" as it currently stands (If
> somebody thinks otherwise, please let me know).
I think otherwise. I don't see anything wrong with this syntax -
consider that the scheme name for this whole class of URNs is called
"urn", and thus "urn:" preceeds the rest of the identifier.
You were not specific about what the nature of the conflict is.
If "urn:" were optional (which is a subject still open for debate, I
presume), we may have a conflict. The general URI syntax allows the
"<scheme name>:" prefix to be optional, and more of the prefix can be
left out, but then we might have a relative URI, which has different
semantics. With no "urn:", the <NID> would actually function as the
scheme name since it indicates how to interpret the <NSS>. But this
is true even with a required "urn:" prefix since we want URNs to be
independent of the resolution mechanism.
I'm not clear whether you believe URNs *should* be used in any data
field that might otherwise hold a URL, independent of whether they
in fact can. I believe they should.
--
Daniel LaLiberte (liberte at ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/
Received: from ietf.org by ietf.org id aa27228; 18 Dec 96 12:12 EST
Received: from cnri by ietf.org id aa27046; 18 Dec 96 12:07 EST
Received: from ester.dsv.su.se by CNRI.Reston.VA.US id aa18104;
18 Dec 96 12:07 EST
Received: from localhost (jpalme at localhost)
by ester.dsv.su.se (8.7.1/8.7.1) with SMTP
id SAA01502;
Wed, 18 Dec 1996 18:05:52 +0100 (MET)
Date: Wed, 18 Dec 1996 18:05:51 +0100 (MET)
Sender:ietf-request at ietf.org
From: Jacob Palme <jpalme at dsv.su.se>
To: ietf at CNRI.Reston.VA.US
Subject: Notes from the applications area at the IETF meeting, December 1996
Message-ID: <Pine.SUN.3.95.961218180227.1461B-100000 at ester.dsv.su.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
My personal notes from the applications area at the IETF meeting
in San Jose, December 1996, can be found at URL
http://www.dsv.su.se/~jpalme/ietf/san-jose-96-notes.html
------------------------------------------------------------------------
Jacob Palme <jpalme at dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme
Received: from cnri by ietf.org id aa03819; 18 Dec 96 14:01 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa20818;
18 Dec 96 14:01 EST
Received: (from daemon at localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA15015 for uri-out; Wed, 18 Dec 1996 13:22:24 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA15010; Wed, 18 Dec 1996 13:22:21 -0500
Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA03878 (mail destined for urn-ietf at services.bunyip.com); Wed, 18 Dec 96 13:22:06 -0500
Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP)
id <02348-0 at josef.ifi.unizh.ch>; Wed, 18 Dec 1996 19:21:07 +0100
Date: Wed, 18 Dec 1996 19:21:06 +0100 (MET)
From: "Martin J. Duerst" <mduerst at ifi.unizh.ch>
To: Ryan Moats <jayhawk at ds.internic.net>
Cc: uri at bunyip.com, urn-ietf at bunyip.com
Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes...
In-Reply-To: <32B80993.5785 at ds.internic.net>
Message-Id: <Pine.SUN.3.95.961218190227.245T-100000 at enoshima>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-uri at bunyip.com
Precedence: bulk
On Wed, 18 Dec 1996, Ryan Moats wrote:
> Folks-
>
> I was reminded this morning that there is a potential inconsistency
> between the URL and URN syntax specifications
> (draft-fielding-url-syntax-02.txt and draft-ietf-urn-syntax-01.txt).
> Because of this, I am cross-posting this to both lists, so I apologize
> to those folks that will see this multiple times (I know I will...)
I have noticed this inconsistency, too, and am glad Ryan brought it up.
> The inconsistency arises from the following:
>
> In the URL syntax draft the following statement is made:
>
> > 1.1. URL, URN, and URI
> >
> > URLs are a subset of Uniform Resource Identifiers (URI), which also
> > includes the notion of Uniform Resource Names (URN). A URN differs
> > from a URL in that it identifies a resource in a location-independent
> > fashion (see RFC 1737, [10]). URNs are defined by a separate set of
> > specifications.
> >
> > Although this specification restricts its discussion to URLs, the
> > syntax defined is that of URI in general. Any requirements placed on
> > the URL syntax also apply to the URI syntax. This uniform syntax for
> > all resource identifiers allows a URN to be used in any data field
> > that might otherwise hold a URL.
>
> However, in the latest draft URN syntax spec (circulating on the urn
> mailing list), the syntax for a URN is
>
> > "urn:" <NID> ":" <NSS>
>
> I don't beleive that the URN specification "can be used in any data
> field that might otherwise hold a URL" as it currently stands (If
> somebody thinks otherwise, please let me know). Therefore, either the
> syntax specs need to be aligned or the statements about the URL
> specification refering to the URI syntax need to be modulated
> (neither of which are pleasant topics...). My current preference
> is to modulate the URL syntax specification to support the URN syntax
> and move forward.
I think there is very much to be gained from URLs and URNs being
syntactically alligned. Currenty, it looks to me as if this is
the case; the "urn" part is a <scheme>, and everything after
that is scheme-specific. The greedy algorithm (Section 4.4)
and the exclusion of ":" in schemes assures that this parsing
will be done correctly.
The treatment of reserved characters could cause some problems,
however. To allow substitution of "%7E" by "~" (URL, 2.2/2.3.2)
while that character is not available on many keyboards is
problematic. Therefore, that aspect has to be reconsidered
anyway.
The URL draft also does not agree with the URN draft on i18n
issues. I18N in URLs is a large topic, and I hope to get the
time tomorrow to comment on its treatment in the URL draft.
In the context of this thread, it is at least required that
consequences in these differences are analysed/understood,
and that there is language in the URL draft (given it is kept
to be responsible for URIs in general) that the syntax
alignement does not include these issues. This most probably
should be done with a general statement explaining what
exactly is covered, and what not, by "uniform syntax".
Regards, Martin.
Received: from ietf.org by ietf.org id aa08311; 18 Dec 96 15:47 EST
Received: from cnri by ietf.org id aa08094; 18 Dec 96 15:41 EST
Received: from bootstrap.agcs.com by CNRI.Reston.VA.US id aa23594;
18 Dec 96 15:41 EST
Received: from pxmhost by bootstrap.agcs.com; (5.65/1.1.8.2/27Apr95-0124PM)
id AA32113; Wed, 18 Dec 1996 13:36:42 -0700
Received: from PC (narulap.agcs.com) by pxmhost (5.x/SMI-SVR4)
id AA04429; Wed, 18 Dec 1996 13:36:03 -0700
Date: Wed, 18 Dec 1996 13:36:03 -0700
Sender:ietf-request at ietf.org
From: narulap at agcs.com
Message-Id: <961218133549.ZM9166 at PC>
In-Reply-To: Bernhard Neumair <neumair at nm.informatik.uni-muenchen.de>
"CALL FOR PAPERS: JOURNAL OF NETWORK AND SYSTEMS MANAGEMENT" (Dec 18, 7:42am)
References: <Pine.HPP.3.95.961218073914.6497E-100000 at hpsp1.nm.informatik.uni-muenchen.de>
X-Mailer: Z-Mail 4.0.1 (4.0.1 Aug 19 1996)
To: Bernhard Neumair <neumair at nm.informatik.uni-muenchen.de>,
kuvs-elg at fokus.gmd.de, sig-dsm at doc.ic.ac.uk, parva at uni-paderborn.de,
cabernet-events at ncl.ac.uk, comsoc.tac at tab.ieee.org,
end2end-interest at venera.isi.edu, rem-conf-request at es.net,
multicomm at cc.bellcore.com, globecom at signet.com.sg,
cnom at maestro.bellcore.com, enternet at bbn.com, ietf at CNRI.Reston.VA.US,
itc at fokus.gmd.de, tccc at cs.umass.edu, comsoc-tcii at ieee.com,
commsoft at cc.bellcore.com, comswtc at gmu.edu, ifip-nm at bbn.com,
nmf-members at nmf.com, ieee.announce at bellcore.com,
cellular at dfv.rwth-aachen.edu
Subject: Re: CALL FOR PAPERS: JOURNAL OF NETWORK AND SYSTEMS MANAGEMENT
Cc: r.wies at ieee.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
Please ignore. This is a test.
Received: from cnri by ietf.org id aa13098; 18 Dec 96 18:42 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa27877;
18 Dec 96 18:42 EST
Received: (from daemon at localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA18316 for uri-out; Wed, 18 Dec 1996 18:24:28 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA18298; Wed, 18 Dec 1996 18:24:20 -0500
Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA06453 (mail destined for uri at services.bunyip.com); Wed, 18 Dec 96 18:24:19 -0500
Received: (leslie at localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id SAA04077; Wed, 18 Dec 1996 18:24:18 -0500
Message-Id: <199612182324.SAA04077 at beethoven.bunyip.com>
From: Leslie Daigle <leslie at bunyip.com>
Date: Wed, 18 Dec 1996 18:24:18 -0500
In-Reply-To: Ryan Moats's message as of Dec 18, 9:11
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Ryan Moats <jayhawk at ds.internic.net>, uri at bunyip.com
Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes...
Cc: urn-ietf at bunyip.com
Sender: owner-uri at bunyip.com
Precedence: bulk
It looks like the following questions are on the table:
. should URN and URL syntaxes be consistent?
. if yes, which should now change:
. URLs cannot, because of legacy support, although
there is the issue of "I18N"
. URNs "can", except that the existing syntax was
built for specific reasons to address issues that
have concerned URNs more than URLs (e.g., bringing
in other namespaces and addressing multiple language
issues).
Is it "desirable" that URN syntax be compliant with URL syntax, or "required"?
What _breaks_ if it is not?
[Ryan quotes from the URL draft:]
> >
> > Although this specification restricts its discussion to URLs, the
> > syntax defined is that of URI in general. Any requirements placed on
> > the URL syntax also apply to the URI syntax. This uniform syntax for
> > all resource identifiers allows a URN to be used in any data field
> > that might otherwise hold a URL.
This draft is for the _URL_ syntax, and this is the only paragraph that
lays claim to all of URI syntaxes. It was written before there was a concrete
proposal for URNs. I think the URL syntax RFC would be quite complete
_without_ this paragraph.
The URL syntax is going to face its own battles as the issues of
character sets and languages are brought up -- it seems like now is a logical
time to separate out the evolution of these two things, _unless_ there
are some very concrete things that will break if they are not kept
consistent.
Cheers!
Leslie.
--
----------------------------------------------------------------------------
"_Be_ Leslie Daigle
where you Vice President, Research
_are_." Bunyip Information Systems
(514) 875-8611
-- ThinkingCat leslie at bunyip.com
----------------------------------------------------------------------------
Received: from cnri by ietf.org id aa13303; 18 Dec 96 18:54 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa28140;
18 Dec 96 18:54 EST
Received: by pad-thai.cam.ov.com (8.8.4/)
id <VAA22109 at pad-thai.cam.ov.com>; Wed, 18 Dec 1996 21:20:08 GMT
Message-Id: <199612182119.QAA14480 at gza-client1.cam.ov.com>
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: promotion of INITIATE and ACCEPT to BOTH ?
In-Reply-To: Your message of "Fri, 13 Dec 1996 11:16:35 PST."
<32B1AB93.37C1 at sap-ag.de>
Date: Wed, 18 Dec 1996 16:19:27 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Re:
>I'm currently wondering if a V2 mechanism is supposed to
>constrain a credential to the user requested usage or if
>it is allowed to promote the credential to GSS_C_BOTH.
I believe that a call to gss_acquire_cred() shouldn't promote
either GSS_C_ACCEPT or GSS_C_INITIATE to GSS_C_BOTH, but should
instead return credentials with no broader usability than that
requested.
--jl
Received: from ietf.org by ietf.org id aa01999; 19 Dec 96 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa00603; 19 Dec 96 9:32 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-myers-auth-sasl-07.txt
Date: Thu, 19 Dec 1996 09:32:44 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9612190932.aa00603 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Simple Authentication and Security Layer (SASL)
Author(s) : J. Myers
Filename : draft-myers-auth-sasl-07.txt
Pages : 14
Date : 12/18/1996
This document describes a method for adding authentication support to
connection-based protocols. To use this specification, a protocol includes
a command for identifying and authenticating a user to a server and for
optionally negotiating protection of subsequent protocol interactions. If
its use is negotiated, a security layer is inserted between the protocol
and the connection. This document describes how a protocol specifies such
a command, defines several echanisms for use by the command, and defines
the protocol used for carrying a negotiated security layer over the
connection.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-myers-auth-sasl-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-myers-auth-sasl-07.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-myers-auth-sasl-07.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961218164245.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-myers-auth-sasl-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-auth-sasl-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961218164245.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa03339; 19 Dec 96 10:32 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa11658;
19 Dec 96 10:32 EST
Received: (from daemon at localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA26248 for uri-out; Thu, 19 Dec 1996 09:56:36 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA26243; Thu, 19 Dec 1996 09:56:34 -0500
Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA09870 (mail destined for urn-ietf at services.bunyip.com); Thu, 19 Dec 96 09:55:13 -0500
Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP)
id <11442-0 at josef.ifi.unizh.ch>; Thu, 19 Dec 1996 15:26:52 +0100
Date: Thu, 19 Dec 1996 15:26:51 +0100 (MET)
From: "Martin J. Duerst" <mduerst at ifi.unizh.ch>
To: Leslie Daigle <leslie at bunyip.com>
Cc: Ryan Moats <jayhawk at ds.internic.net>, uri at bunyip.com,
urn-ietf at bunyip.com
Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes...
In-Reply-To: <199612182324.SAA04077 at beethoven.bunyip.com>
Message-Id: <Pine.SUN.3.95.961219151658.245G-100000 at enoshima>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-uri at bunyip.com
Precedence: bulk
On Wed, 18 Dec 1996, Leslie Daigle wrote:
> It looks like the following questions are on the table:
>
> . should URN and URL syntaxes be consistent?
I guess we have to ask "to what extent should they be consistent".
Definitely, allowing something such as ">" in URNs, while they
are used to delimit URLs, would be a very bad idea. On the other
hand, the fact that the octets represented (with %HH in the canonical
form) in URNs are interpreted as UTF-8 should not at the moment
force URLs to suddenly convert to UTF-8 (quite difficult), but
should not on the other hand scare URLs away from making the
necessary preparations to get better i18n facilities and try
to move in the direction of UTF-8. (more on that later).
> . if yes, which should now change:
>
> . URLs cannot, because of legacy support, although
> there is the issue of "I18N"
>
> . URNs "can", except that the existing syntax was
> built for specific reasons to address issues that
> have concerned URNs more than URLs (e.g., bringing
> in other namespaces and addressing multiple language
> issues).
>
>
> Is it "desirable" that URN syntax be compliant with URL syntax, or "required"?
> What _breaks_ if it is not?
We don't want a HTML parser or something similar to need separate code
for parsing URLs and URNs. It should be able to deal with URNs as one
URL scheme, syntactically. It looks like that is possible, but I have
to admit that I am no regex expert.
> [Ryan quotes from the URL draft:]
> > >
> > > Although this specification restricts its discussion to URLs, the
> > > syntax defined is that of URI in general. Any requirements placed on
> > > the URL syntax also apply to the URI syntax. This uniform syntax for
> > > all resource identifiers allows a URN to be used in any data field
> > > that might otherwise hold a URL.
>
> This draft is for the _URL_ syntax, and this is the only paragraph that
> lays claim to all of URI syntaxes.
But it lays claims for all of the URL document, or at least a large part
of it.
Regards, Martin.
Received: from cnri by ietf.org id aa05864; 19 Dec 96 11:19 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa13010;
19 Dec 96 11:19 EST
Received: (from daemon at localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA27233 for uri-out; Thu, 19 Dec 1996 10:36:55 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA27131; Thu, 19 Dec 1996 10:35:54 -0500
Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA10263 (mail destined for uri at services.bunyip.com); Thu, 19 Dec 96 10:35:48 -0500
Received: by privateer.windrose.omaha.ne.us; Thu Dec 19 09:34 CST 1996
Message-Id: <32B9606C.702E at ds.internic.net>
Date: Thu, 19 Dec 1996 09:34:04 -0600
From: Ryan Moats <jayhawk at ds.internic.net>
Organization: InterNIC Directory and Database Services
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c)
Mime-Version: 1.0
To: "Martin J. Duerst" <mduerst at ifi.unizh.ch>
Cc: Leslie Daigle <leslie at bunyip.com>, uri at bunyip.com, urn-ietf at bunyip.com
Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes...
References: <Pine.SUN.3.95.961219151658.245G-100000 at enoshima>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-uri at bunyip.com
Precedence: bulk
Martin J. Duerst wrote:
>
> We don't want a HTML parser or something similar to need separate code
> for parsing URLs and URNs. It should be able to deal with URNs as one
> URL scheme, syntactically. It looks like that is possible, but I have
> to admit that I am no regex expert.
>
While I am not a regex expert either, there seem to me some obvious
issues here, which I have tried to address with comments on where
changes need to be made:
1. Can a URL parser handle the "urn:<NID>:" leader for URNs properly?
Having looked at the "greedy" algorithm and the Regular Expression
in the URL draft, I can say that the first part is sufficient to
pick up the scheme as "urn:<NID>". If we take the approach in
comment 3 below, then the URL spec should note that (a) schemes
may well have ":" in them or (b) a scheme beginning with "urn:"
is treated as an opaque URL because it is really a URN (ITEM FOR
URL DRAFT).
2. The URN and URL character sets are not currently aligned well.
("Well" means that there are characters allowed for URLs that are
not allowed for URNs). There are currently (by my counting),
two characters allowed in the URN char set that are not allowed in
the URL char set: "\" and "%". I don't have a problem with
moving the "\" to the excluded set for URNs (ITEM FOR URN DRAFT)
"%" is also part of the URN char set only to ensure that the
definition for the end of a URN is clean. It's sole purpose is to
introduce an escape sequence for an octet (a literal "%" must be
encoded as %25). I am strengthening the language in the URN syntax
draft with respect to the "%" issue. (ITEM FOR URN DRAFT)
3. There is no specification of structure for a URN NSS. The only way
to handle this through a URL parser is for the URL parser to declare
the URN as an "opaque-URL" and do no processing on it. This
specification (if done) must be done in the URL document (ITEM
FOR URL DRAFT).
If we do these things, I think we've cleaned up the problem.
I am currently moving the "\" character to the excluded region of
the URN character set.
Ryan
Received: from cnri by ietf.org id aa14519; 19 Dec 96 16:03 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20628;
19 Dec 96 16:03 EST
Received: by pad-thai.cam.ov.com (8.8.4/)
id <TAA05191 at pad-thai.cam.ov.com>; Thu, 19 Dec 1996 19:07:56 GMT
Message-Id: <199612191907.OAA02545 at thunk.orchard.medford.ma.us>
X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs
To: John Linn <linn at cam.ov.com>
Cc: cat-ietf at mit.edu
Subject: Re: DRAFT minutes for San Jose CAT meetings
In-Reply-To: linn's message of Tue, 17 Dec 1996 10:09:28 -0500.
<199612171509.KAA05527 at gza-client1.cam.ov.com>
Date: Thu, 19 Dec 1996 14:07:47 -0500
From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
Precedence: bulk
Our working agreement (impacting both C bindings and high-level
specifications) is as follows: deprecate use of GSS_C_NULL_OID with
gss_import_name() by applications, but require mechanisms to
support it for the present, with its interpretation
locally-defined. State that GSS-V2 mechanism specs shall define the
behavior of the GSS_C_NULL_OID type for their mechanisms; these
may, and likely will, be partly and algorithmically dependent on
local information.
Hmm. That's not what I remember the consensus to be. in particular,
a) I thought we discussed and dismissed the idea of deprecating
NULL_OID name types
b) we clearly achieved consensus among the attendees that the behavior
of NULL_OID name types, which is currently specified as
implementation-dependant should be changed to be specified as
mechanism-dependant.
I'd rephrase this as (deleting the first of the two sentances):
Our working agreement (impacting both C bindings and high-level
specifications) is as follows: State that GSS-V2 mechanism specs
shall define the behavior of the GSS_C_NULL_OID type for their
mechanisms; these may, and likely will, be partly and
algorithmically dependent on local information.
- Bill
Received: from cnri by ietf.org id aa15403; 19 Dec 96 16:59 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22079;
19 Dec 96 16:59 EST
Received: by pad-thai.cam.ov.com (8.8.4/)
id <UAA07748 at pad-thai.cam.ov.com>; Thu, 19 Dec 1996 20:09:47 GMT
Message-Id: <199612192009.PAA17241 at gza-client1.cam.ov.com>
To: Bill Sommerfeld <sommerfeld at apollo.hp.com>
Cc: John Linn <linn at cam.ov.com>, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: DRAFT minutes for San Jose CAT meetings
In-Reply-To: Your message of "Thu, 19 Dec 1996 14:07:47 EST."
<199612191907.OAA02545 at thunk.orchard.medford.ma.us>
Date: Thu, 19 Dec 1996 15:09:36 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
I believe that Bill's correct, propose to make the change as
he's suggested, and regret the confusion. Does anyone disagree?
--jl
Received: from capone.ch.apollo.hp.com by pad-thai.cam.ov.com (8.8.4/) with ESMTP
id <TAA05188 at pad-thai.cam.ov.com>; Thu, 19 Dec 1996 19:07:54 GMT
Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id <AA252582470 at capone.ch.apollo.hp.com>; Thu, 19 Dec 1996 14:07:50 -0500
Received: from thunk ([[UNIX: localhost]]) by thunk.orchard.medford.ma.us (8.7.5/8.6.12) with ESMTP id OAA02545; Thu, 19 Dec 1996 14:07:48 -0500 (EST)
Message-Id: <199612191907.OAA02545 at thunk.orchard.medford.ma.us>
X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs
To: John Linn <linn at cam.ov.com>
Cc: cat-ietf at mit.edu
Subject: Re: DRAFT minutes for San Jose CAT meetings
In-Reply-To: linn's message of Tue, 17 Dec 1996 10:09:28 -0500.
<199612171509.KAA05527 at gza-client1.cam.ov.com>
Date: Thu, 19 Dec 1996 14:07:47 -0500
From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
Status: U
Our working agreement (impacting both C bindings and high-level
specifications) is as follows: deprecate use of GSS_C_NULL_OID with
gss_import_name() by applications, but require mechanisms to
support it for the present, with its interpretation
locally-defined. State that GSS-V2 mechanism specs shall define the
behavior of the GSS_C_NULL_OID type for their mechanisms; these
may, and likely will, be partly and algorithmically dependent on
local information.
Hmm. That's not what I remember the consensus to be. in particular,
a) I thought we discussed and dismissed the idea of deprecating
NULL_OID name types
b) we clearly achieved consensus among the attendees that the behavior
of NULL_OID name types, which is currently specified as
implementation-dependant should be changed to be specified as
mechanism-dependant.
I'd rephrase this as (deleting the first of the two sentances):
Our working agreement (impacting both C bindings and high-level
specifications) is as follows: State that GSS-V2 mechanism specs
shall define the behavior of the GSS_C_NULL_OID type for their
mechanisms; these may, and likely will, be partly and
algorithmically dependent on local information.
- Bill
Received: from ietf.org by ietf.org id aa16847; 19 Dec 96 18:33 EST
Received: from zephyr.isi.edu by ietf.org id aa16444; 19 Dec 96 18:15 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA14461>; Thu, 19 Dec 1996 15:13:25 -0800
Message-Id: <199612192313.AA14461 at zephyr.isi.edu>
To: IETF-Announce: ;
To: Internet-Monthly-Report-People: ;
Subject: Internet Monthly Report for November, 1996
Cc: imr-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Thu, 19 Dec 96 15:13:22 PST
Sender:ietf-announce-request at ietf.org
From: IMR Editor <imr-ed at isi.edu>
--NextPart
The Internet Monthly Report for November, 1996 is now available
at the following location:
URL= ftp://ftp.isi.edu/in-notes/imr/imr9611.txt
The Internet Monthly Report (IMR) is normally distributed via EMail to
the IMR list and the IETF list. For most readers this is the most
convenient way to receive the report. However, there are some mail
systems or mail gateways that do not accommodate large messages (some
issues of the IMR are more than 100,000 characters). Readers that do
not receive the IMR via the normal distribution may obtain copies via
FTP or EMail retrieval.
Requests to be added or deleted from the IMR report list:
The Internet Monthly Report list is managed by MajorDomo atISI.EDU.
The announcements of new issues on the Internet Monthly Report
are sent to the IETF-Announce list and to this IMR list.
Requests to be added or deleted from the Internet Monthly report list
should be sent to majordomo at isi.edu with the message body either
subscribe imr or unsubscribe imr.
Requests to be added or deleted from the IETF list should be sent to
ietf-request at ietf.org.
Internet Monthly Report availability via WWW, FTP and EMAIL:
IMR Retrieval using WWW
-----------------------
The URL below may be used in web browsers to access the IMRs. You
will see a list of names in the form IMR9611.TXT. For example,
IMR9611.TXT is the report for November 1996.
URL: ftp://ftp.isi.edu/in-notes/imr
IMR Retrieval using EMAIL via the RFC-INFO Service
--------------------------------------------------
The EMail retrieval system RFC-Info will send a large report in
segments in separate EMail messages not exceeding 50,000 characters
each.
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to rfc-info at ISI.EDU with
the message body help: ways_to_get_imrs. For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
IMR Retrieval using FTP
-----------------------
IMRs are available via anonymous FTP from FTP.ISI.EDU, with the
pathname: in-notes/imr/imryymm.txt (where yymm refers to the date of
the IMR.
For example IMR9611.TXT is the report for November 1996).
Login with FTP username anonymous and password ftp.
IMR retrieval using MIME
------------------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retreive the current IMR.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="rfc-info at isi.edu"
Content-Type: text/plain
Retrieve: imr
Doc-ID: imr9611
--OtherAccess
Content-Type: Message/External-body;
name="imr9611.txt";
site="ftp.isi.edu";
access-type="anon-ftp";
directory="in-notes/imr"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18500; 19 Dec 96 19:14 EST
Received: from zephyr.isi.edu by ietf.org id aa18403; 19 Dec 96 19:11 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA14581>; Thu, 19 Dec 1996 15:16:05 -0800
Message-Id: <199612192316.AA14581 at zephyr.isi.edu>
To: ietf at ietf.org, imr at isi.edu
Subject: Internet Monthly Report for November, 1996
Cc: imr-ed at isi.edu
Date: Thu, 19 Dec 96 15:16:05 PST
Sender:ietf-request at ietf.org
From: IMR Editor <imr-ed at isi.edu>
Source-Info: From (or Sender) name not authenticated.
November 1996
INTERNET MONTHLY REPORTS
------------------------
The purpose of these reports is to communicate to the Internet Research
Group the accomplishments, milestones reached, or problems discovered by
the participating organizations.
Each organization is expected to submit a 1/2 page report on the first
business day of the month describing the previous month's activities.
These reports should be submitted via network mail to "IMR-ED at ISI.EDU".
`````````````````````````````````````````````````````````````````````
The Internet Monthly Report mailing list is now managed by MajorDomo at
ISI.EDU. The announcements of new issues on the Internet Monthly Report
are sent to the IETF-Announce list and to this IMR list.
Requests to be ADDED or DELETED from the Internet Monthly report list
should be sent to "majordomo at isi.edu" with the message body either
"subscribe imr" or "unsubscribe imr".
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to "rfc-info at ISI.EDU" with
the message body "help: ways_to_get_imrs". For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
or URL: http://www.isi.edu/in-notes/imr/
IMR Editor [Page 1]
Internet Monthly Report November 1996
TABLE OF CONTENTS
INTERNET ARCHITECTURE BOARD
IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . . page 3
INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3
Internet Projects
INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 18
Registration Services . . . . . . . . . . . . . . . . . page 18
Directory Services. . . . . . . . . . . . . . . . . . . page 20
US Domain Registry. . . . . . . . . . . . . . . . . . . page 21
MERIT INTERNET ENGINEERING. . . . . . . . . . . . . . . . page 25
UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 27
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 28
TERENA List of Meetings. . . . . . . . . . . . . . . . . . page 32
IMR Editor [Page 2]
Internet Monthly Report November 1996
INTERNET ARCHITECTURE BOARD
---------------------------
The minutes of the IAB back to 1990 are available for anonymous ftp
access on host ftp.isi.edu, directory /pub/IAB, or via the IAB
World-Wide Web page with URL http://www.iab.org/iab/.
Brian Carpenter IAB Chair
INTERNET ENGINEERING REPORTS
----------------------------
IETF Monthly Report for November, 1996
1. The IETF returns to San Jose, California on December 9-13, 1996.
Our local host will be cisco Systems. The Secretariat will open
for registrations the first part of October. The IETF opens 1997
in Memphis, Tennessee where Federal Express will be the host.
This meeting will be held April 7-11, 1997. Following Memphis,
the IETF is we returning to Europe and will met in Munich,
Germany August 11-15, 1997, hosted by Digi/ISOC.DE. The
Secretariat is still working on the final meeting of 1997.
Once all the arrangements have been made, notifications will be
sent to the IETF Announcement list. Remember that information
on future IETF meetings can be always be found in the file
0mtg-sites.txt which is located on the IETF shadow directories.
This information can also be viewed from the IETF Home Page on
the Web. The URL is:
http://www.ietf.org
2. The minutes of the IESG teleconferences have been publicly
available on the IETF Shadow directories since 1991. These
files are placed in the /ftp/iesg directory.
The following IESG minutes have been added:
October 31, 1996 (iesg.96-10-31)
IMR Editor [Page 3]
Internet Monthly Report November 1996
3. The IESG approved or recommended the following six Protocol
Actions during the month of November, 1996:
o HMAC-MD5 IP Authentication with Replay Prevention be
published as a Proposed Standard.
o HMAC-SHA IP Authentication with Replay Prevention be
published as a Proposed Standard.
o HMAC: Keyed-Hashing for Message Authentication be published
as an Informational RFC.
o IMAP/POP AUTHorize Extension for Simple Challenge/Response
be published as a Proposed Standard.
o Definitions of Managed Objects for IEEE 802.3 Repeater
Devices be published as a Proposed Standard.
o HTTP State Management Mechanism be published as a Proposed
Standard.
4. The IESG issued six Last Calls to the IETF during the month of
November, 1996:
o ISDN Management Information Base
<draft-ietf-isdnmib-snmp-isdn-mib-08> (Proposed Standard)
o Dial Control Management Information Base
<draft-ietf-isdnmib-dial-control-05> for consideration as a
Proposed Standard.
o Internet Group Management Protocol, Version 2
<draft-ietf-idmr-igmp-v2-05> for consideration as a Proposed
Standard.
o The MIME Multipart/Related Content-type
<draft-ietf-mhtml-related-00> for consideration as a Proposed
Standard.
o MIME E-mail Encapsulation of Aggregate Documents, such as
HTML (MHTML) <draft-ietf-mhtml-spec-05> for consideration as
a Proposed Standard.
o Content-ID and Message-ID Uniform Resource Locators
<draft-ietf-mhtml-cid-02> for consideration as a Proposed
Standard.
IMR Editor [Page 4]
Internet Monthly Report November 1996
5. Two Working Groups were created during this period:
Application Configuration Access Protocol (acap)
Roaming Operations (roamops)
6. A total of 260 Internet-Draft actions were taken during the
month of November, 1996:
(Revised draft (o), New Draft (+) )
(cat) o FTP Security Extensions
<draft-ietf-cat-ftpsec-09.txt>
(rsvp) o Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification
<draft-ietf-rsvp-spec-14.txt, .ps>
(idmr) o Protocol Independent Multicast-Sparse Mode (PIM-SM):
Motivation and Architecture
<draft-ietf-idmr-pim-arch-04.txt>
(idmr) o Internet Group Management Protocol MIB
<draft-ietf-idmr-igmp-mib-04.txt>
(idmr) o IP Multicast Routing MIB
<draft-ietf-idmr-multicast-routmib-04.txt>
(none) o Simple Secure DNS <draft-ohta-simple-dns-02.txt>
(ipngwg) o Basic Socket Interface Extensions for IPv6
<draft-ietf-ipngwg-bsd-api-06.txt>
(dhc) o Dynamic Host Configuration Protocol
<draft-ietf-dhc-dhcp-08.txt>
(cat) o Independent Data Unit Protection Generic Security
Service Application Program Interface (IDUP-GSS-API)
<draft-ietf-cat-idup-gss-06.txt>
(mobileip) o Route Optimization in Mobile IP
<draft-ietf-mobileip-optim-05.txt>
(idr) o A Border Gateway Protocol 4 (BGP-4)
<draft-ietf-idr-bgp4-04.txt>
(dhc) o Dynamic Host Configuration Protocol for IPv6
(DHCPv6) <draft-ietf-dhc-dhcpv6-08.txt>
(dnsind) o Dynamic Updates in the Domain Name System (DNS
UPDATE) <draft-ietf-dnsind-dynDNS-11.txt>
(ion) + NHRP Protocol Applicability Statement
<draft-ietf-ion-nhrp-appl-00.txt>
(none) + Router Architecture Extensions for ATM : Overview
<draft-rfced-info-katsube-00.txt>
(cat) o Generic Security Service API Version 2 : C-bindings
<draft-ietf-cat-gssv2-cbind-03.txt>
(ipsec) o Internet Security Association and Key Management
Protocol (ISAKMP) <draft-ietf-ipsec-isakmp-06.txt,
.ps>
IMR Editor [Page 5]
Internet Monthly Report November 1996
(intserv) o Network Element Service Specification Template
<draft-ietf-intserv-svc-template-03.txt>
(mmusic) o SDP: Session Description Protocol
<draft-ietf-mmusic-sdp-02.txt, .ps>
(ion) o IP Broadcast over ATM Networks
<draft-ietf-ion-bcast-01.txt>
(none) o SMTP Service Extension for Authentication
<draft-myers-smtp-auth-04.txt>
(cidrd) o Classless IN-ADDR.ARPA delegation
<draft-ietf-cidrd-classless-inaddr-02.txt>
(dhc) o DHCP Options and BOOTP Vendor Extensions
<draft-ietf-dhc-options-1533update-05.txt>
(nimrod) o DNS Resource Records for Nimrod Routing Architecture
<draft-ietf-nimrod-dns-02.txt>
(rsvp) o RSRR: A Routing Interface For RSVP
<draft-ietf-rsvp-routing-01.txt, .ps>
(none) o RSTs Considered Harmful
<draft-heavens-problems-rsts-03.txt>
(asid) o A MIME Content-Type for Directory Information
<draft-ietf-asid-mime-direct-03.txt>
(ion) o Classical IP and ARP over ATM
<draft-ietf-ion-classic2-01.txt>
(none) o Simple Authentication and Security Layer
<draft-myers-auth-sasl-06.txt>
(idmr) o Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification
<draft-ietf-idmr-pim-sm-spec-09.txt>
(grip) o Expectations for Security Incident Response
<draft-ietf-grip-framework-irt-03.txt>
(receipt) o An Extensible Message Format for Message Disposition
Notifications <draft-ietf-receipt-mdn-02.txt>
(none) o ISO Transport Service on top of TCP (ITOT)
<draft-pouffary-itot-04.txt>
(drums) o Simple Mail Transfer Protocol
<draft-ietf-drums-smtpupd-03.txt>
(intserv) o General Characterization Parameters for Integrated
Service Network Elements
<draft-ietf-intserv-charac-02.txt>
(madman) o Network Services Monitoring MIB
<draft-ietf-madman-nsm-mib-03.txt>
(ids) o A Common Schema for the Internet White Pages Service
<draft-ietf-ids-iwps-schema-spec-02.txt>
(cat) o The SESAME V5 GSS-API Mechanism
<draft-ietf-cat-sesamemech-02.txt>
(intserv) o Integrated Services Management Information Base
<draft-ietf-intserv-mib-04.txt>
(rsvp) o RSVP Management Information Base
<draft-ietf-rsvp-mib-04.txt>
IMR Editor [Page 6]
Internet Monthly Report November 1996
(nimrod) o Endpoint Identifier Destination Option
<draft-ietf-nimrod-eid-01.txt>
(intserv) o Specification of the Controlled-Load Network Element
Service <draft-ietf-intserv-ctrl-load-svc-04.txt>
(ipngwg) o Generic Packet Tunneling in IPv6 Specification
<draft-ietf-ipngwg-ipv6-tunnel-05.txt>
(ospf) o OSPF for IPv6 <draft-ietf-ospf-ospfv6-03.txt>
(ospf) + The OSPF Opaque LSA Option
<draft-ietf-ospf-opaque-00.txt>
(tls) + The SSL Protocol Version 3.0
<draft-ietf-tls-ssl-version3-00.txt>
(pppext) o The PPP Bandwidth Allocation Protocol (BAP) The PPP
Bandwidth Allocation Control Protocol (BACP)
<draft-ietf-pppext-bacp-05.txt>
(atommib) o Definitions of Tests for ATM Management
<draft-ietf-atommib-test-01.txt>
(ids) o X.500 Implementations Catalog-96
<draft-ietf-ids-x500-imps-05.txt>
(none) + Application REQuested IP over ATM (AREQUIPA)
<draft-rfced-info-almesberger-00.txt>
(mobileip) o Mobility Support in IPv6
<draft-ietf-mobileip-ipv6-02.txt>
(ifmib) o The Interfaces Group MIB
<draft-ietf-ifmib-mib-05.txt>
(applmib) o Definitions of Managed Objects for Applications
<draft-ietf-applmib-sysapplmib-06.txt>
(none) o The "data" URL scheme
<draft-masinter-url-data-02.txt>
(dhc) o Authentication for DHCP Messages
<draft-ietf-dhc-authentication-03.txt>
(none) o Header Compression for IPv6
<draft-degermark-ipv6-hc-02.txt>
(dhc) o Extensions for DHCPv6 <draft-ietf-dhc-v6exts-04.txt>
(dnsind) o Selection and Operation of Secondary DNS Servers
<draft-ietf-dnsind-2ndry-04.txt>
(dnsind) o Clarifications to the DNS Specification
<draft-ietf-dnsind-clarify-02.txt>
(ion) + Server Cache Synchronization Protocol (SCSP)
<draft-ietf-ion-scsp-00.txt>
(ion) o Multicast Server Architectures for MARS-based ATM
multicasting. <draft-ietf-ion-marsmcs-01.txt, .ps>
(http) o Transparent Content Negotiation in HTTP
<draft-holtman-http-negotiation-04.txt>
(http) o HTTP State Management Mechanism
<draft-ietf-http-state-mgmt-05.txt, .ps>
(rsvp) o RSVP Diagnostic Messages
<draft-ietf-rsvp-diagnostic-msgs-02.txt>
IMR Editor [Page 7]
Internet Monthly Report November 1996
(ion) o ATM Signalling Support for IP over ATM - UNI 4.0
Update <draft-ietf-ion-sig-uni4.0-01.txt>
(atommib) o Managed Objects for Controlling the Collection and
Storage of Accounting Information for
Connection-Oriented Networks
<draft-ietf-atommib-acct-04.txt>
(snanau) o Definitions of Managed Objects for APPN
<draft-ietf-snanau-appnmib-02.txt>
(rsvp) o Local Policy Modules (LPM): Policy Control for RSVP
<draft-ietf-rsvp-policy-lpm-01.txt, .ps>
(none) o Clarification on the use of Hostnames, Mail Boxes
and Mail Domains in the DNS
<draft-andrews-dns-hostnames-03.txt>
(ipsec) o HMAC: Keyed-Hashing for Message Authentication
<draft-ietf-ipsec-hmac-md5-01.txt>
(none) o Top Level Domain Classification and Categorization
<draft-higgs-tld-cat-03.txt>
(mhtml) o MIME E-mail Encapsulation of Aggregate Documents,
such as HTML (MHTML) <draft-ietf-mhtml-spec-05.txt>
(none) o IANA Character Set Registration Procedures
<draft-freed-charset-reg-01.txt>
(avt) o RTP Payload Format for H.263 Video Stream
<draft-ietf-avt-rtp-payload-02.txt>
(none) o Transient Neighbors for IPv6 over ATM
<draft-armitage-ion-tn-01.txt>
(ipsec) o HMAC-MD5 IP Authentication with Replay Prevention
<draft-ietf-ipsec-ah-hmac-md5-04.txt>
(ipsec) o HMAC-SHA IP Authentication with Replay Prevention
<draft-ietf-ipsec-ah-hmac-sha-04.txt>
(mhtml) o Sending HTML in E-mail, an informational supplement
to RFC ???: MIME E-mail Encapsulation of Aggregate
HTML Documents (MHTML)
<draft-ietf-mhtml-info-05.txt>
(none) o Distributed Component Object Model Protocol --
DCOM/1.0 <draft-brown-dcom-v1-spec-01.txt>
(none) o Another ATM Signaling Protocol for IP (IP-SVC)
<draft-fujikawa-ipsvc-01.txt>
(asid) o An Application/Directory MIME Content-Type
Electronic Business Card Profile
<draft-ietf-asid-mime-vcard-01.txt>
(none) o Using the MARS model in non-ATM NBMA networks.
<draft-armitage-ion-mars-nbma-01.txt>
(ifmib) o Definitions of Managed Objects for System and
Interface Testing <draft-ietf-ifmib-testmib-01.txt>
(ids) o Finding Stuff (Providing information to support
service discovery) <draft-ietf-ids-discovery-03.txt>
(ion) o IPv6 over NBMA Networks
<draft-ietf-ion-ipv6-nbma-01.txt>
IMR Editor [Page 8]
Internet Monthly Report November 1996
(hubmib) o Definitions of Managed Objects for the Ethernet-like
Interface Types
<draft-ietf-hubmib-etherif-mib-01.txt>
(ipsec) o Security Architecture for the Internet Protocol
<draft-ietf-ipsec-arch-sec-01.txt>
(none) o A.L.P.E.S. Administration deLocalisee Par Emissions
Securisees a TCP/IP protocol
<draft-durand-alpes-01.txt>
(none) o SMTP Message Submission and Relay
<draft-gellens-submit-02.txt>
(none) o ACAP -- Application Configuration Access Protocol
<draft-myers-acap-spec-01.txt>
(none) o The Public Key Login Protocol
<draft-kemp-auth-pklogin-02.txt, .ps>
(rsvp) o Policy Control for RSVP: Architectural Overview
<draft-ietf-rsvp-policy-arch-01.txt, .ps>
(rsvp) o RSVP Extensions for Policy Control
<draft-ietf-rsvp-policy-ext-01.txt, .ps>
(none) o User-Agent Display Attributes
<draft-mutz-http-attributes-02.txt>
(none) o Voice Profile for Internet Mail - version 2
<draft-ema-vpim-03.txt>
(ipsec) o The resolution of ISAKMP with Oakley
<draft-ietf-ipsec-isakmp-oakley-02.txt>
(pkix) o Internet Public Key Infrastructure Part III:
Certificate Management Protocols
<draft-ietf-pkix-ipki3cmp-01.txt>
(ipngwg) + IPv6 Router Alert Option
<draft-ietf-ipngwg-ipv6router-alert-00.txt>
(none) o Web Based System and Network Management
<draft-mellquist-web-sys-01.txt>
(roamops) + Dialup Roaming Requirements
<draft-ietf-roamops-roamreq-00.txt>
(urn) o Resolution of Uniform Resource Identifiers using the
Domain Name System <draft-ietf-urn-naptr-01.txt>
(agentx) o Agent Extensibility (AgentX) Protocol Version 1
<draft-ietf-agentx-ext-pro-01.txt>
(issll) o IP Integrated Services with RSVP over ATM
<draft-ietf-issll-atm-support-02.txt, .ps>
(none) o Redundant MARS architectures and SCSP
<draft-armitage-ion-mars-scsp-02.txt>
(find) o The Common Indexing Protocol (CIP)
<draft-ietf-find-new-cip-01.txt>
(none) o SBM (Subnet Bandwidth Manager): A Proposal for
Admission Control over Ethernet
<draft-yavatkar-sbm-ethernet-02.txt>
(ion) o Multiprotocol Interconnect over Frame Relay
<draft-ietf-ion-fr-update-02.txt>
IMR Editor [Page 9]
Internet Monthly Report November 1996
(intserv) o Integrated Services Management Information Base
Guaranteed Service Extensions
<draft-ietf-intserv-guaranteed-mib-02.txt>
(none) o Internet Calendar Access Protocol (ICAP)
<draft-oleary-icap-01.txt>
(oncrpc) o RPCSEC_GSS Protocol Specification
<draft-ietf-oncrpc-rpcsec_gss-01.txt>
(ediint) o Requirements for Inter-operable Internet EDI
<draft-ietf-ediint-req-01.txt>
(none) o S/Ident: Security Extensions for the Ident Protocol
<draft-morgan-ident-ext-02.txt>
(atommib) o Accounting Information for ATM Networks
<draft-ietf-atommib-atmacct-01.txt>
(intserv) o The Use of RSVP with IETF Integrated Services
<draft-ietf-intserv-rsvp-use-01.txt>
(stdguide) o Guide for Internet Standards Writers
<draft-ietf-stdguide-ops-01.txt>
(bmwg) o Benchmarking Terminology for LAN Switching Devices
<draft-ietf-bmwg-lanswitch-01.txt>
(none) o Domain Names and Company Name Retrieval
<draft-klensin-tld-whois-01.txt>
(roamops) + Review of Roaming Implementations
<draft-ietf-roamops-imprev-00.txt>
(dnsind) o Secret Key Transaction Signatures for DNS (TSIG)
<draft-ietf-dnsind-tsig-01.txt>
(issll) + QOSPPP Framing Extensions to PPP
<draft-ietf-issll-framing-ext-00.txt>
(none) o A Framework for Providing Integrated Services Over
Shared and Switched LAN Technologies
<draft-ghanwani-framework-is-lan-01.txt>
(none) o EARTH - EAsy IP multicast Routing THrough ATM clouds
<draft-smirnov-ion-earth-01.txt>
(none) o Network Ingress Filtering Defending Against IP
Source Address Spoofing
<draft-ferguson-ingress-filtering-01.txt>
(none) o IMAP URL Scheme <draft-newman-url-imap-03.txt>
(none) o FTP Extensions for Variable Protocol Specification
<draft-allman-ftp-variable-03.txt>
(none) o The Safe Response Header
<draft-holtman-http-safe-01.txt>
(none) o MIME Parameter Value and Encoded Words: Character
Sets, Language, and Continuations
<draft-freed-pvcsc-01.txt>
(ipngwg) o IPv6 Multicast Address Assignments
<draft-ietf-ipngwg-multicast-assgn-01.txt>
(ediint) o MIME-based Secure EDI <draft-ietf-ediint-as1-02.txt>
(none) o NNTP LIST Additions <draft-hernacki-nntplist-01.txt>
(urn) o URN Syntax <draft-ietf-urn-syntax-01.txt>
IMR Editor [Page 10]
Internet Monthly Report November 1996
(none) o Payload Format for HTTP Encoding in RTP
<draft-aboba-rtp-http-01.txt>
(none) + Uniform Resource Locators for Television and
Telephony <draft-zigmond-media-url-00.txt>
(none) o MIME Calendaring and Scheduling Content Type Profile
<draft-dawson-csp-01.txt>
(ipsec) + Combined 3DES-CBC, HMAC and Replay Prevention
Security Transform
<draft-ietf-ipsec-esp-3des-md5-00.txt>
(ion) + Classical IP to NHRP Transition
<draft-ietf-ion-transition-00.txt>
(none) + Universal Format for Logger Messages
<draft-abela-ulm-00.txt>
(none) + MIME Calendaring and Scheduling Content Type
<draft-dawson-csct-00.txt>
(mboned) + Administratively Scoped IP Multicast
<draft-ietf-mboned-admin-ip-space-00.txt>
(none) + Limiting the role of IPv4-compatible Addresses in
IPv6 <draft-harrington-ngtrans-v4comp-00.txt>
(none) + Internet Location Path System (ILPS)
<draft-martins-ilps-00.txt>
(none) + Transaction Internet Protocol
<draft-lyon-itp-nodes-00.txt>
(none) + Internet Cache Protocol (ICP), version 2
<draft-wessels-icp-v2-00.txt>
(rsvp) + Resource ReSerVation Protocol (RSVP) -- Version 1
Message Processing Rules
<draft-ietf-rsvp-procrules-00.txt, .ps>
(none) o The Multicast Dissemination Protocol (MDP) Framework
<draft-macker-mdp-framework-01.txt>
(none) + Version management with meta-level links via
HTTP/1.1 <draft-ota-http-version-00.txt>
(none) + Proximity Proxies for Mobile Nodes and Mobility
Agents (PPM) <draft-liyunzhou-mobileip-ppm-00.txt,
.ps>
(none) + Network Data Management Protocol
<draft-stager-pdc-netapp-backup-00.txt>
(tls) + Addition of Kerberos Cipher Suites to Transport
Layer Security (TLS)
<draft-ietf-tls-kerb-cipher-suites-00.txt>
(none) + Router Architecture Extensions for ATM : Overview
<draft-rfced-info-katsube-oops-00.txt>
(asid) + Use of Language Codes in LDAP
<draft-ietf-asid-ldapv3-lang-00.txt>
(roamops) + The Network Access Identifier
<draft-ief-roamops-nai-00.txt>
(none) + The Report of the IAB Character Set Workshop
<draft-weider-iab-char-wrkshop-00.txt>
IMR Editor [Page 11]
Internet Monthly Report November 1996
(none) + Interoperability Rules for Multicast Routing
Protocols <draft-thaler-interop-00.txt, .ps>
(none) + IGRPng for IPv6 <draft-minnear-igrpng-00.txt>
(pkix) + Architecture for Public-Key Infrastructure
<draft-ietf-pkix-apki-00.txt>
(dhc) + The User Class Option for DHCP
<draft-ietf-dhc-userclass-00.txt>
(bmwg) + Terminology for Cell/Call Benchmarking
<draft-ietf-bmwg-call-00.txt>
(none) + DHCP Options for Novell Directory Services
<draft-provan-dhcp-options-dir-serv-00.txt>
(none) + Uniform Resource Locators (URL)
<draft-fielding-url-syntax-00.txt>
(poisson) o A New IETF Document Classification
<draft-ietf-poisson-ietfdoc-01.txt>
(rps) + Representing Tunnels in RPSL
<draft-ietf-rps-tunnels-00.txt>
(none) + MLST Command and Extensions to FTP
<draft-hethmon-mlst-command-ftp-00.txt>
(none) + Remote Passphrase Authentication Part One: Extended
Introduction <draft-petke-ext-intro-00.txt>
(none) + Remote Passphrase Authentication Part Four:
Service-to-Deity Protocol
<draft-petke-serv-deity-protocol-00.txt>
(none) + Remote Passphrase Authentication Part Two: The
Mechanism <draft-petke-mech-00.txt>
(none) + Remote Passphrase Authentication Part Three: HTTP
Authentication Scheme
<draft-petke-http-auth-scheme-00.txt>
(none) + NNTP Full-text Search Enhancements
<draft-ballou-nntpsrch-00.txt>
(none) o RTP extension for Scalable Reliable Multicast
<draft-parnes-rtp-ext-srm-01.txt>
(none) + Mail Header Registration Procedure
<draft-palme-MHRegistry-00.txt>
(none) + Path QoS Collection for RSVP-friendly Hop-by-hop QoS
Routing <draft-ohta-rsvp-friendly-hop-path-00.txt>
(none) + ARIS: Aggregate Route-Based IP Switching
<draft-woundy-aris-ipswitching-00.txt>
(ipsec) o The Internet IP Security Domain of Interpretation
for ISAKMP <draft-ietf-ipsec-ipsec-doi-01.txt>
(ion) + Inverse Address Resolution Protocol
<draft-ietf-ion-inarp-update-00.txt>
(none) + POP3 AUTHentication command
<draft-myers-sasl-pop3-00.txt>
(none) + HTTP-based SNMP and CMIP Network Management
<draft-deri-http-mgmt-00.txt>
IMR Editor [Page 12]
Internet Monthly Report November 1996
(none) + PF_KEY Key Management API, Version 2
<draft-mcdonald-pf-key-v2-00.txt>
(none) + Tag Switching: Tag Stack Encodings
<draft-rosen-tag-stack-00.txt>
(none) + Transmission of IPv6 Packets over IPv4 Networks
without Tunnels <draft-carpenter-ipng-6over4-00.txt>
(none) + Copy Control for Web Documents
<draft-daviel-web-copy-control-00.txt>
(none) o Implementation of Mandatory Tunneling via RADIUS
<draft-aboba-radius-tunnel-imp-01.txt>
(none) + Scenarios and Appropriate Protocols for Distributed
Interactive Simulation
<draft-myjak-lsma-scenarios-00.txt>
(snanau) + Definitions of Managed Objects for DLUR
<draft-ietf-snanau-dlurmib-00.txt>
(snanau) + Definitions of Managed Objects for HPR
<draft-ietf-snanau-hprmib-00.txt>
(ssh) + Users' Security Handbook
<draft-ietf-ssh-users-00.txt>
(none) + Efficient HyperLink Maintenance for HTTP
<draft-pritchard-http-links-00.txt>
(none) + The Kitchen Sink Resource Record
<draft-eastlake-kitchen-sink-00.txt>
(urn) + Conventions for the Use of HTTP for URN Resolution
<draft-ietf-urn-http-conv-00.txt>
(ftpext) + Internationalization of the File Transfer Protocol
<draft-ietf-ftpext-intl-ftp-00.txt>
(dhc) + DHCP Option for IEEE 1003.1 POSIX Timezone
Specifications <draft-ietf-dhc-timezone-00.txt>
(otp) + OTP Verification Examples
<draft-ietf-otp-ver-00.txt>
(dhc) + An Inter-server Protocol for DHCP
<draft-ietf-dhc-interserver-00.txt>
(svrloc) + The service: URL Scheme
<draft-ietf-svrloc-service-scheme-00.txt>
(none) + IPv6 network prefix notation
<draft-durand-ipv6prefix-00.txt>
(none) + Requirements for WEB Browser-based Internet Printing
<draft-wright-ipp-req-00.txt>
(none) + A Simple IP Security API Extension to BSD Sockets
<draft-mcdonald-simple-ipsec-api-00.txt>
(tls) + Addition of Shared Key Authentication to Transport
Layer Security (TLS)
<draft-ietf-tls-passauth-00.txt>
(none) + Elvis Spoofing <draft-elvis-email-spoof-00.txt>
(frnetmib) + Definitions of Managed Objects for Frame Relay
Service <draft-ieft-frnetmib-frs-mib-00.txt>
IMR Editor [Page 13]
Internet Monthly Report November 1996
(none) + HTTP-based Distributed Content Editing Scenarios
<draft-lassila-http-edit-dist-00.txt>
(none) + Simple Universal Call/Conference Establishment
Sequence - (SUCCESS) <draft-cordell-success-00.txt>
(frnetmib) + Managed Objects for Monitoring and Controlling the
Frame Relay/ATM Service Interworking Function
<draft-ietf-frnetmib-atmiwf-00.txt>
(urn) + Requirements and a Framework for URN Resolution
Systems <draft-ietf-urn-req-frame-00.txt>
(calsch) + MIME application/calendar Content Type
<draft-ietf-calsch-sch-00.txt>
(none) o Enhanced Communications Transport Service Definition
<draft-kim-jtc1-sc6-ects-01.txt>
(disman) + Definitions of Managed Objects for the Delegation
of Management Scripts
<draft-ietf-disman-script-mib-00.txt>
(none) + The Weak Authentication and Tracing Option
<draft-eastlake-weak-ato-00.txt>
(none) + Representing the Dublin Core within X.500, LDAP and
CLDAP <draft-hamilton-dcxl-00.txt>
(ion) + Definitions of Managed Objects for Multicast over
UNI 3.0/3.1 based ATM Networks
<draft-ietf-ion-mars-mib-00.txt>
(none) + Internet Service Provider Address Coalitions
(ISPACs) <draft-li-ispac-00.txt>
(ids) + NAMING PLAN FOR AN INTERNET DIRECTORY SERVICE
<draft-ietf-ids-dirnaming-00.txt>
(rtfm) + Real Time Flow Measurement Working Group - New
Attributes for Traffic Flow Measurement
<draft-ietf-rtfm-new-traffic-flow-00.txt>
(svrloc) + An API for Service Location
<draft-ietf-svrloc-api-00.txt>
(asid) + WHOIS++ templates
<draft-ietf-asid-whois-schema-00.txt>
(none) + Internet Printing Protocol - IPP/1.0
<draft-isaacson-ipp-info-00.txt>
(rmonmib) + Remote Network Monitoring MIB Protocol Identifiers
<draft-ietf-rmonmib-rmonprot-v2-00.txt>
(ipsec) + Inline Keying within the ISAKMP Framework.
<draft-ietf-ipsec-inline-isakmp-00.txt>
(none) + Architecture of the Resource Reservation Service for
the Commercial Internet
<draft-suzuki-res-resv-svc-arch-00.txt>
(none) + Bulletins as an Extension to HTML
<draft-holstege-bulletintext-00.txt>
(none) + LZS Payload Compression Transform for ESP
<draft-sabin-lzs-payload-00.txt>
IMR Editor [Page 14]
Internet Monthly Report November 1996
(cat) + Public Key Cryptography for Cross-Realm
Authentication in Kerberos
<draft-ietf-cat-kerberos-pk-cross-00.txt>
(none) + Virtual Router Redundancy Protocol
<draft-whipple-vrrp-00.txt>
(none) + Using PICS for Copyright Notice and Control
<draft-reagle-pics-copyright-00.txt>
(applmib) + Application Management MIB
<draft-ietf-applmib-mib-00.txt>
(atommib) + Managed Objects for Recording ATM Performance
History Data Based on 15 Minute Intervals
<draft-ietf-atommib-atmhist-00.txt>
(rps) + Routing Policy Specification Language (RPSL)
<draft-ietf-rps-rpsl-00.txt>
(asid) + Definition of the inetOrgPerson Object Class
<draft-ietf-asid-inetorgperson-00.txt>
(applmib) + Definitions of Managed Objects for WWW Servers
<draft-ietf-applmib-wwwmib-00.txt>
(radius) + RADIUS Attributes for Tunnel Protocol Support
<draft-ietf-radius-tunnel-auth-00.txt>
(none) + Integrated-Services/RSVP Requirements for Layer 2
Traffic Control <draft-hoffman-issll-l2tcreq-00.txt>
(none) + MTP/SO: Self-Organizing Multicast
<draft-bormann-mtp-so-00.txt>
(drums) + Message Format Standard
<draft-ietf-drums-msg-fmt-00.txt>
(none) + RMFP: A Reliable Multicast Framing Protocol
<draft-crowcroft-rmfp-00.txt>
(none) + Limitations of Internet Protocol Suite for
Distributed Simulation in the Large Multicast
Environment <draft-pullen-lsma-limitations-00.txt>
(mmusic) + A real-time stream control protocol (RTSP)
<draft-ietf-mmusic-stream-00.txt, .ps>
(none) + Simple Unified Networking <draft-ohta-sun-00.txt>
(bmwg) + Connectivity <draft-ietf-bmwg-ippm-connect-00.txt>
(none) + A Simulation of QOSFP Multicasting for a Large Area
<draft-pullen-qospf-model-00.txt>
(none) + A Simulation Model for IP Multicast with RSVP
<draft-pullen-ipv4-rsvp-00.txt>
(bmwg) + Empirical Bulk Transfer Capacity
<draft-ietf-bmwg-ippm-treno-btc-00.txt>
(mmusic) + Real Time Streaming Protocol (RTSP)
<draft-ietf-mmusic-rtsp-00.txt>
(calsch) + Calendaring Interoperability Protocol
<draft-ietf-calsch-cip-00.txt>
(asid) + Architecture of the WHOIS++ service
<draft-ietf-asid-whoispp-00.txt>
IMR Editor [Page 15]
Internet Monthly Report November 1996
(none) + IETF Criteria For Evaluating Reliable Multicast
Transport and Application Protocols
<draft-mankin-reliable-multicast-00.txt>
(mmusic) + SAP: Session Announcement Protocol
<draft-ietf-mmusic-sap-00.txt, .ps>
(printmib) + Printer MIB <draft-ietf-printmib-mib-info-00.txt,
.ps>
(tls) + Modifications to the SSL protocol for TLS
<draft-ietf-tls-ssl-mods-00.txt>
(issll) + Integrated Services over ATM LAN Emulation (LANE)
Networks <draft-ietf-issll-lane-00.txt>
(none) + The RWhois Uniform Resource Locator
<draft-mealling-rwhoisurl-00.txt>
(none) + Key Derivation for Authentication, Integrity, and
Privacy <draft-horowitz-key-derivation-00.txt>
(cat) + Key Derivation for Kerberos V5
<draft-ietf-cat-kerb-key-derivation-00.txt>
(cat) + Triple DES with HMAC-SHA1 Kerberos Encryption Type
<draft-ietf-cat-kerb-des3-hmac-sha1-00.txt>
(none) + Secure FTP over SSL
<draft-murray-auth-ftp-ssl-00.txt>
(find) + Using the Common Indexing Protocol in an LDAP
Environment <draft-ietf-find-cip-ldap-00.txt>
(bmwg) + Framework for IP Provider Metrics
<draft-ietf-bmwg-ippm-framework-00.txt>
(ospf) + OSPF Standardization Report
<draft-ietf-ospf-stdreport-00.txt>
(bmwg) + A One-way Delay Metric for IPPM
<draft-ietf-bmwg-ippm-delay-00.txt>
(none) + Alternatives for Enhancing RTP Scalability
<draft-aboba-rtpscale-00.txt>
(avt) o Compressing IP/UDP/RTP Headers for Low-Speed Serial
Links <draft-ietf-avt-crtp-01.txt>
(none) + Selectively Reliable Transport Protocol
<draft-laviano-srtp-00.txt>
IMR Editor [Page 16]
Internet Monthly Report November 1996
7. There were nine RFC's published during the month of November,
1996:
RFC St WG Title
------- -- -------- -------------------------------------
RFC2009 E (none) GPS-Based Addressing and Routing
RFC2011 PS (snmpv2) SNMPv2 Management Information Base for
the Internet Protocol using SMIv2
RFC2012 PS (snmpv2) SNMPv2 Management Information Base for
the Transmission Control Protocol
RFC2013 PS (snmpv2) SNMPv2 Management Information Base for
the User Datagram Protocol using SMIv2
RFC2022 PS (ipatm) Support for Multicast over UNI 3.0/3.1
based ATM Networks.
RFC2039 I (none) Applicability of Standards Track MIBs to
Management of World Wide Web Servers
RFC2050 B (none) INTERNET REGISTRY IP ALLOCATION
GUIDELINES
RFC2056 P (uri) Uniform Resource Locators for Z39.50
RFC2057 I (none) Source directed access control on the
Internet.
St(atus): ( S) Internet Standard
(PS) Proposed Standard
(DS) Draft Standard
( B) Best Current Practice
( E) Experimental
( I) Informational
Steve Coya <scoya at ietf.org>
IMR Editor [Page 17]
Internet Monthly Report November 1996
INTERNET PROJECTS
-----------------
INTERNIC
--------
REGISTRATION SERVICES
I. Significant Events
Help Desk Support
* The Call Center Manager is now on call 24 hours a day
via pager.
* As part of the selection process for a new PBX/ACD system,
three customer site visits were made by Tim McLain and Debbie
Fuller to view installed and operational systems.
* The Call Center reconfiguration was completed and Billing
CSRs moved downstairs from the third floor into the newly
configured Call Center on the first floor.
Name Registration Support
* The Processing Center Manager is now on call 24 hours a
day via pager.
* Approximately 96% of the total new domains registered in
October were processed automatically.
Billing Support
* Record amounts of payments were received in November, causing
significant challenges in processing payments in a timely manner.
* A plan was developed to perform a large volume of problem
reconciliation tasks related to customer payments; many of these
involve payments submitted without a copy of the invoice or other
identifying documentation stating to what name a payment should
be applied.
*Work space was freed up in the Receivables area to provide work
space for temporary hires to work on the elimination of the
payment data entry backlog and the reconciliation tasks.
* The process of outsourcing most fulfillment services was
started; this includes printing, folding, inserting, bar-coding,
and mailing of invoices and 15-Day Deactivation Letters;
previously, just the folding, inserting, and mailing tasks were
outsourced.
IMR Editor [Page 18]
Internet Monthly Report November 1996
IP Support
* Staffing plans and a preliminary budget were completed with
regard to separating the IP Section from InterNIC Registration
Services.
Information Services Support
* Robin Murphy and Anna Carts assisted Pete Magoon (Training
Manager) in the development of Billing-Outsourcing Overview
training materials to be used with customer service representatives
(CSRs).
Engineering Support
Software modifications made include:
* The DomReg software was enhanced to avoid a PGP time-out.
* A response message was added to CReg to notify customers that
the Before-Use Guardian option has not yet been implemented.
* MTS was modified to handle SunOS and Solaris versions of
mktemp-file. 7 New software development work completed includes:
* A GUI-based query tool was created to help CSRs perform
their job more efficiently.
Miscellaneous
Training Support:
* Staffing of the InterNIC Training Section was completed
with the transfer of two InterNIC staff members and the
hiring of one outside candidate.
* First Virtual payment processing training was provided to
all InterNIC CSRs on Thursday, Friday and Saturday,
November 21-23.
* Billing-Outsourcing Overview training materials were
prepared and provided to Information Services for addition
to the InterNIC internal web site.
* Furniture and equipment requirements for a new training
facility were completed.
* Legal staff provided a standard response for CSRs to use
for customers who ask about the InterNIC policy with regard to
registering offensive names.
IMR Editor [Page 19]
Internet Monthly Report November 1996
II. Current Status
November:
Email: 244,228
Postal/Fax: 994
Phone: 30,090
Gopher connections: 8014 retrievals: 27157
WAIS connections: 31502 retrievals: 20394
FTP connections: 55786 retrievals: 101879
Mailserv: n/a
Telnet: 71284
Http: 3592320
Whois client: 677393
Whois server: 7587989
Rich Landers <richl at internic.net>
INTERNIC DIRECTORY AND DATABASE SERVICES
In July, InterNIC Directory and Database Services took over
generation of the Netfind seed database. We have recently changed
the procedure used to build that database and future versions will
contain a great deal more data than the previous versions (the new
database contains over 760,000 entries). The new database is also
substantially larger (about 4 times larger) than the previous
version, so sites that are running Netfind servers may need to
allocate more space to the database.
These changes do NOT affect Netfind users. Users can continue to
use Netfind the same way. The additional data should improve the
accuracy of Netfind searches but users should see no major
differences in the way they use the system.
Sites running Netfind servers should check
http://ds.internic.net/wp/netfind-seeddb.html
for information on the new seed database and the new version of
Netfind that supports it. The old seed database and older version
of Netfind remain available and can also be accessed through the
above URL.
IMR Editor [Page 20]
Internet Monthly Report November 1996
A reminder - if you would like to help the Internet community find
a resource that you offer, send mail to admin at ds.internic.net and
we will send information about listing your resource in the
Directory of Directories. If you prefer, you can enter information
about your resource in our WWW suggestion form. The form can be
reached through our Directory of Directories Web page at:
http://ds.internic.net:80/ds/dsdirofdirs.html
by Rick Huber <rvh at ds.internic.net>
THE US DOMAIN REGISTRY
The US Domain online line registration form may be found at
http://www.isi.edu/us-domain/.
The US Domain administrator no longer makes direct registrations of
hosts, and only makes delegations of third or fourth level domain
names (such as localities).
Some of the processing of the requests to the third level domain
name is now automated. In particular, most requests to register
names in localities already delegated are automatically forwarded
to the administrator for that locality.
A limit has been added to the criteria for delegating domain names
under the US Domain:
It is the intention that the delegation of third level (for
example, locality) domain names be wide spread to many
registries. It is undesirable for one person or organization
to manage a large part of the third level names in any
particular geographic or logical area.
No individual or organization shall have more than 500
delegations total in the US Domain as a whole, or more than 50
delegation in any particuilar second level (for example, a
state).
The special domains under the state codes:
The K12, CC, TEC, LIB, STATE, DST, COG and GEN domain under
each state are established for special purposes (see RFC 1480).
IMR Editor [Page 21]
Internet Monthly Report November 1996
In addition to the constaint to use them only for the defined
purpose, each of these special domains is also to delegated
only to a manager within the state, and the operation of the
delegated registry should be non-profit.
The LIB domain should be managed by a govermental or
educational library organization.
Further, it is most appropriate for the K12, CC, and TEC,
domains to be managed by an educational organization (for
example, a university or a department of education), or a state
government agency.
The STATE domain is most appropriately managed by an agency of
the state government. DST and COG should be managed by a
goverment agency.
The GEN domain may be delegated to any organization that will
provide the registration service for free (and remember the
purpose of the GEN domain is to register statewide non-profit
organizations).
To obtain a copy of the list of other delegated localities and
subdomains not administered by the US Domain Registrar, get the
file "us-domain-delegated.txt".
URL: ftp://ftp.isi.edu/in-notes/us-domain-delegated.txt
For further information about the US Domain, send a message to:
US-DOMAIN at ISI.EDU, or see our WEB page:
http://www.isi.edu/us-domain
The US Domain RWhois database now has the records of 6150 domain
names.
IMR Editor [Page 22]
Internet Monthly Report November 1996
US DOMAIN ADMINISTRATIVE INFORMATION
------------------------------------
EMAIL/FAX 5841
PHONE 450
----------------------------
Total Contacts 6291
DELEGATIONS 1301
FORWARDED DELEGATIONS: 954
OTHER US DOMAIN MSGS: 4036
---------------------------
Total 6291
OTHER US DOMAIN MESSAGES INCLUDE: referrals to other subdomains or
to/from the InterNic, phone calls, modifications, application
requests, discussion and clarification of the requests, questions
about names, resolving technical problems with zone files and name
servers, and whois listings.
Not listed below, another 1200 localities have been delegated in
Arizona, Alabama, Arkansas, California, Illinois, Pennsylvania,
Florida, Georgia, Hawii, Idaho, Iowa, Indiana, Kansas,
Massachusetts, Maryland, Missouri, Montana, Michigan, Maine,
Nebraska, New Hampshire, North Carolina, North Dakota, New Jersey,
New York, Ohio, Virginia, Vermont, Texas,Tennessee, Washington and
Wyoming this month.
MAJOR SUBDOMAINS DELEGATED
K12 CC TEC STATE LIB MUS GEN DST COG
===================================================================
51 38 34 47 39 25 25 9 5
===================================================================
-----------------------
THIRD LEVEL DELEGATIONS
-----------------------
CC.OK.US. Community Colleges, Oklahama.
MUS.LA.US. Museums, Louisiana.
GEN.WA.US. General, Washington.
IMR Editor [Page 23]
Internet Monthly Report November 1996
LOCALITIES
==========
MANCHESTER.MA.US. CRUZ-BAY.VI.US.
FRANKLIN.OH.US. MONTICELLO.IN.US.
FULTON.NY.US. LYNWOOD.CA.US.
STEVENS.WA.US. SCHOHARIE.NY.US.
OKANOGAN.WA.US. JACKSON.OH.US.
JACKSON.NJ.US. BRIDGEWATER.NJ.US.
CLAYTON.MO.US. CAVE-CREEK.AZ.US.
DULLES.VA.US. ST-THOMAS.VI.US.
ST-JOHN.VI.US. ST-CROIX.VI.US.
BEAVER-CREEK.CO.US. MOUNT-CLEMENS.MI.US.
CAMP-HILL.PA.US. DELHI-HILLS.OH.US.
PACIFIC-PALISADES.HI.US. PULASKI.AR.US.
WRIGHTSVILLE.AR.US. ORANGE.FL.US.
WOODBURY.IA.US. ANTIOCH.CA.US.
YAKIMA.WA.US. OTTAWA.IL.US.
SHELBY.KY.US. MOUNT-HOOD.OR.US.
SAINT-FRANCISVILLE.LA.US. MANCHESTER-BY-THE-SEA.MA.US.
OTHER US DOMAIN DELEGATIONS THIS MONTH
--------------------------------------
CCA.CI.COATESVILLE.PA.US. COE.WOODBINE.MD.US.
CI.BRIGANTINE.NJ.US. CI.PINE-CITY.MN.US.
SIERRAMADRE.LIB.CA.US. FD.CHARDON.OH.US.
WYSO.YELLOW-SPRINGS.OH.US. CI.HEATH.OH.US.
CO.MOORE.NC.US. CI.KEMBALL.NE.US.
SJS.HYDES.MD.US. PRUE.K12.OK.US.
PAWHUSKA.K12.OK.US. WELLSTON.K12.OK.US.
OAKS.K12.OK.US. PRETTYWATER.K12.OK.US.
DUNCAN.K12.OK.US. HOBART.K12.OK.US.
RYAL.K12.OK.US. KELLYVILLE.K12.OK.US.
MIAMI.K12.OK.US. WELEETKA.K12.OK.US.
CLEVELAND.K12.OK.US. COALGATE.K12.OK.US.
LONESTAR.K12.OK.US. CLAREMORE.K12.OK.US.
KEYSTONE.K12.OK.US. AFTON.K12.OK.US.
BLUEJACKET.K12.OK.US. CAVESPRINGS.K12.OK.US.
BARTLESVILLE.K12.OK.US. SCOFFEYVILLE.K12.OK.US.
WWW.UCVTS.TEC.NJ.US. GOTMY.BIRD-IN-HAND.PA.US.
CI.FRUITLAND.ID.US. COMMUNITY.FLOYD.VA.US.
CI.PLEASANT-HILL.MO.US. CI.TEKAMAH.NE.US.
CI.GENOA.NE.US. CI.SUTHERLAND.NE.US.
SUSSEX.TEC.NJ.US. CI.WASILLA.AK.US.
LINUX.CARRBORO.NC.US. CLUON.LAKE-SHASTA.CA.US.
ELECTION-INFO.GEN.AK.US. STJOHNCHRY.GEN.MI.US.
BABER.YARDLEY.PA.US. THERAPY.WASHINGTON.DC.US.
IMR Editor [Page 24]
Internet Monthly Report November 1996
BP.WASHINGTON.DC.US. BP.BELLE-CHASSE.LA.US.
BP.PORT-LAVACA.TX.US. BORO.DORMONT.PA.US.
CO.ESSEX.NY.US. CO.OTSEGO.NY.US.
HEALTH.CO.WYOMING.NY.US. SS-BBS.GEN.GA.US.
CI.IOLA.KS.US. CI.NEWMAN-GROVE.NE.US.
CI.RANDOLPH.NE.US. OREGON.COURT.FED.US.
SNAP.LIB.CA.US.
-----------------------------------------------------------
URL: http://www.isi.edu/us-domain/
Shanthi Ranganathan (US-Domain at ISI.EDU)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MERIT INTERNET ENGINEERING
--------------------------
This report summarizes November 1996 activities of Merit's Internet
Engineering group on behalf of the Routing Arbiter (RA) service and
other projects.
Jerry Winters, Xin Liu, and Craig Labovitz are developing a
distributed version of RAWhoisd, the RADB whois server. Known as
Trawhoisd (Trivial rawhoisd), the new server will allow users to
cache any or all of the databases in the Internet Routing Registry
on local workstations, giving users complete, local administrative
control of their own registry. The streamlined Trawhoisd code is
easy to install and run, and will be ported to a variety of
platforms. Users can select a subset of the registries to be
locally cached--only AS objects, Route objects, or Maintainer
objects, for example. This kind of flexibility brings considerable
savings in cache storage requirements--a major concern for users
maintaining their own copies of the IRR.
Trawhoisd supports data caching in two ways: by FTP and by
mirroring. When cached data is mirrored, users can choose to
update the cache every few minutes, providing near real-time
accuracy for the data. The RIPE NCC currently supports mirroring,
and Merit will soon support its own database mirroring site. This
will mean that other IRR organizations, such as MCI, CA*net, and
RIPE, can update their database copies with new RADB data as
frequently as every five minutes, rather than every 24 hours.
IMR Editor [Page 25]
Internet Monthly Report November 1996
Trawhoisd will serve compute-intensive users, such as those using
RAToolSet to generate router configurations. The requirements of
this community of users have not been well served in the past
because of RAWhoisd's performance problems. We are pleased to
report, however, that recent testing has shown Trawhoisd to be
nearly two orders of magnitude faster than RAWhoisd! This
performance speedup is realized by avoiding network delays, and by
the fact that Trawhoisd is written is C rather than Perl, in which
RAWhoisd is implemented (the database management scheme used in
Perl is extremely slow).
The current, centralized RAWhoisd server will remain available,
with the ability to answer router configuration queries and support
whois-type browsing of the IRR. A beta version of Trawhoisd will
be available soon; if you are interested in being a beta-tester,
please send e-mail to merit-ie at merit.edu. We appreciate your
contribution!
User consulting continues to be a priority for the RADB staff, with
e- mail and telephone questions ranging from queries about RIPE
syntax to requests for information about the RADB and its role in
the Internet Routing Registry. The database support team routinely
provides step-by- step instructions for registering user policy in
the RADB, writes scripts that allow users to accomplish desired
routing registry tasks, offers online tutorials on key topics such
as CIDR addressing and PGP encryption, and coordinates efforts
among providers and other registries to ensure that appropriate
policies are registered in the database. To contact the RADB
staff, send e-mail to db-admin at ra.net.
Bill Norton has been named manager of Merit's Internet Engineering
group. In this role, he oversees evolving Routing Arbiter
services, NANOG activities, and Merit's developing for-fee Route
Server operational activities. Norton also heads Merit's NetSCARF
(Network Statistics Collection And Reporting Facility) project. He
came to Merit in 1988 to join the NSFNET project staff, and became
the lead architect of network management solutions for the NSFNET
and the Routing Arbiter Project. On behalf of the Routing Arbiter,
he led the initiative to deploy the first SNMPv2 agent in a
production environment.
Additional Internet Engineering projects include the GateD
Consortium, which is led by Sue Hares, and a short-term project to
provide routing engineering consultation for the Interim Defense
Research and Engineering Network's (IDREN) new national backbone.
This effort is led by Craig Labovitz. Norton, Hares, and Labovitz
now serve as the Internet Engineering group's leadership team.
IMR Editor [Page 26]
Internet Monthly Report November 1996
Labovitz and Masaki Hirabaru attended the 7th Maryland Workshop on
Very High Speed Networks, sponsored by the Maryland Center for
Telecommunications Research and the Department of Computer Science
and Electrical Engineering at the University of Maryland Baltimore
County. The workshop brought together technical experts to discuss
progress and research issues in the design and implementation of
very high speed communication networks. In October, Sue Hares
taught sessions on host- based and backbone internetworking
technology at a NATO Advanced Networking Workshop in St.
Petersburg, Russia.
Susan R. Harris (srh at merit.edu)
UCL
----
UCL had a very interesting time running the Mbone and
SoftwareVision transmission of the IEEE Globecom Conference - we
made use of RAT and some novel tricks for linking up high bandwidth
parts of the Internet (we were transmittign over IP on SMDS, ATM
and while this was happing the London Internet exchange was
upgraded to fast ether switching, which improved connectivity
between the academic sites and the commercial ones enourmously). A
report on the Mbone event (technology and setup and debugging mbone
quality) is available from ftp://cs.ucl.ac.uk/darpa/GLOBECOM96-
mcast.ps
John Crowcroft (j.crowcroft at CS.UCL.AC.UK)
IMR Editor [Page 27]
Internet Monthly Report November 1996
CALENDAR
--------
Last update 12/5/96
The information below has been submitted to the IETF Secretariat
as a means of notifying readers of future events. Readers are
requested to send in dates of events that are appropriate for this
calendar section. Please send submissions, corrections, etc., to:
<meeting-planning at ietf.org>
Please note: The Secretariat does not maintain on-line information
for the events listed below.
A copy of this calendar is available as follows:
VIA FTP
-------
IETF Information is available by anonymous FTP from several sites.
US East Coast Address: ds.internic.net (198.49.45.10)
US West Coast Address: ftp.isi.edu (128.9.0.32)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
Africa Address: ftp.is.co.za (196.4.160.12)
cd ietf
ls *0mtg*
WWW
-------
<http://www.ietf.org/home.html> Click on the link for "meetings" and
you should find an entry "listing of other Internet related events".
************************************************************************
1996
-----------
Dec. 9-13 37th IETF (host by cisco) San Jose, CA
Dec. 9-13 OIW (Firm)
Dec. 10-12 EEMA (Electronic Communications) London
Dec. 10-13 Fall Internet World '96 New York, NY
Dec. 12 Internet Security for System
& Network Administrators Pittsburgh, PA
IMR Editor [Page 28]
Internet Monthly Report November 1996
Dec. 13 Commercenet Albuquerque, NM
Dec. 17 TERENA Executive Committee Amsterdam
1997
-----------
Jan. 6-10 ANSI X3T10 '97
Jan. 6-10 USENIX '97
Annual Technical Conf. Anaheim, CA
Jan. 6-10 USELINUX: Linux Appl. Dev. Anaheim, CA
Jan. 7-10 13th Annual Hawaii Int'l Conf
on Systems Sciences Maui, Hawaii
Jan. 7-10 Internet World Canada '97 Toronto, Canada
Jan. 20-22 RIPE 26 Amsterdam
Jan. 21-23 Internet World Shanghai-China Shanghai, China
Jan. 21-25 Internet World Singapore Intl Singapore
Jan. 22 TERENA Tech. Committee Amsterdam
Jan. 28-30 IEEE 802.10 Interim meeting Orlando, FL
Jan. 28-31 RSA Data Security Conf San Francisco
Feb. 3-7 ANSI X3T11 (host by Sun) San Jose, CA
Feb. 9-14 ATM Forum San Diego, CA
Feb. 10-11 ISOC Symposium on Network and
Distributed System Security San Diego, CA
Feb. 10-12 Multimedia Computing & Networking 1997
San Jose, CA
Feb. 17-19 Internet Expo & EMail World San Jose, CA
Feb. 24-26 2nd Annual VRML '97 Monterey, CA
Mar. 1-5 ACM '97: The Next 50 yrs. of Computing
San Jose, CA
Mar. 10-11 10th Int'l Unicode Conf &
Global Computing Showcase Mainz, Germany
Mar. 10-13 UniForum San Francisco, CA
Mar. 10-14 OIW (Firm)
Mar. 10-14 IEEE 802 '97 Irvine?/Albuguerque
Mar. 11-14 Spring Internet World '97 Los Angeles, CA
Mar. 11-15 ANSI X3T10 '97
Mar. 17-19 1st Euromicro Working Conf. on
Software Maintenance & Reengineering
Berlin, Germany
Mar. 19-21 Internet World Asia '97 Kuala Lumpur, Malaysia
Mar. 24-27 APPN Implementers Workshop Raleigh, NC
Apr. 2-3 Europia '97 Edinburgh, Scotland
Apr. 7-10 EMA'97 Philadelphia, PA
Apr. 7-11 38th IETF (host by Fed. Exp) Memphis, TN
Apr. 7-11 ANSI X3T11 (Brocade) Palm Springs, CA
Apr. 7-11 IEEE INFOCOM '97 Kobe, Japan
Apr. 7-12 W3C "Accessibility" 6th Int'l
WWW Conference Santa Clara, CA
IMR Editor [Page 29]
Internet Monthly Report November 1996
Apr. 9-11 ISADS 97 - 3rd Intl Symposium on
Autonmous Decentralized Sys. Berlin, Germany
Apr. 22-24 Internet Expo & EMail World Chicago, IL
Apr. 27-May 2 ATM Forum Chicago, IL
May 5-9 ANSI X3T10 '97
May 5-9 NATO Workshop Edinburgh, Scotland
May 12-15 8th JENC8 Edinburgh, Scotland
May 12-16 IFIP/IEEE San Diego, CA
May 15-16 TERENA General Assembly Edinburgh, Scotland
May 19-21 7th Int'l Workshop on Ntwk & Oper
for Digital Audio & Video St. Louis, MO
May 21-23 RIPE 27 Dublin
May 27-29 IS&N '97 4th Int'l Conf. on
Intelligence in Services & Networks Como, Italy
May 28-30 Web Developer '97 Chicago, IL
Jun. 2-6 IEEE Multimedia Systems '97 Ottawa, CANADA
Jun. 3-5 Internet World Mexico '97 Mexico City, Mexico
Jun. 8-12 ICC '97 (joint with ENM) Montreal, CANADA
Jun. 9-13 OIW (Firm)
Jun. 9-13 ANSI X3T11 (host by Boeing) Seattle, WA
Jun. 16-18 EEMA'97 Netherlands
Jun. 24-27 INET '97 Kuala Lumpur, Malaysia
Jul. 7-11 IEEE 802 '97 Hyatt Regency Maui, Lahaina HI
Jul. 14-18 ANSI X3T10 '97
Jul. 14-17 APPN Implementers Workshop San Jose, CA
Jul. 20-25 ATM Forum Montreal, CANADA
Jul. 24-25 DMS '97 Vancouver, CANADA
Aug. 4-8 ANSI X3T11 (host by Hitachi) Honolulu, HI
Aug. 11-15 39th IETF (host by German ISOC) Munich, Germany
Aug. 12-14 (tenative) Internet Expo & EMail World Boston, MA
Sep. 8-12 ANSI X3T10 '97
Sep. 8-12 OIW (Firm)
Sep. 8-14 TELECOM Interactive 97 Geneva, Switzerland
Sep. 10-12 IDMS '97 w/ ACM SIGMM, GMD, IEEE
Darmstadt, Germany
Sep. 14-18 ACM SIGCOMM '97 Cannes, French Riviera, France
Sep. 21-26 ATM Forum Paris, France
Oct. 6-10 ANSI X3T11 (host by FSI) Tucson, AZ
Oct. 7-10 COMDEX Internet '97 and Object World '97
Internet Forum Europe (IFE) & Object
World Frankfurt (OWF) Frankfurt, Germany
Nov. 3-7 ANSI X3T10 '97
Nov. 30-Dec 5 ATM Forum Singapore
Dec. 1-5 ANSI X3T11 (host by DPT) Orlando, FL
Dec. 8-12 40th IETF (tentative) Univ. of Hawaii
Dec. 8-12 OIW (Firm)
TELECOM '97 Asia (Venue and Dates to be Determined)
IMR Editor [Page 30]
Internet Monthly Report November 1996
1998
-----------
Feb. 8-13 ATM Forum TBA
Apr. 19-24 ATM Forum TBA
SPRING 1998 TELECOM '97 Africa Midrand, South Africa
Jul. 26-31 ATM Forum TBA
Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and
Budapest, Hungary
Oct. 4-9 ATM Forum TBA
Dec. 6-11 ATM Forum TBA
1999
-----
Oct. 8-14 TELECOM '99 Geneva, Switzerland
IMR Editor [Page 31]
Internet Monthly Report November 1996
TERENA CALENDAR
updated 5 December 1996
This list of meetings is provided for information. Many of the
meetings are closed or by invitation; if in doubt, please contact the
chair of the meeting or the TERENA Secretariat. If you have
additions/corrections/comments, please mail <secretariat at terena.nl>.
**********************************************************************
NAME / DATE LOCATION
TERENA General Assembly
GA7
15-16 May 1997 Edinburgh
TERENA Executive Committee
17 December Amsterdam
TERENA Technical Committee
22 January 1997 (tbd) Amsterdam
JENC8
Programme Committee
4 December Amsterdam
12 February 1997 Amsterdam
Conference Committee
17 January 1997 Amsterdam
TF-CACHE
--------
23 January 1997 Amsterdam
EEMA
----
Spring Conference and Exhibition
25-26 February 1997 Berlin
IMR Editor [Page 32]
Internet Monthly Report November 1996
ENPG
----
9-10 January 1997 Amsterdam
ETSI
----
GA24 10-11 December Nice, France
TA25 23-25 October "
EWOS
----
EWOS Assembly 1, 3-4 December Brussels
EWOS Assembly 2, 25-26 February 1997 "
EWOS Assembly 3, 13-14 May 1997 "
EWOS Assembly 4, 16-17 September 1997 "
EWOS Assembly 5, 2-3 December 1997 "
Workshops
36: 20-24 January 1997 Brussels
37: 7-11 April 1997 "
38: 16-20 June 1997 "
39: 27-31 October 1997 "
ICT Partnership - General Meeting
---------------------------------
29 January 1997 (tbc) Brussels
IETF
----
37, 9-13 December San Jose, CA
38, 7-11 April 1997 Memphis, Tenn.
39, 11-15 August 1997 Munich, Germany
ISOC
----
Symposium
10-11 February 1997 San Diego, CA
NATO
----
Workshop
5-9 May 1997 Edinburgh
IMR Editor [Page 33]
Internet Monthly Report November 1996
RIPE
----
RIPE 26
20-22 January 1997 Amsterdam
RIPE27
21-23 May 1997 Dublin
RIPE IR Training
11 November Berlin
12 November "
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TERENA CONFERENCES
JENC8 - 8th Joint European Networking Conference
"Diversity and Integration: The New European Networking Landscape"
12-15 May 1997
Edinburgh, Scotland
This conference will be the European Forum to get up-to-date
information, to debate and assess the new deregulated tele-communication
environment in Europe, new leading-edge applications, and the
network/internetwork support infrastructure which is currently being
developed
Subject Areas:
* Emerging Network Technologies and Network Engineering
* User Support, Training and Education
* Security and Management Issues
* Information Systems and Distributed Applications
* Economic and Political Issues
IMR Editor [Page 34]
Internet Monthly Report November 1996
For information please contact the JENC8 Secretariat at:
TERENA Secretariat
Singel 466-468
1017 AW Amsterdam, The Netherlands
tel: +31 20 6391131 fax: +31 20 6393289
email: <jenc8-sec at terena.nl>
http://www.terena.nl/jenc8
or
JENC8 Local Organization
c/o Concorde Services Ltd
Unit 5, SECC
Glasgow, G3 8YW, Scotland
email: <jenc8 at ed.ac.uk>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
OTHER CONFERENCES
ASIAN'96 - Asian Computing Science Conference
------------------------------------------------------------
2-5 December
Singapore
Themes of this conference is:
- Programming (sematics, languages, systems, ...)
- Concurrency & Parallelism (algorithms, formalisms, systems ...)
- Networking & Security (algorithms, protocols, formalisms, ...)
Additional information available from:
http://www.escs.nus.sg/~asian96
IMR Editor [Page 35]
Internet Monthly Report November 1996
COREC - "Interregional Cooperation in RTD - Challenges and
Opportunities for Regions in Economic Conversion"
----------------------------------------------------------=
16-17 December
Bremen, Germany
This conference is about "Interregional Cooperation in Research and
Technological Development and its Impact on Regional Economies".
Background is the experience of the community initiative STRIDE and
other programmes of the European Commission.
Agenda is available on the Internet under: http://www.bremen.de
Any further information may be obtained from:
Mr. Wolfgang Petzold <wmte at uni-bremen.de>
Senator fur Wirtschaft, Mittelstand, Technologie und
Europeangelegenheiten
Internet Society's 5th Annual Symposium on Network and
Distributed System Security
------------------------------------------------------
10-11 February 1997
San Diego, California, USA
The symposium is intended for people interested in the practical
aspects of network and distributed system security. It focuses on
actual system design and implementation, rather than theory.
For information, see ISOC web page:
http://info.isoc.org/conferences/
Multimedia Computing and Networking 1997
----------------------------------------
10-12 February 1997
San Jose, CA, USA
The object of this conference is to bring together researchers,
developers, and practitioners working in all facets of multimedia
computing and networking.
Paper submission by 16 July 1996.
For further information email <mmcn at cs.utexas.edu>
IEEE INFOCOM '97
16th Annual Joint Conference of the IEEE Computer &
Communications Societies
----------------------------------------------------
7-11 April 1997
Kobe, Japan
Paper submissions by 14 June 1997.
=46or further information contact
http://www.ics.uci.edu/~infocom/
http:// arpeggio.ics.es.osaka-u.ac.jp/infocom.html
IMR Editor [Page 36]
Internet Monthly Report November 1996
ISADS 97
3rd International Symposium on Autonomous Decentralized Systems
---------------------------------------------------------------
9-11 April 1997
Berlin, Germany
Supported by Hitachi, DeTeBerkom, NEC, Digital, GMD-FOCUS,
Hewlett Packard, IBM.
The focus will be on advancements and innovations in ADS platforms and
applications. Integration of telecommunication and computing aspects
into a uniform concept for providing an open distributed processing
environment.
For information see WWW: http://www.fokus.gmd.de/ws/isads97/
IS&N '97
4th International Conference on Intelligence in Services & Networks
-------------------------------------------------------------------
27-29 May 1997
Como, Italy
Title: "Technology for Co-operative Competition". The conference will
provide a forum for the discussion of issues and the exchange of
outstanding technical results related to the engineering of advanced
communication services and experiments on their use. Sponsored by the
European Commission and Italtel, and supported by ACTS projects in
IS&N domain.
Further information is available on WWW:
http://www.uni-stuttgart.de/SONAH/Acts/domain5
ECOOP'97
11th European Conference on Object-Oriented Programming
-------------------------------------------------------
9-13 June 1997
University of Jyv=E4skyl=E4, Jyv=E4skyl=E4, Finland
=46or information see www page:
http://www.trese.cs.utwente.nl/ecoop97 or
http://www.ecoop97.jyu.fi
IMR Editor [Page 37]
Internet Monthly Report November 1996
EEMA'97
Electronic Commerce and Messaging in Europe'
"The Premier European Forum for Advanced Business"
-------------------------------------------------
16-18 June 1997
Maastricht Exhibition and Congress Centre, Maastricht, Netherlands
Issues of the conference will be:
Global Security; Corporate Directories; Messaging Products & Services;
Electronic Commerce; Global Messaging Enterprise; European
Initiatives; Mobile Messaging Technology; Messaging Technology &
Management Strategy; Intranet; World Wide Web & Infobots.
For information contact WWW: http://www.eema.org/
INET'97 - Workshop
------------------
15-21 June 1997
Kuala Lumpur, Malaysia
Focus of the workshop will be upon assisting countries that are either
not yet connected to the Internet or are in the process of developing
and enhancing an initial national Internet.
For copy of announcement e-mail <workshop-apply at isoc.org>
Apply for admission by 7 February 1997 to e-mail
<workshop-application at isoc.org>
INET'97
7th Annual Internet Society Conference
---------------------------------------
24-27 June 1997
Kuala Lumpur, Malaysia
The conference will address the traditional and evolving frontiers of
the Internet as well as its significant impact on education, commerce
and societies throughout the world.
-information on INET97, the K-12 workshop, the Tutorials, and the
associated Developing Countries Workshop, along with an abstract
submission form, can be found on the ISOC web page:
http://isoc.org/inet or, for information via e-mail:
- for details of submission procedure email
<inet-program-interest at isoc.org>
- for other information email <inet97 at isoc.org>
IMR Editor [Page 38]
Internet Monthly Report November 1996
FMOODS'97 - Second IFIP Interrnational Workshop on
Formal Methods for Open-based Distributed Systems
---------------------------------------------------
21-23 July 1997
Canterbury, United Kingdom
Objective is to provide an integrated forum for the presentation of
research in several related fields. Paper submission deadline 14
January 1997
For all information: e-mail <fmoods97-request at uck.ac.uk> or
web page: http://alethea.u,c.ac.uk/Dept/Computing/Research/NDS/FMOODS/
IDMS'97
European Workshop on Interactive Distributed Multimedia
Systems and Telecommunication Services
--------------------------------------------------------
10-12 September 1997
Darmstadt, Germany
In cooperation with ACM SIGM, Gesellschaft fuer Informatik, GMD, IEEE
Computer Society and VDE ITG
The purpose of this 4th workshop is to provide a forum for the
presentation, exploration and discussion of technologies and their
advancements in the broad field of interactive distributed multimedia
systems.
Paper submission due 1 March 1997
For additional information se www: http://www.th-darmstadt.de/idms97
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
IMR Editor [Page 39]
Received: from cnri by ietf.org id aa05130; 20 Dec 96 6:15 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07082;
20 Dec 96 6:15 EST
Received: by pad-thai.cam.ov.com (8.8.4/)
id <IAA01391 at pad-thai.cam.ov.com>; Fri, 20 Dec 1996 08:43:09 GMT
Message-Id: <32BAD038.20C9 at frcl.bull.fr>
Date: Fri, 20 Dec 1996 09:43:20 -0800
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.0 (Win16; I)
Mime-Version: 1.0
To: CAT-IETF WG <cat-ietf at mit.edu>
Subject: URLs on SESAME
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
During the last CAT session , I mentionned that the reading of the
GSS-API
SESAME mechanism < draft-ietf-cat-sesamemech-01.txt > would be much
easier
if the overview is read before. Here is the URL pointing to the SESAME
V4
Overview :
http://www.esat.kuleuven.ac.be/cosic/sesame/doc-txt/overview.txt
If you can handle postcript and Unix uncompression, you may also try:
http://www.esat.kuleuven.ac.be/cosic/sesame/doc-ps.html
In this way you will get the pictures.
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa05864; 20 Dec 96 7:14 EST
Received: from mvs.oac.ucla.edu by ietf.org id aa05610; 20 Dec 96 7:04 EST
Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1)
with BSMTP id 6944; Fri, 20 Dec 96 04:02:07 PST
Date: Fri, 20 Dec 96 04:01 PST
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Denis DeLaRoca <CSP1DWD at mvs.oac.ucla.edu>
Subject: San Jose IETF Mbone Recordings ???
Message-ID: <9612200704.aa05610 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
Were any of the San Jose IETF Mbone broadcasts saved (as RTP files)
anywhere?
-- Denis
Received: from cnri by ietf.org id aa06956; 20 Dec 96 7:52 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08538;
20 Dec 96 7:52 EST
Received: by pad-thai.cam.ov.com (8.8.4/)
id <KAA03969 at pad-thai.cam.ov.com>; Fri, 20 Dec 1996 10:58:14 GMT
From: Jacques Lebastard <J.Lebastard at frcl.bull.fr>
Message-Id: <9612201054.AA20396 at ronde.frcl.bull.fr>
Subject: Re: URLs on SESAME
To: cat-ietf at mit.edu
Date: Fri, 20 Dec 1996 11:54:47 +0100 (MET)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Precedence: bulk
Denis,
> If you can handle postcript and Unix uncompression, you may also try:
> http://www.esat.kuleuven.ac.be/cosic/sesame/doc-ps.html
The SESAME Web server at K.U.Leuven has been modified yesterday
to allow PC users (provided they have WinZip or similar compression
software available) to uncompress the PostScript documents.
Jacques.
--
Jacques LEBASTARD mailto:J.Lebastard at frcl.bull.fr
BULL SA - ISM AccessMaster http://www-ism.bull.com/ism/
Rue Jean Jaures - A5/146 Tel: +33 (0)1 30 80 77 86
F-78340 Les Clayes sous Bois Fax: +33 (0)1 30 80 77 99
Received: from cnri by ietf.org id aa08298; 20 Dec 96 8:47 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa09488;
20 Dec 96 8:47 EST
Received: (from daemon at localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA21313 for uri-out; Fri, 20 Dec 1996 08:14:48 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA21297; Fri, 20 Dec 1996 08:14:30 -0500
Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA18882 (mail destined for uri at services.bunyip.com); Fri, 20 Dec 96 08:13:52 -0500
Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP)
id <06235-0 at josef.ifi.unizh.ch>; Fri, 20 Dec 1996 14:13:27 +0100
Date: Fri, 20 Dec 1996 14:13:25 +0100 (MET)
From: "Martin J. Duerst" <mduerst at ifi.unizh.ch>
To: Towsner <tows at earthlink.net>
Cc: Larry Masinter <masinter at parc.xerox.com>, leslie at bunyip.com,
tme at casa.usno.navy.mil, urn-ietf at bunyip.com, jcurran at bbn.com,
uri at bunyip.com
Subject: Re: [URN] Checksums in URNs
In-Reply-To: <l03010d02aedf9ebe6b3c at [153.35.78.27]>
Message-Id: <Pine.SUN.3.95.961220140805.245D-100000 at enoshima>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: owner-uri at bunyip.com
Precedence: bulk
On Thu, 19 Dec 1996, Towsner wrote:
> >Checksums and other kinds of decorations can be done outside the
> >URL. Think of it as a metascheme:
> > ck:<checksum><url>
> > e.g. ck:A3Bd:http://www.parc.xerox.com/masinter
>=20
> =09I like the idea of having the checksum be optional, as a
> meta-scheme.
Same for me.
>I also think the checksum should be limited to alpha-numeric
> characters, to avoid confusion.
What do you mean by "limited to alpha-numeric characters"? Can you be
more precise.
>Perhaps this should be part of the URL
> scheme as well.
If it is a metascheme, then it is a new URI scheme. It doesn't
have to be discussed either in URL nor in URN syntax. It would
go into a separate draft. It has to make sure, on its own,
that it is compatible with the URL/URN syntax.
Perhaps the URL syntax draft, where it speaks about URIs,
could be generalized in the direction of metaschemes.
From=20the syntax viewpoint, we already have two metaschemes
(urn: and ck:), which can even be combined together,
as ck:urn:namespace:NSS.
Regards,=09Martin.
Received: from ietf.org by ietf.org id aa09550; 20 Dec 96 9:32 EST
Received: from privateer.windrose.omaha.ne.us by ietf.org id aa09258;
20 Dec 96 9:25 EST
Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 08:21 CST 1996
X-Orig-Sender: jayhawk at ietf.org
Message-ID: <32BAA0F7.22B9 at ds.internic.net>
Date: Fri, 20 Dec 1996 08:21:43 -0600
Sender:ietf-request at ietf.org
From: Ryan Moats <jayhawk at ds.internic.net>
Organization: InterNIC Directory and Database Services
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c)
MIME-Version: 1.0
To: CSP1DWD at mvs.oac.ucla.edu
CC: ietf at ietf.org
Subject: Re: San Jose IETF Mbone Recordings ???
References: <9612200704.aa05610 at ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
>
> Were any of the San Jose IETF Mbone broadcasts saved (as RTP files)
> anywhere?
>
> -- Denis
Yes.
They are located at the following URL:
ftp://ds.internic.net/pub/current-ietf-mbone
(Sorted by day).
We at the InterNIC Directory and Database Services are also working
on translating these recordings into RealAudio to be available from
our Web Server....
Ryan Moats
InterNIC Directory and Database Services
Received: from ietf.org by ietf.org id aa10927; 20 Dec 96 10:05 EST
Received: from cnri by ietf.org id aa10784; 20 Dec 96 10:02 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa11114;
20 Dec 96 10:01 EST
Received: from video.ecn.purdue.edu by venera.isi.edu (5.65c/5.61+local-25)
id <AA24123>; Fri, 20 Dec 1996 07:00:17 -0800
Received: from video.ecn.purdue.edu (ghafoor at localhost)
by video.ecn.purdue.edu (8.8.4/3.8.2moyman)
id JAA16545; Fri, 20 Dec 1996 09:53:43 -0500 (EST)
Message-Id: <199612201453.JAA16545 at video.ecn.purdue.edu>
Date: Fri, 20 Dec 1996 09:53:43 -0500 (EST)
Sender:ietf-request at ietf.org
From: Arif Ghafoor <ghafoor at ecn.purdue.edu>
To: cellular at dfv.rwth-aachen.de, perform at tay1.dec.com, tccc at cs.umass.edu
Cc: announcements.chi at xerox.com, arl at arl.wustl.edu, atm at bbn.com,
ccrc at dworkin.wustl.edu, cip at bbn.com, cnom at maestro.bellcore.com,
end2end-interest at isi.edu, enternet-ec at bbn.com, enternet at bbn.com,
f-troup at aurora.cis.upenn.edu, ietf at isi.edu, rem-conf at es.net
Subject: Call for paper on multimedia for IEEE COMPSAC97
Source-Info: From (or Sender) name not authenticated.
IEEE 25-th Annual International Computer Software and Application Conference (COMPSAC97)
will be held in Washington D.C. (August 13 - 15, 1997)
Papers on various topics, including multimedia, can be submitted.
The detailed Call for Papers can be found at the following web site:
http://www.cs.umn.edu/~tsai/compsac/compsac.html
The deadline for the paper and panel proposal submission is January 15, 1997.
Received: from cnri by ietf.org id aa10972; 20 Dec 96 10:06 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa11218;
20 Dec 96 10:06 EST
Received: (from daemon at localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA22308 for uri-out; Fri, 20 Dec 1996 09:34:56 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA22301; Fri, 20 Dec 1996 09:34:23 -0500
Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA19208 (mail destined for urn-ietf at services.bunyip.com); Fri, 20 Dec 96 09:34:20 -0500
Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 08:32 CST 1996
Message-Id: <32BAA368.4FD2 at ds.internic.net>
Date: Fri, 20 Dec 1996 08:32:08 -0600
From: Ryan Moats <jayhawk at ds.internic.net>
Organization: InterNIC Directory and Database Services
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c)
Mime-Version: 1.0
To: "Martin J. Duerst" <mduerst at ifi.unizh.ch>
Cc: Towsner <tows at earthlink.net>, Larry Masinter <masinter at parc.xerox.com>,
leslie at bunyip.com, tme at casa.usno.navy.mil, urn-ietf at bunyip.com,
jcurran at bbn.com, uri at bunyip.com
Subject: Re: [URN] Checksums in URNs
References: <Pine.SUN.3.95.961220140805.245D-100000 at enoshima>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-uri at bunyip.com
Precedence: bulk
My turn to add my two cents worth...
Martin J. Duerst wrote:
>
> On Thu, 19 Dec 1996, Towsner wrote:
>
> > >Checksums and other kinds of decorations can be done outside the
> > >URL. Think of it as a metascheme:
> > > ck:<checksum><url>
> > > e.g. ck:A3Bd:http://www.parc.xerox.com/masinter
> >
> > I like the idea of having the checksum be optional, as a
> > meta-scheme.
>
> Same for me.
I'll make three...
> >I also think the checksum should be limited to alpha-numeric
> > characters, to avoid confusion.
>
> What do you mean by "limited to alpha-numeric characters"? Can you be
> more precise.
How about just hex characters to keep it simple...
> >Perhaps this should be part of the URL
> > scheme as well.
>
> If it is a metascheme, then it is a new URI scheme. It doesn't
> have to be discussed either in URL nor in URN syntax. It would
> go into a separate draft. It has to make sure, on its own,
> that it is compatible with the URL/URN syntax.
I agree with Martin, and if we use ck:<hex sequence> then we
are already compatible with the URL/URN character sets. How to
generate the hex sequence is another headache altogether...
> Perhaps the URL syntax draft, where it speaks about URIs,
> could be generalized in the direction of metaschemes.
> From the syntax viewpoint, we already have two metaschemes
> (urn: and ck:), which can even be combined together,
> as ck:urn:namespace:NSS.
Martin is correct here as well.
Ryan
Received: from ietf.org by ietf.org id aa15304; 20 Dec 96 11:57 EST
Received: from cnri by ietf.org id aa15134; 20 Dec 96 11:52 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14015;
20 Dec 96 11:52 EST
Received: from INFO-SERVER.BBN.COM by venera.isi.edu (5.65c/5.61+local-25)
id <AA27524>; Fri, 20 Dec 1996 08:50:35 -0800
Received: (daemon at localhost) by info-server.bbn.com (8.6.9/8.6.5) id LAA10225; Fri, 20 Dec 1996 11:43:22 -0500
Received: from USENET by info-server.bbn.com with netnews
for usenet at isi.edu (ietf at isi.edu);
contact usenet at info-server.bbn.com if you have questions.
To: ietf at isi.edu
Date: 19 Dec 96 13:19:29 GMT
Message-Id: <01b9b8a5$41643480$38a71dcb at default>
Organization: - BMTD -
Sender:ietf-request at ietf.org
From: news.bbnplanet.com!cam-news-hub1.bbnplanet.com!www.nntp.primenet.com!nntp.primenet.com!visi.com!news.maxwell.syr.edu!pumpkin.pangea.ca!news.mira.net.au!vic.news. at cam-news-feed5.bbnplanet.com
X-Orig-Sender: ietf-request at isi.edu
Subject: Free homepage and email !
Source-Info: From (or Sender) name not authenticated.
--
Christmas gift !!
Free homepage and Email account ! ( 30 days )
* www.world-business-center.com / YOUR_NAME $4.95 per month
* your own domain name: www.YOUR_NAME.com $30 per month
* unlimited data transfer !
* Email accounts
* SSL Encryption
* high speed
* more and more
Unbeatable service and price
Please visit our site: http://www.world-business-center.com
Received: from cnri by ietf.org id aa15700; 20 Dec 96 12:04 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14355;
20 Dec 96 12:04 EST
Received: by pad-thai.cam.ov.com (8.8.4/)
id <OAA12016 at pad-thai.cam.ov.com>; Fri, 20 Dec 1996 14:40:09 GMT
Message-Id: <199612201439.JAA19951 at gza-client1.cam.ov.com>
To: minutes at ietf.org
Cc: linn at cam.ov.com, cat-ietf at mit.edu
Subject: Minutes from San Jose CAT-WG meeting
Date: Fri, 20 Dec 1996 09:39:55 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
[Note to WG members: some points have been added here relative to the
draft version which I sent to the list on Tuesday, reflecting comments
and notes received from attendees.]
CAT WG MINUTES, 1996 SAN JOSE IETF
Reported by John Linn (OpenVision).
GENERAL SUMMARY
The Common Authentication Technology (CAT) WG met for two sessions at
the 1996 San Jose IETF. The primary topic of the first session was
resolution of outstanding issues affecting the GSS-V2 C bindings
document. Almost all issues were resolved. Following on-list
confirmation of one working position reached at the meeting, we
anticipate that one further revised I-D will be produced and targeted
for WG Last Call. Specific points and corrections to be made to the
high-level GSS-V2 document will be captured in an errata document, to be
reflected when that document is proposed for advancement to Draft. The
Simple Negotiation (SNEGO) document was also discussed, and an
alternative approach in which the negotiation is protected against
active attack was requested and development of a proposal was
volunteered; further consideration of SNEGO's standards advancement was
deferred until February 1997, anticipating that SNEGO and the alternate
proposal will be compared at that time.
The recently-updated FTP security I-D will be placed into WG Last Call
for advancement to Proposed Standard following the meeting.
Presentations were received on the new Kerberos pk-cross I-D, new key
derivation I-D's, and the recently-updated Kerberos pk-init, SESAME
mechanism, and gss-idup I-Ds, engendering several active discussions.
Revisions for pk-init, pk-cross, gss-idup, and key derivation I-Ds are
planned in response to comments. An update to RFC-1510 is anticipated by
15 January 1997, and its planned content areas were summarized. Although
not official CAT WG work items, brief status talks were also received on
SASL and Ident extensions.
GSS-V2 C BINDINGS
Following agenda review, most of the first session was devoted to
discussion of the GSS-V2 C bindings document. The discussion was led
by John Wray (Digital), the document's editor, who summarized known
issues and then revisited those requiring further discussion. The
most contentious topic was memory allocation of OIDs (the
"GSS_Release_OID" issue).
Working rules of engagement were noted for resolution of GSS C
bindings issues. Desirably, approaches which do not impact the
high-level specification are to be preferred. Any changes needed to
the high-level specification will be recorded in a working errata
document, and reflected into the specification at its next standards
action (i.e., when advancement to Draft Standard is contemplated). It
was observed in discussion that most such changes encountered were
clarifications applicable to "corner cases", not inconsistent with the
high-level specification's current status as soon-to-be Proposed
Standard.
The following point was noted in opening discussion of the C bindings
document: the current C bindings draft states that credential elements
cannot be added to the default credential (gss_add_cred() description
discusses behavior in this case); this needs to be flagged in errata
for the high-level specification. Following is a list of further
issues discussed. No new issues were opened at the meeting beyond
those which are enumerated here and which had previously been opened
by E-mail.
#1: A tightened description had been requested about the behavior of
gss_import_name() with GSS_C_NULL_OID as input. Ted Ts'o had noted a
presumption that use of the host-based service name form would result
but John Wray disagreed, stating that this behavior shouldn't be
constrained and that a local GSS implementation should be free to
interpret a default name type based on local information. Marc
Horowitz stated that host-based service is the common case, but that
this won't necessarily hold universally. Bill Sommerfeld noted that
different existing implementations behave differently (e.g., observed
in DCE experience).
The following possibilities exist: Prohibit, define strictly, leave as
a local matter (making clear that different mechanisms and different
instances of the same mechanism may interpret differently). Our
working agreement (impacting both C bindings and high-level
specifications) is as follows: State that GSS-V2 mechanism specs shall
define the behavior of the GSS_C_NULL_OID type for their mechanisms;
these may, and likely will, be partly and algorithmically dependent on
local information.
#2: Changes as summarized on the mailing list re
gss_inquire_mechs_for_name() and nametype OIDs have been incorporated.
#3: A contentious issue, impacting both C bindings and high-level
specifications, concerns treatment of OID management routines and
memory allocation issues. Extensive follow-up E-mail discussion had
ensued, including suggestions to eliminate dynamic OIDs and various
calls. The basic question is: which OIDs and OID sets must callers
release? Ted Ts'o related history: many GSS-V1 calls return OIDs,
which are static. In the GSS-V1 spec, no routines returned dynamic
OIDs, though dynamic OID sets were returned. GSS-V2 added new
convenience routines which returned dynamic OIDs, introducing the
possibility that both types of OIDs could exist. By implication,
either the caller application or the GSS_Release_OID implementation
needs to be able to distinguish one type of OID from the other. This
is difficult in multi-mechanism implementations since the glue layer
can't tell about the static OIDs within individual mechanisms. If the
new convenience functions were to be removed, these issues would
become moot.
A slide was presented summarizing the three proposals which had been
presented by E-mail before the meeting:
#3-1. Delete gss_release_oid(), specify that all OID sets (but not
OIDs) returned by GSS calls must be released, replace gss_str_to_oid()
with gss_add_oid_set_member_str(). (Withdrawn in favor of #3-3.)
#3-2. Redefine OID and OID set structures, state that all GSS-returned
OIDs and OID sets must be released, make return of all OIDs and OID
sets optional to callers. (Rejected for lack of backwards
compatibility with GSS-V1.).
#3-3. Remove gss_str_to_oid(), gss_oid_to_str(), and gss_release_oid()
from specifications. (Dennis Glatting (CyberSAFE) had commented on
the mailing list that he'd seen value in the routines which this
proposal would remove; Ted Ts'o indicated skepticism as to these
routines' value but recognizes the argument and suggested that these
routines be moved into a new, separate mechanism-independent
convenience function document.)
Several additional proposals emerged during meeting discussion:
#3-4. Ted Ts'o introduced this proposal: retain dynamic OIDs, and make
applications responsible for knowing which OIDs to release as a
function of which routine they came from (or, per Bob Blakley (IBM),
based on different types).
#3-5. John Wray noted that the current spec (given specified
constraints) could be implemented as is.
#3-6. Define new "dynamic OID" types for these routines.
#3-7. Cache results of gss_str_to_oid().
A straw poll was taken of attendees to determine which of these
approaches they would consider tolerable: #3-1 (withdrawn); #3-2: 5,
#3-3: 10, #3-4: 9, #3-5: 1; #3-6: 9; #3-7: 1. Based on this sampling,
it appeared that approaches #3-3, #3-4, and #3-6 were preferred, but
the latter two were new and therefore had not been previously reviewed
for broader implications. It was noted that adoption of #3-3 could
cleanly be accompanied by separate libraries (outside GSS-API) which
would provide these functions using their own allocation conventions;
in particular, it was considered desirable and possible that such
libraries could be made generally available by MIT. No attendees
indicated strong opposition to #3-3; the working position from meeting
discussion was to adopt this approach, but confirmation on the mailing
list is required.
#4: New text has been added about behavior re empty strings, and empty
OIDs.
#5: New text has been added on gss_acquire_cred and gss_add_cred
behavior.
#6: Clarification had been requested re empty tokens and on the
circumstances under which tokens may be returned. This has been
handled in the C bindings draft and is an issue for the high-level
specification errata.
#7: New text has been added concerning the modifiability of the
default credential.
#8: Clarifications had been requested about which GSS-returned objects
must be released by a caller, and under what circumstances. Some text
has been added to the bindings draft on this topic; further treatment
will be required to respond to the resolution of issue #3 above.
#9: A facility had been requested which, subsequent to context
establishment, could obtain any incoming delegated credential. This
is particularly applicable to callers of gss_import_sec_context(),
which otherwise have no means within GSS-API to obtain delegated
credentials. It was accepted in discussion that this should be
considered as a "2.1" issue (for both high-level and C bindings
specifications), to be supplied as a separate function, and that it
should not hold up V2 progression, and that a
"get_delegated_cred_from_context()" approach would be used rather than
a more generalized credential transfer facility which could open
broader policy issues.
#10: An explicit statement had been requested (for inclusion within
the high-level specification) that "release" routines can be omitted
in environments where they are not required. Bill Sommerfeld and
others noted in discussion that, even in garbage-collected
environments, an explicit release routine might be desired in order to
ensure that possibly-sensitive data is flushed. Bob Blakley
considered such data flushing to be, instead, something which should
be handled within the mechanism. Bill Sommerfeld agreed to propose
brief draft text on these issues for inclusion in the high-level
specification errata.
#11: Constraints had been requested on GSS_S_BAD_NAMETYPE returns from
name-related routines including gss_display_name() and
gss_compare_name(). These have been accepted and reflected in the C
bindings draft; the high-level specification needs to be aligned.
#12: This issue concerned use of the "const" keyword, usage of which
is new as of the GSS-V2 C bindings. John Wray observed that this
document specifies ANSI C bindings, and that use of const is therefore
appropriate. Bill Sommerfeld commented that const poisoning can have
pervasive impact within implementations; Ted Ts'o had removed "const"
from the MIT Kerberos implementation after errors were encountered.
Given, however, the fact that the current bindings specification
applies "const" to input pointers only, there was apparent agreement
that its current usage shouldn't cause major problems. Possible
follow-up list discussion may take place re the separate question of
future use of "const" on outputs.
#13: Changes to gss_release_buffer() text in current C bindings draft,
made in response to comments, were agreed to be sufficient.
#14: This issue concerned the behavior of gss_release_cred(), in
particular the effect of releasing the default credential. The C
bindings prohibit releasing, while the current high-level
specification allows this case; the working proposal is to align the
high-level specification to match the C bindings.
#15: Deprecation of CREDENTIALS_EXPIRED returns from context-level
calls had been requested and accepted. This has been done in the C
bindings; the high-level specification will align in its errata to
match.
#16: Text changes in the C bindings document have resolved detailed
points about context expiration policy.
#17: E-mail discussion and text changes in the C bindings document
have clarified and resolved a parameter optionality issue.
#18: The C bindings document's ABI appendix has been revised to
include added text re shared library conventions, and the result was
considered acceptable.
#19: Elaboration and changes had been requested to
GSS_Duplicate_name() and GSS_Canonicalize_name(), aligning the C
bindings with the high-level specification and, in both
specifications, rejecting GSS_S_BAD_NAMETYPE returns as discussed for
#11 above. These changes were accepted.
#20: Clarification was requested, for the high-level GSS-V2 document,
concerning cases of processing anonymous names. A statement was
requested that the content of the name string is a "don't care" if its
associated name type indicates "anonymous name". Further discussion
on this point was remanded to the mailing list.
SIMPLE NEGOTIATION (SNEGO)
Denis Pinkas (Bull) led discussion on the current simple negotiation
(SNEGO) draft, draft-ietf-cat-snego-02.txt. Approximately 10
attendees indicated familiarity with this draft or its
predecessors. An available implementation exists. There had been some
mailing list discussion over the summer about cryptographic protection
of negotiation. While the snego design cannot negotiate a result
which is outside either peer's acceptable set, it is not protected
against an active attack forcing less-preferred members of that set to
be selected. Such protection would add complexity and would require
that a choice be made as to what protection mechanism is to be used
for purposes of protecting the negotiation. Denis noted, further, the
fact that support for per-message protection is not required in order
to comprise a conformant GSS-API mechanism; the FIPS JJJ mechanism
design which had previously been presented to the CAT WG was cited as
a concrete example of a mechanism providing no per-message protection
services.
John Wray suggested that negotiation proposals could be reconfirmed
(via gss_get_mic() on selection parameters) using the mechanism which
is eventually selected through negotiation. This led to the
(unreconciled) question: "would you use 40-bit crypto if a statement
protected by 40-bit integrity told you that you had to"? The
suggested paradigm to comprise a protected negotiation would imply
that SNEGO would need to continue control through more transaction
phases than it does currently. Marc Horowitz proposed to circulate a
draft for such a scheme to the WG during January. Bill Sommerfeld
stated that he doesn't consider unprotected SNEGO to be appropriately
useful.
John Wray raised another issue about the SNEGO draft, suggesting that
intra-mechanism options shouldn't have to be in the original
mechanism's OID tree, in order to allow independent extensions even if
not for standards purposes. This would imply a change to SNEGO to
allow choice of separate OIDs for options.
Following a straw poll of attendees, our working position is to wait
until February to reconsider SNEGO advancement; at that time, the WG
will compare SNEGO with Marc Horowitz's anticipated draft for
protected negotiation and will decide in which direction to proceed.
RFC-1510 UPDATE, KERBEROS-PASSWORDS I-D
Cliff Neuman (ISI) presented status on the pending RFC-1510 update
(targeted for 15 January) and on the kerberos-passwords draft. The
kerberos-passwords I-D needs to be reviewed for possible alignment
with Cygnus-developed code. Planned changes to RFC-1510 include:
incorporation of key derivation material, updating of assigned
numbers, description of extensions specified elsewhere (e.g.,
preauthentication data), possible triple-DES support, and updates to
match the accumulated errata list maintained with the MIT Kerberos
distribution. It needs to be determined whether any of the RFC-1510
changes will imply corresponding changes to RFC-1964, and this
question warrants follow-up mailing list discussion; Marc Horowitz
commented that some new algorithm specifiers may imply a need for such
changes.
KERBEROS PK-INIT I-D
Brian Tung (ISI) led discussion on the recently revised Kerberos
pk-init draft, co-authored with Cliff Neuman, Jonathan Trostle
(CyberSAFE), and John Wray. Approximately 8 attendees indicated
familiarity with this draft. Changes since the version discussed at
the last meeting include addition of KDC recovery facilities and
Diffie-Hellman support. Alpha-level software exists for use with
Kerberos V5 Beta 6; availability will be announced when
suitable. Future plans, to be addressed in an upcoming -03 draft,
include: reorganization, support for multiple private keys on KDC,
and resolution of other outstanding issues.
Denis Pinkas observed within the draft the presence of three options:
RSA encryption, Diffie-Hellman encryption, and a digital signature
scheme (which is not described as fully as the others). He opened the
issue of which should be mandatory, and/or whether any should be spun
into separate document(s), recommending the use of a digital signature
method. Denis believed that the scheme for storage of user private
keys in the KDC may be covered by a Digital patent; John Wray wasn't
aware of such a patent but stated that he would check on this
question. Denis also asked about the patent status for use of the
Diffie-Hellman approach.
Brian requested that any discussion of the KDC recovery text be taken
outside the meeting, since this text has already been significantly
reorganized relative to the -02 draft and, according to Brian, "may be
dropped". Some sentiment emerged in discussion that this mode should
be removed. Bill Sommerfeld commented his perception that the current
protocol has too many options, and also stated that he has implemented
the RSA mode based on the -01 draft and that this implementation will
be in DCE 1.2.2. Bill had made some suggestions based on his
implementation experience and which are reflected in his
implementation; these may already be incorporated into the -03 version
of the text.
Ted Ts'o observed that pk-init's original requirements weren't clear,
believed that this fact has promoted the current profusion of options,
and asked, "where and how do we go from here?". The ISI reference
implementation will implement all options, and is targeted to apply
against KV5 1.0. A new -03 draft will be submitted, after possible
further changes, as a basis for continuing discussion.
KERBEROS PK-CROSS I-D
Brian Tung led a discussion on the new Kerberos pk-cross I-D; the goal
of this scheme is to employ public-key technology in order to
establish Kerberos inter-realm keys "on the fly". As Bill Sommerfeld
had noted in mailing list discussion, the currently-proposed scheme
does not address replicated KDCs. An -01 version responding to this
issue and other suggestions (e.g., to improve response time) is
targeted for mid- January. A scheme for transfer of protocol elements
within tickets may be introduced, to get around lack of direct
inter-KDC paths; there was some controversy about this, but a concrete
proposal will be reviewed once it emerges. Bill Sommerfeld is likely
to join as a new co-author of this draft, and notes that its
implementation can leverage significant common code with pk-init. An
off-list discussion on pk-cross has been active, which Brian stated
that he would summarize to the CAT-WG mailing list.
SESAME MECHANISM I-D
Denis Pinkas led a discussion on the SESAME mechanism I-D (-01
version): 4 attendees indicated that they had read either the current
or previous version of this draft. A related SESAME architecture
document is available on the Web via
http://www.esat.kuleuven.ac.be/cosic/sesame/doc-txt/overview.txt or
(with PostScript and graphics) at
http://www.esat.kuleuven.ac.be/cosic/sesame/doc-ps.html. Denis cited
the following SESAME goals and characteristics:
- Allows both unilateral and mutual authentication using loosely
synchronized clocks.
- When unilateral authentication used, no additional message is
needed, so an init token, wrapped token, and close token can be
concatenated and transferred in a single message.
- Today's SESAME Privilege Attribute Certificates (PACs) can carry
group memberships and roles; in future, clearances or capabilities can
be supported.
- Uses push model of privilege transfer, described as enabling
principle of least privileges by presenting and disclosing only needed
privileges.
- Privileges are directly guaranteed by original vouching authority,
not translated by intermediaries.
- Privilege transfer scheme is independent of key management scheme.
Multiple key management schemes are supported.
- Delegation control is a central feature: delegation can be
restricted to specific targets or to groups of targets. Denis noted
that XGSS provides an API which be used to modulate this facility.
SESAME's GSS-API mechanism re-uses Kerberos and SPKM structures,
incorporating them into a broader framework; PACs, however, are
SESAME-defined. Ted Ts'o asked about the desired disposition of the
SESAME mechanism document, which has so far received limited
readership within the CAT WG. John Wray asserted that the current
SESAME mechanism I-D, less the architecture document, did not appear
self-sufficiently complete to enable independent implementations, but
this was debated. Stephen Farrell (SSE) observed that SESAME already
handles many of the goals being addressed by pk-cross.
The question was raised, "What's the state of interoperability between
SESAME and a Kerberos KDC?" It was stated that, per prior testing, a
SESAME client can obtain tickets from an MIT Kerberos server. Ted
noted that this interoperability is analogous to (though somewhat
different from) the MIT-DCE interoperability case, and that
Microsoft's intended Kerberos usage case presents another variant
which is similar in some respects although, like SESAME, incorporating
different authorization data. Attending SESAME participants indicated
their openness to make changes if discussed.
GSS-IDUP I-D
Carlisle Adams (Nortel) led discussion on the -06 version of the GSS-
IDUP draft, stating that it was little changed from -05. He had added
IDUP_SE calls, comprising a simplified API supporting signing and
encryption in single-buffer and multi-buffer modes, intending that
this would become the primary interface for all callers who use just
those functions. Signing and encryption functions, however, would
also remain accessible through the previously-defined IDUP calls.
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
