Hello Med, the change is pushed to the repo and will be in the next iteration.
Talking of that: Which next steps do you see to move this document forward? With best regards, Tobias On Tue, 2025-10-07 at 12:28 +0000, [email protected] wrote: > 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. -- 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]
