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

[Erik Wilde <[e-mail]>]

hello.

thanks a lot for the review!

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

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 suffix was incorrectly being used in a media type registration, so
> 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.

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

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.

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

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?

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

that indeed is the only intent of this document.

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

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.

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

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?

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

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

>> Section 3:
>> Applications encountering such a media type then can either simply
>> [O] then can either
>> [P] can then either
>> [R] readability

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:[e-mail] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |