Last Call Review of draft-ietf-geojson-text-sequence-05
review-ietf-geojson-text-sequence-05-opsdir-lc-banks-2017-03-01-00

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[OPS-DIR] OPS-DIR review of draft-ietf-geojson-text-sequence-04

From: Sarah B <sbanks at encrypted.net>
To: draft-ietf-geojson-text-sequence.all at ietf.org
Cc: Ops Directorate <ops-dir at ietf.org>
Date: Wed, 8 Feb 2017 15:36:37 -0800
References: <E17D4083-6CD5-4B06-984E-C592B03F2602@encrypted.net>
List-id: Ops Directorate <ops-dir.ietf.org>
Resend, as it appears the server didn't pick it up the first time.

Thanks
Sarah

Begin forwarded message:

From: Sarah B <sbanks at encrypted.net>
Subject: OPS-DIR review of draft-ietf-geojson-text-sequence-04
Date: February 1, 2017 at 1:56:54 PM PST
To: draft-ietf-geojson-text-sequence.all at ietf.org
Cc: Ops Directorate <ops-dir at ietf.org>

Hello,

        I have reviewed this document as part of the Operational directorate’s
        ongoing effort to review all IETF documents being processed by the
        IESG.  These comments were written with the intent of improving the
        operational aspects of the IETF drafts. Comments that are not addressed
        in last call may be included in AD reviews during the IESG review. 
        Document editors and WG chairs should treat these comments just like
        any other last call comments.

Document reviewed:  draft-ietf-geojson-text-sequence-04

Status:  Ready with comments

Summary:  This draft is self-described as "This document describes a
specialization of JSON Text Sequences. A GeoJSON Text Sequence is a document of
arbitrarily large size containing one or more GeoJSON objects, e.g., multiple
GeoJSON text that can be parsed and produced incrementally, and not only a
single GeoJSON FeatureCollection, Feature, or Geometry."

Comments: I have serious love for a use case. (seriously). So when I read
things like, in the Introduction, "Large or never-ending sequences of values
pose a problem for JSON that is well explained in the motivation for JSON Text
Sequences [RFC7464]. GeoJSON [RFC7946] faces the same kind of problem: <snip>",
I wonder how your draft is different, and why RFC7464 doesn't solve my problem?
I continued to read on, and I see that really, the difference here is the use
of the ASCII char RS "0x1e" - and gently put, that's kind of it, for the draft.
As an outside reader, it seems to me that this could have been an update or a
use case within RFC7464. Just a thought. If it's not the correct thought, it
might have done well to explain why one RFC didn't solve the problem and this
one calls out for a difference. This is a minor nit.

Thanks
Sarah

Follow-Ups:
Re: [OPS-DIR] OPS-DIR review of draft-ietf-geojson-text-sequence-04
From: Martin Thomson
Prev by Date: [OPS-DIR] Open review assignments in opsdir
Next by Date: Re: [OPS-DIR] OPS-DIR review of
draft-ietf-geojson-text-sequence-04 Previous by thread: [OPS-DIR] OPS-DIR
review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 Next by thread: Re: [OPS-DIR]
OPS-DIR review of draft-ietf-geojson-text-sequence-04 Index(es): Date Thread
Note Well: Messages sent to this mailing list are the opinions of the senders
and do not imply endorsement by the IETF.