> On 22. Mar 2021, at 10:31, <mohamed.boucadair@xxxxxxxxxx> <mohamed.boucadair@xxxxxxxxxx> wrote: > > Re-, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : tuexen@xxxxxxxxxxxxxx [mailto:tuexen@xxxxxxxxxxxxxx] >> Envoyé : lundi 22 mars 2021 10:04 >> À : BOUCADAIR Mohamed TGI/OLN >> <mohamed.boucadair@xxxxxxxxxx> >> Cc : tsv-art@xxxxxxxx; dots@xxxxxxxx; draft-ietf-dots-rfc8782- >> bis.all@xxxxxxxx; last-call@xxxxxxxx >> Objet : Re: Tsvart last call review of draft-ietf-dots-rfc8782-bis-05 >> >>> On 22. Mar 2021, at 07:42, <mohamed.boucadair@xxxxxxxxxx> >> <mohamed.boucadair@xxxxxxxxxx> wrote: >>> >>> Hi Michael, >>> >>> Thank you for the review. >>> >>> The motivation was used as it was the key element in the discussion >> in Section 3.3.3 of RFC1122, but you made a fair comment. >>> >>> == >>> DISCUSSION: >>> Picking the correct datagram size to use when sending data >>> is a complex topic [IP:9]. >>> >>> (a) In general, no host is required to accept an IP >>> datagram larger than 576 bytes (including header and >>> data), so a host must not send a larger datagram >>> without explicit knowledge or prior arrangement with >>> the destination host. >>> == >>> >>> We can update the text as follows: >>> >>> OLD: >>> assume a PMTU of 576 bytes for IPv4 datagrams, as every IPv4 host >>> must be capable of receiving a packet whose length is equal to 576 >>> bytes as discussed in [RFC0791] and [RFC1122]. >>> >>> NEW: >>> assume a PMTU of 576 bytes for IPv4 datagrams (see Section 3.3.3 >> of [RFC1122]). >> Hi Med, >> >> let me try to get my point clear: >> >> You can use Section 3.3.3 of [RFC1122] to motivate that the sender >> should >> not send datagram larger than 576, since there is no guarantee that the >> receiver has resources to reassemble and process it. But RFC 1122 >> makes >> no statement about the path. > > [Med] There is this text in RFC1122: > > Since nearly all networks in the Internet currently > support an MTU of 576 or greater, we strongly recommend > the use of 576 for datagrams sent to non-local networks. OK. Then I' fine with your proposed text. Please note that this is a statement from 1989. It is fine if you can live with that number, I would guess that such a number is larger today (at least in the context of WebRTC a number in the order of 1200 bytes was used). Best regards Michael > > As far as I know there is no safe value >> for >> a PMTU you can derive from a specification. >> > > [Med] I agree with you. Things are more clear for IPv6. > >> >> So maybe: >> NEW: >> assume a PMTU of 576 bytes for IPv4 datagrams (see Section 3.3.3 of >> [RFC1122] >> for support at the receiver). >> >> Best regards >> Michael >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Michael Tüxen via Datatracker [mailto:noreply@xxxxxxxx] >>>> Envoyé : lundi 22 mars 2021 00:33 >>>> À : tsv-art@xxxxxxxx >>>> Cc : dots@xxxxxxxx; draft-ietf-dots-rfc8782-bis.all@xxxxxxxx; last- >>>> call@xxxxxxxx >>>> Objet : Tsvart last call review of draft-ietf-dots-rfc8782-bis-05 >>>> >>>> Reviewer: Michael Tüxen >>>> Review result: Ready with Nits >>>> >>>> This document has been reviewed as part of the transport area >> review >>>> team's ongoing effort to review key IETF documents. These >> comments >>>> were written primarily for the transport area directors, but are >> copied >>>> to the document's authors and WG to allow them to address any >>>> issues raised and also to the IETF discussion list for information. >>>> >>>> When done at the time of IETF Last Call, the authors should >> consider >>>> this review as part of the last-call comments they receive. Please >>>> always CC tsv-art@xxxxxxxx if you reply to or forward this review. >>>> >>>>> From a transport perspective, there is one minor issue: >>>> Section 7.3 provides a motivation for using a path MTU for IPv4 of >> 576 >>>> bytes. >>>> The motivation refers to the requirement that a receiver is capable >> of >>>> receiving IPv4 packets of that size, however they can be received >>>> fragmented. >>>> While it is acceptable to use 576 bytes as the minimum PMTU, the >>>> motivation does not hold. >>>> >>> >>> >>> >> ______________________________________________________ >> ______________________________________________________ >> _____________ >>> >>> 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. >>> > > > _________________________________________________________________________________________________________________________ > > 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. >
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
