Hi Colin, Please see inline. (removed items that are addressed) Cheers, Med PS: The changes can be tracked here: https://tinyurl.com/new-block-latest > -----Message d'origine----- > De : Colin Perkins [mailto:csp@xxxxxxxxxxxxx] > Envoyé : vendredi 30 avril 2021 13:02 > À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@xxxxxxxxxx> > Cc : tsv-art@xxxxxxxx; core@xxxxxxxx; draft-ietf-core-new- > block.all@xxxxxxxx; last-call@xxxxxxxx > Objet : Re: Tsvart last call review of draft-ietf-core-new-block-11 > > Hi, > > [inline] > > On 29 Apr 2021, at 7:52, mohamed.boucadair@xxxxxxxxxx wrote: > > Hi Colin, > > > > Thank you for the review. > > > > Please see inline. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Colin Perkins via Datatracker [mailto:noreply@xxxxxxxx] > Envoyé : > >> mercredi 28 avril 2021 23:55 À : tsv-art@xxxxxxxx Cc : > core@xxxxxxxx; > >> draft-ietf-core-new-block.all@xxxxxxxx; last- call@xxxxxxxx > Objet : > >> Tsvart last call review of draft-ietf-core-new-block-11 > >> > >> Reviewer: Colin Perkins > >> Review result: Ready with Issues > >> > > >> > >> In Section 7.2, I’m not convinced by the argument to set > MAX_PAYLOAD > >> to 10 for similar reasons to RFC 6928. The types of link layer > that > >> CoAP runs over are very different to those measured to support the > >> increase in TCP’s initial window. An argument based on typical > >> properties of links and buffer space in networks used by CoAP > would > >> be more convincing (I accept that using MAX_PAYLOAD of 10 is not > >> going to do any significant harm, even if it is higher than > optimal). > > > > [Med] Actually we set it to 10 as the applicability scope of this > spec > > is DOTS which runs in environments similar to those of 6928. Please > > see Section 3.2. > > This would be a lot clearer if Section 3.2 were cross-referenced, and > a reminder of the limited applicability of this specification was > added to Section 7.2. > [Med] Made this change: OLD: Note: The default value of 10 is chosen for reasons similar to those discussed in Section 5 of [RFC6928]. NEW: Note: The default value of 10 is chosen for reasons similar to those discussed in Section 5 of [RFC6928], especially given the target application discussed in Section 3.2. > >> Section 7.2 also notes that “PROBING_RATE and other transmission > >> parameters are negotiated between peers”. It would be appropriate > to > >> give some guidance on what are the bounds for safe values that can > be > >> negotiated for these parameters. > > > > [Med] I'm afraid this is out of the scope of this spec. The intent > of > > this note is to provide an example of an application that > negotiates > > these parameters. Some of these details can be found in in > > rfc8782#section-4.5.2 mentioned in the text you quoted. > > Makes sense, although I wonder if the text in Section 7.2 might be > more clearly written “The DOTS application uses customised defaults > for PROBING_RATE and other transmission parameters, as discussed in > Section > 4.5.2 of [RFC8782], that are negotiated between peers”? > [Med] Thank you, but I prefer the old wording. > > >> and I would suggest that even if there are such issues, backoff > would > >> be appropriate given persistent congestion. > >> > >> Finally, is there are mechanism for gradually recovering > MAX_PAYLOADS > >> to its original value, if persistent loss ceases for some period? > >> > > > > [Med] This is covered by the configuration refresh/negotiation > > mechanism. The peers will refresh the configuration parameters > > following, for example, I-D.bosh-dots-quick-blocks. > > Might be worth stating that in the draft? > [Med] After thinking about this further, we added this NEW text: NEW: Following a period of 24 hours where no packet recovery was required, the value of MAX_PAYLOADS can be increased by 1 (but without exceeding the default value) for a further 24 hour evaluation. _________________________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
