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

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

Hi Gonzalo and Benoit,

Please correct me if I am wrong, but my impression is that Benoit's
DISCUSS is related to the process of defining the  metrics in the
different places in the IETF in a consistent manner and keeping them in
one repository with a clear owner. Are there any text changes required
in draft-ietf-xrblock-rtcp-xr-pdv? 

Thanks and Regards,

Dan


> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[e-mail]]
> Sent: Tuesday, September 18, 2012 12:45 PM
> To: Romascanu, Dan (Dan)
> Cc: Qin Wu; Glen Zorn; [e-mail]
> Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-
> 06.txt
> 
> Hi Dan,
> 
> yes, it is better to update the document. Just make sure you
coordinate
> the document update with the conversation with Benoit to clear his
> discuss so that nobody gets confused when the new revision is posted.
> 
> Cheers,
> 
> Gonzalo
> 
> On 18/09/2012 11:02 AM, Romascanu, Dan (Dan) wrote:
> > 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