Subject: [media-types] AD review of draft-ietf-dispatch-javascript-mjs-09

From: Francesca Palombini <[email-masked]>
Date: Tue, 24 Aug 2021 15:49:30 +0000

Thank you for the work on this document. This is my AD review.

I have divided comments into "main", "minor" and "nits". I'd like to have a discussion on my main comments before requesting the IETF Last Call. On the other hand, you can address the minors and nits together with any additional Last Call comments you will get. As I am coming in late to the process, please understand that I don't mean to re-hash existing discussions that I am not aware of, and I appreciate your patience: feel free to point me to previous discussion (and conclusions) I might have missed, if relevant.

For the minor comments - some of these are suggestions or questions which I hope will help improve readability, which you can decide to take or leave as you please.

Francesca

## Main

1. ----

FP: This document is presented in the Abstract, Introduction and Compatibility section as aiming to update some IANA registrations for the media types mentioned, as well as documenting current usage of these media types. Because of that, I am not convinced about the use of BCP 14 language: if the intent is documenting current practices, most of these BCP 14 terms should be replaced by explanations on how implementations behave. To give an example of my concern, for the following paragraph in Section 4:

   Implementations that support binary source text MUST support binary
   source text encoded using the UTF-8 [RFC3629] character encoding
   scheme.  Module goal sources MUST be encoded as UTF-8, all other
   encodings will fail.  Source goal sources SHOULD be encoded as UTF-8;
   other character encoding schemes MAY be supported, but are
   discouraged.

FP: Are these requirements that should have been there in RFC 4329 and are being added now? Are these how most implementations already behave? Would it not make more sense to reformulate this paragraph to describe implementations behaviour, rather than mandate and recommend? Why using BCP 14 terms?
This comment applies to all new occurrences of BCP 14 terms (it does not to apply to sections taken from RFC 4329, such as the first paragraph of section 4.1).

2. ----

FP: Maybe more of a question: why is the "Encoding considerations" field in all subsections of section 6.1 "binary"? RFC 4329 did have more text about the encoding, is that obsoleted? Did I miss in which part of the draft this is discussed?

3. ----

FP: "Published specification" field of each subsection of section 6.1 is "this document". I don't believe that is correct, and it should instead point to the correct specification (so JS 1.5, ECMAScript etc).

4. ----

FP: I would also add RFC 4329 authors as "Person & email address to contact", as well as "Author" for those media types that 4329 registered. Please let me know if this is not common practice, but it seems logical to me to have both you authors and previous authors.

5. ----

FP: I believe it would make sense to modify the IANA media type registry to add an "OBSOLETED in favor of ..." note in the name column of all those media types obsoleted. I think this requires a new IANA section.

6. ----

FP: There are 4 occurrences of media types where Intended usage is OBSOLETE, but the Restriction on usage does not have the same sentence as all the other obsolete ones:

  This media type is obsolete; current
      implementations should use text/javascript as the only JavaScript/
      ECMAScript media type.

I think this is an overlook, is that correct?

## Minor

7. -----

FP: Please consider adding some text in the introduction mentioning that this document expands on the security considerations. I appreciate this work on the Security Considerations section was done, and believe the BCP 14 terms make sense there. It should just be highlighted better in the introductory part of the document.

8. -----

FP: I am not sure RFC3986 and RFC3987 need to be a normative reference, given the only place they appear is a paragraph stating how this document does not define processing of fragment identifiers.

9. -----

FP: I'd suggest adding section numbers when referring to [ECMA-262] sections, instead of just names.

10. -----

   javascript.  Differences in ECMAScript versions have been better
   dealt with in the processors.

FP: "in the processors" - I am not sure what is meant here, might be worth considering rephrasing for clarity.

11. -----

   Refer to [RFC6265] for a discussion of terminology used in this
   section.  Source text (as defined in [ECMA-262], section "Source

FP: I am confused by what part of 6265 is relevant regarding terminology used in this section. Maybe adding a section pointer would help.

12. -----

   separately for purposes of external storage and retrieval.  An
   implementation's internal representation of source text and source
   text are not considered binary source text.

FP: I have a hard time parsing "and source text", in the context of the sentence. What's the difference with "an implementation's internal representation of source text"? (this might be me not understanding the phrasing)

13. -----

FP: Section 6 - IANA Considerations: please consider adding a link to the media type registry.

## Nit

14. ----

   of additional scripts, called importing.  Implementations that
   support modules need to process imported sources in the same way
   scripts.  Further, there may be additional privacy and security

FP: "in the same way script" - is it missing an "as"?

---

From: Ben Campbell <[email-masked]>
Date: Tue, 24 Aug 2021 13:49:17 -0500

(as shepherd)

Hi Francesca,

I have a comment on point 1, below. I will leave the other points to the authors. 

Thanks!

Ben.

> On Aug 24, 2021, at 10:49 AM, Francesca Palombini <francesca.palombini=[email-masked]> wrote:
> 

Most of the upper-case normative terms are leftovers from RFC 4329. The text you quote adds a MUST and SHOULD to a paragraph that already had BCP 14 language in order to match the existing style. I think the use of BCP 14 was a mistake for RFC 4329, but this draft did not undertake fixing every flaw in the RFC. 

Rewriting all the previously existing BCP 14 language would be a pretty big undertaking at this stage. Would it be reasonable to leave that as is, and add some explanatory text about it to the introduction?

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Francesca Palombini <[email-masked]>
Date: Tue, 24 Aug 2021 22:29:56 +0000

Hi Ben!

Thank you for your quick reaction, and thank you as well for the excellent shepherd write up, it was very useful. Inline.

Francesca

On 24/08/2021, 20:49, "Ben Campbell" <[email-masked]> wrote:

    (as shepherd)

    Hi Francesca,

    Thanks!

    Ben.

FP: I'm most definitely ok with keeping the leftovers from RFC 4329 and not changing the BCP 14 language that comes from 4329. I think it would be helpful to add some explanatory text about what comes from 4329 and what is new. However, introducing new BCP 14 text seems to go against the stated scope of documenting existing practices. Either the scope is reformulate to something like "update requirements based on existing practices" (this could be the explanatory text in the introduction you were mentioning), or the new requirements are reformulated as descriptions rather than requirements.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 25 Aug 2021 17:22:38 +0100

Hi Francesca,

Just commenting on a few things:

> FP: Are these requirements that should have been there in RFC 4329 and are being added now? Are these how most implementations already behave? Would it not make more sense to reformulate this parag…
I am not an editor of this document, but I am speculating that the above 
is more restrictive than originally specified in RFC 4329.
> FP: Maybe more of a question: why is the "Encoding considerations" field in all subsections of section 6.1 "binary"? RFC 4329 did have more text about the encoding, is that obsoleted? Did I miss in…

Actually text in RFC 4329 is pointing to RFC 3023 and the description in 
the latter is actually wrong. This field should be one of 4 values: 
7bit, 8bit, binary or framed. UTF-8 encoded JSON can be have CRLF 
terminated lines longer than 1000 octets, which makes the encoding field 
"binary".

Best Regards,

Alexey

---

From: Mathias Bynens <[email-masked]>
Date: Thu, 26 Aug 2021 16:39:19 +0200

Thank you Francesca for your thorough AD review! We (the authors) are
currently working on addressing your comments. I’ll reply to this thread
once we have an answer for all of the points you’ve raised.

On Tue, Aug 24, 2021 at 5:49 PM Francesca Palombini <
[email-masked]> wrote:

> I have divided comments into "main", "minor" and "nits". I'd like to have
> a discussion on my main comments before requesting the IETF Last Call. On
> the other hand, you can address the minors and nits together with any
> additional Last Call comments you will get. As I am coming in late to the
> process, please understand that I don't mean to re-hash existing
> discussions that I am not aware of, and I appreciate your patience: feel
> free to point me to previous discussion (and conclusions) I might have
> missed, if relevant.
>
> For the minor comments - some of these are suggestions or questions which
> I hope will help improve readability, which you can decide to take or leave
> as you please.
>
> Francesca
>
> ## Main
>
> 1. ----
>
> FP: This document is presented in the Abstract, Introduction and
> Compatibility section as aiming to update some IANA registrations for the
> media types mentioned, as well as documenting current usage of these media
> types. Because of that, I am not convinced about the use of BCP 14
> language: if the intent is documenting current practices, most of these BCP
> 14 terms should be replaced by explanations on how implementations behave.
> To give an example of my concern, for the following paragraph in Section 4:
>
> FP: Are these requirements that should have been there in RFC 4329 and are
> being added now? Are these how most implementations already behave? Would
> it not make more sense to reformulate this paragraph to describe
> implementations behaviour, rather than mandate and recommend? Why using BCP
> 14 terms?
> This comment applies to all new occurrences of BCP 14 terms (it does not
> to apply to sections taken from RFC 4329, such as the first paragraph of
> section 4.1).
>
> 2. ----
>
> FP: Maybe more of a question: why is the "Encoding considerations" field
> in all subsections of section 6.1 "binary"? RFC 4329 did have more text
> about the encoding, is that obsoleted? Did I miss in which part of the
> draft this is discussed?
>
> 3. ----
>
> FP: "Published specification" field of each subsection of section 6.1 is
> "this document". I don't believe that is correct, and it should instead
> point to the correct specification (so JS 1.5, ECMAScript etc).
>
> 4. ----
>
> FP: I would also add RFC 4329 authors as "Person & email address to
> contact", as well as "Author" for those media types that 4329 registered.
> Please let me know if this is not common practice, but it seems logical to
> me to have both you authors and previous authors.
>
> 5. ----
>
> FP: I believe it would make sense to modify the IANA media type registry
> to add an "OBSOLETED in favor of ..." note in the name column of all those
> media types obsoleted. I think this requires a new IANA section.
>
> 6. ----
>
> FP: There are 4 occurrences of media types where Intended usage is
> OBSOLETE, but the Restriction on usage does not have the same sentence as
> all the other obsolete ones:
>
> FP: Please consider adding some text in the introduction mentioning that
> this document expands on the security considerations. I appreciate this
> work on the Security Considerations section was done, and believe the BCP
> 14 terms make sense there. It should just be highlighted better in the
> introductory part of the document.
>
> 8. -----
>
> FP: I am not sure RFC3986 and RFC3987 need to be a normative reference,
> given the only place they appear is a paragraph stating how this document
> does not define processing of fragment identifiers.
>
> 9. -----
>
> FP: I am confused by what part of 6265 is relevant regarding terminology
> used in this section. Maybe adding a section pointer would help.
>
> 12. -----
>
> FP: I have a hard time parsing "and source text", in the context of the
> sentence. What's the difference with "an implementation's internal
> representation of source text"? (this might be me not understanding the
> phrasing)
>
> 13. -----
>

---

From: Mathias Bynens <[email-masked]>
Date: Mon, 30 Aug 2021 08:47:04 +0200

Hi Francesca,

We’ve worked through your feedback (*italic* below). Here are our responses
(*bold*):

## Main

1. ----

   discouraged.

This comment applies to all new occurrences of BCP 14 terms (it does not to
apply to sections taken from RFC 4329, such as the first paragraph of
section 4.1).

We believe this has already been addressed by the shepherd earlier in the
thread.

2. ----

FP: Maybe more of a question: why is the "Encoding considerations" field in
all subsections of section 6.1 "binary"? RFC 4329 did have more text about
the encoding, is that obsoleted? Did I miss in which part of the draft this
is discussed?

This was done in response to Media-Type Early Review comments:
https://github.com/linuxwolf/bmeck-ids/pull/25

3. ----

This was done in response to Media-Type Early Review comments:
https://github.com/linuxwolf/bmeck-ids/pull/25

4. ----

This does not appear to be common practice. E.g. RFC 54 (by Crocker,
Postel, Newkirk, Kraley) was superseded by RFC 57 (by Kraley & Newkirk).
We’d prefer proceeding in line with this precedent, given that including
the original authors complicates the process further (since it would
require their explicit approval of all our changes before moving forward).

5. ----

FP: I believe it would make sense to modify the IANA media type registry to
add an "OBSOLETED in favor of ..." note in the name column of all those
media types obsoleted. I think this requires a new IANA section.

I think this refers to the document at
https://www.iana.org/assignments/media-types/media-types.xhtml, and not our
draft. Am I misunderstanding? What changes would this require to our draft?

6. ----

      ECMAScript media type.

Good catch! Patch: https://github.com/linuxwolf/bmeck-ids/pull/36/files

## Minor

7. -----

Patch: https://github.com/linuxwolf/bmeck-ids/pull/42 (still under review)

8. -----

Fixed: https://github.com/linuxwolf/bmeck-ids/pull/40
<https://github.com/linuxwolf/bmeck-ids/pull/40/files>

9. -----

FP: I'd suggest adding section numbers when referring to [ECMA-262]
sections, instead of just names.

The ECMAScript specification is a “living standard”, and the section
numbers change frequently as new chapters are introduced or sections are
moved around. Using the section names is a more stable, future-proof way to
refer to specific parts of the spec. Given that, would you be okay with
keeping this as-is?

Alternatively, we could add links to the specific sections in the latest
draft spec, e.g. https://tc39.es/ecma262/#sec-source-text — these URLs are
stable, too, but I don’t think there is precedent for this in any existing
RFC.

10. -----

FP: "in the processors" - I am not sure what is meant here, might be worth
considering rephrasing for clarity.

I think we can just remove this sentence. Patch:
https://github.com/linuxwolf/bmeck-ids/pull/37/files

11. -----

This was a typo, introduced while bringing over text from RFC 4329 and
updating then-obsoleted references. It should be 6365 (Terminology Used in
Internationalization in the IETF), which obsoleted 3536 (Terminology Used
in Internationalization in the IETF), which is what 4329 (the document
we’re obsoleting) referred to. Patch:
https://github.com/linuxwolf/bmeck-ids/pull/43

12. -----

This was a typo. Patch: https://github.com/linuxwolf/bmeck-ids/pull/41/files

13. -----

FP: Section 6 - IANA Considerations: please consider adding a link to the
media type registry.

In search of an example, I looked at recent media type RFCs (e.g. RFC8878,
RFC8478, RFC8351), and none of them seem to do this. I’ve suggested a
change: https://github.com/linuxwolf/bmeck-ids/pull/39/files but please let
me know if you had something else in mind.

## Nit

14. ----

Fixed: https://github.com/linuxwolf/bmeck-ids/pull/34/files

Once the remaining questions are addressed, we’ll be happy to cut a new
(final?) version of the doc.

Thanks,
Mathias Bynens on behalf of the draft-ietf-dispatch-javascript-mjs authors

On Thu, Aug 26, 2021 at 4:39 PM Mathias Bynens <[email-masked]> wrote:

>> FP: Are these requirements that should have been there in RFC 4329 and
>> are being added now? Are these how most implementations already behave?
>> Would it not make more sense to reformulate this paragraph to describe
>> FP: "in the processors" - I am not sure what is meant here, might be
>> worth considering rephrasing for clarity.
>>
>> 11. -----
>>

---

From: Francesca Palombini <[email-masked]>
Date: Mon, 30 Aug 2021 15:12:11 +0000

Hi Mathias,

Thank you for the quick reply! I tried to clarify some of my comments. As you can see, I have my opinion for some of the points (3. 4. And 5.), but it would be good to get the media type experts and IANA opinion as well, as they know better. I will reach out to IANA separately and CC you. Let me know if my suggestions make sense or you have additional questions/comments.

Francesca

From: Mathias Bynens <[email-masked]>
Date: Monday, 30 August 2021 at 08:47
To: Francesca Palombini <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: AD review of draft-ietf-dispatch-javascript-mjs-09

Hi Francesca,

We’ve worked through your feedback (italic below). Here are our responses (bold):

## Main

1. ----

   discouraged.

We believe this has already been addressed by the shepherd earlier in the thread.

FP: Indeed, and to reiterate: I am OK with keeping the BCP 14 terms that come from 4329. Do you think you could add some explanatory text in the introduction about the fact that this document updates existing requirements from 4329 based on existing practice?

2. ----

This was done in response to Media-Type Early Review comments: https://github.com/linuxwolf/bmeck-ids/pull/25<https://protect2.fireeye.com/v1/url?k=c2cbd409-9d50ed0b-c2cb9492-869a14f4b08c-c201474905f16264&q=1&e=bd06a8bd-b4a2-4969-8bac-0dc82582f91e&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F25>

FP: I see, and thanks to Alexey for pointing this out: it seems that what I missed was that 4329 actually had this field wrong in the original registration.

3. ----

This was done in response to Media-Type Early Review comments: https://github.com/linuxwolf/bmeck-ids/pull/25<https://protect2.fireeye.com/v1/url?k=2cecfd41-7377c443-2cecbdda-869a14f4b08c-03f5f96a636cd875&q=1&e=bd06a8bd-b4a2-4969-8bac-0dc82582f91e&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F25>

FP: I take it this is the comment from Murray you are referring to in that issue:
> generally, the templates can't refer to RFC 4329 if you plan to obsolete it; they should refer to this document or something else that won't be obsolete when this is published
I note that Murray pointed out that “Published Specification” should not point to 4329, but should instead point to either this document or “something else”, and I was suggesting that that something else is the published specifications, so for text/javascript JS 1.5 spec, for text/exmascript ECMA spec etc. This is what RFC 4329 did (see for example https://www.iana.org/assignments/media-types/text/javascript ), and from checking RFC 6838 it is not clear to me that was a mistake. I guess it could be fine with pointing to this document since this document references the other specifications, but it seems more convoluted and I wanted to check with you and the media type expert of what’s the best way, if both are ok. I will also send a separate email to ask IANA, since they probably have the answer, and cc you in it.

4. ----

This does not appear to be common practice. E.g. RFC 54 (by Crocker, Postel, Newkirk, Kraley) was superseded by RFC 57 (by Kraley & Newkirk). We’d prefer proceeding in line with this precedent, given that including the original authors complicates the process further (since it would require their explicit approval of all our changes before moving forward).

FP: Maybe I did not explain myself: I was not asking you to add the authors of RFC 4329 as authors of this document (although I hope they are aware of this work and they have been included in the conversation if they are still active in this space) but I was suggesting to keep them on the registrations themselves, so for example for text/javascript: https://www.iana.org/assignments/media-types/text/javascript on the “Person & email address to contact” and “Author” line, replace your current “See Author's Address section of [this document].“ with “See Author's Address section of [this document] and [RFC 4329]”. This would not require their approval, as they are in practice keeping their contact where they already had it. (Also note, I was suggesting this only for those registrations that RFC 4329 initially did). Again, Murray, other media type experts and IANA can tell me if this is not common practice.

5. ----

I think this refers to the document at https://www.iana.org/assignments/media-types/media-types.xhtml, and not our draft. Am I misunderstanding? What changes would this require to our draft?

FP: Yes, sorry for being unclear: what I was referring to was the “Name” column in the IANA registry at https://www.iana.org/assignments/media-types/media-types.xhtml . Your draft already makes changes to the registrations (so, for example, changes the content of : https://www.iana.org/assignments/media-types/text/javascript ) but does not specify the update to the https://www.iana.org/assignments/media-types/media-types.xhtml page itself. So, going back to our text/javascript example, this is the entry for it in the media-type page right now:
javascript - OBSOLETED in favor of application/javascript
text/javascript<https://www.iana.org/assignments/media-types/text/javascript>
[RFC4329<https://www.iana.org/go/rfc4329>]

I believe this should be changed to:
javascript
text/javascript<https://www.iana.org/assignments/media-types/text/javascript>
[This document]

And similarly all other registration should add the “- OBSOLETED in favor of…” note.

In order for IANA to make this change, this draft should add one more section that describe this change, I assume (I will confirm with IANA in a separate email, cc’ing you). Does that make sense?

6. ----

      ECMAScript media type.

Good catch! Patch: https://github.com/linuxwolf/bmeck-ids/pull/36/files<https://protect2.fireeye.com/v1/url?k=c950d583-96cbec81-c9509518-869a14f4b08c-2a3328a8ea380575&q=1&e=bd06a8bd-b4a2-4969-8bac-0dc82582f91e&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F36%2Ffiles>

FP: Great, thanks!

## Minor

7. -----

Patch: https://github.com/linuxwolf/bmeck-ids/pull/42<https://protect2.fireeye.com/v1/url?k=ec8cd245-b317eb47-ec8c92de-869a14f4b08c-dac275d00afd964d&q=1&e=bd06a8bd-b4a2-4969-8bac-0dc82582f91e&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F42> (still under review)

FP: short and to the point, I like it! :)

8. -----

Fixed: https://github.com/linuxwolf/bmeck-ids/pull/40<https://protect2.fireeye.com/v1/url?k=f1d438d8-ae4f01da-f1d47843-869a14f4b08c-a75a3c898aeb7a55&q=1&e=bd06a8bd-b4a2-4969-8bac-0dc82582f91e&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F40%2Ffiles>

FP: Thank you.

9. -----

The ECMAScript specification is a “living standard”, and the section numbers change frequently as new chapters are introduced or sections are moved around. Using the section names is a more stable, future-proof way to refer to specific parts of the spec. Given that, would you be okay with keeping this as-is?

Alternatively, we could add links to the specific sections in the latest draft spec, e.g. https://tc39.es/ecma262/#sec-source-text<https://protect2.fireeye.com/v1/url?k=a860a650-f7fb9f52-a860e6cb-869a14f4b08c-423d42d73db683c7&q=1&e=bd06a8bd-b4a2-4969-8bac-0dc82582f91e&u=https%3A%2F%2Ftc39.es%2Fecma262%2F%23sec-source-text> — these URLs are stable, too, but I don’t think there is precedent for this in any existing RFC.

FP: Ok, thanks for this explanation, and no, I don’t necessarily need the section numbers. However, this worries me: normative references cannot be “living standard” (or as https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ says: “work in progress”) – could we reference a stable published version of the ECMA standard? I can see for example RFC 8785 referenced the 10th edition of it: https://datatracker.ietf.org/doc/html/rfc8785#ref-ECMA-262

10. -----

I think we can just remove this sentence. Patch: https://github.com/linuxwolf/bmeck-ids/pull/37/files<https://protect2.fireeye.com/v1/url?k=151f1802-4a842100-151f5899-869a14f4b08c-e0f3ac7a0a6652ed&q=1&e=bd06a8bd-b4a2-4969-8bac-0dc82582f91e&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F37%2Ffiles>

FP: Ok, thanks.

11. -----

This was a typo, introduced while bringing over text from RFC 4329 and updating then-obsoleted references. It should be 6365 (Terminology Used in Internationalization in the IETF), which obsoleted 3536 (Terminology Used in Internationalization in the IETF), which is what 4329 (the document we’re obsoleting) referred to. Patch: https://github.com/linuxwolf/bmeck-ids/pull/43<https://protect2.fireeye.com/v1/url?k=dbfc4840-84677142-dbfc08db-869a14f4b08c-7c72596afa193437&q=1&e=bd06a8bd-b4a2-4969-8bac-0dc82582f91e&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F43>

FP: That makes sense, thank you.

12. -----

This was a typo. Patch: https://github.com/linuxwolf/bmeck-ids/pull/41/files<https://protect2.fireeye.com/v1/url?k=63d897f6-3c43aef4-63d8d76d-869a14f4b08c-fccb59dd017496be&q=1&e=bd06a8bd-b4a2-4969-8bac-0dc82582f91e&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F41%2Ffiles>

FP: Ok, thanks.

13. -----

In search of an example, I looked at recent media type RFCs (e.g. RFC8878, RFC8478, RFC8351), and none of them seem to do this. I’ve suggested a change: https://github.com/linuxwolf/bmeck-ids/pull/39/files<https://protect2.fireeye.com/v1/url?k=8f419545-d0daac47-8f41d5de-869a14f4b08c-5d496c5c4df46bae&q=1&e=bd06a8bd-b4a2-4969-8bac-0dc82582f91e&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F39%2Ffiles> but please let me know if you had something else in mind.

FP: Looks good.

## Nit

14. ----

Fixed: https://github.com/linuxwolf/bmeck-ids/pull/34/files<https://protect2.fireeye.com/v1/url?k=ae8f5ae3-f11463e1-ae8f1a78-869a14f4b08c-d7d2ecb71109deef&q=1&e=bd06a8bd-b4a2-4969-8bac-0dc82582f91e&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F34%2Ffiles>

FP: great.

Once the remaining questions are addressed, we’ll be happy to cut a new (final?) version of the doc.

Thanks,

On Thu, Aug 26, 2021 at 4:39 PM Mathias Bynens <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Francesca for your thorough AD review! We (the authors) are currently working on addressing your comments. I’ll reply to this thread once we have an answer for all of the points you’ve raised.

On Tue, Aug 24, 2021 at 5:49 PM Francesca Palombini <[email-masked]<mailto:[email-masked]>> wrote:
Thank you for the work on this document. This is my AD review.

Francesca

## Main

1. ----

2. ----

3. ----

4. ----

5. ----

6. ----

## Minor

7. -----

8. -----

9. -----

10. -----

11. -----

12. -----

13. -----

## Nit

14. ----