Re: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07

[Chung Cheung Chu <[e-mail]>]

Hi Robert,

Regarding the comment below relating to a text from Ericsson, I agree that the proposed change does improve the readability of the sentence.  Thank you.  However, I notice that the word "current" has been suggested to replace "instantaneous". The word "Instantaneous" was chosen deliberately to reflect explicitly the dynamic nature of the encoding capability in a call session.  Unless there is a strong objection, I would counter-propose to keep the use of "instantaneous" instead of "current".

- This sentence from Section 6.1 does not parse well:
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the far end of a
     communication session of the instantaneous local EVRC-NW wideband/
     narrowband encoding capability.
  Would this replacement work?
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the current local EVRC-NW
     wideband/narrowband encoding capability to the far end of a
communication
     session.

Regards,

CC

Chung-Cheung Chu
Ericsson

This Communication is Confidential.  We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer.



________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Robert Sparks
Sent: October-24-12 10:27 AM
To: [e-mail]
Subject: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07

Forwarding this to the correct list.

RjS


-------- Original Message --------
Subject:        AD Review: draft-ietf-avt-rtp-evrc-nw-07
Date:   Tue, 23 Oct 2012 15:15:16 -0500
From:   Robert Sparks <[e-mail]><mailto:[e-mail]>
To:     [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
CC:     Gonzalo Camarillo <[e-mail]><mailto:[e-mail]>



Summary: The document should be revised before IETF LC.

Primary Concern:

- This document needs to point to RFC6562, at least in the security
considerations section and
possibly in section 11. I think the reference needs to be normative.

Minor Concerns and Nits:

- Section 8 refers backto a "mapping" in Section 4, but it's not clear
that there's a mapping there.
I suggest adding a note that ToC values are taken from the value column
in the table of section 4.

- This sentence from Section 6.1 does not parse well:
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the far end of a
     communication session of the instantaneous local EVRC-NW wideband/
     narrowband encoding capability.
  Would this replacement work?
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the current local EVRC-NW
     wideband/narrowband encoding capability to the far end of a
communication
     session.

- in Section 9.1.1:
     When this media type is used in the context of transfer over RTP, the
     RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be
     used.  In all other contexts, the file format defined in Section 8
     SHALL be used.  See Section 6 for details for EVRC-NW.
  It needs to be clearer that you are talking about Section 7 and 6 of
_this_ document.
  I suggest saying "Section 8 of RFCXXXX" and "Section 6 of RFCXXXX"
and add a note
  to the RFC Editor asking them to replace XXXX with the RFC number of
this document.

- Section 5 paragraph 1: Suggest s/in a manner consistent with/as
specified in/