Subject: [hrpc] Methods for establishing the relationships between features and rights

From: Scott Craig <[email-masked]>
Date: Thu, 7 Jul 2016 14:51:26 +0100

Hey Niels,

Case examples are definitely good evidence in assessing whether a feature
could have an effect on a right and whether that effect is significant
enough to warrant addition attention by engineers.

However, I think what is needed is a set of criteria which allows for a
transparent and consistent assessment of the claims made for relationships
between features and rights. Case examples could form part of the evidence
base for this assessment.

I’d like to draw your attention to Section 5.2.2 'Translation human rights
to technical terms’ where the document claims that the following listed
features impact upon the right to freedom of expression.

"The combination of content agnosticism, connectivity, security, privacy
> (as defined in [RFC6973] ), and open standards are the technical principles
> that underlie freedom of expression on the Internet.”
>
>
> (  Connectivity )
>   (      Privacy                )
>   (      Security               )   = Right to freedom of _expression_
>   (      Content agnosticism    )
>   (      Internationalization   )
>   (      Censorship resistance  )
>   (      Open Standards         )
>    (     Heterogeneity support )

Instead of detailing the basis on which the claims within it rest, section
5.2.2 just asserts them. I think that, at a minimum, there needs to be
something inserted into 5.2.2 that describes how you have made these
judgements, or states that judgements are based on the intuition of the
authors.

Significantly for the point i’m trying to make, the visual representation
in the document appears to make three more claims than the paragraph. I.e
the diagram claims that Heterogeneity support, Internationalisation and
censorship resistance have an effect on the ability to exercise freedom of
expression whereas the paragraph does not.

This could well be a typo. But what if it’s not? Should we remove the
features from the diagram or add them to the paragraph? How would we decide
whether your paragraph or your diagram is correct without any agreed
criteria for assessing claims? What should be the minimum effect that
merits inclusion?  This is the question that i’ve been pushing on.

If it is the case that that these relationships have been based on authors
intuition then we really have to go back to this section, unpack that black
box, and come up with a set of criteria that ensures these judgments are
being made in an transparent and consistent way.

Scott

On Wed, Jul 6, 2016 at 5:21 PM, Niels ten Oever <[email-masked]> wrote:

> Thanks for this Scott.
>
> If we look at the current standing practice for security considerations
> then I think we should go for examples instead of a test.
>
> So would more examples (per feature and right impacted) be sufficient in
> your opinion?
>
> Best,
>
> Niels
> On 6 Jul 2016 5:40 p.m., Scott Craig <[email-masked]> wrote:
>
> Hey Niels,
>
> Thanks for this.
>
> The fundamental issue I have is that the method you have used to claim
> links between features and rights is a black box. There is no discernible
> basis for the links other than your own judgement.
>
> I don’t in any way doubt the quality of your judgement. But I struggle to
> see how it provides sufficient grounds on which to expect every IETF
> engineer to pay additional attention to the features in the document.
>
> The idea of a test was simply a way to add some rigour to these claims in
> order to give them some means of defence if they are challenged and some
> means of adjudication if they are disputed.  Right now you are literally
> just saying that you talked to some people and then you decided which
> things were linked.
>
> " It is on the basis of these various case studies, elaborate discussion
> on the mailing list and at various IETF conferences that we came to
> determine whether an architectural feature is a 'crucial ingredient for
> enabling the ability to exercise specific rights’. "
>
>
> Simply saying *‘We came to determine’* as the method for determining the
> central claims made in the document just isn’t good enough. You can
> describe this process as  ‘proposing vectors of analysis’ if you want but
> this is no more than an obfuscated synonym for authors judgement.
>
> If I was an aircraft engineer and my colleagues informed me that the
> contents of the pre-flight check had been determined by people who had
> talked to aircraft engineers doing doing ‘vectors of analysis’ and that no
> criteria had then been used to evaluate and prioritise what we were being
> asked to check then I would be terrified for the passengers. This exercise
> is no less serious and demands no less rigour.
>
> If the point of the document is to ask engineers to give greater attention
> to the architectural features it highlights then a black box judgement
> cannot be a solid enough basis on which to make that request.
>
> It would be great to know whether others think the current method is
> sufficient.
>
> Scott Craig
>
>
> On Mon, Jul 4, 2016 at 10:28 PM, Niels ten Oever <[email-masked]>
> wrote:
>
> Hi Scott,
>
> I have been thinking a lot about your suggestions. I think the test you
> have been proposing might not be applicable for a technical environment
> (but am happy to be proven wrong).
>
> I do not think we can exhaustively list and map the risks that protocols
> generate in relation to rights.
>
> I would also like to add that the test you propose is neither part nor a
> requirement in for instance security considerations:
> https://tools.ietf.org/html/rfc2223#section-9
> https://tools.ietf.org/html/rfc3552
>
> Similar to the guidelines on security considerations RFC3552 and the
> guidelines on privacy considerations RFC6973 we've proposed vectors of
> analysis and provided examples.
>
> That these vectors might not be exhaustive and always context dependent
> are for me no arguments to hold the draft back.
>
> Furthermore I think the guidelines provide an input for discussion of
> drafts during drafting phase, but also when they're discussed for review
> in other WGs or later on in the IESG. Decisions and reviews are
> documented (and arguments are provided), so I am not sure whether one
> can say the standpoints are arbitrary, nor that the judgments are not
> replicable or cannot be contested (there are processes for that, that
> can get weighed by the appropriate groups). It is not like these
> guidelines for considerations are applied blindly.
>
> If I understood you incorrectly, could you perhaps illustrate the test a
> bit more in the specific case of security considerations?
>
> Best,
>
> Niels
>
>
>
> Niels ten Oever
> Head of Digital
>
> Article 19
> www.article19.org
>
> PGP fingerprint    8D9F C567 BEE4 A431 56C4
>                    678B 08B5 A0F2 636D 68E9
>
> On 06/27/2016 12:57 PM, Scott Craig wrote:
> > Hi Niels,
> >
> > I’ve attached a document with comments on the pre-adoption draft.
> >
> > I am still hoping that someone can address the concerns I raised on the
> > list about the methodology. I refer specifically to the method by which
> > an architectural feature has been (or can be) claimed to 'shape the
> > enabling environment' for a right.
> >
> > Raised here
> https://www.ietf.org/mail-archive/web/hrpc/current/msg00401.html
> > here https://www.ietf.org/mail-archive/web/hrpc/current/msg00408.html
> > and here
> https://www.ietf.org/mail-archive/web/hrpc/current/msg00417.html
> >
> > Though I agree with some of your conclusions, I do not think the
> > justification for the claims you have made withstands scrutiny. As a
> > result it’s presently difficult to see how an engineer could justify
> > giving additional attention to the features highlighted in the draft.
> >
> > To re-state what I said previously:
> >
> > I think the method you have described (quoted below)*_is great for
> > identifying _**/_candidate features_/*. But my concern is that it’s
> > insufficient to determine that a candidate feature is an enabling (or
> > restricting) feature.
> >
> >     /" It is on the basis of these various case studies, elaborate
> >     discussion on the mailinglist and at various IETF conferences that
> >     *we came to determine whether an architectural feature* is a
> >     'crucial ingredient for enabling the ability to exercise specific
> >     rights’. "/
> >
> > If no explicit test is applied to the candidate features
> > after identification, I think this causes three problems:
> >
> > (1) *Judgements* *are arbitrary    *
> >
> > i.e there is no basis on which to argue that the threshold for inclusion
> > was the same for one technical concept as for another.
> >
> > (2) *Judgements are not replicable. *
> >
> > i.e it is not possible to claim that different authors would not have
> > come to significantly different conclusions than you have.
> >
> > (3) *Judgements cannot be contested  *
> >
> > e.g if someone were to disagree with your contention that
> > internationalisation has a bearing on the right to political
> > participation, on what basis would we adjudicate who is correct?
> >
> > Scott
> >
> >
> >
> > On Mon, Jun 13, 2016 at 3:15 PM, Niels ten Oever <[email-masked]
> > <mailto:[email-masked]>> wrote:
> >
> >     Hi all,
> >
> >     To create a next RG version of the draft-tenoever-hrpc-research ID,
> it's
> >     probably good to draft a clear way forward.
> >
> >     We have had some really good comments and reviews during and before
> the
> >     call for adoption, thanks for that, but if we want to bring this
> further
> >     we will need some more reviews.
> >
> >     Two people (Shane and Giovanni) are currently testing the guidelines
> for
> >     human rights considerations on two actual drafts, which we hope can
> be
> >     presented in Berlin.
> >
> >     Avri mentioned she had elaborate feedback on the current draft and
> >     Collin Anderson mentioned he would do a review of the draft, which
> would
> >     both be greatly appeciated.
> >
> >     So now we're looking for a third and potentially fourth reviewer who
> >     could review the draft in within the coming two weeks so we can
> create a
> >     new version ahead of IETF96 in Berlin.
> >
> >     What we're looking for is a review of the whole document with more or
> >     less coherent notes, suggestions and/or criticisms with which we
> could
> >     improve the document.
> >
> >     Looking forward to hear from you!
> >
> >     Best,
> >
> >     Niels
> >
> >
> >     --
> >     Niels ten Oever
> >     Head of Digital
> >
> >     Article 19
> >     www.article19.org <http://www.article19.org>
> >
> >     PGP fingerprint    8D9F C567 BEE4 A431 56C4
> >                        678B 08B5 A0F2 636D 68E9
> >
> >
> >     _______________________________________________
> >     hrpc mailing list
> >     [email-masked] <mailto:[email-masked]>
> >     https://www.irtf.org/mailman/listinfo/hrpc
> >
> >
> >
> >
> > --
> >
> > *Scott Craig* | Ford-Mozilla Fellow
> > Center for Democracy & Technology |* cdt.org <https://cdt.org/>*
> > *E:* [email-masked] <http://cdt.org/> | *D:* 1.202.407.8887
> > <tel:202.407.8887> | **@scottdavidcraig
> >
> > */
> > /*
> >
>
>
>
>
> --
>
> *Scott Craig* | Ford-Mozilla Fellow
> Center for Democracy & Technology |* cdt.org <https://cdt.org/>*
> *E:* [email-masked] | *D:* 1.202.407.8887 | @scottdavidcraig
>
>
>
>

-- 

*Scott Craig* | Ford-Mozilla Fellow
Center for Democracy & Technology |* cdt.org <https://cdt.org/>*
*E:* [email-masked] | *D:* 1.202.407.8887 | @scottdavidcraig

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 7 Jul 2016 11:10:42 -0400

> base for this assessment.

I want to echo Scott's critique here... as someone who has done a lot
of qualitative research in my life, it's important that we describe
how "interviewing people" leads to "a model for mapping technical
features and human rights" which results in the bracketed
relationships in the document.

> Significantly for the point i’m trying to make, the visual representation in
> the document appears to make three more claims than the paragraph. I.e the
> diagram claims that Heterogeneity support, Internationalisation and
> criteria for assessing claims? What should be the minimum effect that merits
> inclusion?  This is the question that i’ve been pushing on.

My naive suggestion here might be to write down in words how each of
the technical terms on the LHS individually enable/underlie/impact the
right on the RHS. (or if they necessarily work in concert, describe
that.)

I'm hopeful that after having done that for one or two of the human
rights, it might be easier to craft a more generic approach that could
work for any rights or rights that may light in our future.

Niels, Corrine: are we missing something fundamental?

>> just saying that you talked to some people and then you decided which things
>> were linked.
>>
>> Simply saying ‘We came to determine’ as the method for determining the
>> central claims made in the document just isn’t good enough. You can describe
>> this process as  ‘proposing vectors of analysis’ if you want but this is no
>> more than an obfuscated synonym for authors judgement.
>>
>> Scott Craig | Ford-Mozilla Fellow
>> Center for Democracy & Technology | cdt.org
>> E: [email-masked] | D: 1.202.407.8887 | @scottdavidcraig
>>
>>
>>
>
>
>
> --
>
> Scott Craig | Ford-Mozilla Fellow
> Center for Democracy & Technology | cdt.org
> E: [email-masked] | D: 1.202.407.8887 | @scottdavidcraig
>
>
>

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 11 Jul 2016 22:14:31 +0200

Dear Scott,

Am happy to work on (more) examples (as were mentioned in the
interviews, and found in the research). This would then be similar to
the documentation of attack vector examples in the Privacy
Considerations Guidelines and the Security Considerations Guidelines.
Corinne and I will come up with this shortly.

I am afraid though that it will lead to a duplication of the examples
mentioned under the considerations themselves though (at the bottom of
the ID), which would lead to an even longer document.

But if that's what's needed, here we go :)

Best,

Niels

Niels ten Oever
Head of Digital

Article 19
www.article19.org

On 07/07/2016 03:51 PM, Scott Craig wrote:
> Hey Niels, 
> 
> Case examples are definitely good evidence in assessing whether a
> feature could have an effect on a right and whether that effect is
> significant enough to warrant addition attention by engineers.  
> 
> transparent and consistent assessment of the claims made for
> relationships between features and rights. Case examples could form part
> of the evidence base for this assessment. 
> 
> I’d like to draw your attention to Section 5.2.2 'Translation human
> rights to technical terms’ where the document claims that the following
> listed features impact upon the right to freedom of expression. 
> 
>     "The combination of content agnosticism, connectivity,
>     security, privacy (as defined in [RFC6973] ), and open standards are
>     the technical principles that underlie freedom of expression on
>     the Internet.” 
> 
> 
>     (  Connectivity )
>       (      Privacy                )
> Instead of detailing the basis on which the claims within it rest,
> section 5.2.2 just asserts them. I think that, at a minimum, there needs
> to be something inserted into 5.2.2 that describes how you have made
> these judgements, or states that judgements are based on the intuition
> of the authors. 
> 
> Significantly for the point i’m trying to make, the visual
> representation in the document appears to make three more claims than
> the paragraph. I.e the diagram claims that Heterogeneity support,
> Internationalisation and censorship resistance have an effect on the
> ability to exercise freedom of expression whereas the paragraph does not. 
> 
> features from the diagram or add them to the paragraph? How would we
> decide whether your paragraph or your diagram is correct without any
> agreed criteria for assessing claims? What should be the minimum effect
> that merits inclusion?  This is the question that i’ve been pushing on.
> 
> If it is the case that that these relationships have been based on
> authors intuition then we really have to go back to this section, unpack
> that black box, and come up with a set of criteria that ensures these
> judgments are being made in an transparent and consistent way. 
> 
> Scott  
> 
> 
> On Wed, Jul 6, 2016 at 5:21 PM, Niels ten Oever <[email-masked]
>     If we look at the current standing practice for security
>     considerations then I think we should go for examples instead of a test.
> 
>     So would more examples (per feature and right impacted) be
>     sufficient in your opinion?
> 
>     Best,
> 
>     Niels
> 
>     On 6 Jul 2016 5:40 p.m., Scott Craig <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hey Niels,
> 
>         Thanks for this.
> 
>         The fundamental issue I have is that the method you have used to
>         claim links between features and rights is a black box. There is
>         no discernible basis for the links other than your own judgement.
> 
>         I don’t in any way doubt the quality of your judgement. But I
>         struggle to see how it provides sufficient grounds on which to
>         expect every IETF engineer to pay additional attention to the
>         features in the document.
> 
>         The idea of a test was simply a way to add some rigour to these
>         claims in order to give them some means of defence if they are
>         challenged and some means of adjudication if they are disputed. 
>         Right now you are literally just saying that you talked to some
>         people and then you decided which things were linked.
> 
>             " It is on the basis of these various case studies,
>             elaborate discussion on the mailing list and at various IETF
>             conferences that we came to determine whether an
>             architectural feature is a 'crucial ingredient for enabling
>             the ability to exercise specific rights’. "
> 
> 
>         Simply saying /‘We came to determine’/ as the method for
>         determining the central claims made in the document just isn’t
>         good enough. You can describe this process as  ‘proposing
>         vectors of analysis’ if you want but this is no more than an
>         obfuscated synonym for authors judgement.
> 
>         If I was an aircraft engineer and my colleagues informed me that
>         the contents of the pre-flight check had been determined by
>         people who had talked to aircraft engineers doing doing ‘vectors
>         of analysis’ and that no criteria had then been used to evaluate
>         and prioritise what we were being asked to check then I would be
>         terrified for the passengers. This exercise is no less serious
>         and demands no less rigour.
> 
>         If the point of the document is to ask engineers to give greater
>         attention to the architectural features it highlights then a
>         black box judgement cannot be a solid enough basis on which to
>         make that request.
> 
>         It would be great to know whether others think the current
>         method is sufficient.
> 
>         Scott Craig
> 
> 
>         On Mon, Jul 4, 2016 at 10:28 PM, Niels ten Oever
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             Hi Scott,
> 
>             > here
>             https://www.ietf.org/mail-archive/web/hrpc/current/msg00408.html
>             > and here
>             > On Mon, Jun 13, 2016 at 3:15 PM, Niels ten Oever
>             <[email-masked] <mailto:[email-masked]>
>             > <mailto:[email-masked] <mailto:[email-masked]>>>
>             wrote:
>             >
>             >     Hi all,
>             >
>             >     To create a next RG version of the
>             draft-tenoever-hrpc-research ID, it's
>             >     We have had some really good comments and reviews
>             during and before the
>             >     call for adoption, thanks for that, but if we want to
>             bring this further
>             >     Two people (Shane and Giovanni) are currently testing
>             the guidelines for
>             >     human rights considerations on two actual drafts,
>             which we hope can be
>             >     presented in Berlin.
>             >
>             >     Collin Anderson mentioned he would do a review of the
>             draft, which would
>             >     could review the draft in within the coming two weeks
>             so we can create a
>             >     less coherent notes, suggestions and/or criticisms
>             with which we could
>             >     improve the document.
>             >
>             <http://www.article19.org>
>             >
>             >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>
>             > Center for Democracy & Technology |* cdt.org <http://cdt.org> <https://cdt.org/>*
>             > *E:* [email-masked] <mailto:[email-masked]> <http://cdt.org/> |
>             *D:* 1.202.407.8887 <tel:1.202.407.8887>
>             > <tel:202.407.8887 <tel:202.407.8887>> | **@scottdavidcraig
>             >
>             > */
>             > /*
>             >
> 
> 
> 
> 
>         -- 
> 
>         *E:* [email-masked]
>         <http://cdt.org/> | *D:* 1.202.407.8887 | **@scottdavidcraig
> 
>         */
>         /*
> 
> 
> 
> 
> -- 
>

---

From: Scott Craig <[email-masked]>
Date: Mon, 11 Jul 2016 23:26:54 +0100

Hey Niels,

I'm not asking for more examples i'm asking for one of two things;

Either

1. That you to describe the method by which you go from speaking to people
to concluding that a feature has a significant enough effect on a right to
merit inclusion in section 5.2.2.

Or

2. That if you don't have a method and this has just been black box authors
judgement then the list needs to develop one - for all of the reasons I've
set out before. A test being my initial proposal for one method to judge
the relevance of a feature upon a right outside of the current black box.

Joe's proposal seemed like a sensible way to begin pulling back the curtain
figuring out what the method was (or could be).

I don't understand why you are sidestepping the issue and focusing on
examples instead.

Scott

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 12 Jul 2016 00:57:22 +0200

Hi Scott,

In that case I might have misunderstood your comments, let me try to
give it another try, what about replacing the existing explanatory
paragraph at 5.2.2:

   This analysis aims to translate human rights concepts that impact or
   are impacted by the Internet as follows:

   The combination of content agnosticism, connectivity, security,
   privacy (as defined in [RFC6973] ), and open standards are the
   technical principles that underlie freedom of expression on the
   Internet.

into:

The combination of the technical concepts that have been gathered the
steps above have been grouped according to their impact on specific
rights as they have been mentioned in the interviews done at IETF92 as
well as study of literature (see literature and discussion review above).

This analysis aims to assist protocol developers by understanding better
understanding the roles specific technical concepts with regards to the
possibility to exercise human rights on the Internet.

This analysis does not claim to be an complete or exhaustive mapping of
all possible ways in which a protocols could potentially impact human
rights, but it presents an initial combined concept mapping based on
interviews and literature and discussion review.

Happy to discuss!

Best,

Niels

Niels ten Oever
Head of Digital

Article 19
www.article19.org

On 07/12/2016 12:26 AM, Scott Craig wrote:
> 1. That you to describe the method by which you go from speaking to
> people to concluding that a feature has a significant enough effect on a
> right to merit inclusion in section 5.2.2.
> 
> Or
> 
> 2. That if you don't have a method and this has just been black box
> authors judgement then the list needs to develop one - for all of the
> reasons I've set out before. A test being my initial proposal for one
> method to judge the relevance of a feature upon a right outside of the
> current black box.
> 
> Joe's proposal seemed like a sensible way to begin pulling back the
> curtain figuring out what the method was (or could be).
> 
> On 11 Jul 2016 9:14 p.m., "Niels ten Oever" <[email-masked]
>     > On Wed, Jul 6, 2016 at 5:21 PM, Niels ten Oever
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Thanks for this Scott.
>     >
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >         Hey Niels,
>     >
>     >         Thanks for this.
>     >
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >             Hi Scott,
>     >
>     >             have been proposing might not be applicable for a
>     technical
>     >             environment
>     >             Similar to the guidelines on security considerations
>     RFC3552
>     >             and the
>     >             guidelines on privacy considerations RFC6973 we've
>     proposed
>     >             vectors of
>     >             > I’ve attached a document with comments on the
>     pre-adoption
>     >             draft.
>     >             >
>     >             > I am still hoping that someone can address the
>     concerns I
>     >             raised on the
>     >             > giving additional attention to the features
>     highlighted in
>     >             the draft.
>     >             >
>     >             > identifying _**/_candidate features_/*. But my
>     concern is
>     >             that it’s
>     >             > i.e there is no basis on which to argue that the
>     threshold
>     >             for inclusion
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >             > <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>     >             wrote:
>     >             >
>     >             >     Hi all,
>     >             >
>     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>     >             <mailto:[email-masked] <mailto:[email-masked]>>>
>     >             > Center for Democracy & Technology |* cdt.org
>     <http://cdt.org> <http://cdt.org> <https://cdt.org/>*
>     >             > *E:* [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> <http://cdt.org/> |
>     <tel:1.202.407.8887 <tel:1.202.407.8887>>
>     >             > <tel:202.407.8887 <tel:202.407.8887>
>     <tel:202.407.8887 <tel:202.407.8887>>> | **@scottdavidcraig
>     >             >
>     >             > */
>     >             > /*
>     >             >
>     >
>     >
>     >
>     >
>     >         --
>     >
>     >         *E:* [email-masked] <mailto:[email-masked]>
>     >         <http://cdt.org/> | *D:* 1.202.407.8887
>     <tel:1.202.407.8887> | **@scottdavidcraig
>     >
>     >         */
>     >         /*
>     >
>     >
>     >
>     >
>     > --
>     >

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 14 Jul 2016 09:26:19 -0400

Niels, I'd like to sit down and attempt to do what I suggest above
(write down in words the actual relationships between the LHS and RHS
in those figures), but it seems like it's getting closer to the
explicit articulation of a method that we've been talking about. best,
Joe

On Mon, Jul 11, 2016 at 6:57 PM, Niels ten Oever <[email-masked]> wrote:
>>     <http://cdt.org> <https://cdt.org/>*

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 20 Jul 2016 15:08:06 +0200

> interviews and literature and discussion review.

(apologies, mean to send this a few days ago but it's been sitting in
my Drafts folder for some stupid reason.)

I like this new language! I do think the bracket figures need to be
explained a bit more, but I think I can offer PRs for that (or can
offer language here and we can hammer that into a PR).

(Didn't the interviews happen at IETF91 (Honolulu) not 92 (Dallas)?)

Cheers and see you all at 3:50p!

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 20 Jul 2016 19:15:36 +0200

Hi Joe,

> offer language here and we can hammer that into a PR).

Nice! Happy we're making progress. Looking forward to discuss.

> (Didn't the interviews happen at IETF91 (Honolulu) not 92 (Dallas)?)

Nopes, the interviews happened in Dallas, I remember that hotel room
really well :)

Cheers,

Niels