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.