Re: [auth48] AUTH48: RFC-to-be 9377 <draft-ietf-lsr-isis-flood-reflection-12> for your review

[Chris Bowers <[e-mail]>]

Alice,

Can you change my affiliation to "Individual" ?   I approve the text with
that change.

Thanks,
Chris


On Wed, Mar 22, 2023 at 11:47 AM Alice Russo <[e-mail]> wrote:

> Chris,
>
> Per John's mail, we have updated your email address in the document.
> Please let us know if any other updates are needed. The files are here
> (please refresh):
>
>  https://www.rfc-editor.org/authors/rfc9377.html
>  https://www.rfc-editor.org/authors/rfc9377.pdf
>  https://www.rfc-editor.org/authors/rfc9377.txt
>  https://www.rfc-editor.org/authors/rfc9377.xml (source)
>
> Diff files of all changes from the approved Internet-Draft:
>  https://www.rfc-editor.org/authors/rfc9377-diff.html
>  https://www.rfc-editor.org/authors/rfc9377-rfcdiff.html (side by side)
>
> This page shows the AUTH48 status of your document:
>  https://www.rfc-editor.org/auth48/rfc9377
>
> Thank you.
> RFC Editor/ar
>
> > On Mar 22, 2023, at 9:05 AM, John Scudder <[e-mail]> wrote:
> >
> > Hi Alice, all,
> >
> > Chris Bowers requests that we use [e-mail] as his
> email address. I’ve updated the cc accordingly.
> >
> > Thanks,
> >
> > —John
> >
> >> On Mar 22, 2023, at 11:51 AM, Alice Russo <[e-mail]> wrote:
> >>
> >>
> >> Tony,
> >>
> >> Thank you for your reply. The document has been updated accordingly. We
> await word from your coauthors before publishing the document.
> >>
> >> RFC Editor/ar
> >>
> >>> On Mar 21, 2023, at 11:38 PM, Antoni Przygienda <prz=
> [e-mail]> wrote:
> >>>
> >>> Tony it is
> >>>
> >>> Thanks
> >>>
> >>>     • Tony
> >>>
> >>> From: Alice Russo <[e-mail]>
> >>> Date: Tuesday, 21 March 2023 at 21:59
> >>> To: Antoni Przygienda <[e-mail]>
> >>> Cc: Chris Bowers <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail]<[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, John Scudder <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>
> >>> Subject: Re: AUTH48: RFC-to-be 9377
> <draft-ietf-lsr-isis-flood-reflection-12> for your review
> >>>
> >>> [External Email. Be cautious of content]
> >>>
> >>>
> >>> Tony,
> >>>
> >>> Thank you for your reply. Please let us know your preference, and we
> will make a note of it for any documents that may arrive in the queue in
> the future.
> >>>
> >>> In this case, the approved I-D contained both forms:
> >>> A. Przygienda, Ed.       <- header
> >>> Tony Przygienda (editor) <- Authors' Addresses
> >>>
> >>> Thank you.
> >>> RFC Editor/ar
> >>>
> >>>>> On Mar 21, 2023, at 9:29 AM, Antoni Przygienda <prz=
> [e-mail]> wrote:
> >>>>
> >>>> Alice,
> >>>>
> >>>> My passport reads officially “Antoni” but first, no’one can stress
> the pen-ultimate syllable properly in the West and 2nd I’m being fashioned
> into “Antonio” too often so my default became “Tony” for many, many years
> now 😉
> >>>>
> >>>> Pls take your fair pick …
> >>>>
> >>>>     • Tony
> >>>>
> >>>> From: Alice Russo <[e-mail]>
> >>>> Date: Tuesday, 21 March 2023 at 17:08
> >>>> To: Antoni Przygienda <[e-mail]>
> >>>> Cc: Chris Bowers <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail]<[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, John Scudder <
> [e-mail]>, [e-mail]<
> [e-mail]>, [e-mail] <
> [e-mail]>
> >>>> Subject: Re: AUTH48: RFC-to-be 9377
> <draft-ietf-lsr-isis-flood-reflection-12> for your review
> >>>>
> >>>> [External Email. Be cautious of content]
> >>>>
> >>>>
> >>>> Tony,
> >>>>
> >>>> Thank you for your reply; we have marked your approval on the AUTH48
> status page. May the header be updated from "A. Przygienda, Ed." to "T.
> Przygienda, Ed." to match what appears in the Authors' Addresses section
> and most of the past RFCs?
> >>>>
> >>>> Either way, we recommend that full name in the Authors' Addresses
> match up with the header.
> >>>>
> >>>> As far as precedent, in the headers:
> >>>> - "A. Przygienda" in RFC 9272 and RFC 8401. (with "Antoni Przygienda"
> in the Authors' Addresses in RFC 9272)
> >>>> - "T. Przygienda" in RFCs 8918, 8556, 8444, 8279, 7987, 5302, 5120,
> and earlier RFCs.
> >>>>
> >>>> Thank you.
> >>>> RFC Editor/ar
> >>>>
> >>>>> On Mar 20, 2023, at 1:43 PM, Antoni Przygienda <prz=
> [e-mail]> wrote:
> >>>>>
> >>>>> Alice, thanks for the work. Re-read diffs from original version and
> no further comments
> >>>>>
> >>>>>     • Tony
> >>>>>
> >>>>> From: Alice Russo <[e-mail]>
> >>>>> Date: Friday, 17 March 2023 at 01:20
> >>>>> To: Antoni Przygienda <[e-mail]>
> >>>>> Cc: Chris Bowers <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail]<[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, John Scudder <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>
> >>>>> Subject: Re: AUTH48: RFC-to-be 9377
> <draft-ietf-lsr-isis-flood-reflection-12> for your review
> >>>>>
> >>>>> [External Email. Be cautious of content]
> >>>>>
> >>>>>
> >>>>> Tony,
> >>>>>
> >>>>> Regarding the authors' comments that were in the submitted XML file,
> they remain in the edited XML file currently -- please review and let us
> know whether any updates are needed, or it's fine to remove them as this
> point. They include items such as
> >>>>> <!-- @todo: do we make it a SHOULD? -->
> >>>>>
> >>>>> Thank you.
> >>>>> RFC Editor/ar
> >>>>>
> >>>>>> On Mar 16, 2023, at 5:13 PM, Alice Russo <[e-mail]> wrote:
> >>>>>>
> >>>>>> Tony,
> >>>>>>
> >>>>>> Thank you for your reply; details below. The revised files are here
> (please refresh):
> >>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377.html__;!!NEt6yMaO-gk!Ht9VIJ3o9TU4SUTlAhcBu8YVP4a4TVKPkUEAhGJXnsGzdegO8tjg_P1l8VZFqY1ENH7z1HUvu9Y$
> >>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377.txt__;!!NEt6yMaO-gk!Ht9VIJ3o9TU4SUTlAhcBu8YVP4a4TVKPkUEAhGJXnsGzdegO8tjg_P1l8VZFqY1ENH7zqspr-ws$
> >>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377.pdf__;!!NEt6yMaO-gk!Ht9VIJ3o9TU4SUTlAhcBu8YVP4a4TVKPkUEAhGJXnsGzdegO8tjg_P1l8VZFqY1ENH7z9Xqno9w$
> >>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377.xml__;!!NEt6yMaO-gk!Ht9VIJ3o9TU4SUTlAhcBu8YVP4a4TVKPkUEAhGJXnsGzdegO8tjg_P1l8VZFqY1ENH7zUgKbHbQ$
> >>>>>>
> >>>>>> This diff file shows all changes from the approved I-D:
> >>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377-diff.html__;!!NEt6yMaO-gk!Ht9VIJ3o9TU4SUTlAhcBu8YVP4a4TVKPkUEAhGJXnsGzdegO8tjg_P1l8VZFqY1ENH7zTJNLCBg$
> >>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377-rfcdiff.html__;!!NEt6yMaO-gk!Ht9VIJ3o9TU4SUTlAhcBu8YVP4a4TVKPkUEAhGJXnsGzdegO8tjg_P1l8VZFqY1ENH7znInsXcg$
> (side by side)
> >>>>>>
> >>>>>> This diff file shows only the changes since the last posted version:
> >>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377-lastrfcdiff.html__;!!NEt6yMaO-gk!Ht9VIJ3o9TU4SUTlAhcBu8YVP4a4TVKPkUEAhGJXnsGzdegO8tjg_P1l8VZFqY1ENH7zQ0kM4f8$
> (side by side)
> >>>>>>
> >>>>>>
> >>>>>>> On Mar 15, 2023, at 2:37 PM, Antoni Przygienda <[e-mail]>
> wrote:
> >>>>>>>
> >>>>>>> I read side by side. Final Observations:
> >>>>>>>
> >>>>>>> . please do not split across lines things like “IS-IS Level 1”.
> Those are basically “one word concepts”
> >>>>>>
> >>>>>> Added entities in the XML source file to prevent line breaks within
> those terms in the abstract.  (And now there's a line break between "IS-IS
> Level 2" and "(L2)" in the text output, which is acceptable from our
> perspective. As you might imagine, this type of control is a slippery
> slope.)
> >>>>>>
> >>>>>>> . “A tunnel that is between two clients” is very awkward, maybe “A
> tunnel established between two clients which is”.  (since it’s the tunnel
> visible in L1 here)
> >>>>>>
> >>>>>> Updated as follows (using 'that' instead of 'which' because it's
> restrictive):
> >>>>>>
> >>>>>> L1 shortcut:
> >>>>>>    A tunnel established between two clients that is visible in L1
> >>>>>>    only and is used as a next hop, i.e., to carry data traffic in
> >>>>>>    tunnel-based deployment mode.
> >>>>>>
> >>>>>> Alternatively, here's an option to avoid the relative clause:
> >>>>>>
> >>>>>> L1 shortcut:
> >>>>>>   A tunnel established between two clients; it is visible in L1
> >>>>>>   only and is used as a next hop, i.e., to carry data traffic in
> >>>>>>   tunnel-based deployment mode.
> >>>>>>
> >>>>>>
> >>>>>>> . “a flood reflection mechanism”. Well, there is only one so
> either no article or determinate please
> >>>>>>
> >>>>>> Updated to "the flood reflection mechanism".
> >>>>>>
> >>>>>>
> >>>>>>> . “T he” is split across lines in Flood Reflection Client ID
> definition
> >>>>>>
> >>>>>> Good catch. This is a known issue with xml2rfc (
> https://urldefense.com/v3/__https://github.com/ietf-tools/xml2rfc/issues/532__;!!NEt6yMaO-gk!Ht9VIJ3o9TU4SUTlAhcBu8YVP4a4TVKPkUEAhGJXnsGzdegO8tjg_P1l8VZFqY1ENH7zcrYmoCY$
> and againhttps://
> urldefense.com/v3/__https://github.com/ietf-tools/xml2rfc/issues/857__;!!NEt6yMaO-gk!Ht9VIJ3o9TU4SUTlAhcBu8YVP4a4TVKPkUEAhGJXnsGzdegO8tjg_P1l8VZFqY1ENH7zY9cyx04$
> ). At this point, there are at least a couple options:
> >>>>>> a) remove the expanded term.
> >>>>>> b) insert a line break after the colon (by changing the whole list
> to newline="true").
> >>>>>>
> >>>>>> Have done (a) -- removed the expanded term because expanding "ID"
> as "Identifier" is not necessary. Please let us know if you prefer
> otherwise.
> >>>>>>
> >>>>>>
> >>>>>>> . Splitting off and saying “However, in any case” changes the
> meaning a bit. Maybe “In all those cases …”
> >>>>>>
> >>>>>> Updated accordingly.
> >>>>>>
> >>>>>>
> >>>>>>> . “An L1 shortcut …”. Not a vocal, shouldn’t that be “A L1
> shortcut … “
> >>>>>>> . “into an L1 that connects” should be “into an L1 area that …”
> >>>>>>
> >>>>>> As John noted, if "L1" is read "ell won", it's "an L1". Here's the
> Chicago Manual of Style on the topic.
> >>>>>>
> >>>>>> "Before an abbreviation, a symbol, or a numeral, the use of a or an
> depends on (or, conversely, determines) how the term is pronounced. In the
> first example below, “MS” would be pronounced em ess ..."
> >>>>>> (from Chapter 7.33: “A” and “an” before abbreviations, symbols, and
> numerals)
> >>>>>>
> >>>>>>
> >>>>>>> . a “non-FR router” could be expaned to “a router not
> participating in flood reflection”
> >>>>>>
> >>>>>> Added as follows:
> >>>>>> (a "non-FR router", i.e., a router not participating in flood
> reflection)
> >>>>>>
> >>>>>> It makes the resulting sentence even more complex:
> >>>>>>
> >>>>>> In certain cases where reflectors are attached to the same broadcast
> >>>>>> medium, and where some other L2 router that is neither a flood
> >>>>>> reflector nor a flood reflector client (a "non-FR router", i.e., a
> >>>>>> router not participating in flood reflection) attaches to the same
> >>>>>> broadcast medium, flooding between the reflectors in question might
> >>>>>> not succeed, potentially partitioning the flood reflection domain.
> >>>>>>
> >>>>>> Alternatively, let us know if you want to rephrase it as follows or
> otherwise.
> >>>>>>
> >>>>>> Flooding between reflectors might not succeed, thereby potentially
> >>>>>> partitioning the flood reflection domain, in certain cases where:
> >>>>>> *  reflectors are attached to the same broadcast medium and
> >>>>>> *  some other L2 router that is neither a flood reflector nor a
> >>>>>>    flood reflector client (a "non-FR router", i.e., a router not
> >>>>>>    participating in flood reflection) attaches to the same broadcast
> >>>>>>    medium.
> >>>>>>
> >>>>>> Thank you.
> >>>>>> RFC Editor/ar
> >>>>>>
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>>    • Tony
> >>>>>>>
> >>>>>>>
> >>>>>>> From: Alice Russo <[e-mail]>
> >>>>>>> Date: Wednesday, 15 March 2023 at 19:47
> >>>>>>> To: Antoni Przygienda <[e-mail]>
> >>>>>>> Cc: Chris Bowers <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail]<[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, John Scudder <
> [e-mail]>, [e-mail]<
> [e-mail]>, [e-mail] <
> [e-mail]>
> >>>>>>> Subject: Re: AUTH48: RFC-to-be 9377
> <draft-ietf-lsr-isis-flood-reflection-12> for your review
> >>>>>>>
> >>>>>>> [External Email. Be cautious of content]
> >>>>>>>
> >>>>>>>
> >>>>>>> Tony,
> >>>>>>>
> >>>>>>> Thank you for your reply; details below. The revised files are
> here (please refresh):
> >>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377.html__;!!NEt6yMaO-gk!B9ONFT9caWXejp4EDeyz9V282PreLIMnOPYN59SnwtVpXog-ynWlN5q0YoowhMpCEm2B7noyYjY$
> >>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377.txt__;!!NEt6yMaO-gk!B9ONFT9caWXejp4EDeyz9V282PreLIMnOPYN59SnwtVpXog-ynWlN5q0YoowhMpCEm2BKpPIopw$
> >>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377.pdf__;!!NEt6yMaO-gk!B9ONFT9caWXejp4EDeyz9V282PreLIMnOPYN59SnwtVpXog-ynWlN5q0YoowhMpCEm2BtY7EwUU$
> >>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377.xml__;!!NEt6yMaO-gk!B9ONFT9caWXejp4EDeyz9V282PreLIMnOPYN59SnwtVpXog-ynWlN5q0YoowhMpCEm2BnjlCUUc$
> >>>>>>>
> >>>>>>> This diff file shows all changes from the approved I-D:
> >>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377-diff.html__;!!NEt6yMaO-gk!B9ONFT9caWXejp4EDeyz9V282PreLIMnOPYN59SnwtVpXog-ynWlN5q0YoowhMpCEm2BntKNzC4$
> >>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377-rfcdiff.html__;!!NEt6yMaO-gk!B9ONFT9caWXejp4EDeyz9V282PreLIMnOPYN59SnwtVpXog-ynWlN5q0YoowhMpCEm2B4969Us4$
> (side by side)
> >>>>>>>
> >>>>>>> This diff file shows only the changes since the last posted
> version:
> >>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377-lastrfcdiff.html__;!!NEt6yMaO-gk!B9ONFT9caWXejp4EDeyz9V282PreLIMnOPYN59SnwtVpXog-ynWlN5q0YoowhMpCEm2Bb2JJmDs$
> >>>>>>>
> >>>>>>> Re: #13c
> >>>>>>>> LSPDU is seldom used now. It’s LSP normally
> >>>>>>>
> >>>>>>> Both were used in the original; we have updated the document to
> "LSP" only.
> >>>>>>>
> >>>>>>>
> >>>>>>> Re: #13b
> >>>>>>>> As to non-FR or “non FR” or “not an FR”, everything fine for me
> >>>>>>>
> >>>>>>>
> >>>>>>> No changes to "non-FR" have been made.
> >>>>>>>
> >>>>>>> Our original question was whether it means 'non flood reflection'.
> Sounds like it means 'non flood reflector', which seems sufficiently clear
> in context:
> >>>>>>>   some other L2 router that is neither a flood reflector nor a
> flood reflector client (a "non-FR router")
> >>>>>>>
> >>>>>>>
> >>>>>>> Re: #14
> >>>>>>>> As I write above, removing any “historical”, “traditional” or
> some such and replacting with this reference will clarify
> >>>>>>>
> >>>>>>> All instances of 'traditional' were replaced with 'standard' as
> you requested. One sentence has been added in Section 3:  "In this
> document, the term "standard" refers to IS-IS as specified in [ISO10589]."
> Please provide OLD/NEW text (or update the XML file available from
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377.xml__;!!NEt6yMaO-gk!B9ONFT9caWXejp4EDeyz9V282PreLIMnOPYN59SnwtVpXog-ynWlN5q0YoowhMpCEm2BnjlCUUc$
> ) if further updates are needed.
> >>>>>>>
> >>>>>>>
> >>>>>>> FYI, this document as been updated to 'next hop' (noun) and
> 'next-hop' (adjective) in keeping with referenced documents (e.g., RFC
> 9012).
> >>>>>>>
> >>>>>>>
> >>>>>>> We will wait to hear from you again and from your coauthors
> >>>>>>> before continuing the publication process. This page shows
> >>>>>>> the AUTH48 status of your document:
> >>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9377__;!!NEt6yMaO-gk!B9ONFT9caWXejp4EDeyz9V282PreLIMnOPYN59SnwtVpXog-ynWlN5q0YoowhMpCEm2BzojESsY$
> >>>>>>>
> >>>>>>> Thank you.
> >>>>>>> RFC Editor/ar
> >>>>>>>
> >>>>>>>> On Mar 13, 2023, at 9:50 AM, Antoni Przygienda <prz=
> [e-mail]> wrote:
> >>>>>>>>
> >>>>>>>> Alice,
> >>>>>>>>
> >>>>>>>> Yes, we can add such text, probably good clarification anyway …
> >>>>>>>>
> >>>>>>>> Rest inline
> >>>>>>>>
> >>>>>>>>    • Tony
> >>>>>>>>
> >>>>>>>> From: Alice Russo <[e-mail]>
> >>>>>>>> Date: Friday, 10 March 2023 at 21:14
> >>>>>>>> To: Antoni Przygienda <[e-mail]>
> >>>>>>>> Cc: Chris Bowers <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail]<[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, [e-mail]<
> [e-mail]>, [e-mail] <[e-mail]>, John Scudder <
> [e-mail]>, [e-mail]<
> [e-mail]>, [e-mail] <
> [e-mail]>
> >>>>>>>> Subject: Re: AUTH48: RFC-to-be 9377
> <draft-ietf-lsr-isis-flood-reflection-12> for your review
> >>>>>>>>
> >>>>>>>> [External Email. Be cautious of content]
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Tony,
> >>>>>>>>
> >>>>>>>> An addition on:
> >>>>>>>>> Regarding the following note, please clarify where you would
> like [ISO10589] to be cited. Is your request to cite it at each mention of
> 'standard'?
> >>>>>>>>>
> >>>>>>>>>> To avoid confusing the skilled reader following reference must
> be used when “standard” is meant
> >>>>>>>>>>
> >>>>>>>>>> [ISO10589] ISO, "Intermediate System to Intermediate System
> Intra-
> >>>>>>>>>>            Domain Routing Exchange Protocol for use in
> Conjunction
> >>>>>>>>>>            with the Protocol for Providing the
> Connectionless-mode
> >>>>>>>>>>            Network Service (ISO 8473)", ISO/IEC 10589:2002,
> November
> >>>>>>>>>>            2002.
> >>>>>>>>
> >>>>>>>> One option is to add text such as
> >>>>>>>>
> >>>>>>>>  In this document, the term "standard" (as in "standard L2
> adjacencies") refers to [ISO10589].
> >>>>>>>>
> >>>>>>>> Thank you.
> >>>>>>>> RFC Editor/ar
> >>>>>>>>
> >>>>>>>>> On Mar 10, 2023, at 10:03 AM, Alice Russo <[e-mail]>
> wrote:
> >>>>>>>>>
> >>>>>>>>> Tony,
> >>>>>>>>>
> >>>>>>>>> Thank you for your reply. We have updated the document
> accordingly; please see the follow-ups below. The revised files are here
> (please refresh):
> >>>>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377.html__;!!NEt6yMaO-gk!FH4aIH6l4HNV9cct7Od_RCEjdi9Nov-WS-4PXfqft_OGrhaG9sc11WowBWWoFC7_eSkqjOT1LLo$
> >>>>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377.txt__;!!NEt6yMaO-gk!FH4aIH6l4HNV9cct7Od_RCEjdi9Nov-WS-4PXfqft_OGrhaG9sc11WowBWWoFC7_eSkqEYzGChA$
> >>>>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377.pdf__;!!NEt6yMaO-gk!FH4aIH6l4HNV9cct7Od_RCEjdi9Nov-WS-4PXfqft_OGrhaG9sc11WowBWWoFC7_eSkq10E_Yl4$
> >>>>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377.xml__;!!NEt6yMaO-gk!FH4aIH6l4HNV9cct7Od_RCEjdi9Nov-WS-4PXfqft_OGrhaG9sc11WowBWWoFC7_eSkqyghcH74$
> >>>>>>>>>
> >>>>>>>>> This diff file shows all changes from the approved I-D:
> >>>>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377-diff.html__;!!NEt6yMaO-gk!FH4aIH6l4HNV9cct7Od_RCEjdi9Nov-WS-4PXfqft_OGrhaG9sc11WowBWWoFC7_eSkq15JBpZ0$
> >>>>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377-rfcdiff.html__;!!NEt6yMaO-gk!FH4aIH6l4HNV9cct7Od_RCEjdi9Nov-WS-4PXfqft_OGrhaG9sc11WowBWWoFC7_eSkqnIsWuu4$
> (side by side)
> >>>>>>>>>
> >>>>>>>>> This diff file shows the changes made during AUTH48 thus far:
> >>>>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9377-auth48diff.html__;!!NEt6yMaO-gk!FH4aIH6l4HNV9cct7Od_RCEjdi9Nov-WS-4PXfqft_OGrhaG9sc11WowBWWoFC7_eSkq_cOaGzM$
> >>>>>>>>>
> >>>>>>>>> -- Re: #11
> >>>>>>>>>> Please do not remove, the sentence applies each to a different
> mechanism described in the according paragraph. Even they are verbatimely
> same.
> >>>>>>>>>
> >>>>>>>>> OK; the repeated sentence has been restored in the Security
> Considerations. Should a lead-in phrase be added to make it clear that it
> applies to a different mechanism than the first instance?
> >>>>>>>>>
> >>>>>>>>> Currently appears twice:
> >>>>>>>>>> Since the available security procedures will vary by
> >>>>>>>>>> deployment and tunnel type, the details of securing tunnels are
> >>>>>>>>>> beyond the scope of this document.
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>> No lead sentence necessary, the context of the paragraph defines
> which tunnel we talk about
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -- Re: #13b and 13c
> >>>>>>>>> Would you like any updates for "non-FR"  or for the usage of
> LSPDU vs. LSP?
> >>>>>>>>
> >>>>>>>> LSPDU is seldom used now. It’s LSP normally
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> As to non-FR or “non FR” or “not an FR”, everything fine for me
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -- Re: #14
> >>>>>>>>> We have updated the document as requested, including changing
> 'traditional' to 'standard'.  Along the lines of John's suggestions, other
> options, which may not be accurate choices in this case, include
> 'conventional', 'typical', 'commonly used', and 'long-established'.
> >>>>>>>>>
> >>>>>>>>> Regarding the following note, please clarify where you would
> like [ISO10589] to be cited. Is your request to cite it at each mention of
> 'standard'?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> As I write above, removing any “historical”, “traditional” or
> some such and replacting with this reference will clarify
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> To avoid confusing the skilled reader following reference must
> be used when “standard” is meant
> >>>>>>>>>>
> >>>>>>>>>> [ISO10589] ISO, "Intermediate System to Intermediate System
> Intra-
> >>>>>>>>>>            Domain Routing Exchange Protocol for use in
> Conjunction
> >>>>>>>>>>            with the Protocol for Providing the
> Connectionless-mode
> >>>>>>>>>>            Network Service (ISO 8473)", ISO/IEC 10589:2002,
> November
> >>>>>>>>>>            2002.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -- Section 2.1: Should "whereas" be "where" here? If not, how
> should this be rephrased?
> >>>>>>>>
> >>>>>>>> “where” will work as well
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Original:
> >>>>>>>>> ISIS Level-1 and Level-2 areas, mostly abbreviated as L1 and L2:
> >>>>>>>>>    Traditional ISIS concepts whereas a routing domain has two
> >>>>>>>>>    "levels" with a single L2 area being the "backbone" that
> connects
> >>>>>>>>>    multiple L1 areas for scaling and reliability purposes.
> >>>>>>>>>
> >>>>>>>>> Current:
> >>>>>>>>> IS-IS Level 1 and Level 2 areas (mostly abbreviated as L1 and
> L2):
> >>>>>>>>>    IS-IS concepts whereas a routing domain has two "levels" with
> a
> >>>>>>>>>    single L2 area being the "backbone" that connects multiple L1
> >>>>>>>>>    areas for scaling and reliability purposes.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -- Section 1: FYI, this sentence has been updated from
> 'standard' to 'Standards Track document' as it seems to refer to the status
> of a document in the IETF context. Please let us know if you prefer
> otherwise.
> >>>>>>>>
> >>>>>>>> ack
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Original:
> >>>>>>>>> It is expected that deployment at scale, and suitable time in
> >>>>>>>>> operation, will provide sufficient evidence to either make this
> >>>>>>>>> extension a standard, or suggest necessary modifications to
> accomplish this.
> >>>>>>>>>
> >>>>>>>>> Perhaps:
> >>>>>>>>> It is expected that deployment at scale, and suitable time in
> >>>>>>>>> operation, will provide sufficient evidence to either put this
> >>>>>>>>> extension into a Standards Track document or suggest necessary
> >>>>>>>>> modifications to accomplish that.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Agreed
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> We will wait to hear from you again and from your coauthors
> >>>>>>>>> before continuing the publication process. This page shows
> >>>>>>>>> the AUTH48 status of your document:
> >>>>>>>>>
> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9377__;!!NEt6yMaO-gk!FH4aIH6l4HNV9cct7Od_RCEjdi9Nov-WS-4PXfqft_OGrhaG9sc11WowBWWoFC7_eSkqbEAPlfw$
> >>>>>>>>>
> >>>>>>>>> Thank you.
> >>>>>>>>> RFC Editor/ar
> >>>>>>>>>
> >>>>>>>>>> On Mar 8, 2023, at 1:36 PM, Antoni Przygienda <prz=
> [e-mail]> wrote:
> >>>>>>>>>>
> >>>>>>>>>>   • Keywords: scalability
> >>>>>>>>>>   • Yes, please
> >>>>>>>>>>   • Terminology is good
> >>>>>>>>>>   • Ok, as long it’s consistent across the document
> >>>>>>>>>>   • Massaged
> >>>>>>>>>>
> >>>>>>>>>>    Traditional IS-IS architecture prescribes a routing domain
> with two
> >>>>>>>>>>    "levels" where a single L2 area functions as the "backbone"
> that connects
> >>>>>>>>>>    multiple L1 areas amongst themselves for scaling and
> reliability purposes.
> >>>>>>>>>>    In such architecture, L2 can be used as transit for traffic
> carried from one L1 area to another, but
> >>>>>>>>>>    L1 areas themselves cannot be used for that purpose because
> the L2 level must
> >>>>>>>>>>    be a single "connected" entity, and all traffic exiting an
> L1 area flows along L2 routers until the
> >>>>>>>>>>    traffic arrives at the destination L1 area itself.
> >>>>>>>>>>
> >>>>>>>>>>   • Please change per suggestion
> >>>>>>>>>>   • Ditto
> >>>>>>>>>>   • Yes, please change per suggestion
> >>>>>>>>>>   • Ditto
> >>>>>>>>>>   • Ditto
> >>>>>>>>>>   • Please do not remove, the sentence applies each to a
> different mechanism described in the according paragraph. Even they are
> verbatimely same.
> >>>>>>>>>>   • Please change per suggestion
> >>>>>>>>>>   • Remove CAPS on all occurences of “RESERVED”
> >>>>>>>>>>   • Quickly did after reading NIST. I don’t see any terms that
> are not inclusive though of course anything can be argued to be
> non-inclusive in the ever expanding list of political correctness. So,
> unless I’m pointed to specific terms that insult I am at a loss what to
> look for further.
> >>>>>>>>>>
> >>>>>>>>>> As to “traditional”, here are suggestions to make it (more)
> readable for <insert here politically correct term for genus homo
> individuals> not skilled in ISIS previous art.
> >>>>>>>>>>
> >>>>>>>>>> “This arrangement gives the L2 topology significantly better
> scaling properties than traditionally used flat designs.”
> >>>>>>>>>>
> >>>>>>>>>> Could be replaced with “prevalently” ?
> >>>>>>>>>>
> >>>>>>>>>> “Traditional ISIS concepts whereas a routing domain has two
> "levels" with a single L2 area being the "backbone" that connects multiple
> L1 areas for scaling and reliability purposes.”
> >>>>>>>>>>
> >>>>>>>>>> Traditional can be removed
> >>>>>>>>>>
> >>>>>>>>>> “In traditional ISIS L2 can be used as transit for L1-L1
> traffic but L1”
> >>>>>>>>>> “The traditional approach to increasing the scale of an IS-IS
> deployment is to break it up into multiple L1 flooding domains and a single
> L2 backbone”
> >>>>>>>>>>
> >>>>>>>>>> Can be replaced with “standard”. To avoid confusing the skilled
> reader following reference must be used when “standard” is meant
> >>>>>>>>>>
> >>>>>>>>>> [ISO10589] ISO, "Intermediate System to Intermediate System
> Intra-
> >>>>>>>>>>            Domain Routing Exchange Protocol for use in
> Conjunction
> >>>>>>>>>>            with the Protocol for Providing the
> Connectionless-mode
> >>>>>>>>>>            Network Service (ISO 8473)", ISO/IEC 10589:2002,
> November
> >>>>>>>>>>            2002.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> “Unmodified (traditional) L2 routers”
> >>>>>>>>>> “(those having traditional L2 adjacencies)”
> >>>>>>>>>> “client will have both traditional L2 adjacencies and flood
> reflector L2 adjacencies.”
> >>>>>>>>>> “A flood reflector MUST NOT form any traditional L2
> adjacencies.”
> >>>>>>>>>> “flood reflector MUST NOT form any traditional L2 adjacencies.”
> >>>>>>>>>> “When two flood reflector clients form a traditional L2
> adjacency the Cluster IDs are disregarded.”
> >>>>>>>>>> “
> >>>>>>>>>>
> >>>>>>>>>> Same
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thanks for the thorough read through and good suggestions
> >>>>>>>>>>
> >>>>>>>>>>   • Tony
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> From: [e-mail] <[e-mail]>
> >>>>>>>>>> Date: Tuesday, 7 March 2023 at 08:56
> >>>>>>>>>> To: Antoni Przygienda <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail]<[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
> >>>>>>>>>> Cc: [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, John Scudder <
> [e-mail]>, [e-mail]<
> [e-mail]>
> >>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9377
> <draft-ietf-lsr-isis-flood-reflection-12> for your review
> >>>>>>>>>>
> >>>>>>>>>> [External Email. Be cautious of content]
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Authors,
> >>>>>>>>>>
> >>>>>>>>>> While reviewing this document during AUTH48, please resolve the
> following
> >>>>>>>>>> questions, which are also in the XML file.
> >>>>>>>>>>
> >>>>>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that
> appear in the
> >>>>>>>>>> title) for use on
> https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!NEt6yMaO-gk!CTtw8b8jojiV7V4XbM1zBz88j4hp9-_E-Dy6iHRNVkEuVQP7EFJK7f12aL1hMJCqBCkc24Mk18PytVj6qNPYpg$
> .
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2) <!-- [rfced] May we update this sentence as follows for
> correctness?
> >>>>>>>>>> The changes are to
> >>>>>>>>>> - move the phrase "that use the entire forwarding capacity
> >>>>>>>>>> of the L1 areas" so that it modifies "networks"
> >>>>>>>>>> - change "introducing" to "introduces" for consistent verb tense
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> It allows networks to be built that use
> >>>>>>>>>> the entire forwarding capacity of the L1 areas, while at the
> same
> >>>>>>>>>> time introducing control plane scaling benefits provided by L2
> flood
> >>>>>>>>>> reflectors.
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> It allows networks that use
> >>>>>>>>>> the entire forwarding capacity of the L1 areas to be built,
> while
> >>>>>>>>>> at the same time it introduces control plane scaling benefits
> that
> >>>>>>>>>> are provided by L2 flood reflectors.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 3) <!-- [rfced] Since a glossary is an alphabetized list of
> terms,
> >>>>>>>>>> may we alphabetize the terms in the "Glossary"? Or would you
> prefer to
> >>>>>>>>>> change "Glossary" to "Terminology" and leave the terms in
> >>>>>>>>>> their current order?
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 4) <!-- [rfced] FYI, to match past RFCs, we updated "IS-IS
> Level-1" and "IS-IS
> >>>>>>>>>> Level-2" to "IS-IS Level 1" and "IS-IS Level 2", respectively.
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> ISIS Level-1 and Level-2 areas, mostly abbreviated as L1 and L2:
> >>>>>>>>>>    Traditional ISIS concepts whereas a routing domain has two
> >>>>>>>>>>    "levels" with a single L2 area being the "backbone" that
> connects
> >>>>>>>>>>    multiple L1 areas for scaling and reliability purposes.
> >>>>>>>>>>
> >>>>>>>>>> Current:
> >>>>>>>>>> IS-IS Level 1 and Level 2 areas (mostly abbreviated as L1 and
> L2):
> >>>>>>>>>>    Traditional IS-IS concepts whereas a routing domain has two
> >>>>>>>>>>    "levels" with a single L2 area being the "backbone" that
> connects
> >>>>>>>>>>    multiple L1 areas for scaling and reliability purposes.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 5) <!-- [rfced] We had trouble parsing these two sentences and
> understanding
> >>>>>>>>>> what "it" refers to at the end of the second sentence. For
> clarity, may
> >>>>>>>>>> we update the sentence as follows or otherwise?
> >>>>>>>>>>
> >>>>>>>>>> Also, please clarify "L1-L1". Should "L1-L1" be written "L1->L1"
> >>>>>>>>>> to use notation similar to within this document for "L2->L1"?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>>    Traditional ISIS concepts whereas a routing domain has two
> >>>>>>>>>>    "levels" with a single L2 area being the "backbone" that
> connects
> >>>>>>>>>>    multiple L1 areas for scaling and reliability purposes. In
> >>>>>>>>>>    traditional ISIS L2 can be used as transit for L1-L1 traffic
> but
> >>>>>>>>>>    L1 areas cannot be used for that purpose since L2 level must
> be
> >>>>>>>>>>    "connected" and all traffic flows along L2 routers until it
> >>>>>>>>>>    arrives at the destination L1 area.
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>>    Traditional IS-IS concepts where a routing domain has two
> >>>>>>>>>>    "levels" with a single L2 area being the "backbone" that
> connects
> >>>>>>>>>>    multiple L1 areas for scaling and reliability purposes.  In
> >>>>>>>>>>    traditional ISIS, L2 can be used as transit for L1-L1
> traffic, but
> >>>>>>>>>>    L1 areas cannot be used for that purpose because the L2
> level must
> >>>>>>>>>>    be "connected", and all traffic flows along L2 routers until
> the
> >>>>>>>>>>    traffic arrives at the destination L1 area.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 6) <!-- [rfced] The comma in this sentence breaks apart the
> objects of the
> >>>>>>>>>> verb. We suggest replacing ", and" with "and to build". Please
> let us
> >>>>>>>>>> know if you prefer otherwise.
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> Flood Reflector Client:
> >>>>>>>>>>    Node configured to build Flood Reflector Adjacencies to Flood
> >>>>>>>>>>    Reflectors, and normal adjacencies to other clients and L2
> nodes
> >>>>>>>>>>    not participating in flood reflection.
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> Flood Reflector Client:
> >>>>>>>>>>    Node configured to build Flood Reflector Adjacencies to Flood
> >>>>>>>>>>    Reflectors and to build normal adjacencies to other clients
> and
> >>>>>>>>>>    L2 nodes not participating in flood reflection.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 7) <!-- [rfced] Does "this" refer to "a flood reflection
> mechanism"
> >>>>>>>>>> mentioned in the preceding paragraph?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> First, this allows multi-area IS-IS deployments to scale
> without any
> >>>>>>>>>> major modifications in the IS-IS implementation on most of the
> nodes
> >>>>>>>>>> deployed in the network.
> >>>>>>>>>>
> >>>>>>>>>> Suggested:
> >>>>>>>>>> First, a flood reflection mechanism allows multi-area IS-IS
> deployments
> >>>>>>>>>> to scale without any major modifications in the IS-IS
> implementation on
> >>>>>>>>>> most of the nodes deployed in the network.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 8) <!-- [rfced] Please clarify this sentence. Is "L2
> computation"
> >>>>>>>>>> the subject of "can lead"?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> The L2
> >>>>>>>>>> computation determines the egress L1/L2 and with that can create
> >>>>>>>>>> illusions of ECMP where there is none, and in certain scenarios
> lead
> >>>>>>>>>> to an L1/L2 egress which is not globally optimal.
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> The L2
> >>>>>>>>>> computation determines the egress L1/L2 and, with that, can
> create
> >>>>>>>>>> illusions of ECMP where there is none; and in certain scenarios,
> >>>>>>>>>> the L2 computation can lead to an L1/L2 egress that is not
> globally
> >>>>>>>>>> optimal.
> >>>>>>>>>>
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 9) <!-- [rfced] This sentence in Section 4.2 and 4.4 seems to
> be pointing to
> >>>>>>>>>> Section 4.1. Would you like these two instances to mention the
> section number?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> Flood Reflection Cluster ID:  The Flood Reflection Cluster
> Identifier
> >>>>>>>>>>    is the same as that defined in the Flood Reflection TLV and
> obeys
> >>>>>>>>>>    the same rules.
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> Flood Reflection Cluster ID:  The Flood Reflection Cluster
> Identifier
> >>>>>>>>>>    is the same as that defined in the Flood Reflection TLV in
> Section
> >>>>>>>>>>    4.1 and obeys the same rules.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>> 10) <!-- [rfced] Please clarify this sentence, particularly
> "and in the
> >>>>>>>>>> following hop the L2 egress to which it has a forwarding
> tunnel."
> >>>>>>>>>> May we update to the following? Or is there another way we can
> update for
> >>>>>>>>>> clarity?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> Due
> >>>>>>>>>> to the rules in Section 4.6 the computation in the resulting
> topology
> >>>>>>>>>> is relatively simple, the L2 SPF from a flood reflector client
> is
> >>>>>>>>>> guaranteed to reach the Flood Reflector within a single hop,
> and in
> >>>>>>>>>> the following hop the L2 egress to which it has a forwarding
> tunnel.
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> Due
> >>>>>>>>>> to the rules in Section 4.6, the computation in the resulting
> topology
> >>>>>>>>>> is relatively simple: the L2 SPF from a flood reflector client
> is
> >>>>>>>>>> guaranteed to reach the Flood Reflector within a single hop,
> and in
> >>>>>>>>>> the following hop, it is guaranteed to reach the L2 egress to
> which
> >>>>>>>>>> it has a forwarding tunnel.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 11) <!--[rfced] FYI, this sentence appears at the end of the
> 1st paragraph
> >>>>>>>>>> and was repeated at the end of the 2nd paragraph of the
> Security Considerations,
> >>>>>>>>>> so the second instance has been removed. Please let us know if
> you prefer otherwise.
> >>>>>>>>>>
> >>>>>>>>>> Since the available security procedures will vary by
> >>>>>>>>>> deployment and tunnel type, the details of securing tunnels are
> >>>>>>>>>> beyond the scope of this document.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 12) <!--[rfced] May this be rephrased for clarity? In
> particular, the phrase
> >>>>>>>>>> "in case a tunnel is compromised if the tunnel itself does not
> provide..."
> >>>>>>>>>> reads oddly; may we change "if" to "and" as shown below?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> Additionally, the usual IS-IS security mechanisms [RFC5304]
> SHOULD be
> >>>>>>>>>> deployed to prevent misrepresentation of routing information by
> an
> >>>>>>>>>> attacker in case a tunnel is compromised if the tunnel itself
> does
> >>>>>>>>>> not provide mechanisms strong enough guaranteeing the integrity
> of
> >>>>>>>>>> the messages exchanged.
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> Additionally, the usual IS-IS security mechanisms [RFC5304]
> SHOULD be
> >>>>>>>>>> deployed to prevent misrepresentation of routing information by
> an
> >>>>>>>>>> attacker in case a tunnel is compromised and the tunnel itself
> does
> >>>>>>>>>> not provide mechanisms strong enough to guarantee the integrity
> of
> >>>>>>>>>> the messages exchanged.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 13) <!-- [rfced] Terminology:
> >>>>>>>>>>
> >>>>>>>>>> a) This term is capitalized inconsistently. Please review and
> let us
> >>>>>>>>>> know if/how they may be made consistent.
> >>>>>>>>>>
> >>>>>>>>>> Reserved vs. RESERVED
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> b) Please clarify "non-FR"; does it refer to "non flood
> reflection"?
> >>>>>>>>>> May it be explained as follows, or otherwise?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> In certain cases where reflectors are attached to same broadcast
> >>>>>>>>>> medium, and where some other L2 router, which is neither a flood
> >>>>>>>>>> reflector nor a flood reflector client (a "non-FR router")
> attaches ...
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> In certain cases where reflectors are attached to same broadcast
> >>>>>>>>>> medium, and where some other L2 router that is neither a flood
> >>>>>>>>>> reflector nor a flood reflector client (a "non-FR router", where
> >>>>>>>>>> "FR" stands for flood reflection) attaches ...
> >>>>>>>>>>
> >>>>>>>>>> c) Please review usage of LSPDU vs. LSP.
> >>>>>>>>>> It seems this document uses both to refer to "Link State PDU".
> >>>>>>>>>> For consistency, would you like to update all instances of
> LSPDU to LSP,
> >>>>>>>>>> or vice versa?
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 14) <!-- [rfced] Please review the "Inclusive Language" portion
> of the online
> >>>>>>>>>> Style Guide <
> https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!CTtw8b8jojiV7V4XbM1zBz88j4hp9-_E-Dy6iHRNVkEuVQP7EFJK7f12aL1hMJCqBCkc24Mk18PytVg5iF7yYw$
> >
> >>>>>>>>>> and let us know if any changes are needed.
> >>>>>>>>>>
> >>>>>>>>>> In addition, please consider whether "tradition",
> "traditional", and
> >>>>>>>>>> "traditionally" should be updated for clarity.  While the NIST
> website
> >>>>>>>>>> <
> https://urldefense.com/v3/__https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructio*5C__;JQ!!NEt6yMaO-gk!CTtw8b8jojiV7V4XbM1zBz88j4hp9-_E-Dy6iHRNVkEuVQP7EFJK7f12aL1hMJCqBCkc24Mk18PytVjkoQ-5hA$
> >>>>>>>>>> ns#table1>
> >>>>>>>>>> indicates that this term is potentially biased, it is also
> ambiguous.
> >>>>>>>>>> "Tradition" is a subjective term, as it is not the same for
> everyone.
> >>>>>>>>>> -->
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thank you.
> >>>>>>>>>>
> >>>>>>>>>> RFC Editor/st/ar
> >>>>>>>>>>
> >>>>>>>
> >>>>>>> Juniper Business Use Only
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> Juniper Business Use Only
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> Juniper Business Use Only
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>> Juniper Business Use Only
> >>>
> >>
> >>
>
>
>