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

[Wes Hardaker <[e-mail]>]

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