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

[Ben Campbell <[e-mail]>]

Thanks for the response! Please see inline.

Ben.

> On Sep 17, 2019, at 6:12 PM, Matthew A. Miller <[e-mail]> wrote:
> 
> 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:
>> 
>> *** 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?
>> 
> 
> 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.

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.

> 
>> 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.

Thanks.

> 
>> *** Editorial Comments ***
>> 
>> §2:
>> - First paragraph:
>> — Missing comma after “modular programs” in the first sentence.
> 
> Changing in my local copy.
> 
>> — Consider s/ “now defines “ / “defines “  ( time-specific language
>> becomes dated pretty quickly)
> 
> I suggest "(starting with 6th Edition) defines "; modules were first
> introduced in ES6, so there is some version sensitivity here.
> 
>> — 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.
>> 
> 
> 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 >