On Jan 11, 2013, at 5:28 PM, Vijay K. Gurbani wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
Hi Vijay,
thank you very much for your comments.
>
> Document: draft-ietf-tsvwg-sctp-udp-encaps-07
> Reviewer: Vijay K. Gurbani
> Review Date: Jan-11-2013
> IETF LC End Date: Jan-22-2013
> IESG Telechat date: Feb-07-2013
>
> This document is ready as a Proposed Standard.
>
> Major: 0
> Minor: 2
> Nits: 1
>
> Minor:
> - 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.
>
> - 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.
>
> Nits:
>
> - S3.1, third paragraph: I would suggest "s/user-land/user space".
> It is better to be academic than colloquial here.
Fixed in CVS.
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
