Re: [tsvwg] SCTP NAT support, draft-stewart-natsupp-tsvwg-00

[Randy Stewart <[e-mail]>]

James:

My point is that it is optional behavior. Thus how can it "update" a  
base spec. I
guess we need to ask someone more aware of the finer points of what
updates RFCxxxx means.

If optional behavior can be said to update a base RFC then we need
the AUTH/ADD-IP and PR-SCTP specs to also say "updates RFC xxxx"

:-)

R

On Jan 22, 2010, at 2:34 PM, James M. Polk wrote:

> At 03:17 PM 1/22/2010, Stewart,Randall wrote:
>> James:
>>
>> I am not sure I agree.. I can see both points. It is an extension  
>> to the
>> protocol, but if the endpoint agrees to do it, it changes the base  
>> protocol
>> specification.
>
> Doesn't this last point answer your question though?
>
> This is something TSVWG needs to therefore be aware of, and, it is  
> something implementers need to know when referencing or implementing  
> SCTP as defined in RFC 4960 (that there is a modification that is  
> specified to the base protocol that's possibl).
>
>
>> My feeling is since it is an option its not really updating the  
>> base spec.
>> The base spec does not change i.e. we would not put it into the  
>> base spec
>> like we did the checksum change if we respun another BIS. So my  
>> bottom line
>> inclination is that its NOT an update but an optional feature.. one  
>> that I
>> would hope everyone would implement but not part of the base spec.
>
>
> eeehhh.... hmmm.... implementers ought know know this exists, and  
> that it optionally updates the base spec. Isn't this the same as if  
> you put an (RFC 2119) OPTIONAL for this feature in 4960?  I'm  
> thinking the results would be the same.
>
> I could be wrong though.
>
> James
>
>
>> R
>>
>> -----Original Message-----
>> From: James M. Polk [mailto:[e-mail]]
>> Sent: Friday, January 22, 2010 12:27 PM
>> To: Dan Wing; [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [tsvwg] SCTP NAT support, draft-stewart-natsupp-tsvwg-00
>>
>> At 08:02 PM 1/21/2010, Dan Wing wrote:
>> >Section 6: an SCTP client cannot determine if there is an SCTP- 
>> aware NAT
>> >between itself and the SCTP server.  That means an SCTP client  
>> always needs
>> >to include the DISABLE_RESTART parameter.  I assume that has  
>> undesirable
>> >side-effects, yes?  If so, perhaps a different design would be  
>> better,
>> >such as having the SCTP server notice the port collision and send  
>> back an
>> >error, which causes the client to either (a) re-send an INIT with  
>> the
>> >DISABLE_RESTART parameter or (b) choose a different source port  
>> number
>> >and send a new INIT without the DISABLE_RESTART parameter.
>> >
>> >Nit:  draft-stewart-natsupp-tsvwg updates RFC4960 and should say  
>> that
>> >is the intent on the first page header ("Updates: 4960 (if  
>> approved)").
>>
>> I agree
>>
>> James
>> (with my chair hat on)
>>
>>
>> >-d
>

-----
Randall Stewart
[e-mail]