Transcript Using SNMP to Monitor an Adaptive MPLS Environment

Network Standard
1
Contents







기술 특허의 중요성
유선망 구조
무선망 구조
유선망 표준 단체
무선망 표준 단체
IEEE 표준화
기술 표준과 산업체 표준
 IEEE 802.16e (Wibro)
 Mobile WiMax Forum
 Internet Standard Organizations
 IETF
2
기술 특허의 중요성 (1)
3
기술 특허의 중요성 (2)
4
유선망 구조
Net 1
유선 전화망
Net 2
LATA 1
LATA 2
Broadband Access
ADSL(CO)
8Mbps
L2 SW
Ntopia
Ethernet
(Ntopia) 100Mbps
Apart
ATM ADSL
DSLAM
CO
FE
L3 SW
Apart
CO
GE
20/10Mbps
VSDL
(Apart)
IP ADSL
L3
SW
NAS
Premium IP Networks
(MPLS)
E
C
C
E
FE
GE
VDSL
POP
ER
ER
CO
GE
전송망(SDH/DWDM)
FE
VDSL
Curb
50Mbps
일반주택
FE
Curb
맨홀, 전주
FTTC+
Ethernet
(AON)
FTTP
Ethernet
일반주택
Ethernet
100M/1
100Mbps
100M/16
ONU
IP ADSL2+
DSLAM
PON
OLT
ONT
FTTH
PON
OLT
GE
N
GE
CO
CO
FTTC+
VSDL
GE
Best-Effort IP Networks
R
R
R
R
Apart
IP ADSL
(CO)
CO
POP
IP VDSL
50Mbps
8Mbps/4Mbps
(500Kbps)
155Mbps
전주
100Mbps
일반주택
5
무선망 구조
Location /
Billing /
AAA
Servers
RGW
Home
Network
Soft
Switch
AP
WLAN
Edge
Ethernet
xDSL
WiBro
AR
AP
AP
BcN Core
WLAN
DMB
AP
WMGW
cdma2000
WCDMA
BTS/Node-B
(ATM, SDH)
PDSN
GGSN
BSC/RNC
(ATM, SDH)
Mobile Router
BSC/RNC
(IP Transport)
BTS/Node-B
(IP Transport)
6
GPS
NEMO
(Telematics)
유선망 별 표준화 기구
Net 1
유선 전화망
Net 2
LATA 1
LATA 2
Broadband Access
ADSL(CO)
8Mbps
L2 SW
Ntopia
Ethernet
(Ntopia) 100Mbps
Apart
ATM ADSL
DSLAM
CO
FE
L3 SW
Apart
CO
GE
20/10Mbps
VSDL
(Apart)
IP ADSL
L3
SW
NAS
Premium IP Networks
(MPLS)
E
C
C
E
FE
GE
VDSL
POP
ER
ER
CO
GE
전송망(SDH/DWDM)
FE
VDSL
Curb
50Mbps
일반주택
FE
Curb
맨홀, 전주
FTTC+
Ethernet
(AON)
FTTP
Ethernet
일반주택
Ethernet
100M/1
100Mbps
100M/16
ONU
IP ADSL2+
DSLAM
PON
OLT
ONT
FTTH
PON
OLT
GE
N
GE
CO
CO
FTTC+
VSDL
GE
Best-Effort IP Networks
R
R
R
R
Apart
IP ADSL
(CO)
CO
POP
IP VDSL
50Mbps
8Mbps/4Mbps
(500Kbps)
155Mbps
전주
100Mbps
일반주택
7
무선망 별 표준화 기구
Location /
Billing /
AAA
Servers
RGW
Home
Network
Soft
Switch
AP
WLAN
Edge
Ethernet
xDSL
WiBro
AR
AP
AP
BcN Core
WLAN
DMB
AP
WMGW
cdma2000
WCDMA
BTS/Node-B
(ATM, SDH)
PDSN
GGSN
BSC/RNC
(ATM, SDH)
Mobile Router
BSC/RNC
(IP Transport)
BTS/Node-B
(IP Transport)
8
GPS
NEMO
(Telematics)
IEEE (Institute of Electrical and
Electronics Engineers)의 표준화
9
IEEE 조직도
NesCom
 Project 802



IEEE computer society의 sponsorship으로 운영
1980년 2월에 설립된 비영리 프로젝트 위원회
설립목적: 개방적, 신뢰적 프로세서 도용을 통한 LAN/MAN (OSI 하위 2계층)에 대한 표
준 및 권고안 개발
 표준화 회의


Plenary: 3회/년
Interim: WG별로 실시
10
LMSC (LAN/MAN Standard Committee) 조직도
유선 LAN
(Ethernet)
무선 LAN
WiBro
11
표준 개발을 위한 5가지 기준
 Broad Market Potential
 넓은 분야의 응용
 다양한 분야의 벤더와 많은 사용자
 표준에 대한 경쟁력 있는 비용 제시
 Compatibility
 모든 표준은 IEEE 802에서 정의한 구조, 관리, 인터네트워킹 관련 문서에 부
합되야 한다.
 Distinct Identity
 모든 IEEE 표준은 각기 서로 다른 명백한 주체성을 지녀야 한다
 즉, 모든 프로젝트는
• IEEE 802 표준과는 실질적으로 다르고,
• 프로젝트에서 발생되는 문제점에 대한 유일한 해결책을 지녀야 하며
• 적절한 용어를 선택하여 표준 문서의 독자가 이해하기 쉽게 해야 한다
 Technical Feasibility
 최소한 제안된 프로젝트는 인증된 시스템 가능성, 증명된 기술, 논리적인 테
스트 및 기술에 대한 확신이 있어야 함
 Economic Feasibility
 최소한 제안된 프로젝트는 데이터를 통한 비용요소, 표준 실현을 위한 이유
있는 비용요소 및 설치비용에 대한 고려 등을 제시해야 함
12
표준화 승인절차
Sponsor 선정
PAR (Project Authorization Request) 제출
13
Project Approval Process
 PAR (Project Authorization Request)
 새로운 프로젝트를 위한 범위, 프로젝트의 목적 및 contact point를 명시한 공
식 문서
 수명: 4년
 PAR 승인 절차
NesCom: New Standards Committee of the IEEE-SA Standard Board
14
표준초안 개발과정 (Development Draft Standard)
WG 참가자는 IEEE-SA 회원일 필요 없음
Use scope &
purpose from
PAR
관련 표준과 출
판물 점검
Draft Outline
Fill in Outline
Revise, revise,
revise, …
Finalize
document
15
Sponsor Ballot
 Ballot
 제안된 표준 초안을 새로운
표준으로 개발하거나 기존 표
준의 재확인, 개정, 철회를 위
해 Balloting Group에 의해 수
행되는 과정
 투표인단의 75% 응답 및 응답
자의 75% 이상 찬성인 경우
승인
16
IEEE-SA Standard Board Approval
 Review Committee (RevCom)
 표준 초안이 IEEE 표준개발과정 절차를 이행했는지 검사
 투표 과정 중 발생된 반대의견 논평에 대한 solution 점검
 IEEE-SA Standard Board가 표준 최종 승인을 위한 의견 제시
17
표준화 작업물
 표준 (Standards)
 의무적인 요구 사항을 기술한 문서
 Recommended Practices
 IEEE가 권고 (recommend)하는 문서로 기술에 관련된 절차 또는 위
치를 기술한 문서
 Guides
 사용자로 하여금 선택적으로 기술에 대한 접근을 기술한 문서이지만
IEEE의 권고 사항은 아님
 Trial-Use Documents
 공표한지 2년 동안만 유효한 표준
18
IEEE 802.16 기술 표준 / WiMax / WiBro
19
Global Wireless Standards
20
무선 망에서 WiBro의 위치
Cell Coverage
Mobility
Voice-Centric
250km/hr
Data-Centric
120km/hr
2G
Cellular
(IS-95,
CDMA)
60km/hr
1km
Codeless
Phone
0.1km
Wireless LAN (WLAN)
Wired
Phone
Blutooth
ZigBee
1Mbps
xDSL
11Mbps
54Mbps
21
Data Rate
IEEE 802.16 Wireless MAN®
 Wireless MAN을 위한 Broadband Wireless Access 기술, 표준 규
격, “Last Mile”
22
802.16 Standard History
23
IEEE 802.16 WG 산하 Projects
TG NetMan: P802.16g
(Management Plane Procedures
and Services)
amend
IEEE 802.16 Air Interface
for Mobility
TGe: Std 802.16e-2005
(Enhancements to support
mobility)
IEEE 802.16 Air Interface
amend
TGa: IEEE Std 802.16a-2003
for Fixed System
(Enhancement including 2-11
GHz)
amend
TG: IEEE Std 802.16-2001
(Air Interface for 10-66 GHz)
Incor
-porate
TGd: IEEE Std 802.16-2004
(Revision, incorporating and
obsoleting IEEE Std 802.162001 and its two amendments)
amend
TG Maintenance: P802.162004/Cor1 (Corrigendum to
IEEE Std 802.16-2004)
TG NetMan: P802.16f (MIB)
amend
TGc: IEEE 802.16c-2003
(Enhancement including 10-66
GHz Profiles)
TG Relay: P802.16j
802.16 Mobile Multihop Relay (MMR)
24
amend
Protocol Stack
기지국
단말기
- Transformation of external
network data into MAC SDUs
- Classification
- Payload header suppression
- System Access
- Bandwidth Allocation
- Connection setup
- Connection maintenance
- QoS support
Security Sublayer
Security Sublayer
- Single Carrier (SC)
- OFDM
- OFDMA
25
From Fixed Terminal to Mobile Terminal
26
Example: Idle Mode/Paging
Traffic
backbone network
Between BSs
Paging Group
5)
4)
1)
2)
3)
이동
27
Technology Comparison
28
Spectral efficiency comparison
29
Network throughput comparison
30
802.16 Standardization Procedure
Task Group 결성 및 PAR (Project
Authorization Request) 작성
Task Group Scope에 대한 Call for
Contributions
주요 Contribution 및 Comment 제출
TG내에서의 Working Document에 대
한 Review (1/2 찬성)
Baseline Document 채택 및 Review
(3/4 찬성)
주요 Contribution 및 Comment 제출
Working Group Ballot (3/4 찬성)
주요 Contribution 및 Comment 제출
Sponsor Ballot (Sponsor 3/4 찬성)
RevCom 제출 및 승인
31
What is WiBro?
 WiBro is a “Service” name
 정보통신부 (2002.10.31) & TTA: 2.3GHz 대역의 주파수 이용하여 정지 및 이동 중에
서도 언제, 어디서나 고속으로 무선 인터넷 접속이 가능한 서비스
Whenever, Wherever
(seamless wireless Internet access)
Home
Building
University
Full Mobility
(more than 100km/hr)
Subway
on the street
Car
High Data Rate
(1Mbps per user)
Low Access Cost
(lower than existing mobile Internet)
Airport
Various User
Terminals
Laptop
PDA
Smart Phone
WiBro is a “Standard” based on IEEE 802.16-2004 & IEEE 802.16e-2005
TTAS.KO-06.0064/R1 2.3GHz 휴대인터넷표준 – 물리계층 04-12-23
TTAS.KO-06.0065/R1 2.3GHz 휴대인터넷표준 – 매체접근제어계층 04-12-23
TTAS.KO-06.0082/R1 2.3GHz 휴대인터넷표준 – 물리계층 및 MAC 계층 05-12-21
32
Location of WiBro in Wireless Networks
Cell Coverage
Mobility
Voice-Centric
250km/hr
Data-Centric
120km/hr
2G
Cellular
(IS-95,
CDMA)
60km/hr
1km
Codeless
Phone
0.1km
Wireless LAN (WLAN)
Wired
Phone
Bluetooth
ZigBee
1Mbps
xDSL
11Mbps
54Mbps
33
Data Rate
WiBro Network Architecture
 PSS
servers




Public IP Networks
HA
AAA
Router
WiBro Wireless Access
IP-based Service Access
IP Mobility
Terminal/User Authentication
 RAS
 WiBro Wireless Access
 Wired/Wireless Channel Conversion
 Radio Resource Control &
Management
 L2 Mobility Control
 L2 QoS Provisioning
ACR
ACR
RAS
RAS
RAS
RAS
PSS
PSS
 ACR
PSS




PSS: Personal Subscriber Station (=Mobile Node: MN)
RAS: Radio Access Station (=Base Station: BS)
ACR: Access Control Router (=Access Router: AR)
HA: Home Agent
AAA: Authentication, Authorization and Accounting
34
IP Routing
IP Mobility Management
Authentication and Security
Resource Control & Management
WiMax Forum
 Beyond IEEE

IEEE only publishes standards for layer 1 & 2
•

Air Interface = MAC, PHY and radio
Need an e2e system-level definition for system interoperability
•
•
•
NW architecture for RAN (Radio Access Network)
RAS to RAS; RAS to core network / data center
Look to WiMAX Forum to champion layer 3+ interoperability similar to what Wi-Fi Alliance has
done in the areas of VoIP, AAA, etc.
 WiMax Forum

A non-profit organization comprised of broadband wireless access system
manufacturers, component (silicon, RF, antenna) suppliers, software developers and
carriers to drive a common platform for the global deployment of high-performance IPbased broadband wireless services

The WiMAX Forum was founded in April ’01 for IEEE 802.16 standard for 10-66 GHz
•

Since Jan ‘03, membership has increase to more than 70 members
•

Currently, 345 member companies
WiMAX first based on the IEEE 802.16-2004 standard
•

In Jan ‘03, standard was extended to include < 11 GHz
Provision of fixed BWA services
IEEE 802.16e will add mobility to WiMAX
•
•
802.16e ratified in Dec. 2005.
WiMAX Forum certification procedure for 802.16e expected to start in 2 nd half 2006.
35
The WiMAX Forum Membership
2006
36
802.16 vs. WiMAX Forum WG
37
Certification Profile: 802.16e-2005 (OFDMA)
38
Certification Process
PICS (Protocol Implementation and Conformance Statement)
PIXIT (Profile Initialization for Test Cases)
PIXIT (Protocol Implementation Extra Information for Testing)
TSS&TP (Test Suite Structure and Test Purposes)
RCT (Radio Conformance Test)
ATS (Abstract Test Suit)
39
Network WG (NWG)’s Role
40
IETF Structure and Internet Standards
Process
From a documents for IETF newcomers by Scott
Bradner, 64th IETF Vancouver, BC, Canada
41
The IETF
 Internet Engineering Task Force
 formed in 1986
 was not considered important for a long time - good!!
 not government approved - great!!
 people not companies
“We reject kings, presidents and voting. We believe
in rough consensus and running code”
Dave Clark
42
IETF Overview
 Internet standards R us
 does not exist, no members, no voting
 1K to 2K people at 3/year meetings
 many more on mail lists
 123ish working groups (where the stuff happens)
 78 areas (for organizational convenience) with ADs
 APS, GEN, INT, O&M, RAI, RTG, SEC, TSV
 IESG: management (ADs, chosen by community)
 IAB: architectural guidance & liaisons
 produces standards and other documents
43
IETF “Standards”
 standards only when people use them
 formal SDOs can create legally mandated
standards
 no formal recognition for IETF standards
 by governments or “approved” standards
organization
 lack of formal government input “a problem”
at least to some governments
 no submitting to “traditional” bodies

 some keep trying to “help”
44
The Role & Scope of the IETF
 “above the wire and below the
application”
 IP, TCP, email, routing,
IPsec, HTTP, FTP, ssh,
LDAP, SIP, mobile IP,
ppp, RADIUS, Kerberos,
secure email,streaming
video & audio, ...
 but wires are getting fuzzy
 MPLS, GMPLS, pwe3,
VPN, ...
 generally hard to clearly define
IETF scope

constant exploration of
edges
HTTP
DNS
SMTP
RTP
Distributed
applications
Reliable
stream
service
TCP
Best-effort
connectionless packet
transfer
User
datagram
service
UDP
IP
(ICMP, ARP)
Network
Network
Network
interface 1
interface 2
interface 3
Diverse network technologies
45
Scope of Other SDOs
 Internet (and Internet protocols) very interesting to other
standards development organizations (SDO)
 other SDOs trying “fix” or “extend” IETF protocols
 trying to figure out how to proceed when extensions
break underlying protocol assumptions
 see note to ITU-T
 https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=127
46
Top Level View of Organization
Internet
Society
IAD
IASA IESG
IAB
IRTF
area
IANA
IANA
RFC
area
“the IETF”
47
area
Standardization Bodies
 Internet Society (ISOC)
 Professional society to facilitate, support, and promote the
evolution and growth of the Internet as a global research
communication infrastructure
 Internet Architecture Board (IAB)
 Technical oversight and coordination body.
 Composed of 15 international volunteers from various disciplines
 Serves as a final editorial and technical review board for the
quality of Internet standards
 IAB falls under the ISOC
 Internet Engineering Task Force (IETF)
 Near-term, standard-oriented group divided into 9 areas
 Develop the specifications that become Internet standards
 Additional Internet Engineering Steering Group (IESG) was
formed to help the IETF chair
 IETF falls under the IAB
 Internet Research Task Force (IRTF)
 Pursues long-term research project
 IRTF falls under the IAB
48
Internet Assigned Number Authority (IANA)
 assigns numbers and keeps them from colliding
 protocol numbers
 IP addresses
 mostly delegated to IP 5 regional Address registries
 domain names
 deals with top level domains (TLDs)
 mostly delegated to DNS name registries
 functions split with the creation of ICANN
 Internet Corporation for Assigned Names and
Numbers
 (semi) independent corp. to take over IANA functions

(continuing) contract with US government
49
Dots
 IAB member (red)
 IESG member (yellow)
 Working Group chair (blue)
 nomcom (orange)
 Local host (green)
50
Standards Procedure
 generally Birds of a Feather (BOF) first
 most work done in a Working Group
 proposals published as Internet Drafts
 proposal reviewed by AD
 can be sent back to working group
 IETF Last-Call (4-week if no Working Group)
 IESG review
 can be sent back to working group
 publication as RFC
51
Birds of a Feather Sessions (BOF)
 usually precede formation of a Working Group
 group of people interested in a topic
 convince an AD that they have a good idea - one worth
exploring
 need description and agenda before a BOF can be
scheduled
 BOFs generally only meet once
 can lead to a WG or can be a one time thing
52
Working Groups
 this is where the IETF primarily get its work done
 on mailing list
 face-to-face meetings focused on key issues
(ideally)
note: face-to-face meetings generally very short
 working group focused by charter agreed between chair and
area director
 restrictive charters with milestones
 working groups closed when their work is done
 charter approved by IESG with IAB advice
 AD with IESG has final say on charter

53
Working Group Creation
Chair, description,
goals and milestones
community
may have BOF
Area Director
new-work &
IETF Announce
IESG
Working group created
54
IAB
Working Groups. contd.
 no defined membership
 just participants
 “Rough consensus and running code...”
 no formal voting





can do show of hands or hum - but no count
does not require unanimity
disputes resolved by discussion
mailing list and face-to-face meetings
final decisions must be verified on mailing list
taking into account face-to-face discussion
55
IETF Submission
Working group doc, or
individual standards track doc
Submit
Concerns
IESG
RFC Editor
“Last Call”
Comments,
suggestions
IETF Community
Review
56
Published RFC
Non-IETF Submissions
individual
Content concerns and
editorial details
Submit
Comments
RFC Editor
IESG
Publish
57
IETF Documents
 all IETF documents are open
 Internet Draft
 IETF working documents
 some I-Ds are working group documents
 RFC
 archival publications (never changed once
published)
 different types: (not all RFCs are standards!)
58
IETF Working Documents
 Internet-Draft
 random or non-random thoughts
 input to the process
 no admissions control other than boilerplate (see
IPR)
 zapped from IETF directory after 6 months

but many mirrors exist
 all RFCs must pre-exist as IDs


to deal with IPR handoff
other than IANA or RFC Editor created ones
59
What is a RFC?
 RFC used to stand for Request for Comments
 now just a (brand) name
 tend to be more formal documents than early RFCs
 IETF document publication series
 RFC 1 Host Software - Apr 7 1969
 now over 4000 RFCs
 not all RFCs are standards!
 see RFC 1796
 though some vendors imply otherwise
 many types of RFCs
60
RFC Repository Contains:
standards track
poetry
‘Twas the night before
startup
OSPF, IPv6, IPsec ...
obsolete Standards
RIPv1
white papers
On packet switches with
infinite storage
requirements
Host Requirements
policies
corporate documentation
Ascend multilink protocol
(mp+)
Classless InterDomain
experimental history
Routing
Netblt
april fool’s day jokes
IP on Avian Carriers ...
 ... updated for QoS
process documents
IETF Standards Process
61
RFC Editor
 IETF publication arm
 [email protected]
 funded by the Internet Society
 semi-independent
 gets requests to publish IETF IDs from IESG
 also gets requests to publish independent IDs for
info or exp RFCs
asks IESG for advice on publishing independent RFCs
but can exercise own discretion presumption is to
publish technically competent IDs which sometimes is
a conflict with IESG
62
Standards Track RFCs:
 Best Current Practices (BCP)
 policies or procedures (best way we know how)
 3-stage standards track (currently under review)
 Proposed Standard (PS)

good idea, no known problems
Enter
 Draft Standard (DS)



stable
multiple interoperable implementations
note: interoperability not conformance
 Internet Standard (STD)

Experimental
Proposed
standard
Draft
Standard
Standard
wide use
Historical
63
Other RFC Types
 Informational
 Experimental
 Historical
64
Appeals Process
IETF decisions can be appealed
start level above decision being appealed
1st to the WG chair(s)
only then to the Area Director
only then to the IESG
only then to the IAB
if claim is that the process has not been followed,
only then an appeal can be made to the ISOC Board
it is OK to appeal decisions – people do
but appeals are not quick
starting “low” is the right thing to do
65
Intellectual Property Rights
 IPR is a very big issue in standards bodies
 what to do if there is a patent on the technology
 what about patent applications?
 what if you do not know until it’s already a standard?
 demand open rights to implement?
 require “fair & non-discriminatory” licensing?
 what if IPR claim is false?


e.g. an attempt to block the standard
should the standards body evaluate patents?
66
Patents - Issues
 getting pressure from the open source folk for standards
with no (known?) IPR
 maybe in some parallel universe
 see AU “Innovation Patent” AU 2001100012 A4 (8/01)
 also U.S. Patent 5,443,036 (8/95)
67
IPR (Patents)
 RFC 2026 revised IETF IPR rules
 used to require “fair & non-discriminatory” licensing
 some standards blocked using old process
 now use standards sequence to check IPR issues
 require multiple implementations based on multiple
licenses to progress to Draft Standard or Internet
Standard
 but a worry about “submarine patents”
 IPR working group
 clear up fuzzy language in RFC 2026
 produced RFC 3978 and RFC 3979
68
IPR, contd.
 IETF IPR (patent) rules in RFC 3979
 require timely disclosure of your own IPR in your
own submissions & submissions of others
 “reasonably and personally” known IPR
• i.e., no patent search required
 WG takes IPR into account when choosing solution
 RFC 3669 gives background and guidance
 push from open source people for RF-only process
 consensus to not change to mandatory RF-only
• but many WGs tend to want RF or IPR-free
69
IPR (Copyright)
 author(s) need to give non-exclusive publication rights to
ISOC (IETF) if to be published at all
 also (normally) the right to make derivative works
 author(s) retain all other rights
 mandatory ID boilerplate statement

1/ agreement that IPR disclosures have been (or
will be) made
 2/ (optional) no right to produce derivative works
• not permitted for standards track documents


3/ (optional) just publish as ID
4/ Copyright statement
70
IETF IPR Trust
 legal trust
 container for IETF-related IPR e.g.:
copyrights
domain names
software
documents
 not a patent pool
IETF owns no patents
 in process
71
Note Well (1)
 The “Note Well” statement shows up a lot at the IETF.
Mailing lists, registration, meeting openings, etc.
 “Any submission to the IETF intended by the Contributor for
publication as all or part of an IETF Internet-Draft or RFC and any
statement made within the context of an IETF activity is considered an
"IETF Contribution".
 continued ...
72
Note Well (2)
 “Such statements include oral statements in IETF sessions, as well as
written and electronic communications made at any time or place, which
are addressed to:
• the IETF plenary session
• any IETF working group or portion thereof
• the IESG, or any member thereof on behalf of the IESG
• the IAB or any member thereof on behalf of the IAB
• any IETF mailing list, including the IETF list itself,
any working group or design team list, or any
other list functioning under IETF auspices
• the RFC Editor or the Internet-Drafts function”
 continued ...
73
Note Well (3)
 “All IETF Contributions are subject to the rules of RFC 3978 and RFC
3979.
 Statements made outside of an IETF session, mailing list or other
function, that are clearly not intended to be input to an IETF activity,
group or function, are not IETF Contributions in the context of this
notice.
 Please consult RFC 3978 for details.”
74
What next?
 join mailing lists
 This is where the work happens
 read the drafts
 don’t be shy
 talk to people
 look for common ground
 help people
 don’t settle for settle for second-rate
75