Subject: [Gen-art] Genart last call review of draft-nottingham-rfc7320bis-02

From: Robert Sparks via Datatracker <[email-masked]>
Date: Tue, 26 Nov 2019 14:47:13 -0800

Reviewer: Robert Sparks
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-nottingham-rfc7320bis-02
Reviewer: Robert Sparks
Review Date: 2019-11-26
IETF LC End Date: 2019-12-16
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a BCP but with nits to consider during the
approval process

Nits:

Neither the document nor the shepherds write-up acknowledge or explain the
replacement of RFC6838 with RFC3986 for a reference for specifying fragment
identifier syntax and semantics (hence dropping the reference to 6838). It
would be nice to have something captured in the record that supports/explains
this change.

Near that change, there is a typo, currently saying "fragment identiers'
syntax" (should be "identifiers'")

It might be good to capture in the "Note to Readers" that the RFC Editor should
also remove Section 6.3 (URIs) since all the references to them will be removed
with the removal of this Note.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 27 Nov 2019 10:09:43 +1100

Thanks for the review Robert,

> would be nice to have something captured in the record that supports/explains

I did notice this change in my review, but didn't consider it to be significant.  The shift in focus is within the bounds of what I consider editorial discretion as the effect is identical.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 26 Nov 2019 19:54:29 -0600

Hi Martin -

Sent from my iPhone

> On Nov 26, 2019, at 5:16 PM, Martin Thomson <[email-masked]> wrote:
> 

I don’t buy that. If the effect is truly identical, leaving the text alone would have been more in keeping with your characterization of the document that it exists only to make one change. 

I suspect there’s more benefit to the change than an identical effect that just makes the editor feel better. 

To be sure, this isn’t a huge deal, but it really would help to not make the readers not guess why the change was made. 

RjS

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Nov 2019 12:56:10 +1100

> To be sure, this isn’t a huge deal, but it really would help to not make the readers not guess why the change was made. 

Do we expect most readers to be comparing the documents so closely? This is an 'obsoletes', not an 'updates'.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Nov 2019 03:13:11 +0100

> Do we expect most readers to be comparing the documents so closely? This is an 'obsoletes', not an 'updates'.

Speaking for myself as a reader only: Yes.

Grüße, Carsten

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Nov 2019 13:32:09 +1100

> On 27 Nov 2019, at 1:13 pm, Carsten Bormann <[email-masked]> wrote:
> 

My concern is that every time we add text to a document, we increase the cognitive load for readers; adding the reasoning for *every* decision and change expands a page of text into 2 to 3 (or more), so we need to impose a filter of some sort.

The requirement in question is:

 "Media type definitions (as per [RFC6838]) SHOULD specify the fragment identifier syntax(es) to be used with them"

It was removed because it was misleading (6838 doesn't make such a requirement a SHOULD), and the focus of this update was to reduce the number of unnecessary requirements. 3986 isn't replacing that reference; it's providing a grounding for what fragment identifiers are.

IME this information doesn't help the reader understand the document any better unless they're closely comparing the two documents (as reviewers are now doing, and thanks to them). If folks disagree, that's fine, but I'd like to understand why they think this information is worthy of documenting in-spec.

Cheers,

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 26 Nov 2019 18:34:17 -0800

On 26 Nov 2019, at 18:13, Carsten Bormann wrote:

>> Do we expect most readers to be comparing the documents so closely? 
>> This is an 'obsoletes', not an 'updates'.
>

Yes for me as well. Because 7320 has been used as a means of saying "you 
can't do what you want" to some protocol proposals, I definitely expect 
folks to look at the history if that happens in the future with 7320bis.

--Paul Hoffman

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Nov 2019 14:16:39 +1100

Hi Robert, thanks for the review. Responses below.

> On 27 Nov 2019, at 9:47 am, Robert Sparks via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Robert Sparks

See my previous e-mail in this thread for the explanation.

> syntax" (should be "identifiers'")

Fixed in source.

> with the removal of this Note.

Good catch; done.

I've also updated the BCP115 reference to BCP35, as per <https://www.rfc-editor.org/errata_search.php?rfc=7320>. I note that tools.ietf.org doesn't appear to be updated to make the relationship between these clear.

Cheers and thanks for the review,