Re: [tsvwg] Review of draft-ietf-tsvwg-natsupp

[Michael Tuexen <[e-mail]>]

> 
> On 29. Jul 2020, at 10:47, [e-mail] wrote:
> 
> Hi Gorry, all,  
> 
> I support the document to advance in the publication process.
> 
> As I may not be available in the coming weeks, please find below some ** minor ** comments to be considered as part of the WGLC: 
> 
> * pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-tsvwg-natsupp-20-rev%20Med.pdf
Hi Med,

thanks for the review. Here are the comments:

* Page 1: Fixed multi point -> multipoint
* [BMT1]: I changed internal addresses to private-use addresses.
          Then it is clear why RFC 6890 is cited.
* Page 3: added 'AFTR'.
* [BMT2]: Done.
* Page 4: Comma added.
* Page 4: in NAT function -> by NAT function
* [BMT3]: this feature -> SCTP-aware NAT
* Page 4: comma added
* [BMT4]: the extension -> SCTP-aware NAT
* Page 5: sent externally from behind NAT -> sent from behind NAT 
* Page 5: feature -> SCTP-aware NAT
* [BMT5]: Done.
* [BMT6]: Done.
* Page 6: Internet -> Network
* Page 6: Basic network setup -> Basic Network Setup
* Page 6: multi point -> multipoint
* Page 7: Changes accepted.
* [BMT7]: Why? I consider the two NAT functions independent. So if one fails, the
          communication can continue via the other path.
* Page 8: Changes accepted.
* [BMT8]: I don't think you gain anything from an example.
* [BMT9]: Done.
* [BMT10]: Done.
* [BMT11]: Done.
* [BMT12]: Done.
* [BMT13]: Done.
* [BMT14]: Using consistently host.
* Page 9:  Accepted, except figure name/number.
* [BMT15]: I don't think we need figure name/number.
* [BMT16]: Done.
* [BMT17]: Done.
* [BMT18]: Done.
* [BMT19]: Now using consistently host.
* [BMT20]: Not adding name/number to figure.
* [BMT21]: Not adding name/number to figure.
* Page 12: Changes accepted except figure name/number.
* Page 13: First change not accepted due to xml usage, second change accepted.
* [BMT22]: Keeping text, since requested by WG Chair.
* [BMT23]: Keeping text, since requested by WG Chair.
* [BMT24]: Keeping text, since requested by WG Chair.
* [BMT25]: Keeping text, since requested by WG Chair.
* Page 18: Changes accepted.
* BMT[26]: Done.
* Page 19: Changes accepted.
* Page 20: Changes accepted.
* [BMT27]: I'm using 10.0.0.0/8 as a private network in accordance with RFC 6890
* Page 33: Changes accepted.
* Page 40: Changes accepted.

Best regards
Michael
> * doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-tsvwg-natsupp-20-rev%20Med.docx 
> 
> Cheers,
> Med 
> 
>> -----Message d'origine-----
>> De : tsvwg [mailto:[e-mail]] De la part de Gorry
>> Fairhurst
>> Envoyé : mardi 28 juillet 2020 16:53
>> À : Lars Eggert <[e-mail]>; Michael Tuexen <tuexen@fh-
>> muenster.de>
>> Cc : [e-mail]
>> Objet : Re: [tsvwg] Review of draft-ietf-tsvwg-natsupp
>> 
>> In the WG meeting today, it was suggested by the Chairs that the WG
>> should proceed to a last LC of this document, which we plan to start
>> this week. Thanks to all who contributed to this work over the years,
>> and especially for the feedback over the last year that have allowed
>> to reach this point. Please send to the list if you have comments.
>> 
>> Gorry
>> 
>> On 28/07/2020 07:58, Lars Eggert wrote:
>>> On 2019-10-3, at 14:37, Michael Tuexen <[e-mail]>
>> wrote:
>>>> On 3. Oct 2019, at 13:35, Lars Eggert <[e-mail]> wrote:
>>>>> it'll be nine years in November since the WG adopted this
>> document, and almost 15 years since the first drafts were published.
>> Isn't it time to abandon this effort?
>>>> Or finish it? I need to address two sets of comments, which I plan
>> to do in the next two weeks...
>>> Just wanted to point out that it's been almost a year since my last
>> email and we seem no closer to finishing this.
>>> 
>>> Lars
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>