Moin, I just re-added the text. Can you gave it a quick read and check if that works?
With best regards, Tobias On Mon, 2025-10-06 at 06:34 +0000, [email protected] wrote: > 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] -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M [email protected] _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
