Subject: Re: [tsvwg] OPS-DIR review of draft-ietf-tsvwg-sctp-prpolicies-05.txt

From: Michael Tuexen <[email-masked]>
Date: Wed, 10 Dec 2014 00:01:44 +0100

On 26 Nov 2014, at 13:33, Romascanu, Dan (Dan) <[email-masked]> wrote:

> I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments  were written primarily for the benefit of the operational area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.
Hi Dan,

thank you very much for your review. Please see my questions and comments in-line.

Best regards
Michael
> 
>  
> Summary: Ready with issues
>  
> Document Ready, but Operational and Management considerations missing.
>  
> As the Abstract says:
>  
>    This document defines two additional policies for the Partial
>    Reliability Extension of the Stream Control Transmission Protocol
>    (PR-SCTP) allowing to limit the number of retransmissions or to
>    prioritize user messages for more efficient send buffer usage.
> Although this document defines an extension of an existing protocol, there are no explicit considerations about operations and management. The OPS and Transport ADs should decide whether this is an issue to be addressed before the document is approved.
>  
> Specifically, following the checklists in RFC 5707, Appendix A:
>  
> -       Deployment is not discussed, although there is text that says that the Limited Retransmissions Policy can be used with data channels in the WebRTC protocol stack, and that the Priority Policy can be used in the IPFIX protocol stack
The introduction says, that "The decision to abandon a user message is sender side only". So for
deploying the additional policies you need to implement it at the sender side.
> -       Installation and initial setup is not discussed
We normally don't discuss the installation of the OS (assuming that the SCTP stack is part
of the kernel, which is the case for Linux, FreeBSD and Solaris) or how to install applications
(assuming that the transport stack is part of the application, which is the case for
browsers like Firefox, Chrome and Opera).
> -       Migration Path does not seem to apply
Migrating from what? You can just use an implementation at the sender side and you can
operate with every receiver implemening RFC 3758.
> -       There is information about RFC 3758 being mandatory to implement in order to implement these extensions
> -       The impact on the network operation is not discussed explicitly
In the security considerations section we say that the SCTP association using this extension
is not more aggressive than one not using the extension.
> -       There are no explicit suggestions about verifying correct operations, although one can understand that the socket options described in sections 4.3, 4.4, 4.5 are useful to determine stream specific status, association specific status, and to get and set the PR-SCTP support
Are you suggesting to specify test cases? At least this is not common right now in transport area
although it would make sense in my opinion...
> -       Interoperability does not seem to apply excepting the requirement to implement RFC 3758
And that is all what is needed...
> -       There is no information about faults or threshold conditions to be reported
Not sure what you are expecting here.
> -       Configuration is not discussed, it may not apply, but it would be good to state this
Well, configuration is described in detail in the socket API section. This is how you
configure the transport stack.
> -       There are no manageability considerations of any kind
Isn't the socket API what you use to manage the transport stack? Or are you referring to MIB stuff?
>  
> One terminology issue is worth being considered: The document speaks about two additional policies for PR-SCTP. However, the RFC defining PR-SCTP (RFC 3758) does not use the term policy at all. Timed Reliability which in this document is called a ‘policy’ is described in RFC 3758 as a ‘service to upper layer’. It would be good to either align terminology, or to explain that the term policy used here corresponds to the ‘service’ described in RFC 3758.
That is a good catch. Terminology has evolved over time.

I changed in the introduction

The decision to abandon a user message
is sender side only and the exact condition is called a PR-SCTP policy.

to

The decision to abandon a user message
is sender side only and the exact condition is called a PR-SCTP policy
(<xref target='RFC3758'/> refers to them as 'PR-SCTP Services').
> Regards,
> Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 10 Dec 2014 12:23:38 +0000

Hi Michael,

Thank you for addressing the issues raised in the OPS-DIR review. 

First, please see the disclaimer that I put in my review: 

> > Although this document defines an extension of an existing protocol, there
> are no explicit considerations about operations and management. The OPS
> and Transport ADs should decide whether this is an issue to be addressed
> before the document is approved.

The OPS-DIR reviews are written to help the OPS ADs with a reading of the I-Ds in review from the perspective of the operators using the and deploying the new protocols or extensions defined by the document. We - the reviewers - believe that the operational and manageability issues are important, but it's up to the ADs to decide whether they are important enough to require changes in the document, and what these changes should be. 

More in-line. 

Regards,

Dan

> -----Original Message-----
> From: Michael Tuexen [mailto:[email-masked]]
> Sent: Wednesday, December 10, 2014 1:02 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]; draft-ietf-tsvwg-sctp-
> [email-masked]
> Subject: Re: OPS-DIR review of draft-ietf-tsvwg-sctp-prpolicies-05.txt
> 
> > I have reviewed this document as part of the Operational directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments  were written primarily for the benefit of the operational
> area directors.  Document editors and WG chairs should treat these
> comments just like any other last call comments.
> Hi Dan,
> 
> > Although this document defines an extension of an existing protocol, there
> are no explicit considerations about operations and management. The OPS
> and Transport ADs should decide whether this is an issue to be addressed
> before the document is approved.
> >
> > -       Deployment is not discussed, although there is text that says that the
> Limited Retransmissions Policy can be used with data channels in the
> WebRTC protocol stack, and that the Priority Policy can be used in the IPFIX
> protocol stack
> The introduction says, that "The decision to abandon a user message is
> sender side only". So for deploying the additional policies you need to
> implement it at the sender side.

This is not exactly what I meant by deployment. My understanding is that the policies defined in this document come to answer some specific needs of protocols like IPFIX and WebRTC. Am I correct? If I am, I would expect the policies to be deployed where these protocols run. 

> We normally don't discuss the installation of the OS (assuming that the SCTP
> stack is part of the kernel, which is the case for Linux, FreeBSD and Solaris) or
> how to install applications (assuming that the transport stack is part of the
> application, which is the case for browsers like Firefox, Chrome and Opera).

Thank you for the clarification. Maybe it would help writing just this - the installation of the new capabilities will be part of OS upgrades. 

> Migrating from what? You can just use an implementation at the sender side
> and you can operate with every receiver implemening RFC 3758.

This is OK - that's what I had in mind when I said 'does not apply' - so no need to do anything. 

> In the security considerations section we say that the SCTP association using
> this extension is not more aggressive than one not using the extension.

OK. 

> > -       There are no explicit suggestions about verifying correct operations,
> although one can understand that the socket options described in sections
> 4.3, 4.4, 4.5 are useful to determine stream specific status, association
> specific status, and to get and set the PR-SCTP support
> Are you suggesting to specify test cases? At least this is not common right
> now in transport area although it would make sense in my opinion...

OK

> And that is all what is needed...

OK

> Not sure what you are expecting here.

Nothing - this is a point in the 5707 list which does not seem to apply.

> Well, configuration is described in detail in the socket API section. This is how
> you configure the transport stack.

OK

> Isn't the socket API what you use to manage the transport stack? Or are you

Whatever is used by operators to perform and verify installation, check behavior, and troubleshoot problems. 

> >
> > One terminology issue is worth being considered: The document speaks
> about two additional policies for PR-SCTP. However, the RFC defining PR-
> SCTP (RFC 3758) does not use the term policy at all. Timed Reliability which in
> this document is called a 'policy' is described in RFC 3758 as a 'service to
> upper layer'. It would be good to either align terminology, or to explain that
> the term policy used here corresponds to the 'service' described in RFC 3758.
> is sender side only and the exact condition is called a PR-SCTP policy (<xref
> target='RFC3758'/> refers to them as 'PR-SCTP Services').

OK

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 10 Dec 2014 06:57:31 -0600

Hi, Dan,

On Wed, Dec 10, 2014 at 6:23 AM, Romascanu, Dan (Dan) <[email-masked]>
wrote:

> The OPS-DIR reviews are written to help the OPS ADs with a reading of the
> I-Ds in review from the perspective of the operators using the and
> deploying the new protocols or extensions defined by the document. We - the
> reviewers - believe that the operational and manageability issues are
> important, but it's up to the ADs to decide whether they are important
> enough to require changes in the document, and what these changes should be.

I should explicitly thank you for walking this doc through the OPS
checklist. I don't think I've processed a draft where that's happened, as
an AD (for whatever reason), so that's helpful. I'll follow up with the TSV
chairs, calling their attention to that - while much of the checklist
doesn't apply as much transport protocols, some of it does, and that
shouldn't startle authors, shepherds and working group chairs when an OPS
directorate reviewer notices that.

On the point you and Michael are chatting about ...

> This is not exactly what I meant by deployment. My understanding is that
> the policies defined in this document come to answer some specific needs of
> protocols like IPFIX and WebRTC. Am I correct? If I am, I would expect the
> policies to be deployed where these protocols run.

IIUC, this is a general-purpose capability, but I'd be fine with a sentence
or two that pointed out specific needs that motivated these policies, if
the authors/shepherd/chairs agreed.

> Thank you for the clarification. Maybe it would help writing just this -
> the installation of the new capabilities will be part of OS upgrades.

IIUC, OS and browser upgrades (because we're seeing increasing interest in
user-space implementations of SCTP), but that could be a reasonable thing
to point out for a broader audience.

Thanks,

Spencer

> > > -       There is information about RFC 3758 being mandatory to
> implement in
> > order to implement these extensions
> > > -       Interoperability does not seem to apply excepting the
> requirement to
> > implement RFC 3758
> > > -       There is no information about faults or threshold conditions
> to be
> > reported
> > > -       Configuration is not discussed, it may not apply, but it would
> be good
> > to state this
> > Isn't the socket API what you use to manage the transport stack? Or are
> you
> > referring to MIB stuff?
>
> (<xref

---

From: "Black, David" <[email-masked]>
Date: Wed, 10 Dec 2014 13:59:31 +0000

As both an OPS-Dir reviewer and one of the TSVWG chairs, I appreciate this review

> > before the document is approved.

As part of that AD consideration, the following recent addition to the IESG
Discuss criteria (https://www.ietf.org/iesg/statement/discuss-criteria.html)
on protocol extensions is relevant:

   When an extension or minor update is made to an existing protocol that
   has unaddressed issues, it would not be appropriate to hold a DISCUSS
   on that document demanding that the problem in the base protocol
   specification be addressed; rather, the way to address problems of this
   sort is to update the base protocol specification. For example, a lack
   of consideration for pervasive monitoring in an existing specification
   would not justify holding a DISCUSS on the extension or minor update.

This draft is an extension to SCTP-PR, which in turn is part of SCTP.
So, concerns that apply to SCTP-PR regardless of policy or to SCTP overall
are probably out of scope for this draft.  Installation appears to be an

> > application, which is the case for browsers like Firefox, Chrome and Opera).

General SCTP installation and setup are better dealt with elsewhere, although
I have no problem w/Spencer's suggestion of a single sentence that could note
that these additional SCTP-PR policies are part of SCTP implementations that
are deployed, installed, setup and configured as part of operating systems
or browsers.

Thanks,
--David

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Wednesday, December 10, 2014 7:24 AM
> To: Michael Tuexen
> Subject: RE: OPS-DIR review of draft-ietf-tsvwg-sctp-prpolicies-05.txt
> 
> Hi Michael,
> 
> The OPS-DIR reviews are written to help the OPS ADs with a reading of the I-Ds
> in review from the perspective of the operators using the and deploying the
> new protocols or extensions defined by the document. We - the reviewers -
> believe that the operational and manageability issues are important, but it's
> up to the ADs to decide whether they are important enough to require changes
> in the document, and what these changes should be.
> 
> More in-line.
> 
> Regards,
> 
> Dan
> 
> 
> This is not exactly what I meant by deployment. My understanding is that the
> policies defined in this document come to answer some specific needs of
> Thank you for the clarification. Maybe it would help writing just this - the
> installation of the new capabilities will be part of OS upgrades.
> 
> > > -       Interoperability does not seem to apply excepting the requirement
> to
> > implement RFC 3758

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 10 Dec 2014 21:52:50 +0100

Hi Dan,

understood. But I want to understand your points and possibly address them...
> This is not exactly what I meant by deployment. My understanding is that the policies defined in this document come to answer some specific needs of protocols like IPFIX and WebRTC. Am I correct? I…
For IPFIX some of this is discussed in
https://tools.ietf.org/html/rfc7011#section-10.2
For RTCWeb is is discussed in
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section-6.1
Please note that the policies defined here are of general use. So the description
how to use it will be in the documents describing the use cases.
> Thank you for the clarification. Maybe it would help writing just this - the installation of the new capabilities will be part of OS upgrades. 
... if you use a stack provided by the kernel. If the stack is provided by
an application, you need to install the application.
So it comes down to: You need to install the software which contains the SCTP stack you are using.
For me, this is obvious. So I'm hesitating to add this. It would be a sentence which
you can copy to almost every SCTP (or TCP) specification.
> Whatever is used by operators to perform and verify installation, check behavior, and troubleshoot problems. 
Ahh, OK. I don't think an operator would use the socket API for that.
If you want to test you transport stack you need to have tests and a test tool
for running these tests. Up to now, the IETF (at least the transport area)
hasn't specified tests. Personally, I would really love to do it and think
that it is very important. But I think this is a decision not limited to this particular
document, but to (transport) protocols in general. So I leave it up to the ADs...

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 10 Dec 2014 16:09:43 -0600

>From at least one AD :-)

On Wed, Dec 10, 2014 at 2:52 PM, Michael Tuexen <[email-masked]>
wrote:

> > The OPS-DIR reviews are written to help the OPS ADs with a reading of
> the I-Ds in review from the perspective of the operators using the and
I'd say the question of test cases has been raised to the attention of
TSVWG (cc on this thread), and I'd be happy to consider that if they think
working on that would be a good plan, but I don't think this document needs
to wait for them to figure that out.

I'm good with Michael submitting an update addressing the comments as
discussed in this thread.

Thanks,

Spencer

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 11 Dec 2014 10:57:35 +0000

Ø  I'm good with Michael submitting an update addressing the comments as discussed in this thread.

Ø

Ø  Thanks,

Ø

Ø  Spencer

Me too. Can you please send me a note when this happens, so that I do not miss the update?

Thanks for considering my comments.

Regards,

Dan

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Thursday, December 11, 2014 12:10 AM
To: Michael Tuexen
Cc: Romascanu, Dan (Dan); [email-masked]; [email-masked]; [email-masked]
Subject: Re: OPS-DIR review of draft-ietf-tsvwg-sctp-prpolicies-05.txt

From at least one AD :-)

On Wed, Dec 10, 2014 at 2:52 PM, Michael Tuexen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dan,

>> From: Michael Tuexen [mailto:[email-masked]<mailto:[email-masked]>]
>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; draft-ietf-tsvwg-sctp-
>> [email-masked]<mailto:[email-masked]>
>> On 26 Nov 2014, at 13:33, Romascanu, Dan (Dan) <[email-masked]<mailto:[email-masked]>>
>> wrote:
>>
For IPFIX some of this is discussed in
https://tools.ietf.org/html/rfc7011#section-10.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7011-23section-2D10.2&d=AAMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=6cUQU7WzGxVzLIHAs0xxQPmF6uxX5BY1uBQciZGTCcc&s=LqjSQkjNGebAvCFgTSNxXQ_e427vOGThVYUIAPMJDgw&e=>
For RTCWeb is is discussed in
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section-6.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Drtcweb-2Ddata-2Dchannel-2D12-23section-2D6.1&d=AAMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=6cUQU7WzGxVzLIHAs0xxQPmF6uxX5BY1uBQciZGTCcc&s=nVL3E_6PggjIKyLIIspGt7ZzjVOoGU0fIot986j6yTs&e=>
Please note that the policies defined here are of general use. So the description
how to use it will be in the documents describing the use cases.

I'd say the question of test cases has been raised to the attention of TSVWG (cc on this thread), and I'd be happy to consider that if they think working on that would be a good plan, but I don't think this document needs to wait for them to figure that out.

I'm good with Michael submitting an update addressing the comments as discussed in this thread.

Thanks,

Spencer

---

From: [email-masked]
Date: Thu, 11 Dec 2014 11:10:29 -0000

So, it seems most of this is covered by clear statements that describe
this as a sender-side only change to the transport protocol of the
endpoint stack. ... and description and references to examples where
deployment is expected, etc - I suggest to expand the introduction?

Michael can you run the changes by me as the document shepherd, so I can
check that I see the logic and it doesn't potentially  create new issues?

Gorry

> Cc: Romascanu, Dan (Dan); [email-masked]; [email-masked];
> [email-masked]
> On Wed, Dec 10, 2014 at 2:52 PM, Michael Tuexen
> <[email-masked]<mailto:[email-masked]>> wrote:
> On 10 Dec 2014, at 13:23, Romascanu, Dan (Dan)
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>> Hi Michael,
>>
>> deploying the new protocols or extensions defined by the document. We -
>> the reviewers - believe that the operational and manageability issues
>> are important, but it's up to the ADs to decide whether they are
>> important enough to require changes in the document, and what these
>> changes should be.
> Hi Dan,
>
>>> From: Michael Tuexen
>>> [mailto:[email-masked]<mailto:[email-masked]>]
>>> Cc: [email-masked]<mailto:[email-masked]>;
>>> [email-masked]<mailto:[email-masked]>; draft-ietf-tsvwg-sctp-
>>> On 26 Nov 2014, at 13:33, Romascanu, Dan (Dan)
>>> <[email-masked]<mailto:[email-masked]>>
>>> wrote:
>>>
>> the policies defined in this document come to answer some specific needs
>> of protocols like IPFIX and WebRTC. Am I correct? If I am, I would
>> expect the policies to be deployed where these protocols run.
> working on that would be a good plan, but I don't think this document
> needs to wait for them to figure that out.
>

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 11 Dec 2014 15:36:32 +0100

> Me too. Can you please send me a note when this happens, so that I do
Sure. The updated version is available at
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-06
> Thanks for considering my comments.
Thanks for providing them!

Best regards
Michael
> 
> Regards,
> 
> Dan
> 
> FROM: Spencer Dawkins at IETF [mailto:[email-masked]]
>  SENT: Thursday, December 11, 2014 12:10 AM
>  TO: Michael Tuexen
>  CC: Romascanu, Dan (Dan); [email-masked]; [email-masked];
>  SUBJECT: Re: OPS-DIR review of
> draft-ietf-tsvwg-sctp-prpolicies-05.txt
> 
> From at least one AD :-)
> 
> <[email-masked]> wrote:
> 
>  > The OPS-DIR reviews are written to help the OPS ADs with a reading
> of the I-Ds in review from the perspective of the operators using the
> and deploying the new protocols or extensions defined by the document.
> We - the reviewers - believe that the operational and manageability
> issues are important, but it's up to the ADs to decide whether they
> are important enough to require changes in the document, and what
> these changes should be.
>  Hi Dan,
> 
> <[email-masked]>
>  > This is not exactly what I meant by deployment. My understanding is
> that the policies defined in this document come to answer some
> specific needs of protocols like IPFIX and WebRTC. Am I correct? If I
> am, I would expect the policies to be deployed where these protocols
> run.
> 
>  https://tools.ietf.org/html/rfc7011#section-10.2 [1]
> [2]
>  > Thank you for the clarification. Maybe it would help writing just
> this - the installation of the new capabilities will be part of OS
> upgrades.
>  >>> - There is no information about faults or threshold conditions to
> be
>  >> reported
>  >> Isn't the socket API what you use to manage the transport stack?
> Or are you
>  >> referring to MIB stuff?
>  >
>  > Whatever is used by operators to perform and verify installation,
> check behavior, and troubleshoot problems.
> 
> TSVWG (cc on this thread), and I'd be happy to consider that if they
> think working on that would be a good plan, but I don't think this
> document needs to wait for them to figure that out.
> 
> Links:
> ------
> [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7011-23section-2D10.2&amp;d=AAMFaQ&amp;c=BFpWQw8bsuKpl1SgiZH64Q&amp;r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&amp;m=6cUQU7WzGxVzLIHAs0xxQPmF6uxX5BY1uBQciZGTCcc&amp;s=LqjSQkjNGebAvCFgTSNxXQ_e427vOGThVYUIAPMJDgw&amp;e=
> [2]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Drtcweb-2Ddata-2Dchannel-2D12-23section-2D6.1&amp;d=AAMFaQ&amp;c=BFpWQw8bsuKpl1SgiZH64Q&amp;r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&amp;m=6cUQU7WzGxVzLIHAs0xxQPmF6uxX5BY1uBQciZGTCcc&amp;s=nVL3E_6PggjIKyLIIspGt7ZzjVOoGU0fIot986j6yTs&amp;e=

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 11 Dec 2014 15:37:56 +0100

> check that I see the logic and it doesn't potentially  create new 
Hi Gorry,

I'm sorry, I already submitted the version. Please have a look at
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-06
and let me know if they changes are OK for you. If not I can
incorporate your suggested changes.

Best regards
Michael
> 
> Gorry
> 
>> Ã˜  I'm good with Michael submitting an update addressing the comments 
>> as
>> Ã˜
>> Ã˜  Thanks,
>> Ã˜
>> Ã˜  Spencer
>> Me too. Can you please send me a note when this happens, so that I do 
>> not
>> miss the update?
>> 
>>>>> Although this document defines an extension of an existing 
>>>>> protocol,
>>>>> there
>>>>> Although this document defines an extension of an existing 
>>>>> protocol,
>>>>> there
>>>>> -       Deployment is not discussed, although there is text that 
>>>>> says
>>>>> that the
>>>> WebRTC protocol stack, and that the Priority Policy can be used in 
>>>> the
>>>> IPFIX
>>>> protocol stack
>>> that
>>>> We normally don't discuss the installation of the OS (assuming that 
>>>> the
>>>> SCTP
>>>> stack is part of the kernel, which is the case for Linux, FreeBSD 
>>>> and
>>>> Solaris) or
>>>> how to install applications (assuming that the transport stack is 
>>>> part
>>>> of the
>>> this -
>> ... if you use a stack provided by the kernel. If the stack is 
>> provided
>> by
>> So it comes down to: You need to install the software which contains 
>> the
>> SCTP stack you are using.
>>>> Migrating from what? You can just use an implementation at the 
>>>> sender
>>>> side
>>> This is OK - that's what I had in mind when I said 'does not apply' - 
>>> so
>>> no need to do anything.
>>> 
>>>> In the security considerations section we say that the SCTP 
>>>> association
>>>> using
>>>> Are you suggesting to specify test cases? At least this is not 
>>>> common
>>>> right
>>>> Well, configuration is described in detail in the socket API 
>>>> section.
>>>> This is how
>> If you want to test you transport stack you need to have tests and a 
>> test
>> tool
>> that it is very important. But I think this is a decision not limited 
>> to
>> this particular
>> document, but to (transport) protocols in general. So I leave it up to 
>> the
>> ADs...
>> 
>> think