Re: [auth48] [IAB] AUTH48: RFC-to-be 9490 <draft-iab-m-ten-workshop-02> for your review

[Wes Hardaker <[e-mail]>]

>
>
>
> 2) <!--[rfced] This document had the consensus attribute set to true, but
> also
> says the following. Shall the consensus attribute be set to false?
>
> Original:
>    The views and positions documented in this report are
>    those of the expressed during the workshop by participants and do not
>    necessarily reflect IAB views and positions.
> and
>    Thus, the content of this
>    report follows the flow and dialog of the workshop but does not
>    attempt to capture a consensus.
> -->
>

Good point, thanks -- I've changed it in my copy that I'll attach later.

3) <!--[rfced] Section 2.2.1. Please let us know how we can clarify the
> following
> sentence. Is the collaboration between the intermediary services or the
> support they provide?
>
> Original:
>    Instead of encrypted communication between only two ends and passive
>    observation by all on-path elements, intermediate relays could be
>    trusted parties with limited information for the purposes of
>    collaboration between in-network intermediary services' support.
> -->
>

Good catch on the confusion point....  I'll get back to you on this one (or
others will).


>
>
> 4) <!--[rfced] Section 2.2.3. The following sentence appears to be missing
> one
> or more words between "local transmission" and "end-to-end transmission".
> Please let us know how to update this:
>
> Original:
>    E.g. side car information can contain additional
>    acknowledgements to enable in-network local retransmission faster
>    end-to-end retransmission by reducing the signaling round trip time.
> -->
>

I see in the copy you inserted "or" which is, IMHO, the right call.

5) <!--[rfced] Section 2.3.1. Please help us make the following sentence
> clearer. Does "categorized into an envelope" mean "comprises"?
>
> Original:
>    The proposed contract solution is to define a collection of
>    acceptable behaviors categorized into an envelope of different states
>    that might include IP addresses, domain names, and indicators of
>    compromise.
>
> Perhaps:
>    The proposed contract solution is to define a collection of
>    acceptable behaviors that comprises different states
>    that might include IP addresses, domain names, and indicators of
>    compromise.
> -->
>

I think that's a good replacement, yes.

6) <!--[rfced] Section 2.3.3. Is there a phrase missing in this sentence?
> Is the
> compromise between the "tension" and something else? Or is the compromise
> between services that offer privacy and services that offer protection?
>
> Original:
>    These collaborative solutions may be
>    the best compromise between the tension of privacy vs protection
>    based services [PAULY].
>
> Perhaps:
>    These collaborative solutions may be the
>    best compromise on services that balance privacy and protection [PAULY].
> -->
>

I'd think that "balance privacy services and protection services" might be
better.  I see in your text you actually had "balance privacy and
protection-based services."  I've changed it to my copy.


> 7) <!--[rfced] Section 3. In the following sentence, it is not clear what
> kind
> of technologies the operators are being asked to allow into their
> environments. In addition, is the phrase "environment requirements"
> correct? Please let us know how to clarify this sentence.
>
> Original:
>    *  There is an unanswered question of whether or not network
>       operators be willing to participate and allow technologies into
>       their environment requirements in exchange for technologies that
>       prove their clients are being good net-citizens.
> -->
>
>
I agree, that's confusing as written.  Proposing:

"There is an unanswered question of whether or not network operators are
willing to participate by allowing new encryption technologies into their
environment in exchange for technologies that prove their clients are being
good net-citizens."

8) <!--[rfced] We found alternate sources for both the [GRUBBS] and
> [KUEHLEWIND]
> references. Would you like to update these references?
>
[proofpoint mangled URLs dropped]

IMHO, no -- these should be left where published *as they were in the
workshop* which is the intarchboard reference, rather than the usenix and
ericsson sites.



>
> 9) <!--[rfced] The [KNODEL] reference is an introduction to the pearg
> Internet-Draft [I-D.irtf-pearg-safe-internet-measurement].
> [... clipped ...]
> And Appendix A be updated to show the following:
>
>    Iain R. Learmonth, Gurshabad Grover, Mallory Knodel. “Guidelines for
>    Performing Safe Measurement on the Internet.” [LEARMONTH]
>
>    Mallory Knodel. "Additional rationale for 'Guidelines for
>    Performing Safe Measurement on the Internet'" [KNODEL]
> -->
>

I think that makes sense.

10) <!--[rfced] On the [KUEHLEWIND] paper
> (
> https://urldefense.us/v2/url?u=https-3A__github.com_intarchboard_workshop-2Dm-2Dten_blob_main_papers_Kuehlewind-2DRelying-2Don-2DRelays.pdf&d=DwIBaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=0c5g_jBisMd0Mvrv260WjCsDo_lphr-fsVao5L9S4DI&m=IukcwVCq8x5L_zLnPt2xFYJeQQhI5TqHyVH19-TAs-0ZLAhbjauo4uhhFbXGfE1D&s=0W2dWGBJFURa7OVNaxLmR6EHpDqxvw-Oo5tOLc8xwc0&e=
> ),
> it is unclear to us whether "ANM" is part of Zaheduzzaman Sarker's name
> or is an honorific. This may impact the initial used in the Informative
> References section (currently Z.) and the name provided in Appendix A.3
> (Currently Zaheduzzaman Sarker).
> -->
>

Hmm...  THat's a really good question, but that's how the paper was
published and I think it's important that we quote it exactly as is unless
we reach out to them to figure out if the paper should be
update/changed/etc.

[Mirja -- can you check with them?]

11) <!--[rfced] The original URL provided for [DITTO] does not work:
>

Agreed, your replacement is probably the best choice.  We should probably
reach out to the author to take the actual version submitted and reference
it on our own pages (Cindy might be able to help with this, as she probably
has the submitted copy).

12) <!--[rfced] Appendix A.2. The following paper does not have a
> reference.
> Would you like to add one?
>
>    Wes Hardaker. "Network Flow Management by Probability."
> -->
>

 I've uploaded the missing paper (embarrassing it was mine) at
https://github.com/intarchboard/workshop-m-ten/blob/main/papers/Hardaker-Encrypted-Traffic-Estimation.pdf



>
> 13) <!--[rfced] Appendix B.
> a) The list of participants includes a duplication: "Michael Ackermann" and
> "Mike Ackermann". Which should be used?
>

It should probably be "Mike Ackermann" to match the name in the submission.


> b) While we understand that some participants may wish to provide only
> partial
> names, is "Qiufang" actually "Qiufang Ma"?
>

I agree it should be Qiufang Ma.


>
> 14) <!--[rfced] FYI, we have removed the Acknowledgments section because
> it was
> empty. Please let us know if any further updates are necessary.
>

Can we insert the following in a replacement sentence (which occured later):

We wish to acknowledge the comments and suggestions from Elliot Lear
and Arnaud Taddei for their comments and improvements to this document.


> 15) <!--[rfced] Please review the "Inclusive Language" portion of the
> online Style Guide
> <
> https://urldefense.us/v2/url?u=https-3A__www.rfc-2Deditor.org_styleguide_part2_-23inclusive-5Flanguage&d=DwIBaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=0c5g_jBisMd0Mvrv260WjCsDo_lphr-fsVao5L9S4DI&m=IukcwVCq8x5L_zLnPt2xFYJeQQhI5TqHyVH19-TAs-0ZLAhbjauo4uhhFbXGfE1D&s=m2UxyoLAYN4m1IW3-t_Qg9tCiYwJ2hPQW3ypTLyFfWs&e=
> > and let us know
> if any changes are needed.
>

In the attached copy I used "commonly" and "frequently" as replacements.
See if you believe this is sufficient.

-- 
Wes Hardaker
USC/ISI