Subject: Re: Preprocessor constants indicated SCTP is available?

From: "K. Poon" <[email-masked]>
Date: Sun, 10 Nov 2002 02:17:40 -0800 (PST)

--- La Monte Henry Piggy Yarroll <[email-masked]> wrote:
> May I suggest the somewhat presumptuous _POSIX_SCTP?  We should also
> define _POSIX_SCTP_PRSCTP, _POSIX_SCTP_ADDIP, and similar symbols for
> any optional features in the RFC. 

I believe using a name with POSIX is a bad idea.  This is
IETF, I suggest we stay away from using names "belonging" to
other organization.  I believe going thru committees on names
is the last thing people want to here.  And I see no technical
reason why this is a good choice at all.

> A quick scan of the MAY clauses shows mostly minor behavioral and
> implementation options.  The only ones I can IMAGINE being useful to
> an application writer are:
> 
> _POSIX_SCTP_BUNDLING		- supports outbound bundling,
> _POSIX_SCTP_FRAGMENTATION	- supports outbound fragmentation,
> _POSIX_SCTP_ESP			- supports IP Encapsulating Security Payload,
> _POSIX_SCTP_ECN			- supports Explicit Congestion Notification,
> 
> A quick scan of SHOULD clauses turns up:
> 
> _POSIX_SCTP_HOSTNAME		- can generate HOSTNAME-based INITs,
> _POSIX_SCTP_SMALL_COOKIE	- implementation generates a small cookie
> :-),
> _POSIX_SCTP_RESTART		- generates RESTART notifications,
> _POSIX_SCTP_DELAYED_ACK		- implements delayed ACK,
> _POSIX_SCTP_GAP_ACK		- will generate SACK GAP ACK blocks,
> _POSIX_SCTP_DUP			- will generate SACK DUP reports,
> _POSIX_SCTP_REVOCATION		- can revoke GAP ACKd DATA,
> _POSIX_SCTP_GAP_DISABLES_DACK	- GAP reports disable delayed ACK,
> _POSIX_SCTP_PATH_FAILURE	- generates notification on path failure,
> _POSIX_SCTP_IPAH		- supports RFC2402 IP Authentication Header??,
> _POSIX_SCTP_ISAKMP		- supports RFC2408 ISAKMP??,
> _POSIX_SCTP_IKE			- supports RFC2409 Internet Key Exchange??,
> _POSIX_SCTP_SAFE_MAC		- MAC secret key is cryptographic (RFC1750),

I think the decision on which constants to put in the
draft should be based on whether it is really necessary.
For example, I don't see why an app needs to know about
whether a particular stack's SCTP implementation supports 
ECN or not.  It seems to me that most of the above constant
suggestions should not be defined based on this criterion.

=====
K. Poon.				[email-masked]

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2

---

From: Craig Rodrigues <[email-masked]>
Date: Mon, 11 Nov 2002 15:32:34 -0500

> I believe using a name with POSIX is a bad idea.  This is

I agree.  I recommend using just _SCTP_?
Standardizing a few key macros would be very useful for app
developers, and make it easier to add SCTP to existing codebases.

Here is some advice I received from the Andrew Josey at the Open Group.

On Mon, Nov 04, 2002 at 12:20:03PM +0000, Andrew Josey wrote:
> Craig
> Thanks for your mail. 
> 
> We would recommend that you use SCTP_* names in whatever headers 
> you want to use and require that applications define a feature test macro 
> (something like SCTP_C_SOURCE=200ymmL) similar to our use of
> _POSIX_C_SOURCE to make any extensions to C and POSIX visible when
> using any headers specified by POSIX.  If at some later date a revision
> of POSIX incorporates the SCTP stuff, POSIX can at that point adopt the
> SCTP names into the namespace made visible in that POSIX revision.
> 
> 
> best regards
> Andrew
> 
> 
> -----
> Andrew Josey                                The Open Group  
> Austin Group Chair                          Apex Plaza,Forbury Road,
> Email: [email-masked]                Reading,Berks.RG1 1AX,England
> Tel:   +44 118 9508311 ext 2250             Fax: +44 118 9500110

-- 
Craig Rodrigues        Distributed Systems and Logistics, Office 6/325A
[email-masked]       BBN Technologies, a Verizon company
(617) 873-4725         Cambridge, MA