Re: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

Jiangyuanlong <jiangyuanlong@huawei.com> Tue, 07 November 2017 07:53 UTC

Return-Path: <jiangyuanlong@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54DB13FB8A; Mon, 6 Nov 2017 23:53:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level:
X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URG_BIZ=0.573, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGkkojPS0v0N; Mon, 6 Nov 2017 23:53:42 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E036513FC10; Mon, 6 Nov 2017 23:53:40 -0800 (PST)
Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZI28920; Tue, 07 Nov 2017 07:53:39 +0000 (GMT)
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 7 Nov 2017 07:53:38 +0000
Received: from DGGEML507-MBS.china.huawei.com ([169.254.1.221]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0361.001; Tue, 7 Nov 2017 15:53:26 +0800
From: Jiangyuanlong <jiangyuanlong@huawei.com>
To: Alex Campbell <Alex.Campbell@Aviatnet.com>, "tictoc@ietf.org" <tictoc@ietf.org>
CC: Xian Liu <lene.liuxian@foxmail.com>, Xujinchun <xujinchun@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
Thread-Index: AQHTTso91J0wdpBQm0ySMhnhc/8WWaL7pCg3gAzlH4A=
Date: Tue, 07 Nov 2017 07:53:26 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB62C3F8@dggeml507-mbs.china.huawei.com>
References: <150906887826.22201.5033565145094897903.idtracker@ietfa.amsl.com>, <3B0A1BED22CAD649A1B3E97BE5DDD68BBB604A97@dggeml507-mbx.china.huawei.com> <1509329710965.52658@Aviatnet.com>
In-Reply-To: <1509329710965.52658@Aviatnet.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.74.202.215]
Content-Type: text/plain; charset="utf-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5A016683.00A8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.221, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4f5776818ae5929f90e8bb5a96927dab
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ppMSuOEY4bjkdX2u8WwKWmVFEDg>
Subject: Re: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2017 07:53:46 -0000

Hi Alex,

Sorry for a late reply as I spent the last week for an urgent business trip.
Please see my comments in line with [YJ]

Thanks,
Yuanlong

-----Original Message-----
From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com] 
Sent: Monday, October 30, 2017 10:15 AM
To: Jiangyuanlong; tictoc@ietf.org
Cc: Xian Liu; Xujinchun; netmod@ietf.org
Subject: Re: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

Hi,
I've reviewed this latest draft and have some more comments.

1. I find the introduction to be unnecessarily wordy; it feels like it was written with a view of not missing any information out, rather than trying to keep it concise.
   For example, there is no need to elaborate on YANG data types here. It is also not here to sell YANG.

[YJ] Yes, we are trying to give some introductory information for an outsider who may not be familiar with PTP or YANG, and explain why a YANG for PTP is needed. The juicy part of this document is its YANG module, and people can skip all the other texts if they are familiar with PTP and YANG.
Besides, these texts have been contributed by multiple sources and undergone several rounds of reviews, thus I will wait for a clear message from the TICTOC chairs to introduce any big changes at this last call stage.


OLD:

   As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely
   supported in the carrier networks, industrial networks, automotive
   networks, and many other applications. It can provide high
   precision time synchronization as fine as nano-seconds. The
   protocol depends on a Precision Time Protocol (PTP) engine to
   decide its own state automatically, and a PTP transportation layer
   to carry the PTP timing and various quality messages. The
   configuration parameters and state data sets of IEEE 1588-2008 are
   numerous.

   According to the concepts described in [RFC3444], IEEE 1588-2008
   itself provides an information model in its normative
   specifications for the data sets (in IEEE 1588-2008 clause 8). Some
   standardization organizations including the IETF have specified
   data models in MIBs (Management Information Bases) for IEEE 1588-
   2008 data sets (e.g. [RFC8173], [IEEE8021AS]). These MIBs are
   typically focused on retrieval of state data using the Simple
   Network Management Protocol (SNMP), furthermore, configuration of
   PTP data sets is not considered in [RFC8173].

   Some service providers and applications require that the management
   of the IEEE 1588-2008 synchronization network be flexible and more
   Internet-based (typically overlaid on their transport networks).
   Software Defined Network (SDN) is another driving factor, which
   demands an improved configuration capability of synchronization
   networks.

   YANG [RFC6020] is a data modeling language used to model
   configuration and state data manipulated by network management
   protocols like the Network Configuration Protocol (NETCONF)
   [RFC6241]. A small set of built-in data types are defined in
   [RFC6020], and a collection of common data types are further
   defined in [RFC6991]. Advantages of YANG include Internet based
   configuration capability, validation, rollback and so on. All of
   these characteristics make it attractive to become another
   candidate modeling language for IEEE 1588-2008.

NEW:

   IEEE 1588-2008 is a time protocol that provides high precision time
   synchronization as fine as nano-seconds.

   IEEE 1588-2008 itself provides an information model in its normative
   specifications for the data sets (IEEE 1588-2008 clause 8).
   Standard information models (e.g. [RFC8173], [IEEE8021AS]) have been
   previously defined as MIBs focused on the retrieval of state data using
   SNMP [RFC1157].

   YANG [RFC6020] is a data modeling language used to model configuration
   and state data manipulated by network management protocols like NETCONF
   [RFC6241].

2. Can we refer to the system as simply PTP rather than IEEE 1588(-2008)?
[YJ] Advice from IEEE 1588 is, we need to use "1588-2008" as much as possible to help clarify that the scope of this YANG is limited to the published 1588 standard.


3. There is insufficient spacing here to separate the terms from their definitions:
OLD

   PTP dataset  Structured attributes of clocks (an OC, BC or TC) used
   for PTP protocol decisions and for providing values for PTP message
   fields, see Section 8 of [IEEE1588].

   PTP instance A PTP implementation in the device (i.e., an OC or BC)
   represented by a specific PTP dataset.

NEW

   PTP dataset
     Structured attributes of clocks (an OC, BC or TC) used
     for PTP protocol decisions and for providing values for PTP message
     fields, see Section 8 of [IEEE1588].

   PTP instance
     A PTP implementation in the device (i.e., an OC or BC)
     represented by a specific PTP dataset.
[YJ] OK.

4. There's a singular/plural mismatch here:

   module. Query and configuration of device wide or port specific
   configuration information and clock data set is described for this
   version.
[YJ] Good, we will change 'is' to 'are'.

and here:

   Query and configuration of clock information include:


5. The choice of uint16 as instance-number limits implementations to 65536 distinct instances.
   While I have a hard time imagining a system with more than 65536 PTP instances, I would prefer to avoid imposing arbitrary limits.
   I would recommend changing instance-number to a string (and renaming it to instance-name or just name).
[YJ] The 1588-2008 supports multiple instances of PTP, but it is ambiguous in its organization of those PTP instances, especially with regard to management.
 In the 1588 new revision, there is an explicit list of PTP instances, and that list is indexed using a number (not name). Thus to align with the new revision, we need to keep it instance-number.
 If 65536 limit is a concern, how about change it to uint32, any concerns?


6. I still recommend removing -ds from the YANG element names that still include it. It doesn't appear to add any value.
[YJ] Rodney's opinion: the value of using 'ds' is that the 1588 document on which this YANG model is based uses "DefaultDS" as a term. PTP experts even say "default dee ess" verbally when referring to this data. If we changed this to just "default", PTP experts might assume that we are referring to something entirely new to YANG. Thus, to align with 1588-2008, the same set of terminologies are used.

7. What;s the relevance of injection attacks relevant to this YANG module?
[YJ] This is a general statement which is applicable to this YANG module and other YANG modules as well.
Thanks again,
Yuanlong

Alex


________________________________________
From: netmod <netmod-bounces@ietf.org> on behalf of Jiangyuanlong <jiangyuanlong@huawei.com>
Sent: Friday, 27 October 2017 3:21 p.m.
To: tictoc@ietf.org
Cc: Xian Liu; Xujinchun; netmod@ietf.org
Subject: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

Dear all,

Based on all the comments we received during the WG Last Call process, we've updated the document to version 6.
We believe all the LC comments are resolved and the consensus is reflected in this new revision.
Many thanks to Martin, Tal, Opher, Alex, John and many others who had reviewed and commented on this draft.

Cheers,
Yuanlong on behalf of all coauthors

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Friday, October 27, 2017 9:48 AM
To: Xian Liu; Rodney Cummings; rodney.cummings@ni.com; Jiangyuanlong; Xujinchun
Subject: New Version Notification for draft-ietf-tictoc-1588v2-yang-06.txt


A new version of I-D, draft-ietf-tictoc-1588v2-yang-06.txt
has been successfully submitted by Yuanlong Jiang and posted to the IETF repository.

Name:           draft-ietf-tictoc-1588v2-yang
Revision:       06
Title:          YANG Data Model for IEEE 1588-2008
Document date:  2017-10-26
Group:          tictoc
Pages:          30
URL:            https://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588v2-yang-06.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-06
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-1588v2-yang-06
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tictoc-1588v2-yang-06

Abstract:
   This document defines a YANG data model for the configuration of
   IEEE 1588-2008 devices and clocks, and also retrieval of the
   configuration information, data set and running states of IEEE
   1588-2008 clocks.




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

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod