Subject: [rddp] RE: AD review of draft-ietf-rddp-sctp-03

From: "Caitlin Bestler" <[email-masked]>
Date: Wed, 14 Jun 2006 15:07:32 -0700

Lars Eggert wrote:

> 
> 
> Section 5.1., paragraph 2:
> 
>  >    It is presumed that the handling of incoming data chunks for DDP
>  >    enabled associations is sufficiently different than for routine
>  >    SCTP associations that it is undesirable to require support for
>  >    mixing DDP and non-DDP streams in a single association.  More
>  >    than a single association is required if an application desires
>  >    to utilize both DDP and non-DDP traffic with the same remote
>  >    host. 
> 
>          Should this be an RFC2119 "MUST" or "SHOULD" instead
>          of "is undesirable to require support for?"
> 

The intent is to describe a rationale. There is no intention to
discourage
any implementation from attempting to support both. This is for two
reasons: 1) There is no interoperability reason to discourage such
an added feature, 2) the technical problems mentioned provide sufficient
discouragement on their own.

So the intent is to state the rationale for the exclusion of a
requirement
(such as "An SCTP association MUST be able to support both DDP and
non-DDP
streams concurrently.")

Any requirement that could be stated would be on ULP designers,
something
like "Upper Layer Protocol designers MUST NOT assume that an SCTP 
association will support DDP and non-DDP streams concurrently."
I don't think that such wording is any clearer, and in any event
creating MUST NOTs for upper layers is somewhat pointless.

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Lars Eggert <[email-masked]>
Date: Thu, 15 Jun 2006 09:27:07 +0300

Caitlin,

thanks for the feedback.

On Jun 15, 2006, at 1:07, Caitlin Bestler wrote:
> any implementation from attempting to support both.

I should have written "MUST NOT" or "SHOULD NOT."

Anyway, your explanation clears things up - thanks!

> This is for two

Lars
-- 
Lars Eggert                                     NEC Network Laboratories