51th IETF 會議報告

財團法人台灣網路資訊中心因公出國人員報告書

51^st IETF 會議記錄與報告

中央研究院資訊所王大為、吳俊興

London, England, Aug 5-10, 2001

一、出國目的

這次出國是到英國倫敦，參加第51屆IETF會議，自八月五日起為期六天，同時出席MINC的相關會議。目前IETF每年舉辦三次會議，本次是本年度的第二次會議，上次是三月在美國的明尼蘇達州密里雅波斯舉行，下次十二月將回到美國在猶他州的鹽湖城舉行。如同往常，本次會議依然吸引許多世界各地的專家學者與會，但因地緣關係，本次會議有更多的歐洲國家人士出席，相較上次，來自美國的出席人數比率也較為減少，而來自亞洲的人數仍以日本人最多，韓國其次，來自台灣的除了我們TWNIC的兩名與會代表外，另有一名來自工研院參與MobileIP的代表。另外，來自大陸的有CNNIC三人。

這次與會的重點在參與 IDN工作會議的討論與表決，並與IDN及MINC相關人士交換意見。由於IDN的標準制定工作已經落後預期進度許多，因此IDN工作小組的主要成員在會前即以儘速達成各項共識為目標，來運作此次的小組會議，重點包括：ACE、Matching及Protocol部份。雖然此次會議花最多的時間在討論Protocol部份，但並沒有讓三個Drafts有報告的機會，其中包括TWNIC曾教授所提的 UNAME draft。因此我們除了在會議進行當中表達我們的立場及意見外，同時也在會議前後私底下與相關人士進行溝通，並將會場的最新狀況，隨時透過網路向國內回報。

二、考察訪問過程

n 會前準備及會後後續討論會議

在前往倫敦參加本次IETF的IDN工作會議前後，曾就本次會議的各項重點議題及IDN相關問題，在國內舉行了數次研討會議來廣徵各方的意見，包括行前於七月五日及八月一日舉行正式的中文網域名稱技術小組第二十四次及第二十五次會議，會後在八月十九日舉行IETF會議會後討論會，並在八月二十四日舉行的「國際化域名及基礎設施路由」討論會議中，與孔祥重院士及IETF 前主席暨IAB成員Fred Backer和Scott Brander交換相關意見。同時我們也在會議期間及前後，與相關人員針對本次會議進行了約兩百封的信件來往討論。

n 第一天(八月五日)：報到、會議組織介紹、歡迎會

本次大會是由英國電信BT (British Telecommunications)主辦，在倫敦市中心的Hilton London Metropole 飯店舉行。除了提供24小時開放的Terminal Room之外，BT同時在整間飯店佈滿了802.11b的無線網路，在所有公共空間隨時都可以上網，相當方便。另外，除了提供傳統的IPv4網路外，現場的網路也支援 IPv6。Terminal Room內有10部Unix、40部Windows的公用電腦，以及多部Printer Servers和臨時的Mail Servers。現場除了可以無線上網之外，也提供了近兩百個100Mbps Ethernet 連接頭。除了頻寬充足、設施齊全便利之外，網路系統的穩定性也很高。

前天晚上搭機抵達倫敦稍做休息後，第一天中午就到大會現場報到。在報到時，只見現場人山人海，提供有線網路連接、可容納兩三百人的Terminal Room也早已客滿，因此會場邊到處可見很多人席地而坐操作notebook，透過會場提供的無線網路上網。報到完之後，依照大會提供的網路暨電腦設定使用指南，我也順利地連上網路收送Emails。

原訂下午1:00舉行的Security Tutorial臨時因故取消，所以繼續待在會場使用電腦上網。然而由於恰逢Red Code網路病毒肆虐，世界各地及台灣的網路深受其害，從會場很難直接連回台灣，經輾轉借道美國後才勉強可以連回台灣收送Emails，此問題大概持續了兩天。

下午3:30出席IETF的Newcomer及Standards Process的Orientations，聽IETF的組織運作及標準制定過程之介紹，一直進行到近五點結束。隨後參加歡迎會，現場擠滿了幾百人。本來約CNNIC的人在歡迎會上碰面，但未能遇到。飯後再回到Terminal Room上網，同時準備會議資料。

n 第二天(八月六日)：MINC會議

早上研商策略，並分析IDN其它Drafts的優劣，同時分析IDN成員的相關言論立場。中午搭地鐵轉兩次車到Thistle Marble Arch Hotel參加MINC的會議，共約十多人出席。彼此交換名片後，就IDN及未來可能方向交換意見。會後再回到IETF會場，透過Email回報狀況，並繼續與曾教授商討Unicode/Legacy encoding、繁簡互換、UNAME等相關問題。

n 第三天(八月七日)：IDN議程出爐、準備投影片

在IDN工作小組會議前兩天，主席才將議程公布。兩小時的開會時間內將花75分鐘在Protocol討論，但是不像其它部份，Protocol部份並沒讓各drafts (IDNA、UDNS、UNAME)報告，僅由Dave Crocker花十分鐘做Protocol comparison。因此我們收集Dave Crocker的資料，並由TWNIC向IDN提出報告的請求，同時仍持續與國內進行UNAME及繁簡問題的討論，並針對此次IDN會議著手彙整修改投影片。

n 第四天(八月八日)：開幕大會

早上繼續與國內進行討論，並完成UNAME投影片初稿。下午與CNNIC碰面，交換情報，並得知明天的IDN會議將以舉手的方式形成共識決：

(1). ACE部份，目前可能在 AMC跟MACE間選擇其一做為Standard，其中初步的綜合評估結果：用AMC對TW/KR/JP不錯，對CN很好；MACE對TW/KR/JP很好，但對CN不好。

(2). Matching部份，Nameprep可能會過，以目前Unicode為準變成standard，但不含jpchar、tsconv，他們建議 jpchar、tsconv自己去要求 Unicode將 CJK放進去，他們就考慮接受，或者我們自已協調，變成 informational的RFC，做為 Nameprep 的 prepare，但IDN小組不見得會接受。或者就是完全不處理，自行用Zone file處理。

(3). Protocol部份，IDNA可能會被推成共識，目前所有的protocols都沒有安排時間做presentation，只安排Dave Crocker做十分鐘的protocols比較。

向國內回報後商討會議策略、並評估IDNA通過後的影響，同時修改投影片。晚上19:30參加開幕大會，聽取BT總裁的演講，以及IRTF、IAB、RFC Editor、IANA、IESG和各area directors等各相關人士的報告，會議進行到近晚上十一點才結束。

n 第五天(八月九日)：IDN會議

這次來參加IETF的重頭戲將在今天登場。早上先再與CNNIC討論ACE、繁簡互換及UNAME的相關意見，並研擬下午IDN會議進行時如何互相支援。隨後與Patrick會談，各自澄清IDNA、繁簡、UNAME，但彼此並沒有交集。繁簡及日韓文問題應不會被放進Nameprep中，也許IDNA draft可以提到應該要有 standardized pre-prepare，但要看IDN WG的共識，同時IDNA也許更改為不限只能在Applications中處理IDN，但同樣要以IDN WG的共識為依歸。隨後中午13:00起即開進行IDN WG的工作會議，大致的結果如下：

一.ACE選擇AMC-Z

二.Nameprep部份希望能繼續把幾個draft 整合

三.關於Protocol 部分最後是做了表決成為所謂的共識，現場投票的結果是IDNA除了我們幾個反對以外，反對的人不多，UDNA與UNAME支持的人比反對的人少，所以最後的結論是 ”IDNA gets strong support, and UDNA and UANME are opposed strongly.”

詳細的會議記綠如附件。在IDN工作會議結束之後，主席James跑來解釋為何無法讓UNAME報告，以及IDN WG的立場和難處。Local、Regional、Legacy的問題，IDN WG的人沒興趣，要動DNS Protocol、違反Requirements或Charter message的提案都難被接受。另外建議也許tsconv、jpchar、UNAME往Informational 或Experimental / Best-practice 型式的RFC發展，即不在正式的Standard track RFC內，而UNAME如果不走DNS就較容易被接受。與James談了兩個多鐘頭之後，我們則繼續和UDNA的作者交換一下意見。UDNA走UTF-8，想看看有無可能跟UNAME整合。討論完之後，回Terminal Room用Email跟台灣回報狀況。整天會議下來，整體的評估是IDNA/Nameprep/ACE已把板塊劃清了。隨後晚上一群人共進晚餐，交換與會心得。

n 第六天(八月十日)：會議落幕

早上回會場Terminal Room以Email跟國內交換與會心得，同時遇到CNNIC的人並稍微討論一下。中午十二點正，會議正式落幕，同時Terminal Room也將關閉，順利結束了為期六天的IETF-51會議。

三、考察、訪問心得

IDN部份：

l 對IDN、UNAME的了解

l 網路國際化與區域化的衝突

l 與CNNIC、MINC、IDN等的交流

l 未來IDN WG的影響評估

IETF部份：

l 對IAB/IESG/IETF/WG等的運作機制及標準制定的體會

l 參與IETF的利弊

l 角色定位：考察觀摩與長期參與、Follow-up 與 Leading

l 參與策略：單打獨鬥與集團結盟

四、建議意見

IDN部份：

l UNAME與繁簡(漢字)的後續發展

l 了解Unicode/ISO10646、CNS11643及MINC等其它相關組織的狀況

l 由CDNC、JET擬定標準的可能

l 針對未來IETF成立Keyword及UTF-8 IDN (8-bit clean DNS) WG預做準備

l 提早準備IETF52會議─12月9-14日在美國猶他州鹽湖城 (10月8日資料上線)

IETF部份：

l 了解IETF其它相關WG在國際化方面的動向，如：

–Major: dnsext, dnsop, whoisfix, cnrp

–Minor: LDAP(ldapbis, ldaup, ldapext) , ipng, routing

l 及其對TWNIC及台灣的影響

l 與IETF建立長期友好關係，含Area Directors

l 針對網路Localized暨中文化問題，評估建立類似IETF標準制定的機制及RFC之類的文件

其它部份：

l 與國內其它中文處理相關單位的連繫

l 聯合國內CLE、軟體自由協會等volunteers的人力

l 其它Internationalization(I18N)及Localization問題

l ISC/BIND (Internet Software Consortium)、IMC(Internet Mail Consortium)及 W3C等的參與

五、其他相關事項或資料

1. 攜回資料，會議資料將在會議結束後十週出版。

(線上電子版本在 http://www.ietf.org/proceedings/01aug/ )

2. 參考資料

[1] IETF homepage, http://www.ietf.org/

[2] IETF-51 Meeting homepage, http://www.btexact.com/ietf_51/index.htm

[3] IETF Internationalized Domain Name (idn) Charter, http://www.ietf.org/html.charters/idn-charter.html

[4] Internationalized Domain Names IETF Working Group, http://www.i-d-n.net/

3. 附錄資料

A. Agenda of the 51st IETF Meeting

B. Working Group and BOF Agendas

C. Agenda of IDN WG meeting at IETF51

D. Minutes of IDN WG meeting at IETF51

E. MINC London Meetings

F. IDN mailing list發表者排行 (至2001/08/03為止)

G. UNAME Draft 原擬發表的投影片

附錄A. Agenda of the 51st IETF Meeting

Agenda of the 51st IETF Meeting

August 05-10, 2001

http://www.ietf.org/meetings/agenda_51.html

(Text Format of the Agenda Is Available)

SUNDAY, August 5, 2001
1000-1700 IEPG Meeting - Hilton Rooms 1-6
1200-1900 Registration - Monarch Suite/Viscount 2
1300-1500 Security Tutorial - King's Suite/Balmoral 2 changed to Palace Suite
1530-1600 Newcomer's Orientation - King's Suite/Balmoral 2 changed to Palace Suite
1600-1630 IETF Standards Process Orientation - King's Suite/Balmoral 2
1700-1900 Welcome Reception - King's Suite/Sandringham 1
1930-2200 MADDOGS Meeting - Hilton Rooms 1-6

MONDAY, August 6, 2001
0800-1930 IETF Registration - Monarch Suite/Viscount 2
0800-0900 Continental Breakfast - Viscount, Mezzanine Balcony, West Wing Lobby Bar
0900-1130 Morning Sessions

Palace Suite/Blenheim	APP	apparea	Applications Open Area Meeting
Hilton Rooms 1-6	INT	magma	Multicast & Anycast Group Membership BOF *
Cadogan/Berkeley	IRTF	idrm	Internet Digital Right Management
Belgrave/Clarence	OPS	disman	Distributed Management WG
Windsor Suite	RTG	manet	Mobile Ad-hoc Networks WG
Palace Suite/Buckingham	SEC	ipsp	IP Security Policy WG
King's Suite/Sandringham 1	SUB-IP	mpls	Multiprotocol Label Switching WG
King's Suite/Balmoral 2	TSV	sip	Session Initiation Protocol WG *

1130-1300 Break
1300-1500 Afternoon Sessions I

Palace Suite/Buckingham	APP	simple	SIP for Instant Messaging and Presence Leveraging Extensions WG
Hilton Rooms 1-6	OPS	mboned	MBONE Deployment WG *
King's Suite/Balmoral 2	OPS	policy	Policy Framework WG *
Belgrave/Clarence	RTG	udlr	UniDirectional Link Routing WG
Palace Suite/Blenheim	SEC	ipsec	IP Security Protocol WG
Windsor Suite	TSV	megaco	Media Gateway Control WG
King's Suite/Sandringham 1	TSV	seamoby	Context and Micro-mobility Routing WG
Cadogan/Berkeley	USV	uswg	User Services WG

1500-1530 Break (Refreshments) - Viscount, Mezzanine Balcony, West Wing Lobby Bar
1530-1730 Afternoon Sessions II

Palace Suite/Blenheim	APP	cdi	Content Distribution Internetworking WG
Cadogan/Berkeley	APP	webdav	WWW Distributed Authoring and Versioning WG
King's Suite/Balmoral 2	INT & OPS	dnsext & ngtrans	JOINT DNS Extensions WG & Next Generation Transition WG *
Palace Suite/Buckingham	OPS	sming	Next Generation Structure of Management Information WG
Hilton Rooms 1-6	RTG	pim	Protocol Independent Multicast WG *
King's Suite/Sandringham 1	SEC	pkix	Public-Key Infrastructure (X.509) WG
Belgrave/Clarence	TSV	nfsv4	Network File System Version 4 WG
Windsor Suite	TSV	rserpool	Reliable Server Pooling WG

1730-1930 Break
1930-2200 Evening Sessions

Belgrave/Clarence	APP	fax	Internet Fax WG
Cadogan/Berkeley	APP	imapext	Internet Message Access Protocol Extension WG
Palace Suite/Blenheim	OPS	rap	Resource Allocation Protocol WGM
King's Suite/Balmoral 2	RTG	mobileip	IP Routing for Wireless/Mobile Hosts WG *
Windsor Suite	SEC	inch	Extended Incident Handling BOF - CANCELED
King's Suite/Sandringham 1	SUB-IP	ccamp	Common Control and Measurement Plane WG
Hilton Rooms 1-6	TSV	ips	IP Storage WG *
Palace Suite/Buckingham	TSV	rmt	Reliable Multicast Transport WG

* Designates Multicast Sessions

TUESDAY, August 7, 2001
0800-1700 IETF Registration - Monarch Suite/Viscount 2
0800-0900 Continental Breakfast Viscount, Mezzanine Balcony, West Wing Lobby Bar
0900-1130 Morning Sessions

Palace Suite/Buckingham	APP	opes	Open Pluggable Edge Services BOF
Cadogan/Berkeley	IRTF	smug	Secure Multicast Group
Hilton Rooms 1-6	OPS	eos	Evolution of SNMP WG *
King's Suite/Balmoral 2	OPS	ngtrans	Next Generation Transition WG *
Windsor Suite	SEC	secsh	Secure Shell WG
Belgrave/Clarence	SUB-IP	gsmp	General Switch Management Protocol WG
Palace Suite/Blenheim	TSV	ips	IP Storage WG
King's Suite/Sandringham 1	TSV	sip	Session Initiation Protocol WG

1130-1300 Break
1300-1400 Afternoon Sessions I

King's Suite/Sandringham 1	APP	prim	Presence and Instant Messaging Protocol WG

Cadogan/Berkeley	APP	webi	Web Intermediaries WG
Palace Suite/Buckingham	OPS	rap	Resource Allocation Protocol WG
Palace Suite/Blenheim	OPS	multi6	Site Multihoming in IPv6 WG
Windsor Suite	RTG	forces	Forwarding and Control Element Separation BOF
Belgrave/Clarence	SEC	sasl	SASL BOF
King's Suite/Balmoral 2	TSV	ippm	IP Performance Metrics WG *
Hilton Rooms 1-6	TSV	spirits	Service in the PSTN/IN Requesting InTernet Service WG *

1415-1515 Afternoon Sessions II

Windsor Suite	APP	ldup	LDAP Duplication/Replication/Update Protocols WG
Belgrave/Clarence	INT	ipoib	IP over InfiniBand WG
Palace Suite/Blenheim	INT	itrace	ICMP Traceback WG
Cadogan/Berkeley	OPS	entmib	Entity MIB WG
King's Suite/Balmoral 2	RTG	msdp	Multicast Source Discovery Protocol WG *
Hilton Rooms 1-6	SEC	aft	Authenticated Firewall Traversal WG *
Palace Suite/Buckingham	TSV	pilc	Performance Implications of Link Characteristics WG
King's Suite/Sandringham 1	TSV	rmt	Reliable Multicast Transport WG

1515-1545 Break (Refreshments) - Viscount, Mezzanine Balcony, West Wing Lobby Bar
1545-1645 Afternoon Sessions III

Windsor Suite	APP	ldup	LDAP Duplication/Replication/Update Protocols WG
Belgrave/Clarence	INT	ipoib	IP over InfiniBand WG
Palace Suite/Blenheim	OPS	dnsop	Domain Name Server Operations WG
Cadogan/Berkeley	OPS & INT	hubmib & atommib	JOINT Ethernet Interfaces and Hub MIB WG & AToM MIB WG
Hilton Rooms 1-6	RTG	rtgarea	Routing Area Meeting * - CANCELED
King's Suite/Balmoral 2	SEC	ipsec	IP Security Protocol WG *
King's Suite/Sandringham 1	TSV	pwe3	Pseudo Wire Emulation Edge to Edge WG
Palace Suite/Buckingham	TSV	sigtran	Signaling Transport WG

1700-1800 Afternoon Sessions IV

Palace Suite/Buckingham	INT	ipobt	IP over Bluetooth BOF
Cadogan/Berkeley	OPS	bridge	Bridge MIB WG
Belgrave/Clarence	OPS	entmib	Entity MIB WG
King's Suite/Balmoral 2	RTG	mobileip	IP Routing for Wireless/Mobile Hosts WG *
Windsor Suite	SEC	ipsra	IP Security Remote Access WG
Hilton Rooms 1-6	SUB-IP	iporpr	IP over Resilient Packet Rings WG
Palace Suite/Blenheim	TSV	iptel	IP Telephony WG
King's Suite/Sandringham 1	TSV	pwe3	Pseudo Wire Emulation Edge to Edge WG

* Designates Multicast Sessions

WEDNESDAY, August 8, 2001
0800-1700 IETF Registration - Monarch Suite/Viscount 2
0800-0900 Continental Breakfast - Viscount, Mezzanine Balcony, West Wing Lobby Bar
0900-1130 Morning Sessionsa

Cadogan/Berkeley	APP	calsch	Calendaring and Scheduling WG
Palace Suite/Buckingham	INT	urp	User Registration Protocol BOF
Hilton Rooms 1-6	OPS	opsarea	Operations & Management Open Area *
Palace Suite/Blenheim	RTG	isis	IS-IS for IP Internets WG
Windsor Suite	SEC	smime	S/MIME Mail Security WG
King's Suite/Sandringham 1	SUB-IP	ppvpn	Provider Provisioned Virtual Private Networks WG
King's Suite/Balmoral 2	TSV	avt	Audio/Video Transport WG *

1130-1300 Break
1300-1500 Afternoon Sessions I

Cadogan/Berkeley	APP	deltav	Web Versioning and Configuration Management WG
Palace Suite/Buckingham	APP	impp	Instant Messaging and Presence Protocol WG
King's Suite/Balmoral 2	INT	ipngwg	IPNG WG *
Palace Suite/Blenheim	OPS	aaa	Authentication, Authorization and Accounting WG
Belgrave/Clarence	OPS	rmonmib	Remote Network Monitoring WG
Windsor Suite	RTG	idr	Inter-Domain Routing WG
Hilton Rooms 1-6	SEC	tls	Transport Layer Security WG *
King's Suite/Sandringham 1	TSV	tsvwg	Transport Area Working Group

1500-1530 Break (Refreshments) - Viscount, Mezzanine Balcony, West Wing Lobby Bar
1530-1730 Afternoon Sessions II

Hilton Rooms 1-6	APP	provreg	Provisioning Registry Protocol WG *

Windsor Suite	INT	dhc	Dynamic Host Configuration WG
Cadogan/Berkeley	OPS	adslmib	ADSL MIB WG
Belgrave/Clarence	SEC	krb-wg	Kerberos WG
Palace Suite/Buckingham	SEC	msec	Multicast Security WG
King's Suite/Sandringham 1	SUB-IP	ipo	IP over Optical WG
Palace Suite/Blenheim	TSV	seamoby	Context and Micro-mobility Routing WG
King's Suite/Balmoral 2	TSV	sipping	Initiation Protocol Project Investigation WG *

1730-1930 Break
1930-2200 Open Plenary - King's Suite

Welcome
Presentation from local host
IRTF presentation: An architecture for Interplanetary Internet
Update on routing table growth
A day in the life of an I-D
IAB session, consisting of:
- IRTF report
- RFC Editor report
- IANA report
- Discussion of upcoming pressing architectural issues
- IAB Open Microphone
IESG Open Plenary

2230 Late Night Session - Hilton Rooms 1-6
PGP Key Signing

* Designates Multicast Sessions

THURSDAY, August 9, 2001
0800-1700 IETF Registration - Monarch Suite/Viscount 2
0800-0900 Continental Breakfast - Viscount, Mezzanine Balcony, West Wing Lobby Bar
0900-1130 Morning Sessions

Belgrave/Clarence	APP	ldapbis	LDAP (v3) Revision WG
Palace Suite/Buckingham	INT	dnsext	DNS Extensions WG
Cadogan/Berkeley	INT	ipcdn	IP over Cable Data Network WG
Windsor Suite	OPS	ipfx	IP Flow Export BOF
Palace Suite/Blenheim	SEC	sacred	Securely Available Credentials WG
King's Suite/Balmoral 2	Sub-IP	tewg	Internet Traffic Engineering WG *
Hilton Rooms 1-6	TSV	avt	Audio/Video Transport WG *
King's Suite/Sandringham 1	TSV	diffserv	Differentiated Services WG

1130-1300 Break
1300-1500 Afternoon Sessions I

Belgrave/Clarence	APP	ldapext	LDAP Extension WG
King's Suite/Balmoral 2	INT	idn	Internationalized Domain Name WG *
Windsor Suite	INT	l2tpext	Layer Two Tunneling Protocol Extensions WG

Cadogan/Berkeley	OPS	hubmib	Ethernet Interfaces and Hub MIB WG
Palace Suite/Buckingham	OPS	ptomaine	Prefix Taxonomy Ongoing Measurement & Inter Network Experiment BOF
Palace Suite/Blenheim	SEC	kink	Kerberized Internet Negotiation of Keys WG
King's Suite/Sandringham 1	TSV & APP	hip & geopriv	Host Identity Payload BOF (at 1300-1400) & Geographic Location/Privacy WG (at 1400-1500)
Hilton Rooms 1-6	TSV	mmusic	Multiparty Multimedia Session Control WG *

1500-1530 Break (Refreshments) - Viscount, Mezzanine Balcony, West Wing Lobby Bar
1530-1730 Afternoon Sessions II

Palace Suite/Blenheim	APP	whoisfix	Whois Enhancement BOF
Cadogan/Berkeley	INT	atommib	AToM MIB WG
Windsor Suite	INT	zeroconf	Zero Configuration Networking WG
Belgrave/Clarence	OPS	bmwg	Benchmarking Methodology WG
Palace Suite/Buckingham	OPS	policy	Policy Framework WG
King's Suite/Balmoral 2	SEC	saag	Open Security Area Directorate Meeting *
Hilton Rooms 1-6	TSV	rohc	Robust Header Compression WG *
King's Suite/Sandringham 1	TSV	sipping	Initiation Protocol Project Investigation WG

* Designates Multicast Sessions

FRIDAY, August 10, 2001
0800-1000 IETF Registration - Monarch Suite/Viscount 2
0800-0900 Continental Breakfast - Viscount, Mezzanine Balcony, West Wing Lobby Bar
0900-1130 Morning Sessions

Belgrave/Clarence	APP	trade	Internet Open Trading Protocol WG
Cadogan/Berkeley	APP	vpim	Voice Profile for Internet Mail WG
King's Suite/Balmoral 2	INT	ipngwg	IPNG WG *
Palace Suite/Blenheim	IRTF	aaaarch	Authentication Authorisation Accounting ARCHitecture
Windsor Suite	OPS	rmonmib	Remote Network Monitoring WG
King's Suite/Sandringham 1	TSV	midcom	Middlebox Communication WG
Palace Suite/Buckingham	TSV	rohc	Robust Header Compression WG

* Designates Multicast Sessions

AREA DIRECTORS

APP	Applications	Patrik Faltstrom/Cisco Systems and Ned Freed/Innosoft International
INT	Internet	Thomas Narten/IBM Corp. and Erik Nordmark/Sun Microsystems
OPS	Operations & Management	Randy Bush/Verio, Inc. and Bert Wijnen/Lucent Technologies
RTG	Routing	Rob Coltun/Redback and Abha Ahuja/Merit Network Inc.

SEC	Security	Jeff Schiller/MIT and Marcus Leech/Nortel Networks
SUB-IP	Sub-IP Area	Scott Bradner/Harvard Univ. and Bert Wijnen/Lucent Technologies
TSV	Transport	Scott Bradner/Harvard Univ. and Allison Mankin/USC/ISI
USV	User Services	April Marine/Nominum, Inc.

附錄B. Working Group and BOF Agendas

Working Group and BOF Agendas

· AAA - Authentication, Authorization and Accounting WG

· AFT - Authenticated Firewall Traversal WG

· ADSLMIB - ADSL MIB WG

· ATOMMIB - AToM MIB WG

· AVT - Audio/Video Transport WG

· BMWG - Benchmarking Methodology WG

· BRIDGE - Bridge MIB WG

· CALSCH - Calendaring and Scheduling WG

· CCAMP - Common Control and Measurement Plane WG

· CDI - Content Distribution Internetworking BOF

· DELTAV - Web Versioning and Configuration Management WG

· DHC - Dynamic Host Configuration WG

· DIFFSERV - Differentiated Services WG

· DISMAN - Distributed Management WG

· DNSEXT - DNS Extensions WG

· DNSEXT&NGTRANS - Joint DNS Extensions WG & Next Generation Transition WG Meeting

· DNSOP - Domain Name Server Operations WG

· ENTMIB - Entity MIB WG

· EOS - Evolution of SNMP WG

· FAX - Internet Fax WG

· FORCES - Forwarding and Control Element Separation WG

· GEOPRIV - Geographic Location/Privacy WG

· GSMP - General Switch Management Protocol WG

· HIP - Host Identity Payload BOF

· HUBMIB - Ethernet Interfaces and Hub MIB WG

· HUBMIB & ATOMMIB - Ethernet Interfaces and Hub MIB WG & AToM MIB WG

· IDR - Inter-Domain Routing WG

· INCH - Extended Incident Handling BOF

· IMAPEXT - Internet Message Access Protocol Extension WG

· IMPP - Instant Messaging and Presence Protocol WG

· INCH - Extended Incident Handling BOF

· IPCDN - IP over Cable Data Network WG

· IPFX - IP Flow Export BOF

· IPNGWG - IPNG WG

· IPO - IP over Optical WG

· IPOBT - IP over Bluetooth BOF

· IPOIB - IP over InfiniBand WG

· IPORPR - IP Over Resilient Packet Rings WG

· IPPM - IP Performance WG

· IPS - IP Storage WG

· IPSP - IP Security Policy WG

· IPSRA - IP Security Remote Access WG

· IPTEL - IP Telephony WG

· ISIS - IS-IS for IP Internets WG

· ITRACE - ICMP Traceback WG

· KINK - Kerberized Internet Negotiation of Keys WG

· KRB-WG - Kerberos WG

· L2TPEXT - Layer Two Tunneling Protocol Extensions WG

· LDAPBIS - LDAP (v3) Revision WG

· LDUP - LDAP Duplication/Replication/Update Protocols WG

· MAGMA - Multicast & Anycast Group Membership BOF

· MANET - Mobile Ad-hoc Networks WG

· MBONED - MBONE Deployment WG

· MSEC - Multicast Security WG

· MEGACO - Media Gateway Control WG

· MIDCOM - Middlebox Communication WG

· MMUSIC - Multiparty Multimedia Session Control WG

· MOBILEIP - IP Routing for Wireless/Mobile Hosts WG

· MPLS - Multiprotocol Label Switching WG

· MULTI6 - Site Multihoming in IPv6 WG

· NFSV4 - Network File System Version 4 WG

· NGTRANS - Next Generation Transition WG

· OPES - Open Pluggable Edge Services BOF

· OPSAREA - Operations & Management Open Area AG

· PILC - Performance Implications of Link Characteristics WG

· PKIX - Public-Key Infrastructure (X.509) WG

· POLICY - Policy Framework WG

· PPVPN - Provider Provisioned Virtual Private Networks WG

· PRIM - Presence and Instant Messaging Protocol WG

· PROVREG - Provisioning Registry Protocol WG

· PTOMAINE - Prefix Taxonomy Ongoing Measurement & Inter Network Experiment BOF

· PWE3 - Pseudo Wire Emulation Edge to Edge WG

· RAP - Resource Allocation Protocol WG

· RMONMIB - Remote Network Monitoring WG

· RMT - Reliable Multicast Transport WG

· ROHC - Robust Header Compression WG

· RSERPOOL - Reliable Server Pooling WG

· SACRED - Securely Available Credentials WG

· SASL - SASL BOF

· SEAMOBY - Context and Micro-mobility Routing WG

· SECSH - Secure Shell WG

· SIGTRAN - Signaling Transport WG

· SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions WG

· SIP - Session Initiation Protocol WG

· SIPPING - Session Initiation Protocol Project Investigation BOF

· SMIME - S/MIME Mail Security WG

· SMING - Next Generation Structure of Management Information WG

· SPIRITS - Service in the PS TN/IN Requesting InTernet Service WG

· TRADE - Internet Open Trading Protocol WG

· TEWG - Internet Traffic Engineering WG

· TLS - Transport Layer Security WG

· TSVWG - Transport Area Working Group

· UDLR - UniDirectional Link Routing WG

· URP - User Registration Protocol BOF

· USWG - User Services WG

· VPIM - Voice Profile for Internet Mail WG

· WEBDAV - WWW Distributed Authoring and Versioning WG

· WEBI - Web Intermediaries WG

· WHOISFIX - Whois Enhancement BOF

· ZEROCONF - Zero Configuration Networking WG

Please send questions, comments and/or suggestions to ietf-web@ietf.org.

附錄C. Agenda of IDN WG meeting at IETF51

寄件者: "Marc Blanchet" <Marc.Blanchet@viagenie.qc.ca>

收件者: <idn@ops.ietf.org>

主旨: [idn] agenda v1.0 ietf-london

日期: 2001年8月7日上午 09:06

Hi,

here is a first cut of the proposed agenda. The idea here is to leave

room for concensus building.

==================================================

Agenda:

agenda bashing, 1 min., Marc Blanchet

wg update, 5 min., Marc Blanchet

ACE encoding

ACE comparison, 5 min., Yoshiro Yoneya

Reordering, 5 min., Soobok Lee

ACE concensus building (Choosing an ACE if we need one), 5 min.

Matching

Nameprep update, 5 min., Paul Hoffman

TSconv, 5 min., Xiang Deng

Hangulchar, 5 min., Soobok Lee

Matching concensus building, 10 min.

Protocol

Protocol comparison, 10 min., Dave Crocker

Protocol concensus building, 55 min.

Conclusion and next steps, 10 min.

================================================

Marc & James.

PS1. I was on vacation for the past few weeks, so that is why both the

agenda and the pool were not updated.

PS2. I will update the web site shortly and will announce in a separate

email the document pool (a few are not yet there because of PS1 above).

附錄D. Minutes of IDN WG meeting at IETF51

IETF IDN Working group session

9 August 2001

London, England

Agenda Bashing:

Agreement on the floor to cut

Reordering, nameprep update, Uname proposal, Hangulchar, tsconv

from planned agenda.

================================================================

WG UPDATE, Marc Blanchet

Coordination with other groups/efforts:

- IETF apps area

- "requirements" for encoding: ACE or UTF8

- directory efforts: directory@apps.ietf.org

- Unicode/ISO

- Any modifications to Unicode/ISO tables should be done by those

parties, not IETF

- IETF dnsext WG

- Any modification to DNS protocol should be discussed in dnsext

- ICANN/IANA

- Policies

- Pool W, pool of documents that identify core of interest by WG

- Currently:

- requirements

co-chairs believe there is a wg rough concensus and intend to forward

it to IESG for Informational.

- idna

- nameprep

- dude

- aceid

- jpchar

- ace-eval-jp

- mace

- uname

- tsconv

- udns

- amc-ace-z

- hangeulchar

- lsb-ace

- Today's focus is on standards track proposals

================================================================

ACE EVALUATION WITH IDNs ALREADY REGISTERED, Yoshiro Yoneya

- Done by CNNIC, KRNIC, TWNIC and JPNIC with data they have for

registered domain names, focusing on ACEs in Pool W.

- Most important evaluation criterion to study is to maximize number

of characters, raw speed is less important because nameprep is the

slow stage.

- Long IDNs (more than 15 Han characters) are already registered.

- Evaluated ACEs: DUDE, AMC-ACEZ, MACE and RACE

- Focus on DUDE and AMC-ACE-Z with MACE&RACE as reference

Graphs of efficiency of domain names from each of KRNIC and TWNIC,

where AMC-ACE-Z shows best compressions

Charts showing that the four NICs consider AMC-ACE-Z to be either good

or very good, while others were "bad" or "very bad" for at least one NIC.

MACE co-authors (including the presenter, Yoneya-san) support

AMC-ACE-Z.

Recommendation from the study is: AMC-ACE-Z

================

WG Questions for sense of the group:

Question: If there is a need for an ACE, choose one:

- DUDE few hands

- AMC-ACE-Z most hands

- MACE (removed at request of authors)

- don't care but want an ACE chosen fair bunch of hands

Erik Nordmark: question is, if you use an ACE, this is the one. Not

saying you need to use an ACE anywhere.

?: What is re-ordering?

James Seng: pre-processing to make more frequently used chars more

compressed.

Paul Hoffman: Not binding vote. Should be comfirmed on mailing list.

Concensus: AMC-ACE-Z (with many don't care so long one is choosen)

Should we do reordering?

- Yes some hands

- No some hands

No clear result of poll.

Erik Nordmark: A lot fewer people participated in the former poll but

not the latter. Why?

Bill Manning: We read the draft but didn't understand it, and need to

read it again.

Paul Hoffman: Don't understand the re-ordering draft. Does not

broaden to other scripts.

Larry Masinter: Re-ordering adds complexity.

Kilnam Chon: Re-ordering is critical for CJK but add complexity.

Paul Hoffman: This draft adds complexity, so perhaps people are waiting

to decide how to judge whether the added complexity is worth it.

Eric Chen: This is just intended to help CJK. Most of the interest

is in CJK. Why not?

James Seng: What I'm hearing is that the authors should do a

cost/benefit analysis, but it is clear the draft is not ready to move

forward.

Erik Nordmark: Can someone do a pro/con analysis draft, or someone do pro and

someone con, to help drive the discussion on the mailing list?

Paul Hoffman: Let's make Adam [Costello] do it. [laughter]

Kilnam Chon: This straw poll process isn't really valid because not

enough representation from people for whom this is really important.

There's always a trade-off.

James Seng: Could someone who voted against the lsb draft just explain

why you are against it?

Paul: I'd rather someone else did, but I will ... the reordering draft

is somewhat of a hack to optimize for certain scripts, but it is at

the cost of other scripts, isn't really generalized, and there has

been no analysis of how beneficial it is for DUDE and AMC-ACE-Z.

Dongman Lee: The author was not trying to propose this as a

generalized mechanism. It is not surprising that since CJK is driving

internationalization, that proposals would be specific to that.

Ted Hardie: As Paul pointed out, this has different effects on

different scripts, but now that we are focused on one ACE we can ask

more specifically for the authors to focus on just how it affects

AMC-ACE-Z.

Concensus: discuss the reordering on mailing list and request authors

of ACE and reordering to come to a proposal with analysis.

================================================================

MATCHING (NAMEPREP)

- Need for a standardized pre-processing step regardless of what IDN

protocol we choose?

Yes lot of hands

No one hand

(Discussion clarified the question from the original.)

Other comments:

Patrik Faltstrom: Doesn't preclude other pre-processing before it,

which some people have worried it would. But even so, IETF really

needs to have one standard way of processing Unicode.

James Seng: When you say one standard way, do you mean one with flexibility

for locale, or essentially fixed?

Patrik Falstrom: Essentially fixed.

Dave Crocker: I thank Patrik for his comments that helped clarify

things for me. I used to be resistant to it, but am coming to accept

it. It is quite a bit like the case-insensitive/sensitive thing we're

so used to in ASCII. There are two processes here: case-mapping and

determining the legal character set. Keep them cleanly separate.

? Russell:

Wenhui Zhang: Should have a standard that includes where local issues

can be defined, which can include their standarized pre-processing.

?: Goal of working group is noble, but are trying to kill all the

birds with one stone, and so we need a really large stone. So many

legacy systems are optimized for their local languages, and will have

a lot of pain to switch to what is being planned. They don't have

much of a voice here, those who are going to suffer most.

?: Look into what happened in the LDAP group, how they ended up with a

bunch of language-specific things. It is difficult, but it can be

done, and since it has already been solved, build on it.

Erik Nordmark: Can we get back on the topic of this question? We seem to be

wandering into the general requirements area.

POLL: Many to 1 in favour of standard pre-processing step.

Post poll:

John Klensin: I can agree that a standard pre-processing step is

needed, but I can't agree if that necessarily means having a single

binary result even in ambiguous situations. Very concerned about that.

This working group might be resulting in something that is totally

irrelevant.

Eric Brunner-Williams: The ambiguity need not exist in "uniprep" (the

first of the stages observed by Dave Crocker), the problem arises in

the other part.

Paul: I think we should now work toward an architecture that includes

pre-nameprep, nameprep and post-nameprep. The middle one can be

generally standardized while the other stages need not be.

Erik Nordmark: Addressing John's concern of irrelevance, I can see how

this work would eventually be superseded by something better, but that

doesn't mean we have to stop doing this very useful work now.

Dave Crocker: Dealing with "language" is out of scope for this group, this

working group should just be about expanding the set of strings that

are usable as domain names. In that context canonicalization makes a

lot of sense, but not when we start talking about natual language.

Ted Hardie: I have to take exception to Paul describing a system that

is not standarized end-to-end; it can't include processing that is not

standardized. Also agree with Dave that we can't work with natural

language, we don't have the expertise.

?: Rigorously avoid natural languages.

Eric Chen: We need to consider natual language!

Dave Crocker: The scope is very narrow and does not include languages.

Harald: "Yes."

Paul Hoffman: Please defer all questions of language, there will be a draft

soon that addresses where it should be addressed.

Next step will be for the authors to clarify the relation between

the various proposals for processing into a cohesive architecture,

namely nameprep, tsconv, jpchar, hangeulchar.

================================================================

PROTOCOL PROPOSALS, Dave Crocker

Dave's Disclaimers:

- System oriented person

- Not a Unicode expert, or even naif

- Entirely biased -- wanted to be objective, but failed

IDN Task:

- Enhance range of domain names that are useful

- Not human "name"

- Not "language"

- Has no sets

- Requires: fairness, efficiency, reliability, transition, ...

The Usual Suspects:

Encoding Approach

1. ACE only IDNA

2. UTF-8 only IDNA-mod, uDNS

3. ACE then UTF-8 IDNA-mod, uDNS

4. ACE & UTF-8 both uDNS, uNAME

5. Anything goes uNAME

Encoding efficiency:

- ACE is an encoding scheme

- UTF-8 is an encoding scheme

- Both map many bits to a variable length string

- All variable length strings are unfair to some poeple

- Fair vs unfair unfairness:

- longer mapping mean shorter names

- shorter names restricted to information dense character sets

Encoding comparison:

1. ACE is three minuses bad.

2. UTF-8 is two minuses bad.

Charts showing that there are a lot of modules in both systems, and we

have to worry about all the modules in both systems.

ACE has an extraordinarily minimal amount of change necessary to make

an IDN useful, just two applications. This is about as good a

transition scheme as you can possibly get.

UTF-8 is an extreme in the opposite direction, it requires that

everything work end-to-end.

1. ACE only four pluses good

2. UTF-8 only five minuses bad

Transition Interactions:

-------------------------------------------------------------------------

Client-> Server-> ACE UTF-8

Server Client

-------------------------------------------------------------------------

1. old client old dn new dn transparent UTF-8 and ACE

new server maybe break client

-------------------------------------------------------------------------

2. new client, new dn old dn transparent break server?

old server

-------------------------------------------------------------------------

Specification comparison:

-------------------------------------------------------------------------

Efficiency Transition Risk/Operational

Expense

-------------------------------------------------------------------------

IDNA (ACE) bad(data) automatic none

-------------------------------------------------------------------------

how to detect

uDNS (UTF-8) poor(data) when to use ACE? high

(poorly defined

and not realistic)

-------------------------------------------------------------------------

unstated

uName (both) bad (round trip) (and based on CNRP, very, very

with no meaningful high

deployment)

-------------------------------------------------------------------------

Olafur: Hard for me to say this to you Dave, given our history, but

good job.

Harald: Think you underestimate the cost of ACE a bit, in that leakage

will confuse users. But UTF-8 leakage will also confuse users, but

likely even a bit more! But the ranking is still good.

Paul: uName doesn't actually have CNRP in it; it was put in the draft

and then explicitly shot down in the draft. It uses a new RR, but the

end result is pretty much the same as far as your conclusions go.

Erik Nordmark: Can we vote on it without a UTF-8 draft in the pool?

Would need a draft very fast.

Poll:

- idna?

Yes Most

No Some

- udns?

Yes Few

No Most

- uname?

Yes Few

No Most

Interpretation by Harald and Marc was that: IDNA was the only strongly

supported proposal in the room and the other two had

strong opposition. Interpretation was agreed by the floor.

Nameprep discussion back (some time remaining)

Paul Hoffman: Good (from a marketing sense) user interfaces will do a lot of

mucking with input. Really should have it defined how and where they

can do that. If you change machine, different local translation

tables can yield different names.

James Seng: It can be very hard to determine what local conversion

option to turn on. Not sure if this wg has capability to deal

with codepoint matching. We need to reference code points outside

the IETF, at Unicode Consortium.

Paul Hoffman: Unicode has put mapping tables out of scope.

Harald Alvestrand: This working group is internationalized access to domain

names, not localized. This group is trying to specialize what a

client must do no matter where it is in the world. I would accept a

statement that the relationship between the pre-processing drafts. It

has to be made mandatory though or it should not be part of the output

of this group.

Wenhui Zheng: IDNA draft should be explicit where the local

interface/mapping should be done.

Eric Chen: We have built a house and opened some gates but not others.

Some languages can come in and others can not. IDNA should open its

gate to allow other languages to do their thing.

================================================================

NEXT STEPS

- AMC-ACE-Z as chosen ACE.

- Reordering to be discussed on mailing list.

- relation between nameprep/tsconv/hanguelchar/jpchar/stringprep

to be consolidated into one architecture.

- Go forward with IDNA.

附錄E. MINC London Meetings

寄件者: "YJ Park (MINC)" <yjpark@minc.org>

收件者: <announce@minc.org>

主旨: [minc-announce] Final Participant List and Coordination for London MINC Meetings

日期: 2001年8月4日下午 09:31

Dear Members,

MINC secretariat is to remind that Monday and Tuesday

meetings have been designed as informal meetings among

MINC members and Invitees by MINC therefore, there will be

no specific agenda presented.

However, the draft agenda of August 9 meeting after IETF

has been restrictly circulated among MINC members and

some of Invitees.

Thank you for your cooperation in advance and we look

forward to meeting you in London soon.

MINC Secretariat

---------------------------------

MINC London Meetings

---------------------------------

MINC Informal Meeting before IETF IDN WG

Date :August 6, Monday 11:45 - 12:45

Place: Marble Arch Boardroom(Lunch)

Buffet lunch 15.00 Pounds per person

MINC-Keyword Working Group

Date: August 7, Tuesday 18:30 - 20:30

Place: Lincoln room(Dinner)

3 Course Dinner 28.50 Pounds per person

MINC Meeting after IETF IDN WG

Date: August 9, Thursday 18:00 - 20:00

Place: Salisbury Room

-------------------------------------

**All the Rooms are at Thistle Marble Arch Hotel, London

Bryanston Street, Marble Arch, London W1H 7EH.

Please, refer to map attached for the direction.

**Please, note the time for Monday meeting is 11:45 - 12:45

**Payments for Informal MINC Lunch and Dinner meeting are

expected to be paid by participants.

[Appendix]

----------------------------------------------------------

List of London MINC Meeting Participants

----------------------------------------------------------

VeriSign Jeongjun Seo

Michael Mealing

Leslie Daigle

Nominum David Lawrence(* maybe)

RealNames Nicolas Popp

Yves Arrouye

Lisal Poulson

JPNIC and JDNA Yoshiro Yoneya

Toru Takahashi

1 or 2 more likely

Netpia.com Chang Hun Lee

Jin Hyoun Bae

i-DNS James Seng (*Maybe)

Millennium Inc Asaad. Y. Alnajjar

IAK Deokjai Choi

Yangwoo Ko

Moonpyo Seo

Sunyoung Han

KAIST Kilnam Chon

IETF Patrik Faltstrom(*Tuesday only)

John Klensin(*for specific

meetings only)

James Seng(*maybe)

Harald Alverstrand (no comment)

Marc Blanchet (Yes)

TWNIC(CDNgroup) Dr. Da Wei Wong

Dr. Chun Hsing Wu

CNNIC(CDNgroup) Zhang Wenhui

Deng Xiang

KRNIC Jae-chul Sir

Chanki Park

Ahn-gu Kang

Seung-jae Lee

Dongman Lee

Neulevel Alan Sullivan

MINC Tan Tinwee(*Thursday only)

YJ Park

Total Around 35 people

附錄F. IDN mailing list發表者排行 (至2001/08/03為止)

Rank Posts Name Email

1 171 "keith moore" <moore@cs.utk.edu>

2 114 "adam m. costello" <amc@cs.berkeley.edu>

3 92 "james seng/personal" <james@seng.cc>

4 92 "d. j. bernstein" <djb@cr.yp.to>

5 87 "patrik =?iso-8859-1?q?f=e4ltstr=f6m?= " <paf@cisco.com>

6 79 "eric brunner-williams in portland maine" <brunner@nic-naa.net>

7 77 "eric a. hall" <ehall@ehsco.com>

8 73 "soobok lee" <lsb@postel.co.kr>

9 68 "martin duerst" <duerst@w3.org>

10 64 "john c klensin" <klensin@jck.com>

11 55 "paul hoffman / imc" <phoffman@imc.org>

12 55 "dave crocker" <dhc@dcrocker.net>

13 54 "dan oscarsson" <dan.oscarsson@trab.se>

14 47 "edmon" <edmon@neteka.com>

15 44 "marc blanchet" <marc.blanchet@viagenie.qc.ca>

16 36 "brian w. spolarich" <briansp@walid.com>

17 33 "mark davis" <mark@macchiato.com>

18 31 "liana.ydisg" <liana.ydisg@juno.com>

19 25 "david hopwood" <david.hopwood@zetnet.co.uk>

20 24 "j. william semich" <bill@mail.nic.nu>

21 23 "yves arrouye" <yves@realnames.com>

22 20 "martin j. duerst" <duerst@w3.org>

23 15 "bruce thomson" <bthomson@fm-net.ne.jp>

24 14 "ben" <ben@cc-www.com>

25 12 "maynard kang" <maynard@pobox.org.sg>

26 11 "rick h wesson" <wessorh@ar.com>

- 11 "jonathan rosenne" <rosenne@qsm.co.il>

- 11 "hollenbeck, scott" <shollenbeck@verisign.com>

29 10 "russ rolfe" <rrolfe@exchange.microsoft.com>

- 10 "mark.andrews" <mark.andrews@nominum.com>

- 10 "kenneth whistler" <kenw@sybase.com>

- 10 "harald alvestrand" <harald@alvestrand.no>

33 9 "roozbeh pournader" <roozbeh@sharif.edu>

- 9 "lucid" <lucid@epa.secret.org>

35 8 "deng" <deng@pier.cnnic.net.cn>

36 7 "yoshiro yoneya" <yone@po.ntts.co.jp>

- 7 "ned.freed" <ned.freed@innosoft.com>

- 7 "makoto ishisone" <ishisone@sra.co.jp>

- 7 "karlsson kent - keka" <keka@im.se>

- 7 "c c magnus gustavsson" <mag@lysator.liu.se>

41 6 "william morris" <me@williammorris.com>

- 6 "wenhui zhang" <zwh6810@yahoo.com>

- 6 "gim gyeongseog-kim kyongsok" <gimgs@asadal.cs.pusan.ac.kr>

- 6 "david r. conrad" <david.conrad@nominum.com>

- 6 "david c lawrence" <tale@nominum.com>

- 6 "d. j. bernstein c/o james seng" <james@seng.cc>

- 6 "allen smith" <easmith@beatrice.rutgers.edu>

48 5 "sherin alsoudani" <sherinalsoudani@hotmail.com>

- 5 "marc tamsky" <tamsky@www.tv>

- 5 "jim fleming" <jimfleming@prodigy.net>

- 5 "bill manning" <bmanning@isi.edu>

52 4 "tsenglm" <tsenglm@cc.ncu.edu.tw>

- 4 "sean x. zhang" <sean_xzhang@yahoo.com>

- 4 "rj atkinson" <rja@inet.org>

- 4 "mats dufberg" <dufberg@nic-se.se>

- 4 "johnny eriksson" <bygg@cafax.se>

- 4 "andrea vine" <avine@eng.sun.com>

- 4 "adonis el fakih" <adonis@ayna.com>

59 3 "zita wenzel" <zita@isi.edu>

- 3 "william tan" <william.tan@i-dns.net>

- 3 "sun guonian" <sun@cnnic.net.cn>

- 3 "maurizio codogno" <mau@beatles.cselt.it>

- 3 "joel rowbottom" <joel.rowbottom@centralnic.com>

- 3 "erik nordmark" <erik.nordmark@eng.sun.com>

- 3 "deven kalra" <kalra@langoo.net>

- 3 "carl s. gutekunst" <csg@eng.sun.com>

67 2 "xiang deng" <deng@cnnic.net.cn>

- 2 "thaweesak taekratok" <taekratt@gorgai.com>

- 2 "tan tin wee" <tinwee@bic.nus.edu.sg>

- 2 "paul v. mockapetris" <pvm@a21.com>

- 2 "michael mealling" <michael@bailey.dscga.com>

- 2 "mark welter" <mwelter@walid.com>

- 2 "larson, matt" <mlarson@verisign.com>

- 2 "jeff williams" <jwkckid1@ix.netcom.com>

- 2 "florian weimer" <fw@deneb.enyo.de>

- 2 "erin chen" <erin@twnic.net.tw>

- 2 "dlee" <dlee@icu.ac.kr>

- 2 "david leung" <david@neteka.com>

- 2 "dan ebert" <dan@enic.cc>

- 2 "bright fulton" <bright@alldomains.com>

- 2 "bob jung" <bobj@netscape.com>

- 2 "=?iso-8859-1?q?m=e5ns_nilsson?=" <mansaxel@besserwisser.org>

83 1 "zhu yu" <yu.zhu@i-dns.net>

- 1 "xiaodong.lee" <xiaodong.lee@usa.net>

- 1 "vint cerf" <vcerf@mci.net>

- 1 "vietanh" <vietanh1977@yahoo.com>

- 1 "tony hansen" <tony@att.com>

- 1 "the iesg" <iesg-secretary@ietf.org>

- 1 "sung jae shim" <sshim@mailbox.fdu.edu>

- 1 "steve hanna" <steve.hanna@sun.com>

- 1 "steve atkins" <steve@blighty.com>

- 1 "stephen dyer" <steve@uk.com>

- 1 "shaun marquardt" <shaunm@mahjongplayer.com>

- 1 "robert" <robert@chalmers.com.au>

- 1 "randy bush" <randy@psg.com>

- 1 "mike astle" <astle@new.net>

- 1 "maruyama" <maruyama@nic.ad.jp>

- 1 "martin oldfield" <m@mail.tc>

- 1 "marco d'itri" <md@linux.it>

- 1 "mansaxel" <mansaxel@besserwisser.org>

- 1 "levon esibov" <levone@windows.microsoft.com>

- 1 "lee" <lee@pier.cnnic.net.cn>

- 1 "kenny huang" <huangk@alum.sinica.edu>

- 1 "jorge amodio" <jamodio@verio.net>

- 1 "jarallah aljarallah" <jar@nativenames.net>

- 1 "james m galvin" <galvin@acm.org>

- 1 "jacob palme" <jpalme@dsv.su.se>

- 1 "j. douglas hawkins" <dhawkins@walid.com>

- 1 "ian king" <iking@microsoft.com>

- 1 "gary krall" <gary@langoo.net>

- 1 "donald e. eastlake 3rd" <dee3@torque.pothole.com>

- 1 "colosi, john" <jcolosi@verisign.com>

- 1 "bob halley" <bob.halley@nominum.com>

- 1 "alfred novacek" <novacek@pop.idv.uni-linz.ac.at>

- 1 "alan barrett" <apb@cequrux.com>

- 1 "=?iso-8859-1?q?keld_j=f8rn_simonsen?=" <keld@dkuug.dk>

(117) 1 "=?gb2312?q?xiang=20deng?=" <deng_xiang@yahoo.com.cn>

附錄G. UNAME Draft原擬發表的投影片

一、 出國目的

二、 考察訪問過程

三、 考察、訪問心得

四、 建議意見

五、 其他相關事項或資料

一、出國目的

二、考察訪問過程

三、考察、訪問心得

四、建議意見

五、其他相關事項或資料