Hi Florian, Keeping the "full note" is subjective as some prefer to have some context about what is updated/replaced in the abstract itself while others prefer to see that in the main text.
I'm personally neutral on this. Thank you. Cheers, Med > -----Message d'origine----- > De : [email protected] <[email protected]> > Envoyé : lundi 6 octobre 2025 08:06 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Cc : [email protected]; [email protected]; draft-ietf-grow- > [email protected]; [email protected] > Objet : Re: [GROW] Re: draft-ietf-grow-bgpopsecupd-09 early Intdir > review > > > Hi, > oops, my fault. I had never noticed / wasn't aware. > I guess a sentence "This RFC obsoletes XYZ" is enough, or do you > want the whole commentary back? It was the commentary that led to > my comment... > Cheers, > Florian > -- > Sent from a small device. Please excuse interesting auto-correct. > > 6 Oct 2025 07:47:58 [email protected]: > > > Hi Tobias/Florian, > > > > On this one: > > > >>> Abstract > >>> -------- > >>> I was surprised to read commentary on how this document > changes > >> the > >>> document it obsoletes in the abstract. Maybe the 2nd paragraph > >>> ("Previously, security considerations for BGP have been > >> described > >>> in...") can be moved to an appendix. I'm also used to checking > >> the > >>> header of RFC to see if they update or obsolete other RFC, so > I > >> don't > >>> have a need for this information in the abstract. > > > > I'm afraid some changes in the abstract will need to be > reverted. At > > least we need a mention that the document obsoletes RFC7454. > Please > > see the checks at: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > auth > > or- > tools.ietf.org%2Fapi%2Fidnits%3Furl%3Dhttps%3A%2F%2Fwww.ietf.org%2 > F > > archive%2Fid%2Fdraft-ietf-grow-bgpopsecupd- > 10.txt&data=05%7C02%7Cmoham > > > ed.boucadair%40orange.com%7Ce721dc188c56457320f208de049e6bca%7C90c > 7a20 > > > af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638953275641794000%7CUnknown%7 > CTWF > > > pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM > iIsI > > > kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nOS1Iiyf%2FhZU3 > 7aw% > > 2Fyz%2F7AD7LrD0lJG7C7OqZcWEgBc%3D&reserved=0 > > > > FWIW, this guidance is provided in draft-rpc-rfc7322bis, > specifically this part: > > > > Every RFC must have an Abstract that provides a concise and > > comprehensive overview of the purpose and contents of the > entire > > document, to give a technically knowledgeable reader a > general > > overview of the function of the document and some context > with > > regards to its relationship (in particular, whether it > updates or > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^^ > > obsoletes) any other RFCs. In addition to its function in > the RFC > > ^^^^^^^^^^^^^^^^^^^^^^^^ > > itself, the Abstract section text will appear in publication > > announcements and in the online index of RFCs. > > > > Thank you. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Tobias Fiebig <[email protected]> Envoyé : samedi 4 > octobre > >> 2025 16:23 À : Florian Obser <[email protected]>; > >> [email protected] Cc : [email protected]; > >> [email protected] Objet : [GROW] Re: draft-ietf-grow-bgpopsecupd-09 > early > >> Intdir review > >> > >> Hello Florian, > >> > >> thank you for taking the time to review the document. > >> > >>> I am marking the document as ready. Overall the draft is well > >> written > >>> and gives a concise introduction to BGP security without going > >> off > >>> into the weeds. > >>> > >>> I'll note some oddities that I spotted while reading the > >> document with > >>> fresh eyes. Feel free to address these or ignore as you see > fit. > >> > >> Thank you, this is good to hear. I outline below how we > addressed > >> your comments and uploaded -10 with these comments addressed. > >> > >> Please find the diff here: > >> > >> > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > >> author-tools.ietf.org%2Fiddiff%3Furl1%3Ddraft-ietf-grow- > >> bgpopsecupd-09%26url2%3Ddraft-ietf-grow-bgpopsecupd- > >> 10%26difftype%3D-- > >> > html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C6c4ff5c4f52c4 > >> > 8570dfd08de0351c206%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > >> > 38951846989866402%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > >> > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > >> > 3D%7C0%7C%7C%7C&sdata=RACFE8EKVtJLoJBgwILvfyTsyJvhpHlAGMJ2fTWVEGs% > >> 3D&reserved=0 > >> > >>> Title > >>> ----- > >>> "Updated BGP Operations and Security" that's probably not > going > >> to age > >>> well, if someone wishes to update this document 10 years from > >> now, > >>> will its title be "Updated Updated BGP Operations and > Security"? > >>> Maybe change it to "BGP Operations and Security", I don't > think > >> RFC > >>> titles need to be unique. > >> > >> This is an artifact from the initial working title. The > >> recommendation has been implemented. > >> > >> > >>> Abstract > >>> -------- > >>> I was surprised to read commentary on how this document > changes > >> the > >>> document it obsoletes in the abstract. Maybe the 2nd paragraph > >>> ("Previously, security considerations for BGP have been > >> described > >>> in...") can be moved to an appendix. I'm also used to checking > >> the > >>> header of RFC to see if they update or obsolete other RFC, so > I > >> don't > >>> have a need for this information in the abstract. > >>> > >>> If this is done, the 3rd paragraph does not fit any more. It > >> could be > >>> moved to the end of the introduction, slightly changed: > >>> > >>> Remove "To this end, the document describes the security > >> requirements > >>> and..." from the abstract and add > >>> > >>>> The document explicitly does not focus on specific technical > >>>> implementations and requirements. Operators are advised to > >> consult > >>>> documentation and contemporary informational documents > >> concerning > >>>> methods to ensure that these properties are sufficiently > >> ensured in > >>>> their network. > >>> > >>> at the end of the introduction. > >> > >> I partially integrated this, reducing the text to the initial > >> summarizing part, while including the point you mentioned at > the end > >> of the introduction as well. This creates a slight text > duplication; > >> However, given the abstract's purpose, I would argue that the > >> doubling of text there is a reasonable trade-off. > >> > >>> 3. Protection of the BGP Speaker and Session > >>> --------------------------------------------- > >>> > >>> "The BGP speaker, i.e., the host running BGP..." maybe I'm > >> tainted by > >>> IPv6 terminology, but I find the term "host" strange. A host > is > >> a node > >>> that does not forward traffic. A BGP speaker might very well > >> forward > >>> traffic, so maybe "node" is a better term. Otoh I've only ever > >> used > >>> the term BGP speaker myself... > >> > >> This is an interesting point; After some thought about it, I > tend to > >> agree. I hence exchange the two occurrences of 'host' with > 'node'. > >> > >> With best regards, > >> Tobias > >> > >> > >> -- > >> My working day may not be your working day. Please do not feel > >> obliged to reply to my email outside of your normal working > hours. > >> --------------------------------------------------------------- > -- > >> Tobias Fiebig, Forschungsgruppe Internet Architecture (INET) > Max- > >> Planck-Institut für Informatik, Campus E14, 66123 Saarbrücken > >> E1 4 - Raum 517 mobil: +31 616 80 98 99 > > > __________________________________________________________________ > ____ > > ______________________________________ > > 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. _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
