[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last call comments on draft-freed-mime-p4-03.txt



Hello Ned,

Many thanks for your very quick reply.

At 14:39 03/10/20 -0700, ned.freed@mrochek.com wrote:
Dear IESG,

This are my last call comments on draft-freed-mime-p4-03.txt.

- IESG approval and IANA registration:

   Section 3.3.2, IESG Approval, says: "Media types registered in the
      standards tree MUST be approved by the IESG prior to registration."

   Section 3.3.3, IANA Registration, says:
     "When the registration is part of an RFC publication request, close
      coordination between the IANA and the IESG means IESG approval in
      effect submits the registration to the IANA.  There is no need for an
      additional registration request in such cases."

   It may be better to change "When the registration is part of an RFC
   pulication request" to "When the registration is submitted to the IESG
   for approval", which would include all registrations approved by the
   IESG. My guess is that this is just an oversight, but it should be
   checked with the authors.

I'll add some text to this section to make it clear it is also talking about submissions from other standards bodies to the IESG. I don't like collapsing the two cases, however, so I'll instead make it an A or B sort of thing.

I do note it would also be possible for standards tree submissions from
other standards bodies to go through IANA first. I detected some preference
for it to be an IESG first sort of thing so that's how I wrote it up, but
if folks want to change it that would certainly be possible.

In my understanding, the IESG has to approve before the IANA can register. So of course the submitter could send it to IANA, IANA then would send it to the IESG, the IESG would approve and send it back to the IANA, and they would register. That would indeed work. But it seems more straightforward to send it to the IESG, the IESG approves and sends it to IANA, and then IANA registers.

(all these are just details, I don't think there would be any
serious problems in the current wording)


- 3.6: Overall, this is worded a bit confusingly, and should be
        cleaned up. There are the following problems:
        - The intro says "Vendor and personal types will be
             registered by the IANA automatically and without any formal
             review as long as the following minimal conditions are met:",
          but then the remainder falls back to overall requirements and
          requirements for standards track.

Uh, no it doesn't. The requirements for vendor and personal types are quite
minimal, and amount to cusory documentation of any known issues. This falls FAR
short of formal review. Standards tree registrations go through the IESG and
will receive some amount of formal review. (Exactly how much will be for the
IESG to determine. I suppose it is conceivable the IESG won't ask for more than
what's required for vendor or personal tree registrations, but I think this is
fairly unlikely.)

I think I wasn't clear enough about where I saw a problem. I understand that the requirements for vendor/personal are minimal, and the requirements for standard are quite high, and up to the IESG.

What I meant was that Section 3.6 starts out as:

   The IANA will only register media types in the standards tree in
   response to a communication from the IESG stating that a given
   registration has been approved.  Vendor and personal types will be
   registered by the IANA automatically and without any formal review as
   long as the following minimal conditions are met:

with a list following. At this point, the reader expects that this
list contains the minimal conditions for automatic IANA registration
of vendor and personal types. This is indeed the case for bullets
1 to 4. However, bullet 5 says:

   o  Registrations in the standards tree MUST satisfy the additional
      requirement that they originate from another standards body
      recognized as such by the IETF.

This is no longer about vendor or personal registrations. I think the
easiest way to fix the logic would be to change the fifth bullet point
into a plain paragraph.

Regards, Martin.


Since time is fairly short I'll submit a revised version with these
clarifications right away.

Ned