Re: [tsvwg] New Version Notification for draft-morand-tsvwg-sctp-parameters-update-00.txt

[Michael Tuexen <[e-mail]>]

> On 21 Mar 2016, at 17:33, [e-mail] wrote:
> 
> Hi,
> 
> it would be nice to have feedback on the issue addressed in this draft.
> The idea is not to push the draft but to see if the issue exists and if the proposed approach (update of RFC 4960) to solve this issue is the correct one.
> Any proposed alternative would be fine as long as the concern is addressed.
Hi Lionel,

I think the SACK delay parameter can just be added to the list of parameters in section 15
of RFC 4960. I have also seen problems related to SACK.Delay and RTO.Min configurations
in the field.
We are currently working on an update of RFC 4960.
The list of proposed changes is collected in the following ID:
https://tools.ietf.org/html/draft-tuexen-tsvwg-rfc4960-errata
If you agree, we could work on a section for that ID covering your suggested change.
Please note that the above ID is still an individual submission, but we will
ask for WG adoption at the next IETF meeting.

What do you think?

Best regards
Michael
> 
> Regards,
> 
> Lionel
> 
>> -----Message d'origine-----
>> De : MORAND Lionel IMT/OLN
>> Envoyé : lundi 7 mars 2016 17:44
>> À : '[e-mail]'
>> Objet : New Version Notification for draft-morand-tsvwg-sctp-parameters-
>> update-00.txt
>> 
>> Hi,
>> 
>> The following draft has just been submitted: draft-morand-tsvwg-sctp-
>> parameters-update-00.txt
>> 
>> The intent of this draft is to update the RFC 4960 to include the recommend
>> value for the SACK delay in the list of suggested SCTP protocol parameter
>> values given in the section 15 of the RFC.
>> This list of recommended values is often used by SCTP stack implementors as
>> reference for defining the list of parameters that can be configured by SCTP
>> administrators. As the SACK delay is missing in this list, it is usually not
>> possible to configure the value required for the SACK delay.
>> 
>> There is no change to the SCTP protocol and the existing recommended
>> values for SCTP parameters. This draft has to be seen as a clarification and
>> not an enhancement or a correction.
>> 
>> Please comment.
>> 
>> Regards,
>> 
>> Lionel
>> 
>> -----Message d'origine-----
>> De : [e-mail] [mailto:[e-mail]] Envoyé : lundi
>> 7 mars 2016 17:34 À : BONNET Cédric IMT/OLN; MORAND Lionel IMT/OLN
>> Objet : New Version Notification for draft-morand-tsvwg-sctp-parameters-
>> update-00.txt
>> 
>> 
>> A new version of I-D, draft-morand-tsvwg-sctp-parameters-update-00.txt
>> has been successfully submitted by Lionel Morand and posted to the IETF
>> repository.
>> 
>> Name:		draft-morand-tsvwg-sctp-parameters-update
>> Revision:	00
>> Title:		Update of the List of Configurable SCTP Protocol Parameters
>> Document date:	2016-03-07
>> Group:		Individual Submission
>> Pages:		6
>> URL:            https://www.ietf.org/internet-drafts/draft-morand-tsvwg-sctp-
>> parameters-update-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-morand-tsvwg-sctp-
>> parameters-update/
>> Htmlized:       https://tools.ietf.org/html/draft-morand-tsvwg-sctp-
>> parameters-update-00
>> 
>> 
>> Abstract:
>>   In the SCTP protocol stack implementations available for deployment
>>   in operational networks, it has been usually observed that the list
>>   of parameters that can be configured by the operators is often
>>   restricted to the list of SCTP protocol parameter values that are
>>   recommended for SCTP given in the IETF RFC 4960.  However, this list
>>   is not exhaustive.
>> 
>>   This document updates the IETF RFC 4960 by including the SACK delay
>>   as part of the list of SCTP protocol parameters that can be
>>   configurable by an SCTP administrator.  The associated recommended
>>   value is also given, according to the IETF RFC 4960
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>