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

[Jean Mahoney <[e-mail]>]

Wes and *IAB Chair,

Wes,

Thank you for your response and the XML file. We have updated the 
document accordingly. We will await further word from you and your 
coauthors regarding other AUTH48 changes and/or approval.

*Mirja,

Please review the consensus of this document (currently set to "false") 
and also the addition of an Acknowledgments section, and let us know if 
you approve. These changes are highlighted here:

    https://www.rfc-editor.org/authors/rfc9490-lastrfcdiff.html
       (side-by-side diff of these updates)

The updated files are here:

    https://www.rfc-editor.org/authors/rfc9490.txt
    https://www.rfc-editor.org/authors/rfc9490.pdf
    https://www.rfc-editor.org/authors/rfc9490.html
    https://www.rfc-editor.org/authors/rfc9490.xml

    https://www.rfc-editor.org/authors/rfc9490-diff.html
       (comprehensive diff)
    https://www.rfc-editor.org/authors/rfc9490-rfcdiff.html
       (side-by-side comprehensive diff)
    https://www.rfc-editor.org/authors/rfc9490-auth48diff.html
       (diff of updates made during AUTH48)
    https://www.rfc-editor.org/authors/rfc9490-auth48rfcdiff.html
       (side-by-side diff of updates made during AUTH48)

For the AUTH48 status of this document, please see:

    https://www.rfc-editor.org/auth48/rfc9490

Best regards,
RFC Editor/jm


On 10/9/23 4:57 PM, Wes Hardaker wrote:
> 
> 
>     I believe consensus should be left set to “true”. This document has
>     consensus of the IAB as a report of what occurred at the workshop.
> 
> 
> Whoops; I see Tommy and I disagree.  Given the discussion about whether 
> or not there was community consensus about even the contents, and that 
> it's really just a report about what was said/happened in the workshop 
> I'll stand by my thought that there isn't documented consensus in the 
> document itself, but I do see your point.  Our (the IAB's) consensus was 
> to publish it, not on the contents really (IMHO).  We should chat :-)
> 
> 
>      >
>      > 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 ays could be
>      >   trusted parties with limited information for the purposes of
>      >   collaboration between in-network intermediary services' support.
>      > -->
> 
>     I suggest saying the following (the other authors should check):
> 
>     Instead of encrypting communication between only two ends with
>     passive observation by all on-path elements, intermediate relays
>     could be introduced as trusted parties that get to see limited
>     information for the purpose of collaboration between in-network
>     intermediary services.
> 
> 
> that's fine with me.
> 
> 
>     How about:
> 
>        These collaborative solutions may be
>        the best compromise to resolve the the tension between privacy and
>        protection-based services [PAULY].
> 
> 
> Ah whoops, I should have read this first.  I think Tommy's text is fine, 
> but my point of inserting a double services ("between privacy services and
>    protection-based services") was to be clear.  But that should 
> certainly be Tommy's call since he's the PAULY in the sentence :-)
> 
> 
>      >
>      >
>      > 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’ll ask Wes to help answer this one, as I believed he had written
>     that section.
> 
> 
> Answered in the other mail
> 
> 
>     For consistency, it might be best to have all of the references be
>     to GitHub?
> 
> 
> We agree!
> 
> 
>      >
>      > 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."
>      > -->
> 
>     Wes?
> 
> 
> Fixed in my last message.
> 
>      >
>      >
>      > 13) <!--[rfced] Appendix B.
>      > a) The list of participants includes a duplication: "Michael
>     Ackermann" and
>      > "Mike Ackermann". Which should be used?
>      > b) While we understand that some participants may wish to provide
>     only partial
>      > names, is "Qiufang" actually "Qiufang Ma"?
>      >
>      > Please review the participant list and let us know if any updates
>     are needed.
>      > -->
> 
>     Since Mike Ackermann lists himself as “Mike” on the paper, we can
>     probably use that.
>     And yes, Qiufang is Qiufang Ma.
> 
> 
> We agree again!
> 
>      > 14) <!--[rfced] FYI, we have removed the Acknowledgments section
>     because it was
>      > empty. Please let us know if any further updates are necessary.
>      > -->
> 
>     Thank you, that should be fine.
> 
> 
> Tommy: any problems with adding a note about the last call comments we 
> got from Eliot and Arnaud?  They caused changes, so they seem appropriate.
> 
> 
>      > 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=DwIFaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=0c5g_jBisMd0Mvrv260WjCsDo_lphr-fsVao5L9S4DI&m=aEvW67XF5u1jpwXCNHC1PvZUL5gXbCMLU7KOBO9hC8aTZF_A6-_kwr-9VGWASrYk&s=EAIgKlFVgOm-xa2Cdd33SSSPB3MCpTQfwPl_9-QUHsc&e= <https://urldefense.us/v2/url?u=https-3A__www.rfc-2Deditor.org_styleguide_part2_-23inclusive-5Flanguage&d=DwIFaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=0c5g_jBisMd0Mvrv260WjCsDo_lphr-fsVao5L9S4DI&m=aEvW67XF5u1jpwXCNHC1PvZUL5gXbCMLU7KOBO9hC8aTZF_A6-_kwr-9VGWASrYk&s=EAIgKlFVgOm-xa2Cdd33SSSPB3MCpTQfwPl_9-QUHsc&e=> > and let us know
>      > if any changes are needed.
>      >
>      > Please consider whether "tradition" should be updated for
>     clarity.  While the NIST website
>      >
>     <https://urldefense.us/v2/url?u=https-3A__www.nist.gov_nist-2Dresearch-2Dlibrary_nist-2Dtechnical-2Dseries-2Dpublications-2Dauthor-2Dinstructions-23table1&d=DwIFaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=0c5g_jBisMd0Mvrv260WjCsDo_lphr-fsVao5L9S4DI&m=aEvW67XF5u1jpwXCNHC1PvZUL5gXbCMLU7KOBO9hC8aTZF_A6-_kwr-9VGWASrYk&s=vTaIjP8mdb9u7XXOEdmwhon73OCnP_ynNSXEF55y6pQ&e= <https://urldefense.us/v2/url?u=https-3A__www.nist.gov_nist-2Dresearch-2Dlibrary_nist-2Dtechnical-2Dseries-2Dpublications-2Dauthor-2Dinstructions-23table1&d=DwIFaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=0c5g_jBisMd0Mvrv260WjCsDo_lphr-fsVao5L9S4DI&m=aEvW67XF5u1jpwXCNHC1PvZUL5gXbCMLU7KOBO9hC8aTZF_A6-_kwr-9VGWASrYk&s=vTaIjP8mdb9u7XXOEdmwhon73OCnP_ynNSXEF55y6pQ&e=> >
>      > indicates that this term is potentially biased, it is also ambiguous.
>      > "Tradition" is a subjective term, as it is not the same for everyone.
>      > -->
> 
>     Since this refers to a “tradition” in network management, I
>     personally think this use is appropriate.
> 
> 
> I think my suggested changes reflect the point behind the original text 
> while replacing the confusion for non-English speakers about the term.
> 
> 
> -- 
> Wes Hardaker
> USC/ISI