Re: [TICTOC] Benjamin Kaduk's Discuss on draft-ietf-tictoc-1588v2-yang-10: (with DISCUSS and COMMENT)

Jiangyuanlong <jiangyuanlong@huawei.com> Mon, 15 October 2018 16:22 UTC

Return-Path: <jiangyuanlong@huawei.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8633130EB7; Mon, 15 Oct 2018 09:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 m0bSmUbVCghT; Mon, 15 Oct 2018 09:22:03 -0700 (PDT)
Received: from huawei.com (szxga02-in.huawei.com [45.249.212.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4C1130DC4; Mon, 15 Oct 2018 09:22:03 -0700 (PDT)
Received: from dggeml406-hub.china.huawei.com (unknown [172.30.72.54]) by Forcepoint Email with ESMTP id 63240FA614AA; Tue, 16 Oct 2018 00:21:57 +0800 (CST)
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by dggeml406-hub.china.huawei.com (10.3.17.50) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 16 Oct 2018 00:21:58 +0800
Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.93]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0399.000; Tue, 16 Oct 2018 00:21:48 +0800
From: Jiangyuanlong <jiangyuanlong@huawei.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, Karen O'Donoghue <odonoghue@isoc.org>, "draft-ietf-tictoc-1588v2-yang@ietf.org" <draft-ietf-tictoc-1588v2-yang@ietf.org>, "tictoc-chairs@ietf.org" <tictoc-chairs@ietf.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-tictoc-1588v2-yang-10: (with DISCUSS and COMMENT)
Thread-Index: AQHUYWl6D0CRLbSSkk64ywOGn9xD2aUbiaqQ//+fsQCABUmZUA==
Date: Mon, 15 Oct 2018 16:21:48 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBC22CDF7@dggeml512-mbx.china.huawei.com>
References: <153926586208.14803.13432042276042241561.idtracker@ietfa.amsl.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBC218FF5@dggeml532-mbs.china.huawei.com> <20181012143748.GE3293@kduck.kaduk.org>
In-Reply-To: <20181012143748.GE3293@kduck.kaduk.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.171.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/tictoc/U0kdCgqrDXP5UoLlyHHPt5NSScE>
Subject: Re: [TICTOC] Benjamin Kaduk's Discuss on draft-ietf-tictoc-1588v2-yang-10: (with DISCUSS and COMMENT)
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Oct 2018 16:22:05 -0000

> 
> Indeed, this topic is quite related to Ben's point about document access.
> Though I think generally we still want our documents to be able to stand
> alone in some sense, so there's a balance to find.
> 
[YJ] I agree with you that there is a balance to find. Actually, there have been quite a few discussions happened in the mailing list of TICTOC WG regarding whether we add more details to the terms in the document, the IEEE 1588 participants strongly advised we refer to the IEEE 1588 terminologies and keep the texts as simple as possible in the draft. Since the targeted readers are mainly implementers and operators of IEEE 1588 community, and the YANG module will be transferred to the IEEE 1588 WG as in our plan, I hope the balance will be somewhat more tilted towards them;) 

> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> > >
> > > Section 1
> > >
> > >    o  When the IEEE 1588 standard is revised (e.g. the IEEE 1588
> > >    revision in progress at the time of writing this document), it will
> > >    add some new optional features to its data sets.  The YANG module
> > >    of this document MAY be revised and extended to support these new
> > >    features. Moreover, the YANG "revision" SHOULD be used to indicate
> > >    changes to the YANG module under such a circumstance.
> > >
> > > It's not clear that a 2119 SHOULD is best here; I would have expected
> > > either an 8174 "should" or a 2119 "MUST".
> > >
> > [YJ] Are you suggesting to use "must" or "MUST"? Otherwise, I think
> "should" is similar to "SHOULD".
> 
> I was suggesting "MUST".
> 
[YJ] How about change "MAY" to "can", and "SHOULD" to "MUST" in the above bullet? Hopefully the new changes indicate a stronger expectation.

Thanks,
Yuanlong