Document revision for the two comments
because of length; also John Lazzaro has found
a fair number of sentences without verbs but
also clarity requests from readers.
I told him IETF has a strong wish that authors
don't propose changes at AUTH48, so he can
fix now in modest way.

Answered IANA query.

Hi, Michelle,

Inline.

>
> These comments have also been put in the tracker.
>
> For draft-ietf-avt-rtp-midi-guidelines-14.txt, we understand this document
> to not have any IANA Actions.  We understand
> draft-ietf-avt-rtp-midi-format-14.txt discusses any actions that need to be
> implemented.

That's right.

>
> For draft-ietf-avt-rtp-midi-format-14.txt, we have the following
> comments/questions:
>
> For section H.1
> We understand this to be a new MIME Media Type registration for
> audio/rtp-midi to be placed in the following registry:
> http://www.iana.org/assignments/media-types/audio/

Yes.

>
> We understand a new set of sub-registries needs to be set-up for parameters
> associated with audio/rtp-midi.  This registry would go with other
> sub-parameter registries at the following:
> http://www.iana.org/assignments/media-type-sub-parameters

Yes.

>
>
> For section H.3
> We understand this to be a new MIME Media Type registration for audio/asc to
> be placed in the following registry:
> http://www.iana.org/assignments/media-types/audio/
> Is this correct?

Yes

>
> Also in the "Optional parameters" sections in various parts of section H, it
> appears IANA needs to register these.  Where should these go?  Also at the
> following location?:
> http://www.iana.org/assignments/media-type-sub-parameters
>

audio/rtp-midi has a list of non-extensible Optional parameters which don't
need registration.  Then it has the set of 5 extensible Optional parameters
(j_sec to smf_info) for which the Appendix H.1.1 sub-parameters registry was
requested).

audio/mpeg4-generic has the same situation.  The 5 extensible Optional
parameters are a duplicate of the audio/rtp-midi so there's no new action
there.

Do add this document as a reference (not a replacement, but an addition)
to the reference line for audio/mpeg4-generic.

> Let me know if you need any further clarification.  Sorry for getting these
> to you late.
>

And I'm sorry for replying late.  I hope this is clear enough.
If you have any more questions (or if it's not or if it's got
something wrong), I've now got Magnus, the WG Chair shepherd, and
John, the editor, on the cc line.

IANA Comments:
For section H.1
We understand this to be a new MIME Media Type registration for
audio/rtp-midi to be placed in the following registry:
http://www.iana.org/assignments/media-types/audio/

We understand a new set of sub-registries needs to be set-up for parameters associated with audio/rtp-midi.  This registry would go with other sub-parameter registries at the following: 
http://www.iana.org/assignments/media-type-sub-parameters

For section H.2
We understand a new value (rtp-midi) for the mode parameter needs to be registered.  This will go in the existing registry for Sub-Parameters Registry for video/mpeg4-generic, audio/mpeg4-generic and application/mpeg4-generic found at the following:
http://www.iana.org/assignments/media-type-sub-parameters

We understand a new set of sub-registries needs to be set-up for parameters used with rtp-midi mode value.  Do we understand this new set of registries should also go in the following location:
http://www.iana.org/assignments/media-type-sub-parameters

For section H.3
We understand this to be a new MIME Media Type registration for audio/asc to be placed in the following registry:
http://www.iana.org/assignments/media-types/audio/
Is this correct?

Also in the "Optional parameters" sections in various parts of section H, it appears IANA needs to register these.  Where should these go?  Also at the following location?:
http://www.iana.org/assignments/media-type-sub-parameters

[Ballot comment]
We will address Ted's comments on the guide as previously
noted, and fix the IPv6 addresses that Bert noted in his comment.
See the tools-discuss list for an idnit update plan for
catching these in future.

[Ballot discuss]
Holding this Discuss till 1/23 in case there are any comments on
the ietf-types list

This Discuss is also for IANA - the document is very
long and per an email to me,
Michelle needs the day of 1/19 at least to
complete review.

[Ballot comment]
Document: draft-ietf-avt-rtp-midi-format-14.txt

Page 33:  c=IN IP6 FF1E:03AD::7F2E:172A:1E24
Page 95:  c=IN IP6 FF1E:03AD::7F2E:172A:1E24
Page 109: c=IN IP6 FF1E:03AD::7F2E:172A:1E24
Page 113: c=IN IP6 FF1E:03AD::7F2E:172A:1E24
Page 116: c=IN IP6 FF1E:03AD::7F2E:172A:1E24
Page 121: c=IN IP6 FF1E:03AD::7F2E:172A:1E24

These do not look like IPv6 example addresses as required per RFC3849.
That is, they should be from the set: 2001:DB8::/32

[Ballot comment]
rtp-midi-guidelines has the following text:

We now show example code that implements the actions the parties take
during the session.  The code is written in C, and uses the sockets API
and other POSIX systems calls.  We show code for the first party (the
second party takes a symmetric set of actions).

I think it would be valuable to include references here; I can assume which C 
is meant by the reference to posix, but it can't hurt to nail it down.

The information in 6.2 on the target network characteristics seems like it would
be valuable earlier, and it might be useful to consider adding to the introductory material.

[Ballot discuss]
ietf-types review was sent on 8 January.  With two weeks needed for that review, Allison will take a placeholder discuss to ensure that any late-breaking review comments are addressed.

[Ballot discuss]
Placeholder discuss until I hear from Allison: can you point me to the ietf-types review request for the media types described in
draft-ietf-avt-rtp-midi-format?  I see that the write-up says that the review took place, but google isn't finding a copy of the request for me.

Sending out new media type for ietf-types review today.

By definition ietf-types doesn't have new parameters added
media types, so the fact that these can happen is
RTP-specific and I will not send the new ones for mpeg4-generic
for review