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

From: Warren Kumari <[email-masked]>
Date: Mon, 28 Nov 2016 13:16:52 +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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 28 Nov 2016 13:34:56 +0000

Hi Warren,

Thank you for your review.

On 28/11/2016 13:16, Warren Kumari wrote:

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

> Structured Syntax Suffix Registry 
> (http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml) 
>
Yes.

> "+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.
> 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:

---

From: Erik Wilde <[email-masked]>
Date: Mon, 28 Nov 2016 10:00:26 -0800

hello.

thanks a lot for the review!

On 2016-11-28 05:34, Alexey Melnikov wrote:
>> 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.

https://github.com/dret/I-D/commit/8694a1efce71dcb96410be3bd6be8d0373383703 
switches the draft to experimental. to be honest, i do get conflicting 
info on this, and depending on the people dealing with a draft, some 
seem to prefer one status over the other. i have no strong opinion about 
this and thus i am happy to switch to the status people think is most 
appropriate.

> this document is now trying to register the suffix to fix the brokenness.

that is the only reason this draft exists: register the suffix in a way 
that it is properly defined and registered and that the registration can 
be referenced. so yes, this is a simple draft, and intentionally so.

> Yes, this needs to be fixed.

that's the good old xml2rfc bug that still is around. sorry for this, 
https://github.com/dret/I-D/commit/ee5838e5ddf53cf7084022abb7a275ac4a30a028 
is the best workaround there is for this bug, afaict.

https://github.com/dret/I-D/commit/1efd188ff60f2dbe7f414082d730091e803faa77 
fixes another broken reference.

>> find), closest
>> is: https://mailarchive.ietf.org/arch/search/?email_list=art&index=AxC0J7zxKU_wH1jOrkZ0ZZUUcs4 ?

all correct, and apologies for missing these things so far.

- the two versions exist because i accidentally named the initial 
submission incorrectly. the current version simply was a re-submission 
with the fixed submission name.

- i will submit a -01 version with the changes discussed in this message 
today.

- apart from the missing security considerations section (added via 
https://github.com/dret/I-D/commit/f57746b52ffc9d9b89b3af392be41c80ba530743), 
is there anything else that seems to be missing?

>> -- unfortunately it does this very poorly.

that indeed is the only intent of this document.

>> syntax suffixes established by [2]".

that's how it's supposed to read once approved (at which point the 
addition will have been done), and that's how i have written this in 
previous documents.

>> that this was what was being referenced.

RFC 6838 established more than one registry. one is that of media types. 
another one is that of structured syntax suffixes. it is that latter one 
that is targeted by this document:

http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml#structured-syntax-suffix

this one does not have the "+json-seq" structured syntax suffix in there 
and the goal of the document is to add it. this registry is specifically 
called out in the IANA considerations section.

>> The IANA considerations section needs work...

in which particular way? the section says that it updates the structured 
syntax suffixes registry and contains all the necessary fields to do 
that. what are you missing?

>> signal [R] readability; original was a bit awkward

thanks! 
https://github.com/dret/I-D/commit/672780ac2aafd2732e696ae85dec72e9c315ddc7

>> Applications encountering such a media type then can either simply

thanks! 
https://github.com/dret/I-D/commit/f4d915490f1b05551b9b424f3b9e69b617de3645

https://tools.ietf.org/html/draft-wilde-json-seq-suffix-01 is the 
updated version of the draft. once again, thanks a lot for the review 
and feedback, this is greatly appreciated!

cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Nov 2016 12:47:55 +1100

On 29 November 2016 at 05:00, Erik Wilde <[email-masked]> wrote:
> switches the draft to experimental. to be honest, i do get conflicting info
> on this, and depending on the people dealing with a draft, some seem to
> prefer one status over the other. i have no strong opinion about this and
> thus i am happy to switch to the status people think is most appropriate.

Informational is probably a better choice.

---

From: Erik Wilde <[email-masked]>
Date: Mon, 28 Nov 2016 18:12:13 -0800

hello martin.

> Informational is probably a better choice.

alexey pointed that out as well. 
https://github.com/dret/I-D/commit/d0cf3ee1bf53288e8a86e9e62e9be6a2b95bfbda 
switches the draft to informational, but i haven't published a new 
version. i will do that after the next round of feedback.

thanks and cheers,

dret.