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 Qin, Roni,

Thank you for comments.
I've just updated our draft as draft-ietf-payload-rfc3189bis-03.

See comments in-line please.


> 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.

Now, I keep the section by Roni's comment.

> 2. Section 3.1.1
>
> [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?
>
> 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"

I changed the sentence in 1st bullet of sec.7.

> 3. Section 3.1.1
>
>  [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: Go od, add of this RFC

I added the "Interoperability Consideration" which refers to sec.8.

> 4. Section 3.2.1
>
> [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

This discussion moved to sec.8.

> Also not that the syntax " <
>  span lan
> 0pt;font-family:"Courier New"'>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.

I fixed the syntax.

> 5.  Section 3.2.1
>
> Roni: I do not see this as a major issue. It can stay from my point of view.
>
> 6. Section 3.2.1
>
> [Qin]: s/ a format specifc parameter/ a format of specific parameter
>
> Roni: the current text is OK
>
> 7. Section 3.2.1
>
>  [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?
>
> 8. Section 3.2.2
>
> [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""

I changed it.

> 9. Section 3.2.2"
>
> [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.

I mentioned about this example.

> 10. Section 3.3.1
>
>  [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.

I changed it as more clearly.