Hi Tobias, I suggest this change:
OLD: this document replaces RFC7454 / BCP194 NEW: this document obsoletes RFC 7454 The reason is that your document, although obsoleting 7454, will be published under the umbrella of BCP 194. No need to release a new revision to fix this. This can be queued till you have other comments. Thank you. Cheers, Med > -----Message d'origine----- > De : Tobias Fiebig <[email protected]> > Envoyé : mardi 7 octobre 2025 13:28 > À : [email protected] > Objet : [GROW] Re: draft-ietf-grow-bgpopsecupd-09 early Intdir > review > > > 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 : draft-ietf-grow- > [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] ____________________________________________________________________________________________________________ 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]
