< draft-iab-model-00.txt		draft-iab-model-01.txt >
			E. Rescorla
	E. Rescorla
	RTFM, Inc.		RTFM, Inc.
	INTERNET-DRAFT IAB		INTERNET-DRAFT IAB
	draft-iab-model-00.txt October 2003 (Expires April 2004)		draft-iab-model-01.txt May 2004 (Expires November 2004)
	Writing Protocol Models		Writing Protocol Models
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026. Internet-Drafts are working		all provisions of Section 10 of RFC2026. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	skipping to change at page 3, line ? ¶		skipping to change at page 3, line ? ¶
	2. What messages are being transmitted and what do they		2. What messages are being transmitted and what do they
	mean?		mean?
	3. What are the important but un-obvious features of the		3. What are the important but un-obvious features of the
	protocol?		protocol?
	The basic idea is to provide enough information that the reader could		The basic idea is to provide enough information that the reader could
	design a protocol which was roughly isomorphic to the protocol being		design a protocol which was roughly isomorphic to the protocol being
	described. This doesn't, of course, mean that the protocol would be		described. This doesn't, of course, mean that the protocol would be
	identical, but merely that it would share most important features.		identical, but merely that it would share most important features.
	For instance, the decision to use a KDC-based authentication model is		For instance, the decision to use a KDC-based authentication model is
	an essential feature of Kerberos [REF]. By constrast, the use of		an essential feature of Kerberos [KERBEROS]. By constrast, the use of
	ASN.1 is a simple implementation decision. S-expressions--or XML, had		ASN.1 is a simple implementation decision. S-expressions--or XML, had
	it existed at the time--would have served equally well.		it existed at the time--would have served equally well.
	3. Basic Principles		3. Basic Principles
	In this section we discuss basic principles that should guide your		In this section we discuss basic principles that should guide your
	presentation.		presentation.
	3.1. Less is more		3.1. Less is more
	skipping to change at page 3, line ? ¶		skipping to change at page 3, line ? ¶
	3.3. A few well-chosen detail sometimes helps		3.3. A few well-chosen detail sometimes helps
	The converse of the the previous principle is that sometimes details		The converse of the the previous principle is that sometimes details
	help to bring a description into focus. Many people work better when		help to bring a description into focus. Many people work better when
	given examples. Thus, it's often a good approach to talk about the		given examples. Thus, it's often a good approach to talk about the
	material in the abstract and then provide a concrete description of		material in the abstract and then provide a concrete description of
	one specific piece to bring it into focus. Authors should focus on		one specific piece to bring it into focus. Authors should focus on
	the normal path. Error cases and corner cases should only be dis-		the normal path. Error cases and corner cases should only be dis-
	cussed where they help illustrate some important point.		cussed where they help illustrate some important point.
	[QUESTION: Would it help to explicitly indicate use of these techniques
	in the examples that follow?]
	4. Writing Protocol Models		4. Writing Protocol Models
	Our experience indicates that it's easiest to grasp protocol models		Our experience indicates that it's easiest to grasp protocol models
	when they're presented in visual form. We recommend a presentation		when they're presented in visual form. We recommend a presentation
	format that is centered around a few key diagrams with explanatory		format that is centered around a few key diagrams with explanatory
	text for each. These diagrams should be simple and typically consist		text for each. These diagrams should be simple and typically consist
	of "boxes and arrows"--boxes representing the major components,		of "boxes and arrows"--boxes representing the major components,
	arrows representing their relationships and labels indicating impor-		arrows representing their relationships and labels indicating impor-
	tant features.		tant features.
	We recommend a presentation structured in three parts to match the		We recommend a presentation structured in three parts to match the
	three questions mentioned in the previous sections. Each part should		three questions mentioned in the previous sections. Each part should
	contain 1-3 diagrams intended to illustrate the relevant points.		contain 1-3 diagrams intended to illustrate the relevant points.
	4.1. Describe the problem you're trying to solve?		4.1. Describe the problem you're trying to solve
	First, figure out what you are trying to do (this is good		First, figure out what you are trying to do (this is good
	advice under most circumstances, and it is especially apropos here.		advice under most circumstances, and it is especially apropos here.
	--NNTP Installation Guide		--NNTP Installation Guide
	The absolutely most critical task that a protocol model must perform		The absolutely most critical task that a protocol model must perform
	is to explain what the protocol is trying to achieve. This provides		is to explain what the protocol is trying to achieve. This provides
	crucial context for understanding how the protocol works and whether		crucial context for understanding how the protocol works and whether
	it meets its goals. Given the desired goals, in most cases an		it meets its goals. Given the desired goals, in most cases an experi-
	experienced reviewer will have an idea of how they would approach the		enced reviewer will have an idea of how they would approach the prob-
	problem and be able to compare that to the approach taken by the pro-		lem and be able to compare that to the approach taken by the protocol
	tocol under review.		under review.
	The "Problem" section of the model should start out with a short		The "Problem" section of the model should start out with a short
	statement of the environments in which the protocol is expected to be		statement of the environments in which the protocol is expected to be
	used. This section should describe the relevant entities and the		used. This section should describe the relevant entities and the
	likely scenarios under which they participate in the protocol. The		likely scenarios under which they participate in the protocol. The
	Problem section should feature a diagram showing the major communi-		Problem section should feature a diagram showing the major communi-
	cating parties and their inter-relationships. It is particularly		cating parties and their inter-relationships. It is particularly
	important to lay out the trust relationships between the various par-		important to lay out the trust relationships between the various par-
	ties as these are often un-obvious.		ties as these are often un-obvious.
	skipping to change at page 5, line ? ¶		skipping to change at page 5, line ? ¶
	of classes of service from behind the NAT gateway. This is a particu-		of classes of service from behind the NAT gateway. This is a particu-
	lar problem when protocols need to advertise address/port pairs as		lar problem when protocols need to advertise address/port pairs as
	part of the application layer protocol. Although the NAT can be con-		part of the application layer protocol. Although the NAT can be con-
	figured to accept data destined for that port, address translation		figured to accept data destined for that port, address translation
	means that the address that the application knows about is not the		means that the address that the application knows about is not the
	same as the one that it is reachable on.		same as the one that it is reachable on.
	Consider the scenario represented in the figure below. A SIP client		Consider the scenario represented in the figure below. A SIP client
	is initiating a session with a SIP server in which it wants the SIP		is initiating a session with a SIP server in which it wants the SIP
	server to send it some media. In its Session Description Protocol		server to send it some media. In its Session Description Protocol
	(SDP) [REF] request it provides the IP and port on which it is lis-		(SDP) [SDP] request it provides the IP and port on which it is lis-
	tening. However, unbeknownst to the client, a NAT is in the way. It		tening. However, unbeknownst to the client, a NAT is in the way. It
	translates the IP address in the header, but unless it is SIP aware,		translates the IP address in the header, but unless it is SIP aware,
	it doesn't change the address in the request. The result is that the		it doesn't change the address in the request. The result is that the
	media goes into a black hole.		media goes into a black hole.
	+-----------+		+-----------+
	| SIP |		| SIP |
	| Server |		| Server |
	| |		| |
	+-----------+		+-----------+
	skipping to change at page 5, line ? ¶		skipping to change at page 5, line ? ¶
	| [FROM: 10.0.10.5:6791]		| [FROM: 10.0.10.5:6791]
	| [MSG: SEND MEDIA TO 10.0.10.5:6791]		| [MSG: SEND MEDIA TO 10.0.10.5:6791]
	|		|
	10.0.10.5		10.0.10.5
	+-----------+		+-----------+
	| SIP |		| SIP |
	| Client |		| Client |
	| |		| |
	+-----------+		+-----------+
	The purpose of STUN is to allow clients to detect this situation and		The purpose of STUN [STUN] is to allow clients to detect this situation
	determine the address mapping. They can then place the appropriate		and determine the address mapping. They can then place the appropriate
	address in their application-level messages. This is done by making use		address in their application-level messages. This is done by making use
	of an external STUN server. That server is able to determine the trans-		of an external STUN server. That server is able to determine the trans-
	lated address and tell the STUN client, as shown below.		lated address and tell the STUN client, as shown below.
	+-----------+		+-----------+
	| STUN |		| STUN |
	| Server |		| Server |
	| |		| |
	+-----------+		+-----------+
	^ |		^ |
	skipping to change at page 7, line ? ¶		skipping to change at page 7, line ? ¶
	4.3. State Machines		4.3. State Machines
	In certain cases, it may be helpful to provide a state machine		In certain cases, it may be helpful to provide a state machine
	description of the behavior of network elements. However, such state		description of the behavior of network elements. However, such state
	machines should be kept as minimal as possible. Remember that the		machines should be kept as minimal as possible. Remember that the
	purpose is to promote high-level comprehension, not complete under-		purpose is to promote high-level comprehension, not complete under-
	standing.		standing.
	4.4. Example: DCCP		4.4. Example: DCCP
	Although DCCP is datagram oriented like UDP, it is stateful like TCP.		Although DCCP [DCCP] is datagram oriented like UDP, it is stateful
	Connections go through the following phases:		like TCP. Connections go through the following phases:
	1. Initiation		1. Initiation
	2. Feature negotiation		2. Feature negotiation
	3. Data transfer		3. Data transfer
	4. Termination		4. Termination
	4.4.1. Initiation		4.4.1. Initiation
	As with TCP, the initiation phase of DCCP involves a three-way hand-		As with TCP, the initiation phase of DCCP involves a three-way hand-
	shake, shown in Figure 1.		shake, shown in Figure 1.
	Client Server		Client Server
	skipping to change at page 9, line ? ¶		skipping to change at page 9, line ? ¶
	------ ------		------ ------
	Prefer(CC,3,4) ->		Prefer(CC,3,4) ->
	<- Change(CC,3)		<- Change(CC,3)
	Confirm(CC,3) ->		Confirm(CC,3) ->
	4.4.3. Data Transfer		4.4.3. Data Transfer
	Rather than have a single congestion control regime as in TCP, DCCP		Rather than have a single congestion control regime as in TCP, DCCP
	offers a variety of negotiable congestion control regimes. The DCCP		offers a variety of negotiable congestion control regimes. The DCCP
	documents describe two congestion control regimes: additive increase,		documents describe two congestion control regimes: additive increase,
	multiplicative decrease (CCID-2 [REF]) and TCP-friendly rate control		multiplicative decrease (CCID-2 [CCID2]) and TCP-friendly rate con-
	(CCID-3 [REF]). CCID-2 is intended for applications which want maxi-		trol (CCID-3 [CCID3]). CCID-2 is intended for applications which want
	mum throughput. CCID-3 is intended for real-time applications which		maximum throughput. CCID-3 is intended for real-time applications
	want smooth response to congestion.		which want smooth response to congestion.
	4.4.3.1. CCID-2		4.4.3.1. CCID-2
	CCID-2's congestion control is extremely similar to that of TCP. The		CCID-2's congestion control is extremely similar to that of TCP. The
	sender maintains a congestion window and sends packets until that		sender maintains a congestion window and sends packets until that
	window is full. Packets are Acked by the receiver. Dropped packets		window is full. Packets are Acked by the receiver. Dropped packets
	and ECN [REF] are used to indicate congestion. The response to con-		and ECN [ECN] are used to indicate congestion. The response to con-
	gestion is to halve the congestion window. One subtle diference		gestion is to halve the congestion window. One subtle diference
	between DCCP and TCP is that the Acks in DCCP must contain the		between DCCP and TCP is that the Acks in DCCP must contain the
	sequence numbers of all received packets (within a given window) not		sequence numbers of all received packets (within a given window) not
	just the highest sequence number as in TCP.		just the highest sequence number as in TCP.
	4.4.3.2. CCID-3		4.4.3.2. CCID-3
	CCID-3 is an equation based form of rate control which is intended to		CCID-3 is an equation based form of rate control which is intended to
	provide smoother response to congestion than CCID-2. The sender main-		provide smoother response to congestion than CCID-2. The sender main-
	tains a "transmit rate". The receiver sends ACK packets which also		tains a "transmit rate". The receiver sends ACK packets which also
	contain information about the receiver's estimate of packet loss. The		contain information about the receiver's estimate of packet loss. The
	sender uses this information to update its transmit rate. Although		sender uses this information to update its transmit rate. Although
	CCID-3 behaves somewhat differently from TCP in its short term con-		CCID-3 behaves somewhat differently from TCP in its short term con-
	gestion response, it is designed to operate fairly with TCP over the		gestion response, it is designed to operate fairly with TCP over the
	long term.		long term.
	4.4.4. Termination		4.4.4. Termination
	[Still working on this one].		Connection termination in DCCP is initiated by sending a Close mes-
			sage. Either side can send a Close message. The peer then responds
			with a Reset message, at which point the connection is closed. The
			side that sent the Close message must quietly preserve the socket in
			TIMEWAIT state for 2MSL.
			Client Server
			------ ------
			Close ->
			<- Reset
			[Remains in TIMEWAIT]
			Note that the server may wish to close the connection but not remain
			in TIMEWAIT (e.g., due to a desire to minimize server-side state.) In
			order to accomplish this, the server can elicit a Close from the
			client by sending a CloseReq message and thus keeping the TIMEWAIT
			state on the client.
	5. Describe any important protocol features		5. Describe any important protocol features
	The final section (if there is one) should contain an explanation of		The final section (if there is one) should contain an explanation of
	any important protocol features which are not obvious from the previ-		any important protocol features which are not obvious from the previ-
	ous sections. In the best case, all the important features of the		ous sections. In the best case, all the important features of the
	protocol would be obvious from the message flow. However, this isn't		protocol would be obvious from the message flow. However, this isn't
	always the case. This section is an opportunity for the author to		always the case. This section is an opportunity for the author to
	explicate those features. Authors should think carefully before writ-		explicate those features. Authors should think carefully before writ-
	ing this section. If there are no important points to be made they		ing this section. If there are no important points to be made they
	should not populate this section.		should not populate this section.
	Examples of the kind of feature that belongs in this section include:		Examples of the kind of feature that belongs in this section include:
	high-level security considerations, congestion control information		high-level security considerations, congestion control information
	and overviews of the algorithms that the network elements are		and overviews of the algorithms that the network elements are
	intended to follow. For instance, if you have a routing protocol you		intended to follow. For instance, if you have a routing protocol you
	might use this section to sketch out the algorithm that the router		might use this section to sketch out the algorithm that the router
	uses to determine the appropriate routes from protocol messages.		uses to determine the appropriate routes from protocol messages.
	5.1. Example: XXX		5.1. Example: WebDAV COPY and MOVE
	[TODO: Suggested targets welcome]		WebDAV [WEBDAV] includes both a COPY method and a MOVE method. While
			a MOVE can be thought of as a COPY followed by DELETE, COPY+DELETE
			and MOVE aren't entirely equivalent.
			The use of COPY+DELETE as a MOVE substitute is problematic because of
			the creation of the intermediate file. Consider the case where the
			user is approaching some quota boundary. A COPY+DELETE should be for-
			bidden because it would temporarily exceed the quota. However, a
			simple rename should work in this situation.
			The second issue is permissions. The WebDAV permissions model allows
			the server to grant users permission to rename files but not to cre-
			ate new ones--this is unusual in ordinary filesystems but nothing
			prevents it in WebDAV. This is clearly not possible if a client uses
			COPY+DELETE to do a MOVE.
			Finally, a COPY+DELETE does not produce the same logical result as
			would be expected with a MOVE. Because COPY creates a new resource,
			it is permitted (but not required) to use the time of new file cre-
			ation as the creation date property. By contrast, the expectation for
			move is that the renamed file will have the same properties as the
			original.
	6. Formatting Issues		6. Formatting Issues
	The requirement that Internet-Drafts and RFCs be renderable in ASCII		The requirement that Internet-Drafts and RFCs be renderable in ASCII
	is a significant obstacle when writing the sort of graphics-heavy		is a significant obstacle when writing the sort of graphics-heavy
	document being described here. Authors may find it more convenient to		document being described here. Authors may find it more convenient to
	do a separate protocol model document in Postscript or PDF and simply		do a separate protocol model document in Postscript or PDF and simply
	make it available at review time--though an archival version would		make it available at review time--though an archival version would
	certainly be handy.		certainly be handy.
	7. A Complete Example: Internet Key Exchange (IKE)		7. A Complete Example: Internet Key Exchange (IKE)
	7.1. Operating Environment		7.1. Operating Environment
	Internet key Exchange (IKE) [REF] is a key establishment and parame-		Internet key Exchange (IKE) [IKE] is a key establishment and parame-
	ter negotiation protocol for Internet protocols. Its primary applica-		ter negotiation protocol for Internet protocols. Its primary applica-
	tion is for establishing security associations (SAs) [REF] for IPsec		tion is for establishing security associations (SAs) [IPSEC] for
	AH [REF] and ESP [REF].		IPsec AH [AH] and ESP [ESP].
	+--------------------+ +--------------------+		+--------------------+ +--------------------+
	| | | |		| | | |
	| +------------+ | | +------------+ |		| +------------+ | | +------------+ |
	| | Key | | IKE | | Key | |		| | Key | | IKE | | Key | |
	| | Management | <-+-----------------------+-> | Management | |		| | Management | <-+-----------------------+-> | Management | |
	| | Process | | | | Process | |		| | Process | | | | Process | |
	| +------------+ | | +------------+ |		| +------------+ | | +------------+ |
	| ^ | | ^ |		| ^ | | ^ |
	| | | | | |		| | | | | |
	skipping to change at page 17, line ? ¶		skipping to change at page 17, line ? ¶
	key agreement without a round trip to the Initiator, there is no DoS		key agreement without a round trip to the Initiator, there is no DoS
	protection		protection
	7.2.2. Stage 2		7.2.2. Stage 2
	Stage 1 on its own isn't very useful. The purpose of IKE, after all,		Stage 1 on its own isn't very useful. The purpose of IKE, after all,
	is to establish associations to be used to protect other traffic, not		is to establish associations to be used to protect other traffic, not
	just to establish IKE SAs. Stage 2 (what IKE calls "Quick Mode") is		just to establish IKE SAs. Stage 2 (what IKE calls "Quick Mode") is
	used for this purpose. The basic Stage 2 handshake is shown below.		used for this purpose. The basic Stage 2 handshake is shown below.
	Initiator Responder		Initiator Responder
	--------- ---------		--------- ---------
	AH/ESP parameters,		AH/ESP parameters,
	Algorithms, Nonce,		Algorithms, Nonce,
	Handshake Hash ->		Handshake Hash ->
	<- AH/ESP parameters,		<- AH/ESP parameters,
	Algorithms, Nonce,		Algorithms, Nonce,
	Handshake Hash		Handshake Hash
	Handshake Hash ->		Handshake Hash ->
	As with quick mode, the first two messages establish the algorithms		As with quick mode, the first two messages establish the algorithms
	and parameters while the final message is a check over the previous		and parameters while the final message is a check over the previous
	messages. In this case, the parameters also include the transforms to		messages. In this case, the parameters also include the transforms to
	be applied to the traffic (AH or ESP) and the kinds of traffic which		be applied to the traffic (AH or ESP) and the kinds of traffic which
	are to be protected. Note that there is no key exchange information		are to be protected. Note that there is no key exchange information
	shown in these messages.		shown in these messages.
	In this version of Quick Mode, the peers use the pre-existing Stage 1		In this version of Quick Mode, the peers use the pre-existing Stage 1
	keying material to derive fresh keying material for traffic protec-		keying material to derive fresh keying material for traffic protec-
	tion (with the nonces to ensure freshness). Quick mode also allows		tion (with the nonces to ensure freshness). Quick mode also allows
	for a new Diffie-Hellman handshake for per-traffic key PFS. In that		for a new Diffie-Hellman handshake for per-traffic key PFS. In that
	case, the first two messages shown above would also include Key		case, the first two messages shown above would also include Key
	Exchange payloads, as shown below.		Exchange payloads, as shown below.
	Initiator Responder		Initiator Responder
	--------- ---------		--------- ---------
	AH/ESP parameters,		AH/ESP parameters,
	Algorithms, Nonce,		Algorithms, Nonce,
	Key Exchange, ->		Key Exchange, ->
	Handshake Hash		Handshake Hash
	<- AH/ESP parameters,		<- AH/ESP parameters,
	Algorithms, Nonce,		Algorithms, Nonce,
	Key Exchange,		Key Exchange,
	Handshake Hash		Handshake Hash
	Handshake Hash ->		Handshake Hash ->
	7.3. Other Considerations		7.3. Other Considerations
	There are a number of features of IKE that deserve special considera-		There are a number of features of IKE that deserve special considera-
	tion. These are discussed here.		tion. These are discussed here.
	7.3.1. Cookie Generation		7.3.1. Cookie Generation
	As mentioned previously, IKE uses cookies as a partial defense		As mentioned previously, IKE uses cookies as a partial defense
	against DoS attacks. When the responder receives Main Mode message 3		against DoS attacks. When the responder receives Main Mode message 3
	skipping to change at page 18, line 4 ¶		skipping to change at page 19, line ? ¶
	peer is entitled to negotiate for a given class of traffic. In the-		peer is entitled to negotiate for a given class of traffic. In the-
	ory, one might be able to determine this from the name in the		ory, one might be able to determine this from the name in the
	certificate (e.g. the subject name contains an IP address that		certificate (e.g. the subject name contains an IP address that
	matches the ostensible IP address). In practice, this is not clearly		matches the ostensible IP address). In practice, this is not clearly
	specified in IKE and therefore not really interoperable. The more		specified in IKE and therefore not really interoperable. The more
	likely case at the moment is that there is a configuration table map-		likely case at the moment is that there is a configuration table map-
	ping certificates to policies, as with the other two authentication		ping certificates to policies, as with the other two authentication
	schemes.		schemes.
	References		References
			[AH] Kent, S., and Atkinson, R., "IP Authentication Header",
			RFC 2402, November 1998.
	[TODO]		[CCID2] Floyd, S., Kohler, E., "Profile for DCCP Congestion Control ID 2:
			TCP-like Congestion Control", draft-ietf-dccp-ccid2-04.txt,
			October 2003.
			[CCID3] Floyd, S., Kohler, E., Padhye, J. "Profile for DCCP Congestion
			Control ID 3: TFRC Congestion Control",
			draft-ietf-dccp-ccid3-05.txt, February 2004.
			[DCCP] Kohler, E., Handley, M., Floyd, S., "Datagram Congestion
			Control Protocol (DCCP)", draft-ietf-dccp-spec-06.txt,
			February 2004.
			[ECN] Ramakrishnan, K. Floyd, S., Black D., "The Addition of
			Explicit Congestion Notification (ECN) to IP",
			RFC 3168, September 2001.
			[ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
			Payload (ESP)", RFC 2406, November 1998.
			[IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
			RFC 2409, November 1998.
			[IPSEC] Kent, S., Atkinson, R., "Security Architecture for the Internet
			Protocol", RFC 2401, November 1998.
			[KERBEROS] Kohl, J., Neuman, C., "The Kerberos Network Authentication
			Service (V5)", RFC 1510, September 1993.
			[SDP] Handley, M., Jacobson, V., "SDP: Session Description Protocol"
			RFC 2327, April 1998.
			[STUN] Rosenberg, J., Weinberger, J., Huitema, C., Mahy, R.,
			"STUN - Simple Traversal of User Datagram Protocol (UDP)",
			RFC 3489, March 2003.
			[WEBDAV] Goland, Y., Whitehead, E., Faizi, A., Carter, S., Jensen, D.
			"HTTP Extensions for Distributed Authoring -- WEBDAV",
			RFC 2518, February 1999.
	Security Considerations		Security Considerations
	This document does not define any protocols and therefore has no		This document does not define any protocols and therefore has no
	security considerations.		security considerations.
	Author's Address		Author's Address
	Eric Rescorla <ekr@rtfm.com>		Eric Rescorla <ekr@rtfm.com>
	RTFM, Inc.		RTFM, Inc.
	2064 Edgewood Drive		2064 Edgewood Drive
	Palo Alto, CA 94303		Palo Alto, CA 94303
	Phone: (650)-320-8549		Phone: (650)-320-8549
	Internet Architecture Board <iab@iab.org>		Internet Architecture Board <iab@iab.org>
	IAB		IAB
	Appendix A. IAB Members at the time of this writing		Appendix A. IAB Members at the time of this writing
	Bernard Aboba		Bernard Aboba
	Harald Alvestrand		Harald Alvestrand
	Rob Austein		Rob Austein
	Leslie Daigle		Leslie Daigle
	Patrik Falstrom		Patrik Falstrom
	Sally Floyd		Sally Floyd
	Jun-ichiro Itojun Hagino		Jun-ichiro Itojun Hagino
	Mark Handley		Mark Handley
			Bob Hinden
	Geoff Huston		Geoff Huston
	Charlie Kaufman
	James Kempf
	Eric Rescorla		Eric Rescorla
	Mike St. Johns		Pete Resnick
			Jonathon Rosenberg
End of changes. 26 change blocks.
	36 lines changed or deleted		109 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/