Subject: [Gen-art] Gen-ART review of draft-ietf-tsvwg-sctp-udp-encaps-07

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 11 Jan 2013 10:28:30 -0600

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.

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.

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

Nits:

- S3.1, third paragraph: I would suggest "s/user-land/user space".
  It is better to be academic than colloquial here.

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-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 11 Jan 2013 18:11:22 +0100

> Please resolve these comments along with any other Last Call comments
Hi Vijay,

thank you very much for your comments.
> 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.
> 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.
> It is better to be academic than colloquial here.
Fixed in CVS.

Best regards
Michael

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 11 Jan 2013 13:48:03 -0600

> thank you very much for your comments.

Michael: Thank you for attending to my comments.  Please see inline.

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

> 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

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 11 Jan 2013 21:33:56 +0100

> Michael: Thank you for attending to my comments.  Please see inline.
Vijay, thanks for the comments. See my comments in-line.
> 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? 
> rfc4960 is better.  But I will certainly leave it to your sound
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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 11 Jan 2013 16:20:03 -0600

> the current text and also provides the necessary flexibility. Could you

Michael: It could be that in the end any text we add may lead to other
ambiguities --- so maybe we leave things as-is.  Since we are
essentially at the transport layer, let's just talk in terms of ports,
which are the canonical identifiers at that layer.

> So I prefer to leave it as it is.

Sure.

Thanks,

- vijay