Subject: [dispatch] Yet Another Shepherd Review of draft-ietf-dispatch-javascript-mjs-04

From: Ben Campbell <[email-masked]>
Date: Tue, 17 Sep 2019 16:50:55 -0500

Hi Authors,

I have taken over as shepherd for draft-ietf-dispatch-javascript-mjs. I realize there have been reviews from at least two other shepherds, but due diligence requires me to do one myself.

Have two concerns that we need to resolve prior to handing this to the IESG, and a few editorial comments that can be handled along with any AD or IETF Last Call comments.

Thanks!

Ben.

*** Material Comments/Questions ***

1) There was at least one WGLC comment that this should obsolete RFC 4329 rather than update it. I recall a comment from Matt that seemed to be agreement with that change. Was there a specific decision not to make the change?

2) The document lacks a Security Considerations section. It may be that there are no new security considerations beyond those in 4329, but if that is the case this document needs to explicitly say (and justify) that.  But please consider whether it is realistic to say we’ve learned nothing new about the security considerations since 4329 was published 13 years ago. (We can expect statements to that effect to get close scrutiny from the secdir reviewer and security ADs.)

*** Editorial Comments ***

§2:
- First paragraph:
— Missing comma after “modular programs” in the first sentence.
— Consider s/ “now defines “ / “defines “  ( time-specific language becomes dated pretty quickly)
— Consider a brief (no more than one sentence) explanation of the term “goal symbols”

- 2nd paragraph: This is the first mention of “Module or “Script” grammar goals. A very brief explanation of those terms would be helpful.

§3, 2nd paragraph:
-  Inconsistent tense.
-  consider s/“… specification is using ...”/“… specification uses ..."

---

From: "Matthew A. Miller" <[email-masked]>
Date: Tue, 17 Sep 2019 17:12:16 -0600

Thanks for the latest review, Ben.  We should be able to have the
editorial changes done very soon, but the substantive comments will take
longer.  I cannot provide a time frame right now, but should be able to
update by next week.

More specific comments inline:

On 19/09/17 15:50, Ben Campbell wrote:
> 1) There was at least one WGLC comment that this should obsolete RFC
> 4329 rather than update it. I recall a comment from Matt that seemed to
> be agreement with that change. Was there a specific decision not to make
> the change?
> 

I cannot find my original message, but I think was (probably
unnecessarily) more nuanced than that: I could see how that is valid,
and asked if doing so would require porting all the maintained content
from RFC 4329 into this document.

I admittedly went the route of leaving it alone since I don't recall
seeing any response to my question, and porting seemed like a
significant amount of work.

If changing from "Updates" to "Obsoletes" is enough, I can do that
fairly quickly.  If porting the content is needed, that will take me
much longer, but will do that if that's the consensus.

> 2) The document lacks a Security Considerations section. It may be that
> there are no new security considerations beyond those in 4329, but if
> that is the case this document needs to explicitly say (and justify)
> that.  But please consider whether it is realistic to say we’ve learned
> nothing new about the security considerations since 4329 was published
> 13 years ago. (We can expect statements to that effect to get close
> scrutiny from the secdir reviewer and security ADs.)
> 

Reading RFC 4329's existing considerations again, I think they are still
the most relevant, as surprising as that seems.

I'll consult with some of my colleagues to get their input before
submitting an update.

> — Missing comma after “modular programs” in the first sentence.

Changing in my local copy.

> becomes dated pretty quickly)

I suggest "(starting with 6th Edition) defines "; modules were first
introduced in ES6, so there is some version sensitivity here.

> - 2nd paragraph: This is the first mention of “Module or “Script”
> grammar goals. A very brief explanation of those terms would be helpful.
> 

Will do both in my working copy.

> §3, 2nd paragraph: 
> -  Inconsistent tense.
> -  consider s/“… specification is using ....”/“… specification uses ...."
> 
> 

Changing both in my working copy.

Thank you again, Ben!

- m&m

Matthew A. Miller
< http://goo.gl/LM55L >

---

From: Ben Campbell <[email-masked]>
Date: Tue, 17 Sep 2019 18:15:27 -0500

Thanks for the response! Please see inline.

Ben.

> On Sep 17, 2019, at 6:12 PM, Matthew A. Miller <[email-masked]> wrote:
> 

Making it “obsoletes” would require porting content.

I am okay leaving it as is based on the “done is a feature” principle, but don’t be surprised if it gets brought up in IETF LC.

> I'll consult with some of my colleagues to get their input before

Thanks.