Re: [Mops] TreeDN Shepherd Review

[Chris Lemmons <[e-mail]>]

> @Chris- can you point to where in the doc you see these, perhaps with line
numbers?  I am not seeing them.

Oh, fantastic, the mail server removed the unicode marks. :)

Line 29, the apostrophe inside "weren't".
Line 108, around "seven-second delay".
Line 138, around "walled-garden".
Line 189, around "All or Nothing".
Line 197, around "It's Too Complex", including the apostrophe inside "It's".
Line 202, around "Chicken and Egg", and in "there's".
Line 203, in "there's".
Line 204, in "there's", twice.
Line 263, around "All or Nothing".
Line 276, around "Chicken and Egg".
Line 310, around the start of "It's Too", including the apostrophe in "It's".
Line 311, at the end of "Complex".
Line 461, in "aren't".

These marks are the "directional" marks instead of the plain marks.
For example, on line 29, it uses U+2019 "single right quotation mark"
instead of U+0027 "apostrophe". Editors like Microsoft Word often
insert these and call them "smart quotes". (They look nicer.) I could
be misreading the relevant RFCs regarding their use, but I was unable
to find any other RFCs that used them. The document is also
inconsistent about their usage, for example using plain quotation
marks on line 262 around "off-net receivers", but directional marks
around "All or Nothing" in the same sentence.

And regarding the boilerplate... I suspect this document isn't likely
to receive changes at this point that would add RFC 2119 words, but I
have no opinion about when the boilerplate should be dropped, merely
an observation that we probably don't need it in this doc.

@kyle: I wasn't entirely certain whether I should add my full writeup
to the datatracker before or after giving the authors a chance to make
the minor updates. It felt weird to add it with the nits when I
suspected the authors would want to fix at least some subset of them
before sending it for additional review. Let me know what works best
for streamlining things.

On Thu, Feb 15, 2024 at 2:27 PM Leonard Giuliano <[e-mail]> wrote:
>
>
> Thanks for the thorough review, @Chris!  See comments/questions inline:
>
> On Thu, 15 Feb 2024, Kyle Rose wrote:
>
> |
> | Thanks for doing the shepherd writeup, Chris. MOPS appreciates your
> | service! I'm sure I'll see it when you submit it to the data tracker,
> | but ping me or the list anyway just in case I miss it, and I'll request
> | publication for the doc.
> |
> | Authors: please feel free to address nits now, prior to submission to
> | the IESG, or indicate that you will wait for a final editorial pass in
> | IETF LC.
>
> @Kyle- I'll update in the next day or so with these fixes.
>
> |
> | Thanks,
> | Kyle
> |
> | On Sat, Feb 10, 2024 at 6:29?PM Chris Lemmons <[e-mail]> wrote:
> |       Oh, and... the document has the RFC 2119 boilerplate but doesn't
> |       actually use any of the keywords. This should also be dropped.
>
> Can we leave this in for now just in case some of these keywords gets
> added during the publication process?
>
> |
> |       On Sat, Feb 10, 2024 at 4:13?PM Chris Lemmons <[e-mail]> wrote:
> |       >
> |       > I have completed my shepherd writeup for the document, but during the
> |       > process, I located a few very minor editorial problems with the
> |       > document. Here's what I have for the remaining nits. The usage of
> |       > non-ASCII punctuation marks and the obsolete reference should, in my
> |       > opinion, be changed. If you're issuing a new draft to fix those, it
> |       > might be worthwhile to update the out-of-date draft references, but I
> |       > don't think that's critical and could be skipped, especially if the
> |       > changes on the new drafts are time-consuming to review.
> |       >
> |       > The Problem Statement section title is an acceptable editorial choice
> |       > and this document shepherd likes it :), but I'm flagging it in case it
> |       > wasn't an intentional one and you would prefer to use the more
> |       > commonly used Introduction.
> |       >
> |       > Here's my current nits section in my writeup:
> |       >
> |       > There are 13 lines with non-ASCII punctuation marks, like '?', '?',
> |       > '?', and '?'. These do not appear to comport with any of the usage
> |       > guidelines for non-ASCII Unicode characters as described in RFC 7997.
>
> @Chris- can you point to where in the doc you see these, perhaps with line
> numbers?  I am not seeing them.
>
> |       >
> |       > The Introduction section is named "Problem Statement". This appears to
> |       > be an acceptable editorial decision per RFC 7322?4.8.1.
>
> Thanks.  Started out as Intro, but thought Problem Statement was more
> appropriate based on early reviews.
>
> |       >
> |       > A number of references are slightly stale, but none appear to be critical:
> |       > - The year has incremented by one, because that is how time works. :)
> |       > - draft-ietf-bess-bgp-multicast-05 has a -07
> |       > - draft-ietf-ipsecme-g-ikev2-09 has a -10
> |       > - draft-jholland-quic-multicast-03 has a -03
>
> Good catch, I'll update while I've got the hood up.
>
> |       >
> |       > The informational reference to RFC 6830 is, however, out of date. This
> |       > document was obsoleted by RFCs 9300 and 9301.
>
> Will update.
>