Hi John,
From: John Scudder <[email protected]>
Date: Monday, May 9, 2022 at 3:06 PM
To: Acee Lindem <[email protected]>
Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [Lsr] [Editorial Errata Reported] RFC2328 (6679)
-rfc-editor
Hi Acee,
Did you mean “the intention of the text is to reference Figure 6”? Because
Figure 9 seems unrelated.
I can’t exactly remember what I meant then but it is obviously wrong since it
was inconsistent. I think it was this.
The area border routers RT3, RT4, RT7, RT10 and RT11 condense
the routing information of their attached non-backbone areas for
distribution via the backbone; these are the stubs that
appear in Figure 6. Remember that the third area has been
configured to condense Networks N9-N11 and Host H1 into a single
route. This yields a single line for networks N9-N11 and
Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary
routers; their externally derived information also appears on
the graph in Figure 8 as stubs.
While you’re checking that, can you also confirm that your proposed text’s
references to Figure 8 really do mean Figure 8? (I think they do but we might
as well double-check it.)
Seems to me that the erratum as filed makes the minimum necessary update and is
accurate, I think you agree? And your suggested text would be a further
improvement, fixing the “dashed stub” language which I agree is difficult to
understand. For that matter, 2328 has a second reference to “dashed stub”:
Figure 7 shows the resulting link-state database for the Area 1.
The figure completely describes that area's intra-area routing.
It also shows the complete view of the internet for the two
internal routers RT1 and RT2. It is the job of the area border
routers, RT3 and RT4, to advertise into Area 1 the distances to
all destinations external to the area. These are indicated in
Figure 7 by the dashed stub routes.
Which… TBH I don’t know what John is talking about there, there is nothing that
obviously looks like a “dashed stub route” (or a dashed anything) in Figure 7.
And now that I’m looking at it, every place the word “dashed” appears in 2328
seems suspect. A few of them can be inferred unambiguously from context, but
most of them, not even that.
Unless you think the erratum is wrong, I’m inclined to verify it as written,
because if we’re going to start fixing “dashed” there is a lot more work to do.
If we do want to fix “dashed” I guess we should open another erratum for that.
Yes – I agree. These diagrams could benefit from a BIS version with non-ASCII
text.
Thanks,
Acee
Thoughts?
Thanks,
—John
On Sep 13, 2021, at 1:28 PM, Acee Lindem (acee)
<[email protected]<mailto:[email protected]>> wrote:
Removing John as he hasn't followed the IETF for decades.
I believe the intention of the text is to reference Figure 9. However, the
terminology is confusing. I would remove the reference to "dashed". See
suggested corrections to line 3 and 6 of the paragraph below.
Corrected Text
--------------
The area border routers RT3, RT4, RT7, RT10 and RT11 condense
the routing information of their attached non-backbone areas for
distribution via the backbone; these are the stub costs that
appear in Figure 8. Remember that the third area has been
configured to condense Networks N9-N11 and Host H1 into a single
route. This yields a single line for networks N9-N11 and
Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary
routers; their externally derived information also appears on
the graph in Figure 8 as stubs.
Thanks,
Acee
On 9/7/21, 9:33 AM, "Lsr on behalf of RFC Errata System"
<[email protected]<mailto:[email protected]> on behalf of
[email protected]<mailto:[email protected]>> wrote:
The following errata report has been submitted for RFC2328,
"OSPF Version 2".
--------------------------------------
You may review the report below and at:
https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6679__;!!NEt6yMaO-gk!XUULc4qSNtOFd83qOc04rNI1xHU0WKFLBIkkxyn7q0uHXyE3C2e0rWY0s_OrQw$<https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid6679__;!!NEt6yMaO-gk!XUULc4qSNtOFd83qOc04rNI1xHU0WKFLBIkkxyn7q0uHXyE3C2e0rWY0s_OrQw$>
--------------------------------------
Type: Editorial
Reported by: Nikolai Malykh <[email protected]<mailto:[email protected]>>
Section: 3.4
Original Text
-------------
The area border routers RT3, RT4, RT7, RT10 and RT11 condense
the routing information of their attached non-backbone areas for
distribution via the backbone; these are the dashed stubs that
appear in Figure 8. Remember that the third area has been
configured to condense Networks N9-N11 and Host H1 into a single
route. This yields a single dashed line for networks N9-N11 and
Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary
routers; their externally derived information also appears on
the graph in Figure 8 as stubs.
Corrected Text
--------------
The area border routers RT3, RT4, RT7, RT10 and RT11 condense
the routing information of their attached non-backbone areas for
distribution via the backbone; these are the dashed stubs that
appear in Figure 6. Remember that the third area has been
configured to condense Networks N9-N11 and Host H1 into a single
route. This yields a single dashed line for networks N9-N11 and
Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary
routers; their externally derived information also appears on
the graph in Figure 8 as stubs.
Notes
-----
Incorrect figure number (8 instead 6).
Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.
--------------------------------------
RFC2328 (no draft string recorded)
--------------------------------------
Title : OSPF Version 2
Publication Date : April 1998
Author(s) : J. Moy
Category : INTERNET STANDARD
Source : Open Shortest Path First IGP
Area : Routing
Stream : IETF
Verifying Party : IESG
_______________________________________________
Lsr mailing list
[email protected]<mailto:[email protected]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!XUULc4qSNtOFd83qOc04rNI1xHU0WKFLBIkkxyn7q0uHXyE3C2e0rWbKRBLUkA$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!XUULc4qSNtOFd83qOc04rNI1xHU0WKFLBIkkxyn7q0uHXyE3C2e0rWbKRBLUkA$>
_______________________________________________
Lsr mailing list
[email protected]<mailto:[email protected]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!XUULc4qSNtOFd83qOc04rNI1xHU0WKFLBIkkxyn7q0uHXyE3C2e0rWbKRBLUkA$
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
