Re: [secdir] Secdir review of: draft-wilde-json-seq-suffix

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 28 November 2016 13:35 UTC

Return-Path: <alexey.melnikov@isode.com>
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 C4B0912943A; Mon, 28 Nov 2016 05:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level:
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 ruCpDQe1t7zy; Mon, 28 Nov 2016 05:34:58 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id A3DAD12988C; Mon, 28 Nov 2016 05:34:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1480340097; d=isode.com; s=june2016; i=@isode.com; bh=Ge/YVrmDI/FVRm7sLLK7vIf7atmZKtVsJdb2XDZumQs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=aqpdzEeRuc3rKHuEvMiJZEkE3PKiRrQenx4KB2Sqcn5ooZ2L9XJHLgdztTgJugFaRziKu0 mjl38xTpjlhgGrIOsCzg6M87mdIUhsmRkK6Aqf01qGh4BDrgjwEo40s00S5xKkEsqNr8Vt RiqP4uLyy10Y5hQS4VE4cp3EtUJHcFU=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <WDwygAAZuo85@waldorf.isode.com>; Mon, 28 Nov 2016 13:34:57 +0000
To: Warren Kumari <warren@kumari.net>, The IESG <iesg@ietf.org>, IETF Security Directorate <secdir@ietf.org>, draft-wilde-json-seq-suffix.all@ietf.org
References: <CAHw9_iLXOq-hD7qrQAJDBYoi4bKs9msjOivzuc5z9fs6yniYQQ@mail.gmail.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <a9a1fa95-582d-a6ae-7da8-cbe2df596181@isode.com>
Date: Mon, 28 Nov 2016 13:34:56 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
In-Reply-To: <CAHw9_iLXOq-hD7qrQAJDBYoi4bKs9msjOivzuc5z9fs6yniYQQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------AD19928D260EC5B11B6AB9A4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Dvj7lLR-_DBK3zhJylWEQGN-JR8>
Subject: Re: [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:35:00 -0000

Hi Warren,

Thank you for your review.

On 28/11/2016 13:16, Warren Kumari 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.
>
> 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 theIANA 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.
While this indeed can be just sent in an email, IMHO, it is better to 
register Media Type suffixes in RFCs. All existing Media Type suffixes 
were registered in RFCs.
It probably doesn't need to be Standards Track.

I would be happy to follow IESG's advice on how to handle this document.

This suffix was incorrectly being used in a media type registration, so 
this document is now trying to register the suffix to fix the brokenness.
> 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)
Yes, this needs to be fixed.

> 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 ?

The document is rather trivial (and yes, it does contain annoying 
omissions). Chairs of GeoJSON WG reached out to me for AD sponsoring of 
this document, because one of their documents used the prefix incorrectly.

> 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) 
>
Yes.

> -- 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