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 <bill.wu@xxxxxxxxxx>: > 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' ; ietf@xxxxxxxx > Cc: payload@xxxxxxxx ; 'Kazuhiro Mishima' ; ikob@xxxxxxxx ; '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: payload-bounces@xxxxxxxx [mailto:payload-bounces@xxxxxxxx] On Behalf > Of Qin Wu > > Sent: Tuesday, September 20, 2011 9:16 AM > To: ietf@xxxxxxxx > Cc: payload@xxxxxxxx > 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" <iesg-secretary@xxxxxxxx> > > To: "IETF-Announce" <ietf-announce@xxxxxxxx> > > Cc: payload@xxxxxxxx > > 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. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf