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

Benjamin Kaduk <kaduk@mit.edu> Tue, 16 October 2018 15:07 UTC

Return-Path: <kaduk@mit.edu>
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 55EC7130DEB; Tue, 16 Oct 2018 08:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3cWed6OMG6su; Tue, 16 Oct 2018 08:07:37 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 DC47C12D4EE; Tue, 16 Oct 2018 08:07:36 -0700 (PDT)
X-AuditID: 12074425-2b7ff70000007318-1e-5bc5feb596ee
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id B3.B3.29464.6BEF5CB5; Tue, 16 Oct 2018 11:07:35 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w9GF7SIC000709; Tue, 16 Oct 2018 11:07:30 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w9GF7NpO004194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Oct 2018 11:07:25 -0400
Date: Tue, 16 Oct 2018 10:07:22 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Jiangyuanlong <jiangyuanlong@huawei.com>
Cc: "tictoc-chairs@ietf.org" <tictoc-chairs@ietf.org>, "draft-ietf-tictoc-1588v2-yang@ietf.org" <draft-ietf-tictoc-1588v2-yang@ietf.org>, The IESG <iesg@ietf.org>, Karen O'Donoghue <odonoghue@isoc.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Message-ID: <20181016150722.GQ19309@kduck.kaduk.org>
References: <153926586208.14803.13432042276042241561.idtracker@ietfa.amsl.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBC218FF5@dggeml532-mbs.china.huawei.com> <20181012143748.GE3293@kduck.kaduk.org> <3B0A1BED22CAD649A1B3E97BE5DDD68BBC22CDF7@dggeml512-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBC22CDF7@dggeml512-mbx.china.huawei.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IRYrdT0d3+72i0wVVZi7ubZjBZzPgzkdni 6od2NotZj/YzW2yZ85LR4m9zD7sDm0fLkbesHkuW/GTyeDWtkTWAOYrLJiU1J7MstUjfLoEr Y3pHO2vBGsGKj50HWRsYT/B2MXJySAiYSJx69ZGti5GLQ0hgMZPElQdLGUESQgIbGSXu/OWH SFxlkjiw6AgLSIJFQFWiae9UJhCbTUBFoqH7MjOILSKgI/F1zyVmkAZmgW4mic6LC9lBEsIC 6RJrf/WB2bxA67Z3nYPaMIFJYuGMUIi4oMTJmU/AFjALaEnc+PcSaAEHkC0tsfwfB0iYUyBM Yvq0B2CtogLKEnv7DrFPYBSYhaR7FpLuWQjdCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFula 6OVmluilppRuYgSHtYvqDsY5f70OMQpwMCrx8P64fiRaiDWxrLgy9xCjJAeTkiivxp6j0UJ8 SfkplRmJxRnxRaU5qcWHGCU4mJVEeNMvAeV4UxIrq1KL8mFS0hwsSuK8k1oWRwsJpCeWpGan phakFsFkZTg4lCR43/wFahQsSk1PrUjLzClBSDNxcIIM5wEaLvUPZHhxQWJucWY6RP4Uoy5H 29PrM5iFWPLy81KlxHn/ggwSACnKKM2DmwNKRxLZ+2teMYoDvSXMuwCkigeYyuAmvQJawgS0 xN32CMiSkkSElFQDo59Q+UelMylPM468WXHM6QHjXQkDhffXXBvNzjw4673JO+kB94wF9/PM cl7ulDJpN1U3D1JcYV9xavbkR9cErBheng0KStP0sl4uE+O+xX/LsY+1sgsd84TfznO+xZvX b6f9T9vroLFuzs7/C72a2C4rPA0QPPPFWFMg/gBLxf19mzZ0eDe6KrEUZyQaajEXFScCAGlw OsIiAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/tictoc/t7tvVB10esTpmYE7vI_QkLKxWoI>
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: Tue, 16 Oct 2018 15:07:39 -0000

On Mon, Oct 15, 2018 at 04:21:48PM +0000, Jiangyuanlong wrote:
> > 
> > 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;) 

Ah, thanks for the extra background from the WG.  I am interested to see
how Ben's Discuss gets resolved, which may end up doing enough for me to be
able to resolve mine as a side effect.

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

They do, thanks!

-Benjamin