layers: describe policy enforcement for foreign layer media type #233

stevvooe · 2016-09-01T00:35:17Z

Signed-off-by: Stephen J Day [email protected]

Supersedes #216, Requires #169.

philips · 2016-09-01T01:28:07Z

@stephenrwalli Can you take a look at this language? I am still unclear if "MUST NOT distribute" is something we can define usefully in a spec.

I totally get it as a human being with context on copyrights for proprietary software about the usefullness. I just don't know how to codify this. It is like the evil bit RFC: https://www.ietf.org/rfc/rfc3514.txt

wking · 2016-09-01T16:49:54Z

layer.md

+Typically, one can download such layers but they should never be uploaded.
+
+Layers that have these restrictions SHOULD be tagged with an alternative mediatype of `application/vnd.oci.image.serialization.rootfs.foreign.tar.gzip`.
+[Descriptors][descriptor.md] referencing these layers MAY include `urls` for downloading these layers.


[Descriptors][descriptor.md] → [Descriptors](descriptor.md).

wking · 2016-09-02T13:57:32Z

layer.md

+Certain layers, due to legal requirements, may not be regularly distributable.
+Typically, one can download such layers but they should never be uploaded.
+
+Layers that have these restrictions SHOULD be tagged with an alternative mediatype of `application/vnd.oci.image.serialization.rootfs.foreign.tar.gzip`.


Pre-#212 media type pattern?

Yes, good catch!

jlbutler · 2016-09-03T00:21:02Z

media-types.md

 - `application/vnd.oci.image.config.v1+json`: [Container config JSON](serialization.md)
+- `application/vnd.oci.image.layer.tar+gzip`: ["Layer", as a gzipped tar archive](layer.md)
+- `application/vnd.oci.image.layer.foreign.tar+gzip`: ["Layer", as a gzipped tar that should never be pushed](layer.md#foreign-layers)


Since a foreign layer must not be pushed per the layer spec, might this media type be better defined as "must not be pushed" rather than "should never be pushed"?

Possibly better to redefine "as a non-redistributable gzipped tar archive", or similar.

jonboulle · 2016-09-06T16:06:11Z

-1 on the underspecified use of the "push" verb, as discussed in #216 (comment)

stevvooe · 2016-09-06T18:59:35Z

@jonboulle It is sufficient to comment inline on the specific language that needs correcting rather than saying "-1". It is much more constructive, unless you intend to block the PR.

I've replaced the term "push" with the more generic "distribute".

stephenrwalli · 2016-09-06T20:58:49Z

@philips I understand your example. It's not necessarily how you would codify it, so much as it gives the certification process the language to revoke a certification based on non-compliance. While it might be difficult to write a test to prove the MUST NOT, if an implementation was demonstrated to distribute such a layer, it clearly doesn't do what the specification says, and would not be able to claim conformance/compliance. Likewise, for a certification process, one can design the process to manual test such a thing or to use the condition to revoke a certification until the implementation complies. Make sense? (Sorry for the tardy reply.)

wking · 2016-09-07T05:49:31Z

On Tue, Sep 06, 2016 at 01:58:50PM -0700, Stephen Walli wrote:

While it might be difficult to write a test to prove the MUST NOT,
if an implementation was demonstrated to distribute such a layer, it
clearly doesn't do what the specification says, and would not be
able to claim conformance/compliance. Likewise, for a certification
process, one can design the process to manual test such a thing or
to use the condition to revoke a certification until the
implementation complies.

“Yeah, automatically testing that would be hard, but we can manually
test it” is a marker for a wishy definition 1. I think the problem
here is that “distributing” is not something that one instance can do
by itself. If it's pushing a blob, someone else must be receiving it.
In some cases (e.g. pushing to a local disk on a single-user system),
that probably doesn't count as “distributing” in a legal sense. In
others (e.g. pushing to a public repo on hub.docker.com) it does.
Where does caching to disk on a multi-user system fall in that
continuum? Are you distributing it by saving to a system-readabale
cache? Or is it only distributing if another user on the system reads
it out of that cache? If that system-readable cache happens to live
under your home directory, are you being robbed (and not distributing)
when the other user reads the file?

I imagine there are consensus opinions on at least some of that
(although I'm not aware of them). I don't think we want to make it
the business of spec implementers and validators to independently
figure out what those opinions are. If there are conditions under
which you would certify (or not) an implementation, I'd like to see
those conditions spelled out in the spec in enough detail for them to
be objectively tested without appealing to “The average person,
applying local community standards, looking at the work in its
entirety” and such. In some cases, that wishyness is unavoidable.
But we need something more solid if we're expecting implementation
software to act consistently based on a ‘foreign’ boolean.

One option would be to have a CAS engine API (e.g. #159) where the
public/private-ness of the engine was part of its initialization.
E.g.:

casEngine, err := NewEngine(ctx, path, public)

Then the engine is non-compliant if you can successfully:

casEngine.Put(ctx, reader, mediaType)

with a foreign mediaType (this is testable by the OCI). And the
engine-initializer is breaking the law if they create a CAS engine
pointing at a public hub.docker.com repo and claiming it is not public
(this is between the CAS engine configurer and the copyright holders
of the pushed content, and not something the OCI has to certify).

philips · 2016-09-07T13:20:48Z

cc @runcom @vbatts ?

runcom · 2016-09-07T13:32:16Z

I'm not sure either on this one - is it an hard requirement for this spec to outline the legal matters of foreign layers? I (sorry I may be wrong) don't think so. I think as foreign layers just layers that are downloaded through a list of urls in a descriptor. Do we really need to clarify that those layers can't be distributed? I understand this was born in Docker for this exact legal reason but I don't think the spec should enforce this restriction (not to push) - if people end up pushing the layer it's them breaking any legal terms, I'm not sure what the spec has to do with this. (I believe it's perfectly possible to upload the Windows base layer by taking it and uploading it, implementers (Docker) enforce this, can we just add an implementor note? or add a SHOULD?)

(sorry if any of the above makes no sense...)

stephenrwalli · 2016-09-07T17:23:07Z

You make good sense, @runcom. So a way to call attention to such things, that I've seen in the past, is to explicitly call something out as implementation defined. This is basically a warning to spec implementers that are not part of the immediate spec community to pay attention in the space before naively doing something in their implementation. It also allows for the behaviors that already exist in implementations. So in this case, wording becomes: "It is implementation defined whether or not implementations distribute layers tagged with this media type."

jonboulle · 2016-09-07T17:28:24Z

Such a phrasing would definitely assuage my concerns about the vagueness of "pushing", "distributing", "distributable", etc. (My wariness is largely around combining such terms with the keyword MUST without being very explicit about what they mean.)

runcom · 2016-09-07T17:30:08Z

@stephenrwalli that sounds perfect to me if people agree

wking · 2016-09-07T17:56:45Z

layer.md

+# Foreign Layers
+
+Certain layers, due to legal requirements, may not be regularly distributable.
+Typically, one can download such layers but they should never be uploaded.


@RobDolinMS is going to quibble with this non-SHOULD should (e.g. opencontainers/runtime-spec#536 ;). How about dropping this line, since the idea is covered in the rest of this section?

This is an important clarification and frames the stronger language below. I can capitalize the SHOULD or re-phrase it.

On Wed, Sep 07, 2016 at 11:43:09AM -0700, Stephen Day wrote:

@@ -156,3 +156,13 @@ Note that this opaque file will apply to all children, including sub-directori
Implementations SHOULD generate layers using explicit whiteout files, but MUST accept both.

Any given image is likely to be composed of several of these Image Filesystem Changeset tar archives.
+
+# Foreign Layers
+
+Certain layers, due to legal requirements, may not be regularly distributable.
+Typically, one can download such layers but they should never be uploaded.

This is an important clarification and frames the stronger language
below.

What is this line adding beyond the earlier:

Certain layers, due to legal requirements, may not be regularly distributable.

and the planned 1:

It is implementation defined whether or not implementations
distribute layers tagged with this media type.

Can you pin down the information the other lines are missing that
you're trying to convey here?

I agree with @wking to drop this line and favor the new one proposed

wking · 2016-09-07T17:56:58Z

On Wed, Sep 07, 2016 at 10:23:08AM -0700, Stephen Walli wrote:

So in this case, wording becomes: "It is implementation defined
whether or not implementations distribute layers tagged with this
media type."

This works for me too.

wking · 2016-09-07T19:49:20Z

On Wed, Sep 07, 2016 at 10:23:08AM -0700, Stephen Walli wrote:

So in this case, wording becomes: "It is implementation defined
whether or not implementations distribute layers tagged with this
media type."

It feels awkard to repeat “implementation”. How about:

It is unspecified whether or not implementations distribute layers
tagged with this media type.

?

stephenrwalli · 2016-09-07T20:53:22Z

I believe the suggested text becomes:

Foreign Layers
Layers that have these restrictions SHOULD be tagged with an alternative mediatype of `application/vnd.oci.image.layer.foreign.tar+gzip`.
 [Descriptors](descriptor.md) referencing these layers MAY include `urls` for downloading these layers.
It is implementation defined whether or not implementations upload layers tagged with this media type.

stephenrwalli · 2016-09-07T20:56:08Z

@wking I appreciate the awkwardness of language, but I'm using very specific phrasing. "Unspecified" says you can do anything. "Implementation defined" is that bit stronger saying implementations may already do things here and you should pay attention to your choices.

philips · 2016-09-07T20:58:59Z

LGTM

wking · 2016-09-07T21:04:30Z

On Wed, Sep 07, 2016 at 01:56:09PM -0700, Stephen Walli wrote:

@wking I appreciate the awkwardness of language, but I'm using very
specific phrasing. "Unspecified" says you can do
anything. "Implementation defined" is that bit stronger saying
implementations may already do things here and you should pay
attention to your choices.

Interesting. It looks like C defines those terms [1,2]. If we are
going to split those hairs (and it sounds like a good idea to me), I'd
recommend we put something like that in our spec or reference another
spec to define them for us. Ideally the latter. Is there an
equivalent to RFC 2119 for these terms?

 Page 18 of the PDF, page 11 of the document.

runcom · 2016-09-07T21:07:37Z

Are we sticking with the current language?

stevvooe · 2016-09-07T21:40:51Z

Updated with the new language!

runcom · 2016-09-07T21:44:18Z

layer.md

+
+Layers that have these restrictions SHOULD be tagged with an alternative mediatype of `application/vnd.oci.image.layer.foreign.tar+gzip`.
+[Descriptors](descriptor.md) referencing these layers MAY include `urls` for downloading these layers.
+It is implementation defined whether or not implementations upload layers tagged with this media type.


s/upload/distribute?

@runcom I think there were concerns about the meaning of distribute. I'll change it to that if we can re-obtain consensus.

@stephenrwalli CC

@stevvooe sorry for the noise, I re-read and you're right..

wking · 2016-09-07T22:25:30Z

On Wed, Sep 07, 2016 at 02:40:52PM -0700, Stephen Day wrote:

Updated with the new language!

I still think we want to drop the “should never be uploaded” line 1,
and would like to define “implementation defined” 2. But those can
be addressed in follow-up work if they're too contentious to handle
now, and the rest of fbc6ce4 looks good to me.

Signed-off-by: Stephen J Day <[email protected]>

stevvooe · 2016-09-09T21:07:48Z

@jonboulle I fully agree with the goal of reducing cognitive burden but consistency is also a valid goal. Docker calls this application/vnd.docker.image.rootfs.foreign.diff.tar.gzip and the concepts are isomorphic. Do you think these having different names helps to reduce cognitive burden?

How about we get this merged based on content and concept do another PR where we discuss the name of the media type? Would that suffice?

wking · 2016-09-09T21:24:56Z

On Fri, Sep 09, 2016 at 02:07:49PM -0700, Stephen Day wrote:

Do you think these having different names helps to reduce cognitive
burden?

When the new OCI name is more clear? Yes. If we didn't think so, we
wouldn't have landed #212.

How about we get this merged based on content and concept do another
PR where we discuss the name of the media type? Would that suffice?

I don't see how splitting this discussion out into a new PR will help
resolve it (there's not a lot of other distracting stuff happing in
this one), but if folks feel like that's the case, I'm happy to
discuss foreign → nondistributable in a follow-up PR.

stevvooe · 2016-09-09T21:39:34Z

When the new OCI name is more clear? Yes. If we didn't think so, we
wouldn't have landed #212.

#212 actually brings it closer to https://github.com/docker/distribution/blob/master/docs/spec/manifest-v2-2.md#media-types. Before, we had an extra level of indirection in OCI.

I'll say that I am as much of a stickler for naming as anyone, but I'm really just trying to move things forward. I think we have agreement on the concept, but I don't want to get it held up on naming. Let's get the concept in. If we agree on a name change, then we can merge that, as well.

wking · 2016-09-09T21:43:03Z

On Fri, Sep 09, 2016 at 02:39:34PM -0700, Stephen Day wrote:

Let's get the concept in. If we agree on a name change, then we can
merge that, as well.

Fair. I'm just not sure why we don't already have an agreement on
changing the name ;).

Signed-off-by: Stephen J Day <[email protected]>

wking · 2016-09-09T21:55:40Z

I still have the concerns from 1, which I'm ok ignoring or punting
on, but otherwise e48e595 looks good to me.

jonboulle · 2016-09-12T10:35:03Z

LGTM now, thanks @stevvooe

I do agree with wking's comments in #233 (comment) but we can follow up for that.

philips · 2016-09-13T05:20:45Z

LGTM

stevvooe · 2016-09-13T19:12:14Z

🎊

runcom · 2016-09-13T19:20:05Z

🎉

I had been unaware of formal distinctions between these terms until Stephen Walli called it out [1] in the context of his suggestion to use "implementation defined" for uploading application/vnd.oci.image.layer.nondistributable.tar+gzip [2]. I couldn't find anything as compact as RFC 2119 around this idea, but linking to a section of the C99 rationale seems reasonable enough. The PDF I'm linking is "Rationale for International Standard - Programming Languages - C Revision 5.10 April-2003" and the referenced content appears in section 3: The terms *unspecified behavior*, *undefined behavior*, and *implementation-defined behavior* are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. The goal of adopting this categorization is to allow a certain variety among implementations which permits *quality of implementation* to be an active force in the marketplace as well as to allow certain popular extensions, without removing the cachet of *conformance to the Standard*. Informative Annex J of the Standard catalogs those behaviors which fall into one of these three categories. *Unspecified behavior* gives the implementor some latitude in translating programs. This latitude does not extend as far as failing to translate the program, however, because all possible behaviors are "correct" in the sense that they don't cause undefined behavior in *any* implementation. *Undefined behavior* gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior. *Implementation-defined behavior* gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a user could make meaningful coding decisions based on the implementation's definition. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation-defined behavior is not an adequate response. The "rationale for the C99 standard" link text seems pretty informal, but that's what WG14 uses to refer to the document [3]. And I've got the full title, revision, date, and referenced text in here in case the link dies and there is any ambiguity about the particular revision intended ;). [1]: opencontainers#233 (comment) [2]: opencontainers#233 (comment) [3]: http://www.open-std.org/jtc1/sc22/wg14/ Signed-off-by: W. Trevor King <[email protected]>

I had been unaware of formal distinctions between these terms until Stephen Walli called it out [1] in the context of his suggestion to use "implementation defined" for uploading application/vnd.oci.image.layer.nondistributable.tar+gzip [2]. I couldn't find anything as compact as RFC 2119 around this idea, but linking to a section of the C99 rationale seems reasonable enough. The PDF I'm linking is "Rationale for International Standard - Programming Languages - C Revision 5.10 April-2003" and the referenced content appears in section 3: The terms *unspecified behavior*, *undefined behavior*, and *implementation-defined behavior* are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. The goal of adopting this categorization is to allow a certain variety among implementations which permits *quality of implementation* to be an active force in the marketplace as well as to allow certain popular extensions, without removing the cachet of *conformance to the Standard*. Informative Annex J of the Standard catalogs those behaviors which fall into one of these three categories. *Unspecified behavior* gives the implementor some latitude in translating programs. This latitude does not extend as far as failing to translate the program, however, because all possible behaviors are "correct" in the sense that they don't cause undefined behavior in *any* implementation. *Undefined behavior* gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior. *Implementation-defined behavior* gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a user could make meaningful coding decisions based on the implementation's definition. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation-defined behavior is not an adequate response. The "rationale for the C99 standard" link text seems pretty informal, but that's what WG14 uses to refer to the document [3]. And I've got the full title, revision, date, and referenced text in here in case the link dies and there is any ambiguity about the particular revision intended ;). Also update the layer.md instance to use the C99 standard's hyphenated form. [1]: opencontainers#233 (comment) [2]: opencontainers#233 (comment) [3]: http://www.open-std.org/jtc1/sc22/wg14/ Signed-off-by: W. Trevor King <[email protected]>

I had been unaware of formal distinctions between these terms until Stephen Walli called it out [1] in the context of his suggestion to use "implementation defined" for uploading application/vnd.oci.image.layer.nondistributable.tar+gzip [2]. I couldn't find anything as compact as RFC 2119 around this idea, but linking to a section of the C99 rationale seems reasonable enough. The PDF I'm linking is "Rationale for International Standard - Programming Languages - C Revision 5.10 April-2003" and the referenced content appears in section 3: The terms *unspecified behavior*, *undefined behavior*, and *implementation-defined behavior* are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. The goal of adopting this categorization is to allow a certain variety among implementations which permits *quality of implementation* to be an active force in the marketplace as well as to allow certain popular extensions, without removing the cachet of *conformance to the Standard*. Informative Annex J of the Standard catalogs those behaviors which fall into one of these three categories. *Unspecified behavior* gives the implementor some latitude in translating programs. This latitude does not extend as far as failing to translate the program, however, because all possible behaviors are "correct" in the sense that they don't cause undefined behavior in *any* implementation. *Undefined behavior* gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior. *Implementation-defined behavior* gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a user could make meaningful coding decisions based on the implementation's definition. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation-defined behavior is not an adequate response. The "rationale for the C99 standard" link text seems pretty informal, but that's what WG14 uses to refer to the document [3]. And I've got the full title, revision, date, and referenced text in here in case the link dies and there is any ambiguity about the particular revision intended ;). [1]: opencontainers/image-spec#233 (comment) [2]: opencontainers/image-spec#233 (comment) [3]: http://www.open-std.org/jtc1/sc22/wg14/ Signed-off-by: W. Trevor King <[email protected]>

I had been unaware of formal distinctions between these terms until Stephen Walli called it out [1] in the context of his suggestion to use "implementation defined" for uploading application/vnd.oci.image.layer.nondistributable.tar+gzip [2]. I couldn't find anything as compact as RFC 2119 around this idea, but linking to a section of the C99 rationale seems reasonable enough. The PDF I'm linking is "Rationale for International Standard - Programming Languages - C Revision 5.10 April-2003" and the referenced content appears in section 3: The terms *unspecified behavior*, *undefined behavior*, and *implementation-defined behavior* are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. The goal of adopting this categorization is to allow a certain variety among implementations which permits *quality of implementation* to be an active force in the marketplace as well as to allow certain popular extensions, without removing the cachet of *conformance to the Standard*. Informative Annex J of the Standard catalogs those behaviors which fall into one of these three categories. *Unspecified behavior* gives the implementor some latitude in translating programs. This latitude does not extend as far as failing to translate the program, however, because all possible behaviors are "correct" in the sense that they don't cause undefined behavior in *any* implementation. *Undefined behavior* gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior. *Implementation-defined behavior* gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a user could make meaningful coding decisions based on the implementation's definition. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation-defined behavior is not an adequate response. The "rationale for the C99 standard" link text seems pretty informal, but that's what WG14 uses to refer to the document [3]. And I've got the full title, revision, date, and referenced text in here in case the link dies and there is any ambiguity about the particular revision intended ;). Also update the layer.md instance to use the C99 standard's hyphenated form. [1]: opencontainers/image-spec#233 (comment) [2]: opencontainers/image-spec#233 (comment) [3]: http://www.open-std.org/jtc1/sc22/wg14/ Signed-off-by: W. Trevor King <[email protected]>

wking reviewed Sep 1, 2016
View reviewed changes

stevvooe force-pushed the foreign-layer-media-type branch from e7aa01a to 6c5b891 Compare September 1, 2016 17:40

runcom mentioned this pull request Sep 2, 2016

media-types.md: add foreign layer media type #216

Closed

wking reviewed Sep 2, 2016
View reviewed changes

stevvooe force-pushed the foreign-layer-media-type branch from 6c5b891 to 9b3d777 Compare September 2, 2016 21:21

jlbutler reviewed Sep 3, 2016
View reviewed changes

stevvooe force-pushed the foreign-layer-media-type branch from 9b3d777 to 4b60850 Compare September 6, 2016 18:56

wking reviewed Sep 7, 2016
View reviewed changes

philips added this to the v1.0.0 milestone Sep 7, 2016

stevvooe force-pushed the foreign-layer-media-type branch from 4b60850 to fbc6ce4 Compare September 7, 2016 21:40

runcom reviewed Sep 7, 2016
View reviewed changes

layers: describe policy enforcement for foreign layer media type

8a0c75c

Signed-off-by: Stephen J Day <[email protected]>

stevvooe force-pushed the foreign-layer-media-type branch from ba1ac91 to 8a0c75c Compare September 9, 2016 21:07

layer: change to "non-distributable" over foreign

e48e595

Signed-off-by: Stephen J Day <[email protected]>

runcom mentioned this pull request Sep 12, 2016

specs-go/v1: add nondistributable media type #297

Merged

philips merged commit 2903142 into opencontainers:master Sep 13, 2016

stevvooe deleted the foreign-layer-media-type branch September 13, 2016 19:11

wking mentioned this pull request Sep 13, 2016

manifest: List media types supported by descriptor references #304

Merged

wking mentioned this pull request Sep 14, 2016

README: Define "unspecified", "undefined", and "implementation-defined" #311

Merged

wking mentioned this pull request Sep 18, 2016

[README] Add a should #323

Closed

wking mentioned this pull request Dec 8, 2016

layer: wordsmith non-distributable section #483

Merged

layers: describe policy enforcement for foreign layer media type #233

layers: describe policy enforcement for foreign layer media type #233

Conversation

stevvooe commented Sep 1, 2016 • edited Loading

philips commented Sep 1, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonboulle commented Sep 6, 2016 • edited Loading

stevvooe commented Sep 6, 2016

stephenrwalli commented Sep 6, 2016

wking commented Sep 7, 2016

philips commented Sep 7, 2016

runcom commented Sep 7, 2016 • edited Loading

stephenrwalli commented Sep 7, 2016

jonboulle commented Sep 7, 2016

runcom commented Sep 7, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wking commented Sep 7, 2016

wking commented Sep 7, 2016

stephenrwalli commented Sep 7, 2016

stephenrwalli commented Sep 7, 2016

philips commented Sep 7, 2016 • edited by caniszczyk Loading

wking commented Sep 7, 2016

runcom commented Sep 7, 2016

stevvooe commented Sep 7, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wking commented Sep 7, 2016

stevvooe commented Sep 9, 2016

wking commented Sep 9, 2016

stevvooe commented Sep 9, 2016

wking commented Sep 9, 2016

wking commented Sep 9, 2016

jonboulle commented Sep 12, 2016 • edited by caniszczyk Loading

philips commented Sep 13, 2016 • edited by caniszczyk Loading

stevvooe commented Sep 13, 2016

runcom commented Sep 13, 2016

stevvooe commented Sep 1, 2016 •

edited

Loading

jonboulle commented Sep 6, 2016 •

edited

Loading

runcom commented Sep 7, 2016 •

edited

Loading

philips commented Sep 7, 2016 •

edited by caniszczyk

Loading

jonboulle commented Sep 12, 2016 •

edited by caniszczyk

Loading

philips commented Sep 13, 2016 •

edited by caniszczyk

Loading