Hi John, Would it be better to say “and how the parsing of the BFP OPEN is modified”? Because, the document is not only saying that one should do something, but HOW it is done :)
Regards, Christer From: Gen-art <gen-art-boun...@ietf.org> On Behalf Of John Scudder Sent: torstai 22. huhtikuuta 2021 22.23 To: Christer Holmberg <christer.holmberg=40ericsson....@dmarc.ietf.org> Cc: draft-ietf-idr-ext-opt-param....@ietf.org; i...@ietf.org; gen-art@ietf.org; last-c...@ietf.org Subject: Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-idr-ext-opt-param-11 Hi Christer, I chose to leave the abstract alone, however I updated the introduction for -13, similar to your suggestion: This document updates [RFC4271] by extending, in a backward- compatible manner, the length of the Optional Parameters in BGP OPEN. This is done by using Optional Parameter Type 255 as a distinguished value, that indicates an extended Optional Parameters Length field follows and that the parsing of the BGP OPEN should be modified according to these procedures. In this case the Parameter Length field of the individual Optional Parameters in the BGP OPEN message is also extended. Thanks again for your feedback, —John On Apr 22, 2021, at 10:36 AM, Christer Holmberg <christer.holmberg=40ericsson....@dmarc.ietf.org<mailto:christer.holmberg=40ericsson....@dmarc.ietf.org>> wrote: [External Email. Be cautious of content] Hi John, >> Q1: As far as I understand, the document only defines a new BGP OPEN Optional >> Parameter Type, but does not modify/add procedures in RFC 4271. So, is the >> document really an update to RFC 4271? And, when reading RFC 5429, I cannot >> find any text saying that new parameter types would require an update to RFC >> 4271. I also looked at a few other RFCs that add new values to the BGP IANA >> registry, and they were not updating any RFC. > > The document modifies the way a router parses the OPEN. It doesn’t just add a > new type, indeed the new type is only added as a special token to tell the > router to use the new procedures. Would it be good to explicitly indicate that? Something like: "This document updates RFC 4271 by extending, in a backward-compatible manner, the length of the Optional Parameters in the BGP OPEN, and by modifying the way a router parses the OPEN." Regards, Christer > Nits/editorial comments: > > Q2: I suggest that Section 2 is renamed to "New Optional Parameter Type > code", > or something like that. OR, if the document really is updating RFC 4271, > perhaps "Update to RFC 4271". I’ve adopted your second suggestion. > Q3: I suggest that Section 3 is renamed to "Backward Compatibility", or > something like that. Done. —John -- last-call mailing list last-c...@ietf.org<mailto:last-c...@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!NEt6yMaO-gk!VekRXfZ40ytJtNm-1zuv9KJuAV1ydVIzwKvejYNnzo0ti0AsnFotbZxEvgsYrg$<https://protect2.fireeye.com/v1/url?k=d42fed95-8bb4d4d8-d42fad0e-86b568293eb5-db9bb5f1f8c980ab&q=1&e=e63753a2-3e0d-413f-a66e-06d68918c5dd&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flast-call__%3B%21%21NEt6yMaO-gk%21VekRXfZ40ytJtNm-1zuv9KJuAV1ydVIzwKvejYNnzo0ti0AsnFotbZxEvgsYrg%24>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
