On Jan 11, 2013, at 8:48 PM, Vijay K. Gurbani wrote:
> On 01/11/2013 11:11 AM, Michael Tuexen wrote:
>> thank you very much for your comments.
>
> Michael: Thank you for attending to my comments. Please see inline.
Vijay, thanks for the comments. See my comments in-line.
>
>>> - S4.1, second paragraph: I suspect that the expectation is that
>>> the SCTP stack uses a single local UDP port number for
>>> *all local interfaces*, right? As written currently, the qualifier
>>> for "all local interfaces" is missing --- maybe it is assumed? If so,
>>> better to state explicitly.
>> The text says
>>
>> Each SCTP stack uses a single local UDP encapsulation port number as
>> the destination port for all its incoming SCTP packets.
>>
>> So we are not referring to any kind of interfaces. When building the
>> stack in userland, you might not deal with interfaces. You might
>> bind to some addresses. So it might make sense not to explicitly
>> deal with the notion on interfaces.
>
> Well, yes, but the larger point I was trying to make was whether the
> same port number is expected to be bound to multiple local addresses,
> which is what we get through using INADDR_ANY when filling in the
> sin_addr.s_addr component before the bind() system call during coding
> servers for other transports. It seems that the answer would be yes,
> since the semantics are similar to UDP and TCP ... so maybe it is okay
> not to explicitly deal with interfaces.
If you are implementing the SCTP in userland and want to use all IPv4
addresses on a host, you could bind to INADDR_ANDY and process all
received packets in the SCTP stack.
But it would also be allowed to run the SCTP stack only on a subset of
IP addresses, bind a UDP socket specifically to each address and
process only those. So it depends on "which packets and SCTP processes".
For example, I have seen hosts running multiple applications, each one
having its own SCTP stack, and all applications had (multiple) different
IP addresses. You could also run the SCTP only on all
IPv4 addresses and ignore the IPv6 ones. Or use only the IPv6 ones.
It is hard for me to suggest a concrete text improvement which clarifies
the current text and also provides the necessary flexibility. Could you
suggest some text?
>
>>> - S5, second paragraph ("Please note that this section is informational
>>> only.") --- I am not sure the value of this sentence. The draft itself
>>> is targeted as a standards track document, so it comes as a surprise
>>> that a certain section is to be exempted from normative language. How-
>>> ever, since there isn't any normative language (as per rfc2119) in the
>>> remainder of S5, why bother with informing the reader that this section
>>> is informational? My suggestion would be to simply remove the
>>> offending sentence to decrease any ambiguity.
>> Section 5 describes the Socket API. It extends RFC 6458, which describes
>> the socket API and is an informational RFC. Also section 10 of RFC 4960
>> which describes a generic API is "for illustrative purposes".
>>
>> Please note that also section 6 of RFC 6525 describing the corresponding
>> socket API extensions contains the same sentence
>> "Please note that this section is informational only."
>>
>> So for consistency, I would prefer to keep it as it is.
>
> That is certainly your prerogative; although it seems to me that maybe
> saying that "this section is for illustrative purposes only" a la
> rfc4960 is better. But I will certainly leave it to your sound
> discretion.
The API section in RFC 4960 is really illustrative. No implementation
is expected to exactly implement it. It is just a rough guideline.
The API section in this document is exactly implemented in the FreeBSD
kernel. Other implementations are expected to do it the same. Just
as RFC 6458 (which is Informational).
So I prefer to leave it as it is.
In general, I understand your point, and there was a small discussion
recently on the mailing list if it would be better for the IETF to
specific APIs also as standard track RFCs instead of Informational RFCs.
However, that might apply in the future and I prefer to keep the
SCTP socket API definitions consistent.
Best regards
Michael
>
> Thanks,
>
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / [email protected]
> Web: http://ect.bell-labs.com/who/vkg/
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
