I think we're done here, the posted -06 version looks fine. In Section 4.1, I might insert an "e.g." before the added references: PT - The assignment of an RTP payload type for the format defined in this memo is outside the scope of this document. The RTP profiles in use currently mandate binding the payload type OLD dynamically for this payload format (see [RFC3550], [RFC4585]). NEW dynamically for this payload format (e.g., see [RFC3550], [RFC4585]). I'll leave whether that's appropriate up to the authors - if so, it can be handled via an RFC Editor Note or during Authors' 48 Hours. Joel - the -06 version is fine wrt the concerns raised in the review, please clear. Thanks, --David > -----Original Message----- > From: Michael Ramalho (mramalho) [ mailto:mramalho at cisco.com] > Sent: Monday, May 11, 2015 9:48 PM > To: Black, David; Ben Campbell > Cc: draft-ietf-payload-g7110 at ietf.org; Joel Jaeggli; 'Paul E. Jones'; > harada.noboru at lab.ntt.co.jp; muthu.arul at gmail.com; lei.miao at huawei.com > Subject: RE: OPS-Dir review of draft-ietf-payload-g7110-05 > > Hi David, > > I was waiting for the all OK from you (to avoid another version number > confusion) before posting any -06 version. I forgot about the part that if no > comments came in that I would re-submit within a week. > > Thanks again for your careful reviews. > > Michael > > -----Original Message----- > From: Black, David [ mailto:david.black at emc.com] > Sent: Monday, May 11, 2015 10:36 AM > To: Michael Ramalho (mramalho); Ben Campbell > Cc: draft-ietf-payload-g7110 at ietf.org; Joel Jaeggli; 'Paul E. Jones'; > harada.noboru at lab.ntt.co.jp; muthu.arul at gmail.com; lei.miao at huawei.com; Black, > David > Subject: RE: OPS-Dir review of draft-ietf-payload-g7110-05 > > Michael, > > I believe the -06 version will be good enough to go to the RFC Editor (perhaps > w/an RFC Editor Note after I check the diff against the -05 version. > > When do you plan to submit the -06 version? > > Thanks, > --David > > > -----Original Message----- > > From: Michael Ramalho (mramalho) [ mailto:mramalho at cisco.com] > > Sent: Friday, April 17, 2015 4:55 PM > > To: Black, David; Ben Campbell > > Cc: draft-ietf-payload-g7110 at ietf.org; Joel Jaeggli; 'Paul E. Jones'; > > harada.noboru at lab.ntt.co.jp; muthu.arul at gmail.com; lei.miao at huawei.com > > Subject: RE: OPS-Dir review of draft-ietf-payload-g7110-05 > > > > David, > > > > Edits accepted. > > > > Attached is the preliminary "06" version in html. > > > > If no additional comments on it come in, I will submit mid-next week > > (with new date). > > > > Best, > > > > Michael > > > > -----Original Message----- > > From: Black, David [ mailto:david.black at emc.com] > > Sent: Friday, April 17, 2015 4:39 PM > > To: Michael Ramalho (mramalho); Ben Campbell > > Cc: draft-ietf-payload-g7110 at ietf.org; Joel Jaeggli; 'Paul E. Jones'; > > harada.noboru at lab.ntt.co.jp; muthu.arul at gmail.com; > > lei.miao at huawei.com; Black, David > > Subject: RE: OPS-Dir review of draft-ietf-payload-g7110-05 > > > > Michael, > > > > > Convergence is good ... added paragraph for [G] accepted ... also > > > accepted is your parenthetical addition for [F]. Thanks. > > > > > > That leaves us with [D]. I have a proposed fix for that below. > > > > That fix works for me, as the last two sentences in the new text > > provide clarity on the concern. > > I have some minor edits to suggest to those two sentences: > > > > > As a packet produced by the compression and decompression as > > > described above is indistinguishable in every detail to the source > > > G.711 packet, such compression can be made invisible to the end system. > > > Specification of how systems on the path between the end systems > > > discover themselves and negotiate the compression to/from G.711.0 as > > > described is outside the scope of this document. > > > > End of 1st sentence: "end system" -> "end systems". > > > > Next to last line: > > OLD > > themselves and negotiate the compression to/from G.711.0 as > > described is NEW > > each other and negotiate the use of G.711.0 compression as described in > > this paragraph is > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Michael Ramalho (mramalho) [ mailto:mramalho at cisco.com] > > > Sent: Friday, April 17, 2015 4:07 PM > > > To: Black, David; Ben Campbell > > > Cc: draft-ietf-payload-g7110 at ietf.org; Joel Jaeggli; 'Paul E. > > > Jones'; harada.noboru at lab.ntt.co.jp; muthu.arul at gmail.com; > > > lei.miao at huawei.com > > > Subject: RE: OPS-Dir review of draft-ietf-payload-g7110-05 > > > > > > David, > > > > > > Convergence is good ... added paragraph for [G] accepted ... also > > > accepted is your parenthetical addition for [F]. Thanks. > > > > > > That leaves us with [D]. I have a proposed fix for that below. > > > > > > As this point goes back a long way in the email archive, let me add > > > some context/history for Ben. > > > > > > Consider the following: > > > > > > 1) End_System_A (abbreviated to A). > > > 2) End_System_Z (abbreviated to Z). > > > 3) End_System_A has negotiated use of G.711 with End_System_Z. > > > > > > Thus we have: > > > > > > A(G.711)<---------------(G.711)------------------>(G.711)Z > > > > > > In a manner similar to lossless header compression (G.711.0 is both > > > stateless and lossless), any system along the path used by A<-->Z > > > may compress and corresponding decompress the payload. Consider as a > > > simple case that this was performed on a LINK somewhere between A > > > and Z (thus both ends of the link know about G.711.0). Call the ends > > > of this link La(facing A direction) and Lb (facing B direction). > > > > > > A(G.711)<---(G.711)--->(G.711/G.711.0)La<--(G.711.0)--->Lb(G.711.0/G > > > .7 > > > 11)< --- (G.711)--->(G.711)Z > > > > > > Thus although the link La<->Lb compressed and decompressed the payload ... > > > that is invisible to the end systems ... as the payloads are just as > > > indistinguishable from the originals as header > > > compression/decompression is for lossless header compression. > > > > > > Note: > > > 1)The end systems negotiated G.711. > > > 2) Unbeknownst to these end systems ... something "between the end > systems" > > > (present text quoted) was used G.711.0 to losslessly compress the > payloads. > > > > > > Thus the statement (presently in the document) is accurate, which is: > > > "G.711.0, being both lossless and stateless, may also be employed as > > > a lossless compression mechanism anywhere between end systems which > > > have negotiated use of G.711." > > > > > > The statement by itself is silent on how these "systems in the middle" > > > negotiated the joint agreement to do the lossless > > > compression/decompression of the payload. This is the point I > > > perceive David desires more clarity on. I note that this section > > > simply quotes ITU-T work and not any interoperability concerns explicitly. > > > > > > I noted in very early comments on this concern that the Payload WG > > > had agreed that if this was to be codified in the IETF that such > > > issue would be documented in a "G.711.0 Use Case" draft. It is for > > > this reason that this use case is not documented more in this > > > G.711.0 RTP Payload > > Format Draft. > > > > > > Nevertheless, I added a sentence (the last one) in the paragraph to > > > make this point (negotiation of intermediate systems) explicitly out > > > of scope for this document. Thus the entire paragraph presently reads: > > > > > > > > > G.711.0, being both lossless and stateless, may also be employed as > > > a lossless compression mechanism for G.711 payloads anywhere between > > > end systems which have negotiated use of G.711. Because the only > > > significance between the G.711 RTP payload format header and the > > > G.711.0 payload format header defined in this document is the > > > payload type, a G.711 RTP packet can be losslessly converted to a > > > G.711.0 RTP packet simply by compressing the G.711 payload (thus > > > creating a > > > G.711.0 payload), changing the payload type to the dynamic value > > > desired and copying all the remaining G.711 RTP header fields into > > > the corresponding G.711.0 RTP header. In a similar manner, the > > > corresponding decompression of the G.711.0 RTP packet thus created > > > back to the original source G.711 RTP packet can be accomplished by > > > losslessly decompressing the > > > G.711.0 payload back to the original source G.711 payload, changing > > > the payload type back to the payload type of the original G.711 RTP > > > packet and copying all the remaining G.711.0 RTP header fields into > > > the corresponding > > > G.711 RTP header. Negotiation specifics for this lossless G.711 > > > payload compression for RTP use case is not in scope for this document. > > > > > > > > > However, we are not adverse to other wording to further clarify the > > > intent. I propose the following (modification of last sentence above > > > with the addition of another one): > > > > > > > > > G.711.0, being both lossless and stateless, may also be employed as > > > a lossless compression mechanism for G.711 payloads anywhere between > > > end systems which have negotiated use of G.711. Because the only > > > significance between the G.711 RTP payload format header and the > > > G.711.0 payload format header defined in this document is the > > > payload type, a G.711 RTP packet can be losslessly converted to a > > > G.711.0 RTP packet simply by compressing the G.711 payload (thus > > > creating a > > > G.711.0 payload), changing the payload type to the dynamic value > > > desired and copying all the remaining G.711 RTP header fields into > > > the corresponding G.711.0 RTP header. In a similar manner, the > > > corresponding decompression of the G.711.0 RTP packet thus created > > > back to the original source G.711 RTP packet can be accomplished by > > > losslessly decompressing the > > > G.711.0 payload back to the original source G.711 payload, changing > > > the payload type back to the payload type of the original G.711 RTP > > > packet and copying all the remaining G.711.0 RTP header fields into > > > the corresponding > > > G.711 RTP header. As a packet produced by the compression and > > > decompression as described above is indistinguishable in every > > > detail to the source G.711 packet, such compression can be made > > > invisible to the > > end system. > > > Specification of how systems on the path between the end systems > > > discover themselves and negotiate the compression to/from G.711.0 as > > > described is outside the scope of this document. > > > > > > > > > Does that work, David? I am open to other ways to address your concern. > > > > > > As this is the first lossless and stateless > > > compression/decompression of a RTP payload ever attempted in an IETF > > > document, I truly appreciate your thoroughness. > > > > > > Michael Ramalho > > > > > > -----Original Message----- > > > From: Black, David [ mailto:david.black at emc.com] > > > Sent: Friday, April 17, 2015 2:27 PM > > > To: Michael Ramalho (mramalho); Ben Campbell > > > Cc: draft-ietf-payload-g7110 at ietf.org; Joel Jaeggli; 'Paul E. > > > Jones'; harada.noboru at lab.ntt.co.jp; muthu.arul at gmail.com; > > > lei.miao at huawei.com; Black, David > > > Subject: RE: OPS-Dir review of draft-ietf-payload-g7110-05 > > > > > > Michael, > > > > > > Thanks for this note - the proposed additional paragraph for [G] > > > will suffice, and I think [F] is now editorial (see below for small > > > change that I would prefer, but that's at your discretion). > > > > > > That leaves [D] where we seem to be talking past each other - I > > > understand that the wording that I initially suggested is > > > unacceptable, so I'm looking to the authors to suggest alternative > > > wording that addresses the interoperability concern. While I > > > appreciate the attempts to explain that there can't be an > > > interoperability > > problem here, I remain unconvinced. > > > > > > Towards that end, let start over and explain what's bothering me: > > > > > > > *********Issue [D]:************* > > > > > > > > > [D] Backwards compatibility. > > > > > > > > > > The problem here is that it's not clear that negotiation (e.g., > > > > > via > > > > > SDP) is required. This sentence in Section 3.1 is a particular > problem: > > > > > > > > > > G.711.0, being both lossless and stateless, may also be employed as > a > > > > > lossless compression mechanism anywhere between end systems which > > > > > have negotiated use of G.711. > > > > > > > > > > That's definitely wrong. Use of G.711.0 when only G.711 has > > > > > been negotiated will fail to interoperate correctly. > > > > > > > > > > First of all, please ignore the word "negotiation" in my original > > > comment > > > - there are other ways to address this interoperability concern. > > > > > > I read the original sentence quoted from the draft as allowing an > > > encoding node (which might be an inline transcoder as opposed to an > > > end system) to switch from the native G.711 format to the G.711.0 > > > compression format without any negotiation, notice, coordination, etc. > > > with/to the decoding node (which may or may not also be an inline > > transcoder). That will fail to interoperate. > > > > > > I'm looking for wording to say that both the encoding and decoding > > > nodes have to understand that G.711.0 is being used instead of G.711. > > > I don't care how the negotiation, notice, coordination, etc. is done > > > to accomplish that (e.g., static configuration should suffice), just > > > that the necessity of doing something be pointed out. If the > > > original sentence quoted above cannot be changed, then an additional > > > sentence to make > > this point would be fine. > > > > > > Turning to [F], this is editorial (i.e., doing nothing here will be > > > ok with me), although the current suggested change is simple: > > > > > > > *****Issue [F]: (David says not a critical issue)****** > > > > > [F] Section 4.1: > > > > > > > > > > PT - The assignment of an RTP payload type for the format > defined > > > > > in this memo is outside the scope of this document. The RTP > > > > > profiles in use currently mandate binding the payload type > > > > > dynamically for this payload format. > > > > > > My concern here is that "The RTP profiles in use" is somewhat vague. > > > > > > Here's my latest suggested change: > > > > > > > It'll suffice to add citations to two examples that are already > > > > referenced by this draft, i.e., at the end of the above paragraph > > > > on PT add > > > the following: > > > > > > > > (e.g., see RFC 3551 [RFC3551], RFC 4585 [RFC4585]) > > > > > > I think that change will help readers, but this is editorial and so > > > I can live with no change being made here. > > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Michael Ramalho (mramalho) [ mailto:mramalho at cisco.com] > > > > Sent: Friday, April 17, 2015 11:26 AM > > > > To: Black, David; Ben Campbell > > > > Cc: draft-ietf-payload-g7110 at ietf.org; Joel Jaeggli; 'Paul E. > > > > Jones'; harada.noboru at lab.ntt.co.jp; muthu.arul at gmail.com; > > > > lei.miao at huawei.com > > > > Subject: RE: OPS-Dir review of draft-ietf-payload-g7110-05 > > > > > > > > David/Ben, > > > > > > > > Again, thanks to David for his through reviews (and to others who > > > > have commented and added valuable input/clarity to post last WG > > > > call of this draft). > > > > > > > > This email addresses David's remaining points as of his April 16, > > > > 2015 email below (issues {[D] & [G]} and [F]). > > > > > > > > All these issues ({[D] & [G]} and [F]) were addressed in my March > > > > 20, > > > > 2015 reply to David; however I have repeated them below for > > > > context and ease of assimilation for Ben Campbell. > > > > > > > > I have also attached the html version of the 05 draft, for simple > > > > comparison of the points made in this email as well. > > > > > > > > The net result is a proposed new paragraph to explicitly address > > > > the "framing errors" issue of item [G] (see below). > > > > > > > > Best Regards, > > > > > > > > Michael Ramalho, Ph.D. > > > > > > > > *********Issue [D]:************* > > > > > > > > > [D] Backwards compatibility. > > > > > > > > > > The problem here is that it's not clear that negotiation (e.g., > > > > > via > > > > > SDP) is required. This sentence in Section 3.1 is a particular > problem: > > > > > > > > > > G.711.0, being both lossless and stateless, may also be employed as > a > > > > > lossless compression mechanism anywhere between end systems which > > > > > have negotiated use of G.711. > > > > > > > > > > That's definitely wrong. Use of G.711.0 when only G.711 has > > > > > been negotiated will fail to interoperate correctly. > > > > > > > > > > > > > > > > OLD > > > > G.711.0, being both lossless and stateless, may also be employed as a > > > > lossless compression mechanism for G.711 payloads anywhere between > > > > end systems which have negotiated use of G.711. > > > > NEW > > > > G.711.0, being both lossless and stateless, may also be employed as a > > > > lossless compression mechanism for G.711 payloads anywhere between > > > > end systems that support use of G.711. > > > > > > > > Then the added sentence on negotiation being out of scope (end of > > > > paragraph that begins with that problematic sentence) makes more sense. > > > > > > > > > > > > > > > > G7110: Again, we never say how "the end systems that negotiated G.711" > > > > actually NEGOTIATED use of G.711 - as this negotiation is out of > > > > scope of this payload description document (and any RTP payload > > > > document for that > > > matter). > > > > We are PURPOSELY SILENT on how G.711 is negotiated because > > > > virtually all payload format definitions for voice codecs are also > > > > silent on this > > > point. > > > > > > > > G7110: As we addressed in our previous email reply, any > > > > negotiation protocol may be used (e.g., javascript between the > > > > endpoints, SDP, H.323). The only reason why SDP parameters are in > > > > this document is that if SDP is used, then we need to specify > > > > those parameters (as all IETF RTP payload formats do). The mere > > > > specification of those SDP parameters in this payload format does not > imply SDP must be used. > > > > Again, this is just like any other IETF RTP payload format definition. > > > > Thus (to my knowledge) SDP is never required to be the negotiation > > > > means for any IETF RTP payload format. Thus SDP is not mandated > > > > (or > > > > assumed) > > > to be the negotiation mechanism. > > > > > > > > G7110: "Support" is also problematic because a system that > > > > "supports > > G.711" > > > > does not necessarily imply that G.711 is presently in use (i.e., > > > > negotiated for the session) - which is what this sentence needs. > > > > So the suggested fix of using the word "support" doesn't work. > > > > > > > > G7110: Lastly, as addressed in previous commentary, this section > > > > is entirely background about "General Information for the ITU-T > > > > G.711.0 Codec". It would be inappropriate to talk about IETF > > > > negotiation means in a section devoted to a summary of ITU-T > > > > information. This section IMHO must be silent on IETF means of > > > > negotiation, as the ITU-T does not define SDP use or specify negotiation > means of other SDOs. > > > > > > > > G7110: Summary. The ITU-T spec allows for the case that G.711 was > > > > negotiated between endpoints and that compression (when > > > > IETF-specified IP/UDP/RTP is in use for the media) is desired. > > > > This sentence must stay as it is - the IETF cannot change the > > > > intent or desires > > of another SDO. > > > > > > > > > > > > AUTHORS END POSITION ON [D]: As per my last paragraph above, this > > > > sentence IMHO must remain as it is (must use the word negotiated - > > > > and be silent on how > > > > G.711.0 is negotiated). The IETF Payload Format document ought not > > > > to > > > > re- intention a past design intent/goal of the ITU-T captured in > > > > the text of Section 3.1. Roni (Payload chair) knows this history > > > > as he was present in the ITU-T when G.711.0 was defined. > > > > > > > > *********Issue [G]:************* > > > > > > > > > [G] Framing errors > > > > > > > > > > Section 4 generally assumes that the G.711.0 decoder gets handed > > > > > frames generated by the G.711.0 encoder and can't get disaligned. > > > > > I'm not convinced that this "just works" based on the text in > > > > > the draft - major issue [B] is a significant reason why, and > > > > > explaining that should > > > > help. > > > > > > > > > > > > SIDE NOTE: This comment of David's led to very significant wording > > > > added in the paragraphs following the decoding process. It also > > > > led to comments by others on other potential error conditions. > > > > These were addressed in the last three paragraphs in Section > > > > 4.2.3, such > > > > as: 1) A MUST to discard a decode known to contain an incorrect > > > > number of G.711 source symbols, and 2) text addressing buffer > > > > overrun risk (there is no such risk because decoder output buffer > > > > is > > bounded). > > > > > > > > The issue of framing errors came up in the context of G.711.0 > > > > payload decoding. These were related to the "prefix code" thread. > > > > David accurately captured those in an email he wrote recently: > > > > > > > > > > > > "If strict architectural separation were being followed, this IETF > > > > draft would not mention the G.711.0 prefix code, as that's part of > > > > the > > > > G.711.0 codec's encoding output, and the usual practice for IETF > > > > payload drafts (as I understand it) is to treat that output as > > > > opaque wrt > > > the RTP payload format. > > > > > > > > This draft doesn't completely do that, as the "prefix code" is > > > > produced by the codec, and it is integral to the RTP aspects of > > > > the decoding process for what appear to be a couple of reasons: > > > > > > > > - Explanation of how frame concatenation in a single RTP payload > > > > works and why it's ok (codec uses prefix code to determine > > > > frame length). > > > > - Explanation of why 0x00 is safe to use as a padding value in > > > > the RTP payload without adding any RTP information on > padding > > > > (codec ignores 0x00 values of prefix code when decoding). > > > > > > > > I think those are reasonable design decisions, even if they don't > > > > exhibit complete architectural separation of RTP and the codec, > > > > and I currently don't have any prefix-code-related issues with the > > > > text in the -05 version of this > > > > draft: " > > > > > > > > > > > > AUTHORS END POSITION ON [G]: > > > > 1: The draft is silent on framing issues, per se. > > > > 2: But it now (thanks to David, Richard and others who commented > > > > on overrun > > > > issues) has text on what to do when a KNOWN ERRONEOUS lossless > > > > decoding from > > > > G.711.0 to G.711 occurred (and that is a MUST discard). > > > > 3: And it also discusses the "different than expected output" > > > > (larger or > > > > smaller) that can occur with ANY CODEC that has a decoding problem > > > > due to frame error (i.e., the frame given to it isn't as expected > > > > by the > > > decoder). > > > > However: > > > > 4: If we think a paragraph is needed to explicitly call out the > > > > potential frame errors issue, I could add the following (or > > > > something like it) immediately before Section 4.2.4: > > > > > > > > PROPOSED NEW PARAGRAPH (second paragraph above Section 4.2.4): > > > > We explicitly note that a framing error condition will result > > > > whenever the buffer sent to a G.711.0 decoder does not begin with > > > > a valid first > > > > G.711.0 frame octet (i.e., a valid G.711.0 prefix code or a 0x00 > > > > padding octet). The expected result is that the decoder will not > > > > produce the desired/correct G.711 source symbols. However, as > > > > already noted, the output returned by the G.711.0 decoder will be > > > > bounded (to less than 321 octets per G.711.0 decode request) and > > > > if the number of the (presumed) G.711 symbols produced is known to > > > > be in error, the decoded > > > output MUST be discarded. > > > > > > > > *****Issue [F]: (David says not a critical issue)****** > > > > > [F] Section 4.1: > > > > > > > > > > PT - The assignment of an RTP payload type for the format > defined > > > > > in this memo is outside the scope of this document. The RTP > > > > > profiles in use currently mandate binding the payload type > > > > > dynamically for this payload format. > > > > > > > > > > Good start, but not sufficient - cite the "RTP profiles > > > > > currently in use" and I would expect those citations to be normative > references. > > > > > > > > Not done. Just listing those profiles with RFC citations will suffice. > > > > > > > > > > > > > > > > G7110: Firstly, it is hard, if not close to impossible, to list > > > > all the RFC citations (given how the payload type definitions grew > > > > over time AND the special rules for when "static types" - if not > > > > presently in use - can be used for "dynamic assignment"). > > > > Secondly, no other IETF Payload Format has such a listing (likely > > > > for similar > > reasons). > > > > Thirdly (and as described earlier), this wording was requested > > > > from the WG and was provided to us (and other payload format > > > > authors). I requested updates for this wording based on your > > > > previous review and it was stated that this text was the > > > > boilerplate text being used at present. It is our view that > > > > changes to this wording must come from the > > > PAYLOAD WG. > > > > > > > > > > > > AUTHORS END POSITION ON [D]: > > > > 1) Our position remains that ANY changes to the wording on the PT > > > > come from the PAYLOAD WG Chars (as the precise wording above came > > > > from > > them). > > > > 2) We have no objection to changing the wording to anything the > > > > PAYLOAD WG chairs (or ADs/IESG/etc.) desire. > > > > 3) Lastly, if the PAYLOAD WG chairs desire to provide an example > > > > reference that David would like to see (presumably on how an > > > > assignment may be made, I am not sure), we will be happy to > > > > accommodate such a reference on a revised draft. > > > > > > > > -----Original Message----- > > > > From: Black, David [ mailto:david.black at emc.com] > > > > Sent: Thursday, April 16, 2015 7:22 PM > > > > To: Ben Campbell > > > > Cc: draft-ietf-payload-g7110 at ietf.org; Joel Jaeggli; Black, David > > > > Subject: FW: OPS-Dir review of draft-ietf-payload-g7110-05 > > > > > > > > Hi Ben, > > > > > > > > You asked: > > > > > > > > > Can anyone summarize where we stand with this for the new AD > > > > > (me.) > > > > > > > > Sure ... the latest status email on this review is below. Summary: > > > > > > > > (1) The serious issues related to the prefix code ([A] & [B]) have been > > > > addressed by text in the -05 draft. Nothing new has come up in > > > > this area in subsequent emails. > > > > > > > > (2) There are two issues below ([D] and [G]) for which the authors > should > > > > propose text. A sentence or two for each issue should suffice. > > > > > > > > (3) I'd like to see a couple of citations of existing references added > > > > for [F], but that is not crucial. > > > > > > > > Thanks, > > > > --David > > > > > > > > -----Original Message----- > > > > From: Black, David > > > > Sent: Wednesday, March 25, 2015 10:35 PM > > > > To: Michael Ramalho (mramalho); Paul E. Jones > > > > (paulej at packetizer.com); harada.noboru at lab.ntt.co.jp; > > > > muthu.arul at gmail.com; lei.miao at huawei.com; ops- dir at ietf.org > > > > Cc: Ali C. Begen (abegen); roni.even at mail01.huawei.com; Black, > > > > David > > > > Subject: OPS-Dir review of draft-ietf-payload-g7110-05 > > > > > > > > Authors, > > > > > > > > Thank you for the response and -05 revision. This is progress > > > > towards addressing the review concerns. > > > > > > > > Here's a summary of where things stand on the 6 open concerns from > > > > the review of the -04 version: > > > > > > > > [A] & [B]: Resolved in -05. > > > > - The added text in 4.2.2.1 and 3.3 on "prefix code" is sufficient > > > > explanation. > > > > - The use of "convey" in 3.3 is now clear based on the text added there. > > > > - I've moved the concern about invalid "prefix code" values to [G], but > it > > > > does need attention. > > > > > > > > [C]: Ok in -05. The text in -05 is good enough for me. I would > > > > have written it differently, but that's an editorial concern. > > > > > > > > [D]: OPEN - The authors need to propose text, as the current text > > > > has an interoperability problem. > > > > > > > > [F]: Should be simple to resolve - see text proposed below. > > > > > > > > [G] OPEN - Authors should propose text, as they've offered to do. > > > > > > > > [D] and [G] are the major remaining concerns. > > > > > > > > -- [D] Backwards compatibility -- > > > > > > > > I'm still looking for a useful response to this text from the > > > > original > > > > review: > > > > > > > > > This sentence in Section 3.1 is a particular problem: > > > > > > > > > > G.711.0, being both lossless and stateless, may also be employed as > a > > > > > lossless compression mechanism anywhere between end systems which > > > > > have negotiated use of G.711. > > > > > > > > > > That's definitely wrong. Use of G.711.0 when only G.711 has > > > > > been negotiated will fail to interoperate correctly. > > > > > > > > I suggested changing "have negotiated" to "support," and the authors' > > > > response was a long explanation that appears to state that the > > > > ITU-T forbidding the IETF from using the word "support" in that fashion. > > > > If correct, that fails to address the actual problem with the text. > > > > > > > > I leave it to the authors to suggest text that will both > > > > interoperate and not offend the ITU-T; I might suggest adding an > > > > additional sentence to explain that both the encapsulator and > > > > decapsulator have to agree on use of G.711.0 for it to work. > > > > > > > > Lack of interoperability is a significant IETF concern that cannot > > > > be addressed by claiming that the ITU-T is a higher authority. > > > > > > > > -- [F] Section 4.1: -- > > > > > > > > > > > > PT - The assignment of an RTP payload type for the > > > > > > format > > defined > > > > > > in this memo is outside the scope of this document. The RTP > > > > > > profiles in use currently mandate binding the payload type > > > > > > dynamically for this payload format. > > > > > > > > > > > > Good start, but not sufficient - cite the "RTP profiles > > > > > > currently in use" and I would expect those citations to be > > > > > > normative > > references. > > > > > > > > > > Not done. Just listing those profiles with RFC citations will > suffice. > > > > > > > > It'll suffice to add citations to two examples that are already > > > > referenced by this draft, i.e., at the end of the above paragraph > > > > on PT add > > > the following: > > > > > > > > (e.g., see RFC 3551 [RFC3551], RFC 4585 [RFC4585]) > > > > > > > > Ok? > > > > > > > > -- [G] Framing errors -- > > > > > > > > > > > > Section 4 generally assumes that the G.711.0 decoder gets > > > > > > handed frames generated by the G.711.0 encoder and can't get > disaligned. > > > > > > I'm not convinced that this "just works" based on the text in > > > > > > the draft - major issue [B] is a significant reason why, and > > > > > > explaining that should > > > > > help. > > > > > > > > > > Not done - the concern here is what happens when the decoder > > > > > reads a > > > > > G.711.0 payload octet (encoded from G.711 symbols) as a "Prefix Code" > > > > > octet? I think resolving [B] will address most of this, > > > > > especially if that results in a "Not a valid Prefix Code value" error. > > > > > > > > > > G7110: We can add a sentence on this point, although it is > > > > > already addressed in a hidden way. Let me explain. > > > > > > > > That explanation took 5 paragraphs, and is subtle in a number of ways. > > > > I prefer to accept the authors' offer to add a clear single > > > > sentence on this point, including text on why bounding of garbage > > > > decoding results avoids problems here. > > > > > > > > As part of this, there's a lingering concern from [B] that needs > > > > to be addressed - if there are invalid values of the prefix code > > > > octet, the behavior of the decoder on such values needs to be > > > > specified as part of step H5, otherwise, section 3.3 needs > > > > additional text to state that all values of the prefix code octet are > valid. > > > > > > > > The latter concern is a technical flaw (omission) in this draft. > > > > > > > > Thanks, > > > > --David > > > > > > > > > > > > > -----Original Message----- > > > > > From: Michael Ramalho (mramalho) [ mailto:mramalho at cisco.com] > > > > > Sent: Friday, March 20, 2015 4:15 PM > > > > > To: Black, David; Paul E. Jones (paulej at packetizer.com); > > > > > harada.noboru at lab.ntt.co.jp; muthu.arul at gmail.com; > > > > > lei.miao at huawei.com; ops- dir at ietf.org > > > > > Cc: Ali C. Begen (abegen); roni.even at mail01.huawei.com > > > > > Subject: RE: OPS-Dir review of draft-ietf-payload-g7110-04 > > > > > > > > > > David, > > > > > > > > > > Comments are in-line below with "G7110:". > > > > > > > > > > Thank you again for your through review; it is appreciated. > > > > > > > > > > I have created an "05" version of this draft (see attached) , > > > > > although I cannot submit it until after the Sunday deadline for > > > > > new > > > drafts. > > > > > > > > > > Regards, > > > > > > > > > > Michael Ramalho > > > > > > > > > > -----Original Message----- > > > > > From: Black, David [ mailto:david.black at emc.com] > > > > > Sent: Wednesday, December 24, 2014 12:42 AM > > > > > To: Michael Ramalho (mramalho); Paul E. Jones > > > > > (paulej at packetizer.com); harada.noboru at lab.ntt.co.jp; > > > > > muthu.arul at gmail.com; lei.miao at huawei.com; ops- dir at ietf.org > > > > > Cc: payload at ietf.org; Black, David > > > > > Subject: OPS-Dir review of draft-ietf-payload-g7110-04 > > > > > > > > > > The -04 version of this draft is an improvement, but does not > > > > > resolve all the issues from the Gen-ART and OPS-Dir review of > > > > > the > > > > > -03 > > > version. > > > > > This is now reduced to an OPS-Dir review (and email > > > > > distribution), as Joel's holding the relevant "Discuss" > > > > > position. > > > > > > > > > > The following issues are still open: > > > > > > > > > > -- Major -- (these four are all now minor issues in -04) > > > > > > > > > > > [A] Section 4.2.3 specifies a detailed decoding algorithm > > > > > > covering how > > > > > > G.711.0 decompression interacts with received RTP G.711.0 payloads. > > > > > > A corresponding encoding algorithm specification is needed on > > > > > > the sending side for G.711.0 compression interaction with RTP > sending. > > > > > > The algorithm will have some decision points in it that cannot > > > > > > be fully specified, e.g., time coverage of the generated > > > > > > G.711.0 > > frames. > > > > > > > > > > Section 4.2.2.1 does most of this. It needs to include > > > > > generation of the "Prefix Code" octet that is described in Section > 3.3. > > > > > > > > > > G7110: The authors disagree; the readers need not know about the > > > > > "prefix > > > > code" > > > > > until the very next section after 4.2.2.1 (which is 4.2.3) where > > > > > it is needed for actually decoding the frames. > > > > > > > > > > G7110: However we are not adverse to adding the following > > > > > sentence in Section > > > > > 4.2.2.1 (or anything similar - I have included it in the "05" > version): > > > > > > > > > > [... and any of these combinations would decompress into the > > > > > same source > > > > > 160 G.711 octets.] > > > > > As an aside, we note that the first octet of any G.711.0 frame > > > > > will be the prefix code octet > > > > > and information in this octet determines how many G.711 symbols > > are > > > > > represented in the G.711.0 frame. > > > > > > > > > > G7110: We will defer to input from the editor on this point > > > > > (whether or not to delete it from the new "05" version). > > > > > > > > > > > [B] The G.711.0 frame format is not specified here, making it > > > > > > very difficult to figure out what's going on when G.711.0 > > > > > > frames are concatenated. A specific example is that the > > > > > > concept of a "prefix code" that occurs at the start of a > > > > > > G.711.0 frame is far too important to be hidden in step H5 of > > > > > > the decoding algorithm in Section > > > > 4.2.3. > > > > > > > > > > This is mostly done in Section 3.3, but is a bit unclear: > > > > > > > > > > The first octet of a G.711.0 frame is called the > > > > > "Prefix Code" octet; the value of this octet conveys how many G.711 > > > > > symbols the decoder is to create from a given G.711.0 input frame. > > > > > The Prefix Code value of 0x00 is used to denote zero G.711 source > > > > > symbols, which allows the use of 0x00 as a payload padding octet > (to > > > > > be described later). > > > > > > > > > > The word "conveys" is problematic, as the "Prefix Code" octet > > > > > cannot contain the number of G.711 symbols, as that number could > > > > > be 320, which is larger than 255. I'm guessing that the "Prefix Code" > > > > > is an encoded value - if so, here's some suggested text: > > > > > > > > > > OLD > > > > > the value of this octet conveys how many G.711 > > > > > symbols the decoder is to create from a given G.711.0 input frame. > > > > > NEW (fill in value of 0xNN below) > > > > > the encoded value in this octet indicates how many G.711 > > > > > symbols the decoder is to create from a given G.711.0 input frame > > > > > (e.g., the value 0xNN indicates that 320 G.711 symbols are > expected). > > > > > > > > > > If there are invalid values of the "Prefix Code" octet, that > > > > > will affect step > > > > > H5 in Section 4.2.3 where finding an invalid value should cause > > > > > decoding to stop. > > > > > > > > > > G7110: The authors do not agree that "conveys" is problematic, > > > > > as the prefix code only needs information within it to convey > > > > > the SIX possible lengths of the G.711 input frames (0, 40, 80, > > > > > 160, 240 and 320). We never stated nor implied the length of the > > > > > G.711 input frame was encoded in the prefix code in > > > > > unit8 format. Indeed, the prefix code can AND DOES convey MORE > > > > > information than just the length of the input frame (for certain > > > > > frame lengths). The interested reader is free to read the ITU-T > > > > > standard if they are interested in what else the prefix code > > > > > conveys. As we also have instruction from the IESG not to > > > > > include information that is not required in the payload format > > > > > (e.g., Richard's comments), we decline to specify further. > > > > > However, the authors > > > are OK with the following change: > > > > > > > > > > G7110: > > > > > NEW: > > > > > The first octet of a G.711.0 frame is called the > > > > > "Prefix Code" octet; the information within this octet > > > > > conveys how many > > > > > G.711 > > > > > symbols the decoder is to create from a given G.711.0 input frame > > > > > (i.e., 0, 40, 80, 160, 240 or 320). The Prefix Code value of > > > > > 0x00 is used to denote > > > > > zero G.711 source symbols, which allows the use of 0x00 as a > > > > > payload padding octet (to > > > > > be described later in Section 3.3.1). > > > > > > > > > > G7110: [Aside for David: The issue of invalid prefix codes is > > > > > deferred until we address your issue of framing errors later in > > > > > this email (and later in the draft).] > > > > > > > > > > > [C] The discussion of use of the SDP ptime parameter is spread > > > > > > out and imprecise (is SDP REQUIRED?, when is ptime REQUIRED, > > > > > > RECOMMENDED, or recommended? - it's not obvious). > > > > > > > > > > > [... snip ...] > > > > > > > > > > > > I would suggest that a subsection be added, possibly at the > > > > > > end of Section 3, to gather/summarize all of the relevant > > > > > > ptime discussion in one place. I suspect that the contents of > > > > > > this draft are mostly correct wrt ptime, but it's hard to > > > > > > figure out what's going on from the current spread-out text. > > > > > > > > > > Not done, although the sentence added (for [D]) on negotiation > > > > > being out of scope helps. The first mention of "ptime" is in A4 > > > > > in Section 3.2, with effectively no explanation of what ptime is: > > > > > > > > > > A G.711.0 decoder need not > > > > > know what ptime is, as it is able to decompress the G.711.0 > > > > > frame presented to it without signaling knowledge. > > > > > > > > > > A definition would help - somewhere before that first use of > > > > > ptime, define "ptime" using the words from RFC 4566: > > > > > > > > > > ptime: length of time in milliseconds represented by > > > > > the media in a packet. This is an attribute that can > > > > > be signaled via SDP [RFC 4566]. > > > > > > > > > > G7110: You are correct. We defined ptime the first time it was > > > > > used outside of a parenthetical - which was the very next paragraph. > > > > > > > > > > G7110: I have fixed this with the text below in the paragraph > > > > > you refer (and deleted the reference in the subsequent paragraph): > > > > > A G.711.0 decoder need not know how > > > > > many symbols are contained in the original G.711 frame > > > (e.g., > > > > > parameter ptime in Session Description Protocol, SDP, > > > > > [RFC4566]), as it is able to decompress the G.711.0 frame > > > > > presented to it without signaling knowledge. > > > > > > > > > > > [D] Backwards compatibility. > > > > > > > > > > > > The problem here is that it's not clear that negotiation > > > > > > (e.g., via > > > > > > SDP) is required. This sentence in Section 3.1 is a > > > > > > particular > > problem: > > > > > > > > > > > > G.711.0, being both lossless and stateless, may also be > > > > > > employed as > > a > > > > > > lossless compression mechanism anywhere between end systems which > > > > > > have negotiated use of G.711. > > > > > > > > > > > > That's definitely wrong. Use of G.711.0 when only G.711 has > > > > > > been negotiated will fail to interoperate correctly. > > > > > > > > > > That problematic sentence is still there - I suggest a minor > > > > > change to remove the word "negotiated": > > > > > > > > > > OLD > > > > > G.711.0, being both lossless and stateless, may also be employed as > a > > > > > lossless compression mechanism for G.711 payloads anywhere between > > > > > end systems which have negotiated use of G.711. > > > > > NEW > > > > > G.711.0, being both lossless and stateless, may also be employed as > a > > > > > lossless compression mechanism for G.711 payloads anywhere between > > > > > end systems that support use of G.711. > > > > > > > > > > Then the added sentence on negotiation being out of scope (end > > > > > of paragraph that begins with that problematic sentence) makes more > sense. > > > > > > > > > > G7110: Again, we never say how "the end systems that negotiated G.711" > > > > > actually NEGOTIATED use of G.711 - as this negotiation is out of > > > > > scope of this payload description document (and any RTP payload > > > > > document for that > > > > matter). > > > > > We are PURPOSELY SILENT on how G.711 is negotiated because > > > > > virtually all payload format definitions for voice codecs are > > > > > also silent on this > > > > point