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://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-grow-bgpopsecupd-10.txt > > 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. _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
