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.
- 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.
- 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.
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
