Re: [Gen-art] Genart last call review of draft-ietf-tictoc-1588v2-yang-09

[Jiangyuanlong]

Linda,

Your description is simpler, but the risk is, this description seems to refer 
to IEEE 1588 for the whole definition.
We know the 2nd sentence is not in IEEE 1588, it just reflects our own 
interpretation.
Thus, the original texts are more accurate IMO.

Thanks,
Yuanlong

-Original Message-
From: Linda Dunbar 
Sent: Thursday, September 06, 2018 11:02 PM
To: Jiangyuanlong ; Rodney Cummings 
; gen-art@ietf.org
Cc: draft-ietf-tictoc-1588v2-yang@ietf.org; i...@ietf.org; tic...@ietf.org
Subject: RE: [Gen-art] Genart last call review of 
draft-ietf-tictoc-1588v2-yang-09

Yuan Long, 

It would be better to have the description for the "default-ds" as

description
 " This data represents
  the configuration/state data set of the clock required for 
operation
  of Precision Time Protocol (PTP) state machines. (see IEEE Std
  1588-2008 subclause 8.2.1).";


My two cents, 

Linda

-Original Message-
From: Jiangyuanlong
Sent: Thursday, September 06, 2018 2:52 AM
To: Linda Dunbar ; Rodney Cummings 
; gen-art@ietf.org
Cc: draft-ietf-tictoc-1588v2-yang@ietf.org; i...@ietf.org; tic...@ietf.org
Subject: RE: [Gen-art] Genart last call review of 
draft-ietf-tictoc-1588v2-yang-09

Linda,

Thank you for your kind comments. The original IEEE 1588-2008 specification is 
ambiguous on these terminologies.
The authors suggest to update with the following description texts:
 container default-ds {
   description
 "The default data set of the clock (see IEEE Std
  1588-2008 subclause 8.2.1). This data represents
  the configuration/state required for operation
  of Precision Time Protocol (PTP) state machines.";

 container current-ds {
   description
 "The current data set of the clock (see IEEE Std
  1588-2008 subclause 8.2.2). This data represents
  local state learned from the exchange of 
  Precision Time Protocol (PTP) messages.";

Are you satisfied with the new texts?
If there is no objection, we will reflect this change for the next revision.

Kind regards,
Yuanlong

-Original Message-
From: TICTOC [mailto:tictoc-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, September 06, 2018 2:59 AM
To: Rodney Cummings ; gen-art@ietf.org
Cc: draft-ietf-tictoc-1588v2-yang@ietf.org; i...@ietf.org; tic...@ietf.org
Subject: Re: [TICTOC] [Gen-art] Genart last call review of 
draft-ietf-tictoc-1588v2-yang-09

Rodney, 

Thanks for addressing my comments. 

It is not like "right" or "wrong" for using ENUM. Just when IEEE1588 adds a new 
type, the new data model to include the new type won't be backward compatible 
to your current one.  It is more like a better choice, not like your current 
design has any flaws. So, it is not necessary to change now. Maybe to consider 
for next data model specification. 

It would be great to have additional description in the YANG module especially 
the "default-ds" & "current-ds", the names are not self-explanatory. 

Thanks, Linda Dunbar
-Original Message-
From: Rodney Cummings [mailto:rodney.cummi...@ni.com]
Sent: Wednesday, September 05, 2018 12:26 PM
To: Linda Dunbar ; gen-art@ietf.org
Cc: draft-ietf-tictoc-1588v2-yang@ietf.org; i...@ietf.org; tic...@ietf.org
Subject: RE: [Gen-art] Genart last call review of 
draft-ietf-tictoc-1588v2-yang-09

Hi Linda,

I'll attempt to address both of your comments, and my co-authors can chime in 
as needed.

Regarding use of enum...

I agree that identity would be preferable in order to allow augments and other 
modules to add new values. The reason this module uses enum is to explicitly 
disallow that sort of addition.
The reason why is that the list of number/name pairs is published in the IEEE 
1588 standard, and the IEEE 1588 working group is the only entity that can add 
new values. The number for each name is used for IEEE 1588 messages (not only 
YANG management), and that's why the
1588 standard itself needs to enforce its own registration to avoid 
incompatibilities.

That being said, it is certainly possible that future editions of the IEEE 1588 
standard will add new number/name pairs to the list. When that occurs, IEEE 
1588 will revise the YANG module to align with the new 1588 edition, and that 
YANG revision will add new enum values according to the requirements of RFC 
7950 section 11, which states:
  An "enumeration" type may have new enums added, provided the old
  enums's values do not change.  Note that inserting a new enum
  before an existing enum or reordering existing enums will result
  in new values for the existing enums, unless they have explicit
  values assigned to them.
Since IEEE 1588 assigns explicit values, and IEEE 1588 cannot change old values 
(i.e., cannot break existing products), this requirement is straightforward.

Therefore, I recommend retaining the current use of enum.

[Gen-art] Genart last call review of draft-ietf-bess-mvpn-mib-10

[David Schinazi]

Reviewer: David Schinazi
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-bess-mvpn-mib-10
Reviewer: David Schinazi
Review Date: 2018-09-06
IETF LC End Date: 2018-09-03
IESG Telechat date: 2018-09-13

Summary: This document is clearly written and looks ready to me.

Major issues: None found.

Minor issues: None found. 

Nits/editorial comments: Typo "senstive" - please run the internet draft 
spellchecker tool.


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

Re: [Gen-art] Genart telechat review of draft-ietf-taps-minset-08

[Aaron Falk]

Robert-

Thanks for the (quick) clarification.  I misunderstood the intent of 
your note.


--aaron

On 6 Sep 2018, at 16:30, Robert Sparks wrote:


Aaron -

To be a bit more clear, my point is to twist the IESGs arm about 
recent pushback on WGs publishing requirements documents...


RjS


On 9/6/18 3:22 PM, Aaron Falk wrote:


On 6 Sep 2018, at 16:07, Robert Sparks wrote:

(Repeating one thing from my Last Call review for the benefit of
the IESG):

This was a big effort, and it appears that it was helpful to the 
folks
working on the interface document, but it's not clear how it will 
be
useful to implementers. The IESG should consider whether this, 
like
requirements documents, needs to be in the RFC series. The most 
likely
use I can see in the future would be for historians, and a 
different

and shorter presentation would serve them better.

Hi Robert-

This seems like more useful information for RFC Editor than for the 
IESG. According to RFC2026 the IESG's criteria for publication for 
Informational RFCs are:


4.2.2 Informational

... The Informational
designation is intended to provide for the timely publication of 
a

very broad range of responsible informational documents from many
sources, subject only to editorial considerations and to 
verification
that there has been adequate coordination with the standards 
process

(see section 4.2.3).

and

6.1.2 IESG Review and Approval

The IESG shall ... determine whether or not the technical quality
and clarity
of the specification is consistent with that expected for the
maturity level to which the specification is recommended.


So, I don't think the IESG gets to decide that it doesn't belong in 
an RFC just because it doesn't it wouldn't be useful to implementors 
or historians (only two of many RFC audiences). I suggest you take 
your concerns up with the TAPS working group, who thought it was 
important to document their analysis, and/or Heather (cc'ed).


--aaron




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

Re: [Gen-art] Genart telechat review of draft-ietf-taps-minset-08

[Robert Sparks]

Aaron -

To be a bit more clear, my point is to twist the IESGs arm about recent 
pushback on WGs publishing requirements documents...


RjS


On 9/6/18 3:22 PM, Aaron Falk wrote:


On 6 Sep 2018, at 16:07, Robert Sparks wrote:

(Repeating one thing from my Last Call review for the benefit of
the IESG):

This was a big effort, and it appears that it was helpful to the folks
working on the interface document, but it's not clear how it will be
useful to implementers. The IESG should consider whether this, like
requirements documents, needs to be in the RFC series. The most likely
use I can see in the future would be for historians, and a different
and shorter presentation would serve them better.

Hi Robert-

This seems like more useful information for RFC Editor than for the 
IESG. According to RFC2026 the IESG's criteria for publication for 
Informational RFCs are:


4.2.2 Informational

... The Informational
designation is intended to provide for the timely publication of a
very broad range of responsible informational documents from many
sources, subject only to editorial considerations and to verification
that there has been adequate coordination with the standards process
(see section 4.2.3).

and

6.1.2 IESG Review and Approval

The IESG shall ... determine whether or not the technical quality
and clarity
of the specification is consistent with that expected for the
maturity level to which the specification is recommended.


So, I don't think the IESG gets to decide that it doesn't belong in an 
RFC just because it doesn't it wouldn't be useful to implementors or 
historians (only two of many RFC audiences). I suggest you take your 
concerns up with the TAPS working group, who thought it was important 
to document their analysis, and/or Heather (cc'ed).


--aaron



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

Re: [Gen-art] Genart telechat review of draft-ietf-taps-minset-08

[Aaron Falk]

On 6 Sep 2018, at 16:07, Robert Sparks wrote:

(Repeating one thing from my Last Call review for the benefit of the 
IESG):


This was a big effort, and it appears that it was helpful to the folks
working on the interface document, but it's not clear how it will be
useful to implementers. The IESG should consider  whether this, like
requirements documents, needs to be in the RFC series. The most likely
use I can see in the future would be for historians, and a different
and shorter presentation would serve them better.


Hi Robert-

This seems like more useful information for RFC Editor than for the 
IESG.  According to RFC2026 the IESG's criteria for publication for 
Informational RFCs are:




4.2.2  Informational

   ... The Informational
   designation is intended to provide for the timely publication of a
   very broad range of responsible informational documents from many
   sources, subject only to editorial considerations and to 
verification
   that there has been adequate coordination with the standards 
process

   (see section 4.2.3).


and


6.1.2  IESG Review and Approval

   The IESG shall ... determine whether or not the technical quality 
and clarity

   of the specification is consistent with that expected for the
   maturity level to which the specification is recommended.




So, I don't think the IESG gets to decide that it doesn't belong in an 
RFC just because it doesn't it wouldn't be useful to implementors or 
historians (only two of many RFC audiences).  I suggest you take your 
concerns up with the TAPS working group, who thought it was important to 
document their analysis, and/or Heather (cc'ed).


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

[Gen-art] Genart telechat review of draft-ietf-taps-minset-08

[Robert Sparks]

Reviewer: Robert Sparks
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-taps-minset-08
Reviewer: Robert Sparks
Review Date: 2018-09-06
IETF LC End Date: 2018-09-04
IESG Telechat date: 2018-09-13

Summary: Ready for publication as an Informational RFC

(Repeating one thing from my Last Call review for the benefit of the IESG):

This was a big effort, and it appears that it was helpful to the folks
working on the interface document, but it's not clear how it will be
useful to implementers. The IESG should consider  whether this, like
requirements documents, needs to be in the RFC series. The most likely
use I can see in the future would be for historians, and a different
and shorter presentation would serve them better.


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

[Gen-art] Review Assignments

[Jean Mahoney]

Hi all,

The following reviewers have assignments:

For telechat 2018-09-13

Reviewer   Type  LC end Draft
Francis Dupont Telechat  2018-08-29 draft-ietf-lisp-rfc6830bis-16
David Schinazi Last Call 2018-09-03 draft-ietf-bess-mvpn-mib-10
Robert Sparks  Telechat  2018-09-04 draft-ietf-taps-minset-08 *

Last calls:

Reviewer   Type  LC end Draft
Fernando Gont  Last Call 2018-09-20 
draft-ietf-teas-assoc-corouted-bidir-frr-06
Vijay Gurbani  Last Call 2018-09-12 
draft-ietf-isis-segment-routing-msd-15
Matthew Miller Last Call 2018-08-30 draft-ietf-extra-imap-savedate-01

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Joel Halpern
  Christer Holmberg
  Russ Housley
  Erik Kline
  Jouni Korhonen
  Paul Kyzivat
  Matthew Miller
  Francesca Palombini
  Pete Resnick
  Ines Robles

The LC and Telechat review templates are included below:
---

-- Begin LC Template --
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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments: 

-- End LC Template --

-- Begin Telechat Template --
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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

-- End Telechat Template --


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

[Gen-art] Genart last call review of draft-ietf-dhc-dhcp4o6-saddr-opt-04

[Elwyn Davies]

Reviewer: Elwyn Davies
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-dhc-dhcp4o6-saddr-opt-04
Reviewer: Elwyn Davies
Review Date: 2018-09-06
IETF LC End Date: 2018-09-07
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with nits. Thanks - well written and almost all quite clear.

Major issues:
None

Minor issues:
s7.4:
>o  The received bindprefix6-len value is not larger than the number
>   of bytes, divided by 8, received in the bind-ipv6-prefix field.
>   (e.g. the bindprefix6-len is 128 but the bind-ipv6-prefix field is
>   only 8 bytes long).
Given that s6.1 gives a deterministic algorithm for calculating the length of
the bind-ipv6-prefix field, I don't understand why the validation does not
check that the length of the field is exactly as specified by this algorithm
rather than using it as a lower limit.

s7.5 and s8 (last para): Given that the time constraints and number of retries
will interact and are implemented in different devices, I think these two
values need some sensible defaults defined so that devices from different
sources should interoperate successfully out of the box.

Nits/editorial comments:
General: s/e.g./e.g.,/g

Abstract, sentence 2: Introduce DHCP 4o6 abbreviation: s/For DHCPv4 over
DHCPv6/For DHCPv4 over DHCPv6 (DHCP 4o6)/.

Abstract: Add mention of RFC 6346 and RFC 7598 for explanation of softwire
scheme.

Abstract, para 2: Expand ORO (Option Request Option) and give ref to rfc3315bis.

s1, para 3:  s/attached to any routable IPv6 prefix/attached to a network
segment using any routable IPv6 prefix/

s4, para 1: It would be useful to remind readers of the expansion of BR in
OPTION_S46_BR:  Maybe s/the remote IPv6 address for the softwire/the remote
IPv6 address used for the softwire border router/

s4, para 1: Expand ULA (not a well-known abbreviation).

s7.2.1, para 1: 'flash' is colloquial and may not be generally understood.  I
think it can safely be removed.

s7.4, para after bullets: s/For either of these cases,/If either check fails,/

s10: To be absolutely clear, there are two instances where the following change
ought to be made: OLD: in the table at
https://www.iana.org/assignments/dhcpv6-parameters: NEW: in the Option Codes
table at https://www.iana.org/assignments/dhcpv6-parameters: ENDS

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