Re: [secdir] secdir review of draft-ietf-geojson-03

Tim Schaub <> Thu, 26 May 2016 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6CAC12D6F5; Thu, 26 May 2016 08:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VJ15dc9lM2SV; Thu, 26 May 2016 08:11:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0DEF212D6C6; Thu, 26 May 2016 08:11:51 -0700 (PDT)
Received: by with SMTP id ct2so4704574igb.0; Thu, 26 May 2016 08:11:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=TPJlasU6gOM/X/8jJqj/LG4zSRcPcFyDp9XMY/XqZ58=; b=Rb19EkdRTpgdPDFCpQ1zi/6InIu/9Lc0KsIuQJn/MQDaOlyFAZyawUR+5Exb4ctBek iyOcA2ei8yY1tXfcSV+bCkZnSxOnjUwlBcshY2K0NP3t1HVyXNexG67Xm/oBFkg56aKC 9OWzhwMGzGrImg7Ge71JU27kA2yzoO2rZwNL/8P2RhsLVHllkETIiPz4v3vpEjRPLJDK QZ4hoQG4YV28eLOD06NqIYHKOtglymPR7c7JBHNFnI/PkrbzWWRMh9hRrQ9rc3WvmHmY 9aJsb4xQIJuMnaWA2f1SRRoJ8jfbP65dpizccywK803E2/71iyO1Eh5lT+a7n573Semd xeuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=TPJlasU6gOM/X/8jJqj/LG4zSRcPcFyDp9XMY/XqZ58=; b=OxEezS7MxwmqM+az4srvP5QRLBZfW0ETDATtH2DvHRp5B5u4FUZkUoowxQ7eKLx9OQ f0JbVTtWpVJCYVFBE+YYoaybxe5iR35ja9VPFOQuKc1oR4Mr8ArZwpuIDun18cF9DJ7c +JzmM4fSs9HdKdHLFQFlJgUGh7875Ox8NmaMqAR+AlpeQ7311wMw/9GSrWZsR+hte3ju 77rWbhAJVhuQq3GWsmfC1Pn31JV126TmC2mvUNYJckM+gmHKb5R9SMg/EdKWR7nktKcd hB9sz1OPvxMKUReyZSyOVt21Q3SqSPE0kIGwK+GlC4tcXPRk4yoz/BLgB0QI9xI7GIst UrRw==
X-Gm-Message-State: ALyK8tJYoLHD0rUuRNeowyEYKEkvsPfBKNB6OTO8hN1jZAv3JdMa+4C7/858/6TIR/9tiIfvOTNcBFHadFHPUg==
MIME-Version: 1.0
X-Received: by with SMTP id k8mr3791225ige.9.1464275510245; Thu, 26 May 2016 08:11:50 -0700 (PDT)
Received: by with HTTP; Thu, 26 May 2016 08:11:49 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 26 May 2016 09:11:49 -0600
Message-ID: <>
From: Tim Schaub <>
To: Melinda Shore <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-geojson-03
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 May 2016 15:11:53 -0000

Thanks for the feedback Melinda.  I put together a pull request with
your proposed changes:


On Thu, May 26, 2016 at 12:15 AM, Melinda Shore <> wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> (note: I was assigned the -02 revision of the document, but the -03
> version was just issued and I am reviewing that).
> Summary: this document is ready, with minor issues
> This document describes a JSON format for representing geospatial
> data.  It recommends a single coordinate reference system and does
> not appear to be readily extensible to other coordinate reference
> systems, but I'll assume that this has been addressed and resolved
> by the responsible AD, etc. if it's actually a problem.
> The security considerations section is brief and refers the reader
> to the core JSON specification.  The second paragraph of the
> security considerations sections may have minor issues in that it
> says "if sensitive data requires privacy or integrity protection the
> service must be provided externally."  It may be appropriate, and
> provide additional clarity, to distinguish between protection of
> data in flight and data at rest (the IETF does not typically deal
> with protection of the latter).  It may be sufficient to make the
> word "externally" go away and replace it with something more specific -
> for example,
>     "if sensitive data require privacy or integrity protection
>     those must be provided by the transport, for example TLS or
>     HTTPS."
> Otherwise, looks ready.
> Melinda