Re: [payload] [Payload] Last Call: <draft-ietf-payload-rfc3189bis-02.txt> (RTP Payload Format for DV (IEC 61834) Video)) to Proposed Standard

[Kazuhiro Mishima <[e-mail]>]

Hi, Roni and Qin
Thank you for your comments!

I'll correspond these issues and update the draft soon.

Best regards,
Kazuhiro


2011/9/27 Qin Wu <[e-mail]>:
> Hi, Roni:
> Thank for your replies. Your proposed changes look good to me.
> I would like to see the remaining minor issues are addressed by authors.
>
> Regards!
> -Qin
> ----- Original Message -----
>
> From: Roni Even
> To: 'Qin Wu' ; [e-mail]
> Cc: [e-mail] ; 'Kazuhiro Mishima' ; [e-mail] ; 'Stephen Casner'
> Sent: Tuesday, September 27, 2011 2:53 AM
> Subject: RE: [payload] [Payload] Last Call:
> <draft-ietf-payload-rfc3189bis-02.txt> (RTP Payload Format for DV (IEC
> 61834) Video)) to Proposed Standard
>
> Hi Qin,
>
> Thanks for the review see inline
>
> Roni
>
>
>
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Qin Wu
>
> Sent: Tuesday, September 20, 2011 9:16 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [payload] [Payload] Last Call:
> <draft-ietf-payload-rfc3189bis-02.txt> (RTP Payload Format for DV (IEC
> 61834) Video)) to Proposed Standard
>
>
>
> Hi,
>
> I have just read this document and have some minor comments, hope it is not
> late to be taken into account.
>
> 1. Section 1:
>
> [Qin]: It looks this version extends RFC3189 to support some new features.
> However I can not see any dependency to RFC3189 in the introduction section
> until
> I read the last section in this document, is it more straigtforward and
> clear to merge the section 7,8
> to the introduction section and clarify how this document is different from
> RFC3189.
>
>
>
> Roni: This document does not extend but obsolete RFC3189, so it should not
> reference it. As for the difference from RFC3189 I think it is better to
> have a separate section.
>
>
>
> [Qin]: Yes, I recheck this document, you are right, this document is
> intending to replace the old feature with new feature, e.g., abandon using
> SMPTE 306M, replace with SMPTE314M. Therefore I agree with your
> justification.
>
>
>
>
>
> 2. Section 3.1.1
>
> "
>
> 3.1.1.  Media Type Registration for DV Video
>
>    Type name:  video
>
>
>
>    Subtype name:  DV
>
>
>
>    Required parameters:
>
>
>
>       encode:  type of DV format.  Permissible values for encode are
>
>          SD-VCR/525-60,
>          SD-VCR/625-50,
>          HD-VCR/1125-60,
>          HD-VCR/1250-50,
>          SDL-VCR/525-60,
>          SDL-VCR/625-50,
>          314M-25/525-60,
>          314M-25/625-50,
>          314M-50/525-60,
>          314M-50/625-50,
>          370M/1080-60i,
>          370M/1080-50i,
>          370M/720-60p,
>          370M/720-50p,
>          306M/525-60 (for backward compatibility),
>          and 306M/625-50 (for backward compatibility).
>
> "
>
> [Qin]: In section 7, you claim you have removed SMPTE 306M, since it is
> covered by SMPTE 314M format.
> However in section 3.1.2, the value for SMPTE 306M is still kept in the
> encode list. So the question is
> where do you remove SMPTE 306M in this document? Why SMPTE 306M in the media
> type registration is still kept?
> Does this conflict with what you said in the section 7?
>
>
>
> The same comment applies in any place of this document where SMPTE 306M is
> still kept.
>
>
>
> Roni: Maybe change the first bullet of section 7
>
> " Removed SMPTE 306M, since it is covered by SMPTE 314M format"
>
> To
>
> "support for SMPTE 306M is only for backward interoperability, since it is
> covered by SMPTE 314M format"
>
>
>
> [Qin]: Yes, make sense to me.
>
>
>
> 3. Section 3.1.1
>
> "
>
>    Optional parameters:
>
>
>
>       audio:  whether the DV stream includes audio data or not.
>
>          Permissible values for audio are bundled and none.  Defaults to
>          none.
>
>
>
>    Encoding considerations:
>
>
>
>          DV video can be transmitted with RTP as specified in RFCXXXX
>          (This document).  Other transport methods are not specified.
>
>
>
>    Security considerations:
>
>
>
>          See Section 4 of RFCXXXX (This document).
>
>
>
>    Interoperability considerations:  NONE
>
> "
>
>
>
>  [Qin]: Is it real that there is no interoperability consideration since
> Interoperability with Previous Implementations is discussed in the section 8
> of this document?
>
>
>
> Roni: Good, add a reference to section 8 of this RFC
>
>
>
> [Qin]:  Your proposal Looks good to me.
>
>
>
> 4. Section 3.2.1
>
> "
>
>    Note that the examples in RFC3189 (older version of this document)
>    provides incorrect SDP "a=fmtp" attribute usage.
>
>
>
> "
>
> [Qin]: I believe it is not appropriate to spell this note out when this
> document is published but you may put
> it as errata or in the section 7.
>
>
>
> Roni: good point. Maybe discuss it in section 8, since this may be an
> interoperability issue
>
>
>
>
>
> [Qin]: Good suggestion since "a=fmtp:<format> <format-specific parameters>"
> should not be used in this document, instead, the format-specific parameter
> is incorporated into
>
> a = fmtp: <payload type> encode=<DV-video encoding>;audio ...
>
>
>
>
>
> Also not that the syntax " a=fmtp:<payload type> encode=<DV-video encoding>
> audio=<audio
>
>       bundled>"
>
>
>
> Does not have ";" before the audio while the examples have, I think that ";"
> should separate between the parameters.
>
>
>
>
>
> [Qin]: Good catch, also I notice this rule has already been defined in the
> 3rd bullet in the section 3.2.1. However the example didn't follow this.
>
>
>
>
>
> 5.  Section 3.2.1
>
> "
>
>    The required parameter <DV-video encoding> specifies which type of DV
>    format is used.  The DV format name will be one of the following:
>
>
>
>       SD-VCR/525-60
>
>       SD-VCR/625-50
>       HD-VCR/1125-60
>       HD-VCR/1250-50
>       SDL-VCR/525-60
>       SDL-VCR/625-50
>       314M-25/525-60
>       314M-25/625-50
>       314M-50/525-60
>       314M-50/625-50
>       370M/1080-60i
>       370M/1080-50i
>       370M/720-60p
>       370M/720-50p
>       306M/525-60 (for backward compatibility)
>       306M/625-50 (for backward compatibility)
>
> "
>
> [Qin]: Why you need to repeat the same text in the section 3.1, why not just
> simply reference it described in the section 3.1.
>
>
>
> Roni: I do not see this as a major issue. It can stay from my point of view.
>
>
>
> [Qin]: Okay, I am fine to keep as it is.
>
>
>
> 6. Section 3.2.1
>
> "
>
>    In order to show whether the audio data is bundled into the DV stream
>    or not, a format specific parameter is defined as below:
>
> "
>
> [Qin]: s/ a format specifc parameter/ a format of specific parameter
>
>
>
> Roni: the current text is OK
>
>
>
> [Qin]:  agree, I realized the format specific paramter defined in the old
> version RFC3189 has been merged as one paramter
>
> into
>
> "
>
> a = fmtp: <payload type> encode=<DV-video encoding>;audio ...
>
> "
>
>
>
>
>
> 7. Section 3.2.1
>
> "   The optional parameter <audio bundled> will be one of the following:
>
> "
>
>  [Qin] s/one of the following/one of the following value.
> One question is:
> How do you distinguish between required parameter or optional parameter in
> the a=fmtp line?
>
>
>
> Roni: This is why a ";" should separate between parameters. If audio does
> not exist the default is none
>
>
>
> [Qin]: Good justification, I agree.
>
>
>
> 8. Section 3.2.2
>
> "
>
> 3.2.2.  Usage with the SDP Offer/Answer Model
>
>
>
>    The following considerations apply when using SDP offer-answer
>    procedures [RFC3264] to negotiate the use of DV payload in RTP:
>
>
>
>    o  The "encode" parameter can be used for sendrecv, sendonly and
>       recvonly streams.  Each encode type MUST use a separate payload
>       type number.
>
> "
> [Qin]: When you are talking about encode, you are using "encoding
> type","DV-video encoding", "type of DV format" in the section 3.2,
> and using "encode type" in section 3.2.2, should they be the same thing? why
> not use the same terminology for consistency?
>
>
>
> Roni: The only issue I see is in
>
> "The required parameter <DV-video encoding>" which should be "The required
> parameter "encode""
>
>
>
>
>
> [Qin]:I think that is a big mistake that need to be fixed. Since sendonly,
> recvonly are usually defined in SDP as independent attribute,
>
> I don't why they should define a parameter encode like  "a = sendonly or a
> =recvonly" ?
>
> Also I think it is necessary to unify the terminology to avoid confusion.
>
>
>
>
>
> 9. Section 3.2.2
>
> "
>
>    In an offer for unbundled streams, in order to associate the related
>    audio and video, the group attribute as defined in the Session
>    Description Protocol (SDP) Grouping Framework [RFC5888] can be used.
>
>
>
> "
>
> [Qin]: Does it worth a exmaple to expain how SDP Grouping Framework can be
> used to correlate audio with video data in the section 3.3.1?
>
>
>
> Roni: I think that there is example in RFC 5888, so I will leave it to the
> authors.
>
>
>
> [Qin]: Okay.
>
>
>
> 10. Section 3.3.1
>
> "
>
>    When this is done, SDP carries several m=?? lines, one for each media
>
>    type of the session (see RFC 4566).
>
> "
>  [Qin]: What do you mean "when this is done"? It is not clear to me from the
> context.
>
> Roni: to me it looks like if what is said in the previous sentence.
>
>
>
> [Qin]: This is not a big issue, but at the first sight, it is not clear to
> me. Also I realize the text
>
> comes from the old version RFC3189.
>
>
>
> Regards!
>
> -Qin
>
> ----- Original Message -----
>
> From: "The IESG" <[e-mail]>
>
> To: "IETF-Announce" <[e-mail]>
>
> Cc: [e-mail]
>
> Sent: Monday, September 12, 2011 12:24:16 -0700
>
> Subject: [Payload] Last Call: <draft-ietf-payload-rfc3189bis-02.txt>
> (DiameterBase Protocol) to Proposed Standard
>
> The IESG has received a request from the Audio/Video Transport Payloads
>
> WG (payload) to consider the following document:
>
> - 'RTP Payload Format for DV (IEC 61834) Video'
>
>   <draft-ietf-payload-rfc3189bis-02.txt> as a Proposed Standard
>
>
>
> The IESG plans to make a decision in the next few weeks, and solicits
>
> final comments on this action. Please send substantive comments to the
>
> ietf at ietf.org mailing lists by 2011-09-26. Exceptionally, comments may be
>
> sent to iesg at ietf.org instead. In either case, please retain the
>
> beginning of the Subject line to allow automated sorting.
>
>
>
> Abstract
>
>
>
>
>
>    This document specifies the packetization scheme for encapsulating
>
>    the compressed digital video data streams commonly known as "DV" into
>
>    a payload format for the Real-Time Transport Protocol (RTP).  This
>
>    document obsoletes RFC 3189.
>
>
>
>
>
>
>
>
>
> The file can be obtained via
>
> http://datatracker.ietf.org/doc/draft-ietf-payload-rfc3189bis/
>
>
>
> IESG discussion can be tracked via
>
> http://datatracker.ietf.org/doc/draft-ietf-payload-rfc3189bis/
>
>
>
>
>
> No IPR declarations have been submitted directly on this I-D.