Diff: rfc9622v2.txt - rfc9622.txt

	rfc9622v2.txt	rfc9622.txt

	skipping to change at line 677 ¶	skipping to change at line 677 ¶
	(".") MUST be omitted for well-known generic properties, i.e., for	(".") MUST be omitted for well-known generic properties, i.e., for
	properties that are not specific to a protocol.	properties that are not specific to a protocol.

	* Protocol-specific Properties MUST use the protocol acronym as the	* Protocol-specific Properties MUST use the protocol acronym as the
	Namespace (e.g., a Connection that uses TCP could support a TCP-	Namespace (e.g., a Connection that uses TCP could support a TCP-
	specific Transport Property, such as the TCP User Timeout value,	specific Transport Property, such as the TCP User Timeout value,
	in a Protocol-specific Property called tcp.userTimeoutValue (see	in a Protocol-specific Property called tcp.userTimeoutValue (see
	Section 8.2)).	Section 8.2)).

	* Vendor-specific or implementation-specific properties MUST be	* Vendor-specific or implementation-specific properties MUST be

	placed in a Namespace starting with the underscore _ character and	placed in a Namespace starting with the underscore character ("_")
	SHOULD use a string identifying the vendor or implementation.	and SHOULD use a string identifying the vendor or implementation.

	* For IETF protocols, the name of a Protocol-specific Property MUST	* For IETF protocols, the name of a Protocol-specific Property MUST

	be specified in an RFC from the IETF Stream (after IETF review).	be specified in an RFC from the IETF Stream (after IETF Review
	An IETF protocol Namespace does not start with an underscore	[RFC8126]). An IETF protocol Namespace does not start with an
	character ("_").	underscore character ("_").

	Namespaces for each of the keywords provided in the "Protocol	Namespaces for each of the keywords provided in the "Protocol
	Numbers" registry (see <https://www.iana.org/assignments/protocol-	Numbers" registry (see <https://www.iana.org/assignments/protocol-
	numbers/>) are reserved for Protocol-specific Properties and MUST NOT	numbers/>) are reserved for Protocol-specific Properties and MUST NOT
	be used for vendor-specific or implementation-specific properties.	be used for vendor-specific or implementation-specific properties.
	Terms listed as keywords, as in the "Protocol Numbers" registry,	Terms listed as keywords, as in the "Protocol Numbers" registry,
	SHOULD be avoided as any part of a vendor-specific or implementation-	SHOULD be avoided as any part of a vendor-specific or implementation-
	specific property name.	specific property name.

	Though Transport Property Names are case insensitive, it is	Though Transport Property Names are case insensitive, it is

	skipping to change at line 926 ¶	skipping to change at line 926 ¶
	identifying the local interface to which the Connection is bound and	identifying the local interface to which the Connection is bound and
	a Remote Endpoint identifying the multicast group.	a Remote Endpoint identifying the multicast group.

	The following API calls can be used to configure a Preconnection	The following API calls can be used to configure a Preconnection
	before calling Initiate:	before calling Initiate:

	RemoteSpecifier.WithMulticastGroupIP(GroupAddress)	RemoteSpecifier.WithMulticastGroupIP(GroupAddress)
	RemoteSpecifier.WithPort(PortNumber)	RemoteSpecifier.WithPort(PortNumber)
	RemoteSpecifier.WithHopLimit(HopLimit)	RemoteSpecifier.WithHopLimit(HopLimit)


	Calling Listen on a Preconnection with a multicast group specified on	Calling Listen on a Preconnection with a multicast group address
	the Remote Endpoint will join the multicast group to receive	specified as the Remote Endpoint Identifier will trigger the
	Messages. This Listener will create one Connection for each Remote	Transport Services Implementation to join the multicast group to
	Endpoint sending to the group, with the Local Endpoint Identifier	receive Messages. This Listener will create one Connection for each
	specified as a group address. The set of Connection objects created	Remote Endpoint sending to the group, with the Local Endpoint
	forms a Connection Group. The receiving interface can be restricted	Identifier specified as a group address. The set of Connection
	by passing it as part of the LocalSpecifier or queried through the	objects created forms a Connection Group. The receiving interface
	Message Context on the Messages received (see Section 9.1.1 for	can be restricted by passing it as part of the LocalSpecifier or
	further details).	queried through the Message Context on the Messages received (see
		Section 9.1.1 for further details).

	Specifying WithHopLimit sets the Time To Live (TTL) field in the	Specifying WithHopLimit sets the Time To Live (TTL) field in the
	header of IPv4 packets or the Hop Count field in the header of IPv6	header of IPv4 packets or the Hop Count field in the header of IPv6
	packets.	packets.

	The following API calls can be used to configure a Preconnection	The following API calls can be used to configure a Preconnection
	before calling Listen:	before calling Listen:

	LocalSpecifier.WithSingleSourceMulticastGroupIP(GroupAddress,	LocalSpecifier.WithSingleSourceMulticastGroupIP(GroupAddress,
	SourceAddress)	SourceAddress)

	skipping to change at line 2489 ¶	skipping to change at line 2490 ¶
	and/or receive data without any urgency. This can, for example,	and/or receive data without any urgency. This can, for example,
	be used to select Protocol Stacks with scavenger transmission	be used to select Protocol Stacks with scavenger transmission
	control and/or to assign the traffic to a lower-effort service.	control and/or to assign the traffic to a lower-effort service.
	Transport Services systems that map the requested capacity profile	Transport Services systems that map the requested capacity profile
	to per-connection DSCP signaling SHOULD assign the DSCP "Less than	to per-connection DSCP signaling SHOULD assign the DSCP "Less than
	best effort" PHB [RFC8622].	best effort" PHB [RFC8622].

	Low Latency/Interactive: The application is interactive and prefers	Low Latency/Interactive: The application is interactive and prefers
	loss to latency. Response time SHOULD be optimized at the expense	loss to latency. Response time SHOULD be optimized at the expense
	of delay variation and efficient use of the available capacity	of delay variation and efficient use of the available capacity

	when sending on this Connection. This can be used by the system	when sending on this Connection. The "Low Latency/Interactive"
	to disable the coalescing of multiple small Messages into larger	value of the capacity profile can be used by the system to disable
	packets (Nagle algorithm (see Section 4.2.3.4 of [RFC1122])); to	the coalescing of multiple small Messages into larger packets
	prefer immediate acknowledgement from the peer endpoint when	(Nagle algorithm (see Section 4.2.3.4 of [RFC1122])); to prefer
	supported by the underlying transport; and so on. Transport	immediate acknowledgement from the peer endpoint when supported by
	Services systems that map the requested capacity profile to per-	the underlying transport; and so on. Transport Services systems
	connection DSCP signaling without multiplexing SHOULD assign a	that map the requested capacity profile to per-connection DSCP
	DSCP Assured Forwarding (AF41,AF42,AF43,AF44) PHB [RFC2597].	signaling without multiplexing SHOULD assign a DSCP Assured
	Inelastic traffic that is expected to conform to the configured	Forwarding (AF41,AF42,AF43,AF44) PHB [RFC2597]. Inelastic traffic
	network service rate could be mapped to the DSCP Expedited	that is expected to conform to the configured network service rate
	Forwarding PHBs [RFC3246] or PHBs as discussed in [RFC5865].	could be mapped to the DSCP Expedited Forwarding PHBs [RFC3246] or
		PHBs as discussed in [RFC5865].

	Low Latency/Non-Interactive: The application prefers loss to latency	Low Latency/Non-Interactive: The application prefers loss to latency
	but is not interactive. Response time SHOULD be optimized at the	but is not interactive. Response time SHOULD be optimized at the
	expense of delay variation and efficient use of the available	expense of delay variation and efficient use of the available
	capacity when sending on this Connection. Transport system	capacity when sending on this Connection. Transport system
	implementations that map the requested capacity profile to per-	implementations that map the requested capacity profile to per-
	connection DSCP signaling without multiplexing SHOULD assign a	connection DSCP signaling without multiplexing SHOULD assign a
	DSCP Assured Forwarding (AF21,AF22,AF23,AF24) PHB [RFC2597].	DSCP Assured Forwarding (AF21,AF22,AF23,AF24) PHB [RFC2597].

	Constant-Rate Streaming: The application expects to send/receive	Constant-Rate Streaming: The application expects to send/receive

	skipping to change at line 4043 ¶	skipping to change at line 4045 ¶
	[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage	[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
	Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,	Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
	March 2017, <https://www.rfc-editor.org/info/rfc8085>.	March 2017, <https://www.rfc-editor.org/info/rfc8085>.

	[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,	[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
	Ed., "Services Provided by IETF Transport Protocols and	Ed., "Services Provided by IETF Transport Protocols and
	Congestion Control Mechanisms", RFC 8095,	Congestion Control Mechanisms", RFC 8095,
	DOI 10.17487/RFC8095, March 2017,	DOI 10.17487/RFC8095, March 2017,
	<https://www.rfc-editor.org/info/rfc8095>.	<https://www.rfc-editor.org/info/rfc8095>.


		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
		Writing an IANA Considerations Section in RFCs", BCP 26,
		RFC 8126, DOI 10.17487/RFC8126, June 2017,
		<https://www.rfc-editor.org/info/rfc8126>.

	[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,	[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
	"Stream Schedulers and User Message Interleaving for the	"Stream Schedulers and User Message Interleaving for the
	Stream Control Transmission Protocol", RFC 8260,	Stream Control Transmission Protocol", RFC 8260,
	DOI 10.17487/RFC8260, November 2017,	DOI 10.17487/RFC8260, November 2017,
	<https://www.rfc-editor.org/info/rfc8260>.	<https://www.rfc-editor.org/info/rfc8260>.

	[RFC8293] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R.	[RFC8293] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R.
	Krishnan, "A Framework for Multicast in Network	Krishnan, "A Framework for Multicast in Network
	Virtualization over Layer 3", RFC 8293,	Virtualization over Layer 3", RFC 8293,
	DOI 10.17487/RFC8293, January 2018,	DOI 10.17487/RFC8293, January 2018,

End of changes. 5 change blocks.
	25 lines changed or deleted	32 lines changed or added
This html diff was produced by rfcdiff 1.48.