Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt

["Romascanu, Dan (Dan)" <[e-mail]>]

Gonzalo,

We can do one more update before the document is approved, in order to
incorporate these changes. This would spare a lengthy note to the RFC
editor. 

Dan




> -----Original Message-----
> From: Qin Wu [mailto:[e-mail]]
> Sent: Tuesday, September 18, 2012 5:10 AM
> To: Glen Zorn; Romascanu, Dan (Dan)
> Cc: [e-mail]
> Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-
> 06.txt
> 
> Hi, Glen:
> Thank for your comments, please see my reply inline.
> 
> Regards!
> -Qin
> ----- Original Message -----
> From: "Glen Zorn" <[e-mail]>
> To: "Romascanu, Dan (Dan)" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Monday, September 17, 2012 11:59 PM
> Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-
> 06.txt
> 
> 
> >
> > On 09/16/2012 03:55 PM, Romascanu, Dan (Dan) wrote:
> >> A revised version of raft-ietf-xrblock-rtcp-xr-pdv was issued in
> order
> >> to address the problems raised in DISCUSSes and COMMENTs during the
> IESG
> >> review.
> >>
> >> We believe that the changes are editorial and clarification in
> nature,
> >> they do not affect bits on the wire and improve the quality of the
> >> document. However, more scrutiny from the other WG participants
never
> >> harms. Please read the revised version and let us know before 9/21
if
> >> you see any problems.
> >>
> >> Thanks and Regards,
> >>
> >> Dan
> >
> > The change to Section i.1 introduced a punctuation error: s/,,/,/
> 
> [Qin]: Good catch and will fix this. Thanks.
> 
> >
> > I find the change to Section 1.4 rather confusing:
> >
> >
> >                 Application designers can know the range of delay
> > variation they must
> >                 accommodate, whether they are designing fixed or
> > adaptive buffer
> >                 systems.
> 
> > Are these app designers clairvoyant?  If not, how can they "know the
> > range of delay variation they must accommodate, whether they are
> > designing fixed or adaptive buffer systems" from measurements that
> can't
> > be made until the system is not only implemented but deployed (at
> least
> > in a test bed)?
> 
> [Qin]: Sorry to bring confusing here, what we want to convey is
> these application designers need to know the range of delay variation
> they must accomodate,
> and then based on the range of delay variation to determine whether
they
> are designing
> fixed or adaptive buffer systems.
> You can get more details in the section 3.2 of RFC5481.
> Do we really need to delete this first sentence you mentioned above?
> 
> > The next sentence doesn't make much sense, either, as
> > written.  I suggest deleting the first and rewriting the second to
> make
> > more sense; for example: "For example, network managers can use this
> > metric to compare actual delay variation to targets (i.e., a
numerical
> > objective or Service Level Agreement) to help ensure the quality of
> > real-time application performance." Or something like that.
> 
> [Qin]: Your proposed change to the second setence looks good to me.
> 
> > What does Section 2 mean?  How can one use an entire RFC as a
> > "terminology statement"?  Does it actually mean "This document uses
> ABNF
> > notation [RFC5234] in Section 4."?
> 
> [Qin]: Yes, this statement doesn't intend to apply to the whold
> document.
> Thank for your proposed change.
> 
> >If so, just say that; OTOH, since
> > the ABNF usage is in the context of SDP & RFC 3611 both references
the
> > ABNF spec and is listed as a normative reference in this draft, why
> > bother?
> 
> [Qin]: The reason is ABNF spec referenced by SDP document (i.e.,
> RFC4566) and RFC3611
> is outdated or obsoleted RFC4234, this RFC should be replaced by
> RFC5234.
> 
> >I suggest just deleting Section 2.
> 
> [Qin] How about move this statement to the first place in the section
4?
> >
> >>
> >> -----Original Message-----
> >> From:[e-mail]  [mailto:[e-mail]] On
> >> Behalf [e-mail]
> >> Sent: Friday, September 14, 2012 12:26 PM
> >> To:[e-mail]
> >> Cc:[e-mail]
> >> Subject: [xrblock] I-D Action:
draft-ietf-xrblock-rtcp-xr-pdv-06.txt
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >>   This draft is a work item of the Metric Blocks for use with
RTCP's
> >> Extended Report Framework Working Group of the IETF.
> >>
> >> Title           : RTCP XR Report Block for Packet Delay
> >> Variation Metric Reporting
> >> Author(s)       : Alan Clark
> >>                            Qin Wu
> >> Filename        : draft-ietf-xrblock-rtcp-xr-pdv-06.txt
> >> Pages           : 21
> >> Date            : 2012-09-14
> >>
> >> Abstract:
> >>     This document defines a Real-Time Control Protocol (RTCP)
> Extended
> >>     Report (XR) block that allows the reporting of Packet Delay
> Variation
> >>     metrics for a range of Real-time Transport Protocol (RTP)
> >>     applications.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-pdv
> >>
> >> There's also a htmlized version available at:
> >> http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-pdv-06
> >>
> >> A diff from the previous version is available at:
> >> http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-pdv-06
> >>
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> _______________________________________________
> >> xrblock mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/xrblock
> >> _______________________________________________
> >> xrblock mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/xrblock
> >
> >
> > _______________________________________________
> > xrblock mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/xrblock