[Gen-art] Fwd: New Version Notification for draft-ietf-ippm-twamp-time-format-04.txt

2017-03-03 Thread Greg Mirsky 
Dear All,
changes are to address comments by Joel Halpern.

Regards,
Greg
-- Forwarded message --
From: 
Date: Fri, Mar 3, 2017 at 4:54 PM
Subject: New Version Notification for
draft-ietf-ippm-twamp-time-format-04.txt
To: Gregory Mirsky , ippm-cha...@ietf.org, Israel
Meilik 



A new version of I-D, draft-ietf-ippm-twamp-time-format-04.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:   draft-ietf-ippm-twamp-time-format
Revision:   04
Title:  Support of IEEE-1588 time stamp format in Two-Way Active
Measurement Protocol (TWAMP)
Document date:  2017-03-03
Group:  ippm
Pages:  8
URL:https://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-
time-format-04.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-
time-format/
Htmlized:   https://tools.ietf.org/html/draft-ietf-ippm-twamp-time-
format-04
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-twamp-
time-format-04

Abstract:
   This document describes an OPTIONAL feature for active performance
   measurement protocols allowing use of the Precision Time Protocol
   time stamp format defined in IEEE-1588v2-2008, as an alternative to
   the Network Time Protocol that is currently used.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-ietf-ippm-twamp-time-format-03

2017-03-03 Thread Joel M. Halpern 

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 > 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

>.

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.





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-ietf-ippm-twamp-time-format-03

2017-03-03 Thread Greg Mirsky 
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  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
>
> .
>
> 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.
>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Review of draft-ietf-jsonbis-rfc7159bis-03

2017-03-03 Thread Elwyn Davies 
Reviewer: Elwyn Davies
Review result: Ready

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

.

Document: draft-ietf-jsonbis-rfc7159bis-??
Reviewer: Elwyn Davies
Review Date: 2017-03-03
IETF LC End Date: 2017-03-07
IESG Telechat date: 2017-03-16

Summary: Ready for IESG.  I checked through the varous errata cited
and it seems these are all covered as specified.  Thanks.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Review of draft-ietf-lamps-eai-addresses-06

2017-03-03 Thread Stewart Bryant 
Reviewer: Stewart Bryant
Review result: Ready

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-lamps-eai-addresses-??
Reviewer: Stewart Bryant
Review Date: 2017-03-03
IETF LC End Date: 2017-01-30
IESG Telechat date: 2017-03-16

Summary: Ready for Publication

Major issues: None

Minor issues: None 

Nits/editorial comments: None


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Review of draft-hardie-privsec-metadata-insertion-06

2017-03-03 Thread Stewart Bryant 
Reviewer: Stewart Bryant
Review result: Ready with Nits

Reviewer: Stewart Bryant
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

.

Document: draft-hardie-privsec-metadata-insertion-06
Reviewer: Stewart Bryant
Review Date: 2017-03-03
IETF LC End Date: 2017-02-21
IESG Telechat date: 2017-03-16

Summary:  This is a well written document with two very minor nits.

Major issues: None

Minor issues: None

Nits/editorial comments: 

1.  Introduction

   exploited in the attacks document in [RFC7258] and the threats
s/document/documented/

===

EDNS0 ought to be expanded.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art