Subject: [Gen-art] Gen-ART review of draft-ietf-appsawg-media-type-suffix-regs-06

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Oct 2012 14:48:00 -0700

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-appsawg-media-type-suffix-regs-06
Reviewer: Martin Thomson
Review Date: 2012-10-16
IETF LC End Date: 2012-10-19
IESG Telechat date: 2012-10-25

Summary: This document is ready for publication as a (?) RFC.

Minor issues: Is BCP status really appropriate?  Informational seems
more appropriate for this sort of document.  The choice of providing a
modicum of guidance in Section 2, as opposed to in the RFC that
establishes the registry, could suggest this status, but that seems a
bit weak as motivation.

Nits:

+der doesn't even make a passing reference to +ber.  That's odd, since
one describes a subset of the other.

Mention of schema for +der and +ber doesn't seem relevant to the key
security consideration: that structures can be nested indefinitely.
This is possible regardless of what the schema says - a generic
processor is more likely to fall victim in that regard.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 19 Oct 2012 13:15:11 +0100

Hi Martin,
Thank you for your review.

> establishes the registry, could suggest this status, but that seems a
This is a Normative reference for a BCP. It was split off from it.

I agree the registrations themselves can be Informational.
> one describes a subset of the other.
It might be worth adding a sentence on this.
> processor is more likely to fall victim in that regard.
This is not really different from arbitrary nesting in, for example, 
XML. But I suppose this can be pointed out explicitly.

---

From: Tony Hansen <[email-masked]>
Date: Fri, 19 Oct 2012 08:30:06 -0400

> Thank you for your review.

Yes, thank you.

> It might be worth adding a sentence on this.

I originally had the two in the same section with a common description 
and subsections for the registration forms, making it very obvious that 
they were related. I got comments to separate them out an dpull them 
both up to top level.

You can still tell that they are related by the fact that they use the 
same reference, but do we really need any additional text? My 
inclination is to not add anything further.

     Tony