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

From: Qin Wu <[email-masked]>
Date: Tue, 20 Sep 2011 14:16:25 +0800

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.

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.

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?

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.

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.

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

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?

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?

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?

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.

Regards!
-Qin
----- Original Message ----- 
From: "The IESG" <[email-masked]>To: "IETF-Announce" <[email-masked]>Cc: [email-masked]: Monday, September 12, 2011 12:24:16 -0700Subject: [Payload] Last Call: <draft-ietf-payload-rfc3189bis-02.txt> (DiameterBase Protocol) to Proposed StandardThe 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.

---

From: Roni Even <[email-masked]>
Date: Mon, 26 Sep 2011 21:53:14 +0300

Hi Qin,

Thanks for the review see inline

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Qin Wu
Sent: Tuesday, September 20, 2011 9:16 AM
To: [email-masked]
Cc: [email-masked]
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.

2. Section 3.1.1

"

   Type name:  video

   Subtype name:  DV

   Required parameters:

"

[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"

3. Section 3.1.1

"

   Optional parameters:

   Encoding considerations:

   Security considerations:

"

 [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

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

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.

5.  Section 3.2.1

"

      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

"

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

6. Section 3.2.1

"

"

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?

Roni: This is why a ";" should separate between parameters. If audio does
not exist the default is none

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

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.

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.

Regards!

-Qin

----- Original Message ----- 

From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: [email-masked]
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

Abstract

 
 
The file can be obtained via
 <http://datatracker.ietf.org/doc/draft-ietf-payload-rfc3189bis/>
http://datatracker.ietf.org/doc/draft-ietf-payload-rfc3189bis/
 
IESG discussion can be tracked via
 <http://datatracker.ietf.org/doc/draft-ietf-payload-rfc3189bis/>
http://datatracker.ietf.org/doc/draft-ietf-payload-rfc3189bis/

---

From: Qin Wu <[email-masked]>
Date: Tue, 27 Sep 2011 11:52:13 +0800

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' ; [email-masked] 
  Cc: [email-masked] ; 'Kazuhiro Mishima' ; [email-masked] ; '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,

  Roni

  From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
  Sent: Tuesday, September 20, 2011 9:16 AM
  To: [email-masked]
  Cc: [email-masked]
  Subject: Re: [payload] [Payload] Last Call: <draft-ietf-payload-rfc3189bis-02.txt> (RTP Payload Format for DV (IEC 61834) Video)) to Proposed Standard

  Hi,

  1. Section 1:

  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

  "

     Type name:  video

     Subtype name:  DV

     Required parameters:

  "

  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:

     Encoding considerations:

     Security considerations:

  "

  [Qin]:  Your proposal Looks good to me.

  4. Section 3.2.1

  "

  "

  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

  "

        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

  "

  [Qin]: Okay, I am fine to keep as it is.

  6. Section 3.2.1

  "

  "

  [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

  "

  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

  "

  "  

  "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

  "

  "

  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

  "

  "

  [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" <[email-masked]>To: "IETF-Announce" <[email-masked]>Cc: [email-masked]: Monday, September 12, 2011 12:24:16 -0700Subject: [Payload] Last Call: <draft-ietf-payload-rfc3189bis-02.txt> (DiameterBase Protocol) to Proposed StandardThe IESG has received a request from the Audio/Video Transport PayloadsWG (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 solicitsfinal comments on this action. Please send substantive comments to theietf at ietf.org mailing lists by 2011-09-26. Exceptionally, comments may besent to iesg at ietf.org instead. In either case, please retain thebeginning 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 payloa
e Transport Protocol (RTP).  This   document obsoletes RFC 3189.    The file can be obtained viahttp://datatracker.ietf.org/doc/draft-ietf-payload-rfc3189bis/ IESG discussion can be tracked viahttp://datatracker.ietf.org/doc/draft-ietf-payload-rfc3189bis/  No IPR declarations have been submitted directly on this I-D.

---

From: Kazuhiro Mishima <[email-masked]>
Date: Wed, 28 Sep 2011 12:24:51 +0900

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 <[email-masked]>:
> Subject: RE: [payload] [Payload] Last Call:
> [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
>
> "
>
> [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
>
> "
>
> [Qin]:  agree, I realized the format specific paramter defined in the old
> version RFC3189 has been merged as one paramter
>
> into
>
> "
>
> [Qin]:I think that is a big mistake that need to be fixed. Since sendonly,
> recvonly are usually defined in SDP as independent attribute,
>