Re: [payload] review of draft-ietf-payload-tetra-01

[REISENBAUER Andreas <[e-mail]>]

Hi Roni,
Thanks a lot for your hints

I am now working on a draft-ietf-payload-tetra-03 which considers:

*         Dave Satterlee's first comment

*         Your comments (extending section 7.1)

*         And Andreas Ahland's comment from June 16th I also did not address til now

May I ask you to have a quick check of what is "work in progress" on section 7.1? I think I got RFC6838 now - was more struggling with tooling (indent level) then content
   Type name:
      audio
   Subtype name:
      TETRA
   Required parameters:
      none
   Optional parameters:
      These parameters apply to RTP transfer only.

      *  maxptime: The maximum amount of media which can be encapsulated
         in a payload packet, expressed as time in milliseconds.  The
         time is calculated as the sum of the time that the media
         present in the packet represents.  The time SHOULD be an
         integer multiple of the frame size.  If this parameter is not
         present, the sender MAY encapsulate any number of speech frames
         into one RTP packet.
      *  ptime: see RFC 4566 [RFC4566].
   Encoding considerations:
      This media type is framed and binary according Section 4.8 of RFC
      6838 [RFC6838].
   Security considerations:
      See Section Section 10 of RFC XXXX.  [RFC Editor: Upon publication
      as an RFC, please replace "XXXX" with the number assigned to this
      document and remove this note.]

   Interoperability considerations: N/A

   Published specification:
      RFC XXXX [RFC Editor: Upon publication as an RFC, please replace
      "XXXX" with the number assigned to this document and remove this
      note.]
   Applications that use this media type:
      This media type is used in applications needing transport or
      storage of encoded voice.  Some examples include; Voice over IP,
      streaming media, voice messaging, and voice recording on recording
      systems.

   Additional Information:

                - Deprecated alias names for this type: N/A
                - Magic number(s): N/A
                - File extension(s): N/A
                - Macintosh file type code(s): N/A

   Person & email address to contact for further information:
      Andreas Reisenbauer <mailto:[e-mail]>
      IETF Payload Working Group <mailto:[e-mail]>
   Intended usage:
      COMMON
   Restrictions on usage:
      This media type depends on RTP framing and hence is only defined
      for transfer via RTP RFC 3550 [RFC3550].  Transport within other
      framing protocols is not defined at this time.
   Author:
      Andreas Reisenbauer <mailto:[e-mail]>
   Change controller:
      The IETF PAYLOAD Working Group, or other party as designated by
      the IESG.

If OK for you (and the others as I sent pm), I would generate a version 03 of this draft very soon.
Do you think this approach is appropriate?

Many thanks in advance and all the best
Andreas

From: Roni Even (A) [mailto:[e-mail]]
Sent: Donnerstag, 25. Oktober 2018 08:38
To: REISENBAUER Andreas
Cc: [e-mail]
Subject: review of draft-ietf-payload-tetra-01

Hi Andreas,
I looked at the new revision and it looks like it addresses most of the comments.

Two comments were not addressed

1. Dave Satterlee had the following one in an email from 25.6.2018 "In section 1 (Introduction) the document says "The payload format supports transmission of multiple channels..." . It is unclear to me what this means, and where it is specified in the draft."

2.  My comment from 28.6.2018 was not addressed "The media type definition in section 7.1 does not include all fields from the registration template. See section 5.6 in RFC6838 and similar payload WG RFCs "
Look for the template at https://tools.ietf.org/html/rfc6838#section-5.6 and one of the latest payload RFCs like RFC8130 and RFC8331



Roni Even
Payload WG co-chair