[secdir] Secdir review of: draft-wilde-json-seq-suffix
Warren Kumari <warren@kumari.net> Mon, 28 November 2016 13:17 UTC
Return-Path: <warren@kumari.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595631295BD for <secdir@ietfa.amsl.com>; Mon, 28 Nov 2016 05:17:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rc9rd0wgKHRP for <secdir@ietfa.amsl.com>; Mon, 28 Nov 2016 05:17:04 -0800 (PST)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8930312943A for <secdir@ietf.org>; Mon, 28 Nov 2016 05:17:04 -0800 (PST)
Received: by mail-qk0-x22c.google.com with SMTP id n204so138872201qke.2 for <secdir@ietf.org>; Mon, 28 Nov 2016 05:17:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=vVZwygOkWvLCAGoJbYm/hu4i1hs7gNykpJdWyvoKoHQ=; b=C3/teyMNXG/tCTvTZVFfJ18bFEzqwppSPvhleVRlcP997efdwRsVmSa0CJIheOBKf2 a0ZqTHhgK/h39dXUWi9ZS6fIc2Kly+oOLNrq908ofoYoX99POrH7NXOd+JuVbs2O75OU /9WaPZOyT+lIOShvvWi717Cb+eR0bXFay6DcYA8r1ZW3ygNDjI1a6mKVpEK3BOjfCArs m3/ya8Wyyp6Vxe8QaUlSEbstXTTeZuBT3E1PfpPlukmURzgmT5Hvf9paqFXqFB8HRuR+ 0LLeHSrQhv9bgs0BRp04RcCMsRf+ChQ99ayZ2T6nIVeaCzH8RZ/TVLoVdtOnDJp7O5hA 6EJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vVZwygOkWvLCAGoJbYm/hu4i1hs7gNykpJdWyvoKoHQ=; b=QKjxFM5qqdyWHbx9AlrSC9UBiYlp2QHX1RS3g3MVy340WFJClkGkK8P9g8W164o8/2 /bfcTJk8YBXEQxUvXNf/qwiT+4DO5PRzFN37XBMd/9uhPtSKY630s8SeUbOcKOVDImVV T7g/4ipgtRokvaahd7L8tRkdvMlaRW16+0d1B/UiFjtUEMaoZlv8pudRxDHszrovkOWg yjWdTeAAZFoMcKHVnaGhsjwH91K2CICeyVLtaxLkFKq3b5uJIIy8yOY3qZblye/W1NRK R1ryCDNaNvtG/HJMpbj2zn9A0kNt0HR5GuCAfMgk5q94ck2fP33NgcJ4/VXIM/C7VYIr X1Ig==
X-Gm-Message-State: AKaTC0159lK7zSJyx5yv+DJP5OSMY3GT7Pa3qF3IYYzXKQgHuGGm0dxWhW7P7F42kiM1LeKKK5K9UzA0+hBUPz6I
X-Received: by 10.55.118.65 with SMTP id r62mr20492275qkc.21.1480339023353; Mon, 28 Nov 2016 05:17:03 -0800 (PST)
MIME-Version: 1.0
From: Warren Kumari <warren@kumari.net>
Date: Mon, 28 Nov 2016 13:16:52 +0000
Message-ID: <CAHw9_iLXOq-hD7qrQAJDBYoi4bKs9msjOivzuc5z9fs6yniYQQ@mail.gmail.com>
To: The IESG <iesg@ietf.org>, IETF Security Directorate <secdir@ietf.org>, draft-wilde-json-seq-suffix.all@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c062206a2857e05425c499d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/GZAjAXBcSjejeF15XkQx22FX4eQ>
Subject: [secdir] Secdir review of: draft-wilde-json-seq-suffix
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Nov 2016 13:17:07 -0000
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. Summary: I do not think that it is ready (see below), but presumably there is some backstory that I'm not aware of, or it wouldn't be here. I don't see any *security* issues, but the document is very unclear. It *looks* like it just tries to add "+json-seq" to the IANA Structured Syntax Suffix Registry, but I don't see why it is Standards Track, or why it need to be an RFC at all; the registry is Expert Review, and RFC 6838 Section 6 seems clear. Other issues: It does not contain a Security Considerations section, and there are a number of broken references (e.g: it says: "Online access to all versions and files is available on github [2]." - but [2] is a link to: http://www.rfc-editor.org/info/rfc6838) It is a -00, submitted Sept 23rd 2016, and the document on which it was based (draft-json-seq-suffix-00) was also a -00, submitted Sept 19th 2016. The only changes between the 2 are the metadata (name, date). There has been basically no discussion (at least, that I can find), closest is: https://mailarchive.ietf.org/arch/search/?email_list=art&index=AxC0J7zxKU_wH1jOrkZ0ZZUUcs4 ? I *think* that it is simply trying to add "+json-seq" to the IANA Structured Syntax Suffix Registry ( http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml) -- unfortunately it does this very poorly. It starts off by saying (note tense): "IANA has added the following "+json-seq" structured syntax suffix to its registry of structured syntax suffixes established by [2]". [2] references to RFC 6838 - "Media Type Registration", which creates a number of registries - while looking I found " http://www.iana.org/assignments/media-types/media-types.xhtml", which does indeed have "json-seq". Because of the "IANA has added" I assumed that this was what was being referenced. The IANA considerations section needs work... Nits: Section 1: how a media type can signal that it is based on another media type as [O] way of how a media type can signal [P] way for a media type to signal [R] readability; original was a bit awkward Section 3: Applications encountering such a media type then can either simply [O] then can either [P] can then either [R] readability W
- [secdir] Secdir review of: draft-wilde-json-seq-s… Warren Kumari
- Re: [secdir] Secdir review of: draft-wilde-json-s… Alexey Melnikov
- Re: [secdir] Secdir review of: draft-wilde-json-s… Erik Wilde
- Re: [secdir] Secdir review of: draft-wilde-json-s… Martin Thomson
- Re: [secdir] Secdir review of: draft-wilde-json-s… Erik Wilde
- Re: [secdir] Secdir review of: draft-wilde-json-s… Warren Kumari