Re: Review of draft-ietf-ippm-twamp-time-format-03

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yes, that makes the relationship of the conditions significantly clearer.
Thank you,
Joel

On 3/3/17 5:46 PM, Greg Mirsky wrote:
Hi Joel,
thank you for your thorough review and the most helpful comments. I've
did s/proposal/specification/ through the document. As for the section
2.1 would the following text be clearer:

The rules of setting timestamp flags in
   Modes field in server greeting and Set-Up-Response messages and
   interpreting them are as follows:

   o  If the Session-Receiver supports this extension, then the Server
      that establishes test sessions on its behalf MUST set PTPv2
      Timestamp flag to 1 in the server greeting message per the
      requirement listed in Section 2.  Otherwise, the PTPv2 Timestamp
      flag will be set to 0 to indicate that the Session-Reciever
      interprets only NTP format.

   o  If the Control-Client receives greeting message with the PTPv2
      Timestamp flag set to 0, then the Session-Sender MUST use NTP
      format for timestamp in the test session and Control-Client SHOULD
      set PTPv2 Timestamp flag to 0 in accordance with [RFC4656].  If
      the Session-Sender cannot use NTP timestamps, then the Control-
      Client SHOULD close the TCP connection associated with the OWAMP-
      Control session.

   o  If the Control-Client receives greeting message with the PTPv2
      Timestamp flag set to 1 and the Session-Sender can set timestamp
      in PTPv2 format, then the Control-Client MUST set the PTPv2
      Timestamp flag to 1 in Modes field in the Set-Up-Response message
      and the Session-Sender MUST use PTPv2 timestamp format.

   o  If the Session-Sender doesn't support this extension and can set
      timestamp only in NTP format, then the PTPv2 Timestamp flag in
      Modes field in the Set-Up-Response message will be set to 0 as
      part of Must Be Zero and the Session-Sender use NTP format.

Regards,

Greg


On Thu, Mar 2, 2017 at 8:45 PM, Joel Halpern <jmh@xxxxxxxxxxxxxxx
<mailto:jmh@xxxxxxxxxxxxxxx>> wrote:

    Reviewer: Joel Halpern
    Review result: Ready with Nits

    I am the assigned Gen-ART reviewer for this draft. The General Area
    Review Team (Gen-ART) reviews all IETF documents being processed
    by the IESG for the IETF Chair.  Please treat these comments just
    like any other last call comments.

    For more information, please see the FAQ at

    <https://trac.ietf.org/trac/gen/wiki/GenArtfaq
    <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.

    Document: draft-ietf-ippm-twamp-time-format-??
    Reviewer: Joel Halpern
    Review Date: 2017-03-02
    IETF LC End Date: 2017-03-15
    IESG Telechat date: Not scheduled for a telechat

    Summary:

    Major issues:

    Minor issues:
        The wording of the behavioral requirements for signaling in
    section 2.1 is atypical for IETF documents (and in my view makes it
    harder for the reader to follow.)  The rules are listed as separate
    rules, but they are actually sequential steps that must be test in
    order, exiting the process if the condition for each step is met.  But
    it does not actually say that.

    Nits/editorial comments:
        Section 2.3 refers to this as a proposal.  It is a specification,
    not a proposal.  Please reword.







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]