Re: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier

Jiangyuanlong <jiangyuanlong@huawei.com> Fri, 29 September 2017 09:22 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 2FB79132941; Fri, 29 Sep 2017 02:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 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] 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 j-e1DNjG33ON; Fri, 29 Sep 2017 02:22:18 -0700 (PDT)
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 ABEB1132403; Fri, 29 Sep 2017 02:22:15 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWM85036; Fri, 29 Sep 2017 09:22:12 +0000 (GMT)
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 29 Sep 2017 10:22:10 +0100
Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.79]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Fri, 29 Sep 2017 17:22:03 +0800
From: Jiangyuanlong <jiangyuanlong@huawei.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "sean.condon@microsemi.com" <sean.condon@microsemi.com>, "netmod@ietf.org" <netmod@ietf.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Thread-Topic: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
Thread-Index: AdM20lxp4a4LJ64bREK66XJnd3gJawAF4nRwABKMRUAAEqGn9wA1hiAA//+KVAD//jENcA==
Date: Fri, 29 Sep 2017 09:22:02 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CC14E@dggeml507-mbx.china.huawei.com>
References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5C9C01@dggeml507-mbx.china.huawei.com> <640F4C69F839A64C8949EF04FAAEE44679F25561@avsrvexchmbx1.microsemi.net> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CB62E@dggeml507-mbx.china.huawei.com> <20170928.152312.261607006753399632.mbj@tail-f.com>
In-Reply-To: <20170928.152312.261607006753399632.mbj@tail-f.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-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59CE10C5.00AD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.79, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d823f5a7908b24376032dabf2c58d99d
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/aL22laJGrsL0LjWw18vUOsBZxgw>
Subject: Re: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
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: Fri, 29 Sep 2017 09:22:22 -0000

Martin,

Thank a lot for your instantly reply. Please see my further comments inline.

Cheers,
Yuanlong

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] 
Sent: Thursday, September 28, 2017 9:23 PM
To: Jiangyuanlong
Cc: sean.condon@microsemi.com; netmod@ietf.org; tictoc@ietf.org
Subject: Re: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier

Jiangyuanlong <jiangyuanlong@huawei.com> wrote:
> Sean,
> 
> My personal opinion is that it can work, but I would like to ask for 
> more opinions from our netmod experts;)
> 
> Hi netmod experts,
> Considering the following sample module, my-list is a list, and it 
> needs to use a leaf member "port-number" in my-port-container as a 
> key.
> We now have 3 options:
> 1.
>   list my-list {
>     key "port-number";
>     leaf port-number {
>        type uint16;
>     }
> 
>     container my-port-container {
>         leaf port-number {
>           type uint16;
>         }
>          leaf other-leaf {
>            ...
>          }
>     }
>   }
> But this does not work for there is compiling error.

Why wouldn't this work?
[JY] The original intention of the 1588 info model is to use my-port-container.port-number as the key. The code actually parses, but we need to synchronize my-list.port-number and my-list.my-port-container.port-number all the while.

I suspect you meant:

   list my-list {
     key "port-number";
 
     container my-port-container {
         leaf port-number {
          type uint16;
         }
          leaf other-leaf {
            ...
          }
     }
   }


> 2.
>   list my-list {
>     key "port-number";
>     leaf port-number {
>        type uint16;
>     }
>     container my-port-container {
>         leaf port-number {
>             type leafref{
>               path "../../port-number";
>             }
>         }
>          leaf other-leaf {
>            ...
>          }
>     }
>   }
> Option 2 can parse, though leafref in a sub-module seems not very 
> natural.
> 
> 3.
>   list my-list {
>     key "port-number";
>     leaf port-number {
>        type leafref{
>           path "../my-port-container/port-number";
>        }
>     }
>     container my-port-container {
>         leaf port-number {
>           type uint16;
>         }
>          leaf other-leaf {
>            ...
>          }
>     }
>   }
> 
> Option 3 can also parse, though leafref seems not a very natural key. 
> What is your favorite option? Or do you have any better schemes?


Having a leafref like in option 2 or 3 is just redundant and a hassle for the client.  In order to create a a list entry, the client would have to first provide the port-number value once for the key, and then again the exact same value in the container:

  <my-list>
    <port-number>25</port-number>
    <my-port-container>
      <port-number>25</port-number>
      <other-leaf>...</other-leaf>
    </my-port-container>
  </my-list>

Note that both "port-number" MUST be given the exact same value by the client.

In YANG, key leafs cannot be nested under containers.  I would simply have the key on the top of the list, and not in the container.

(It seems this is what others have proposed as well in this thread.)

[JY] Yes, I agree that this model is not very elegant, but the info model was published in IEEE 1588 already, people have been used to this info model for a long time and we would like to stick to it as far as we can. 
As an alternative, option 2 can be enhanced:
   list my-list { 
     key "port-number"; 
     leaf port-number { 
        type uint16; 
     } 
     container my-port-container { 
         leaf port-number { 
             type leafref{ 
               path "../../port-number"; 
             }
             config false;
         } 
         leaf other-leaf { 
           ... 
       } 
     } 
   }

In this way, the "config false" makes the leafref read-only, so that configuration doesn't need to write twice. How do you think about this scheme?
Thanks again,
Yuanlong


/martin





> Your opinions are very important for our revision of this draft.
> 
> Thanks,
> Yuanlong
> 
> 
> From: Sean Condon [mailto:sean.condon@microsemi.com]
> Sent: Wednesday, September 27, 2017 7:11 PM
> To: Jiangyuanlong
> Cc: tictoc@ietf.org; Rodney Cummings
> Subject: RE: draft-ietf-tictoc-1588v2-yang-05 - Concern over port 
> identifier
> 
> Thanks guys for your responses.
> 
> I accept your points to keep the structure as aligned to the IEEE 1588 
> standard as possible.
> 
> One alternate suggestion that I would make, is that the port-number 
> currently defined as leafref should be made the real attribute (i.e. 
> uint16) and that the port-number inside port-identity container should 
> be made in to the leaf ref (and set to mandatory true).
> 
> The reason I say this is that
> 
>   1.  XML models are usually navigated and constructed root-to-leaf, and
>   the way it's portrayed at the moment is that port-number leafref
>   points to something that may not exist at the time it is being
>   defined. This makes it difficult to implement.
>   2.  Also port-identity/port-number is not "mandatory true" meaning
>   that it could be left out altogether. It's not valid for it to have a
>   default value either since every item in the list will need a
>   different identifier.
> 
> With this suggestion the structure you require with port-identity 
> still exists, but now the implementation is more straightforward, and 
> the change will be transparent to an end user.
> 
> 
> Best regards, Sean
> =======================
> Sean Condon
> System & Software Architect
> Frequency & Timing Division
> Microsemi Inc.
> sean.condon@microsemi.com<mailto:sean.condon@microsemi.com>
> 
> ________________________________
> From: Jiangyuanlong [jiangyuanlong@huawei.com]
> Sent: 27 September 2017 08:05
> To: Sean Condon
> Cc: tictoc@ietf.org<mailto:tictoc@ietf.org>; Rodney Cummings
> Subject: RE: draft-ietf-tictoc-1588v2-yang-05 - Concern over port 
> identifier EXTERNAL EMAIL
> 
> Dear Sean,
> 
> 
> 
> Thank you a lot for diving into the technical details of this module. 
> Just as Rodney said, it is a challenge of 1588 info model to YANG, and 
> we use the leafref of YANG to work around it.
> 
> I would like to provide a little more backgrounds on the tradeoff:
> 
> 
> 
> 1. It says in Sec. 7.5.2.1 in IEEE 1588-2008: portIdentity is a member 
> of the portDS data set. A portIdentity consists of two attributes, as
> 
> follows:
> 
> ⎯ portIdentity.clockIdentity
> 
> ⎯ portIdentity.portNumber
> 
> Furthermore, the "portDS.portIdentity" attribute is mentioned quite a 
> few times in 1588-2008, especially in Table 17 and under Table 61, 
> with a hint that assignment and comparison can be done on this member 
> directly, thus it seems to me portIdentity is an important and well 
> understood construct in the 1588 specification.
> 
> 
> 
> 2. If we change portDS.portIdentity from a container to a grouping, 
> then there is no portIdentity for portDS and transparentclockPortDS in 
> the resulting tree diagram:
> 
> 
> 
> module: ietf-ptp-dataset
> 
>     +--rw instance-list* [instance-number]
> 
>     |  +--rw instance-number       uint16
> 
>     |  +--rw default-ds
> 
>     |  |  +--rw two-step-flag?    boolean
> 
>     |  |  +--rw clock-identity?   clock-identity-type
> 
>     |  |  +--rw number-ports?     uint16
> 
>     |  |  +--rw clock-quality
> 
>     |  |  |  +--rw clock-class?                  uint8
> 
>     |  |  |  +--rw clock-accuracy?               uint8
> 
>     |  |  |  +--rw offset-scaled-log-variance?   uint16
> 
>     |  |  +--rw priority1?        uint8
> 
>     |  |  +--rw priority2?        uint8
> 
>     |  |  +--rw domain-number?    uint8
> 
>     |  |  +--rw slave-only?       boolean
> 
>     |  +--rw current-ds
> 
>     |  |  +--rw steps-removed?        uint16
> 
>     |  |  +--rw offset-from-master?   time-interval-type
> 
>     |  |  +--rw mean-path-delay?      time-interval-type
> 
>     |  +--rw parent-ds
> 
>     |  |  +--rw parent-port-identity
> 
>     |  |  |  +--rw clock-identity?   clock-identity-type
> 
>     |  |  |  +--rw port-number?      uint16
> 
>     |  |  +--rw parent-stats?                                 boolean
> 
>     |  |  +--rw observed-parent-offset-scaled-log-variance?   uint16
> 
>     |  |  +--rw observed-parent-clock-phase-change-rate?      int32
> 
>     |  |  +--rw grandmaster-identity?                         binary
> 
>     |  |  +--rw grandmaster-clock-quality
> 
>     |  |  |  +--rw clock-class?                  uint8
> 
>     |  |  |  +--rw clock-accuracy?               uint8
> 
>     |  |  |  +--rw offset-scaled-log-variance?   uint16
> 
>     |  |  +--rw grandmaster-priority1?                        uint8
> 
>     |  |  +--rw grandmaster-priority2?                        uint8
> 
>     |  +--rw time-properties-ds
> 
>     |  |  +--rw current-utc-offset-valid?   boolean
> 
>     |  |  +--rw current-utc-offset?         int16
> 
>     |  |  +--rw leap59?                     boolean
> 
>     |  |  +--rw leap61?                     boolean
> 
>     |  |  +--rw time-traceable?             boolean
> 
>     |  |  +--rw frequency-traceable?        boolean
> 
>     |  |  +--rw ptp-timescale?              boolean
> 
>     |  |  +--rw time-source?                uint8
> 
>     |  +--rw port-ds-list* [port-number]
> 
>     |     +--rw clock-identity?                clock-identity-type
> 
>     |     +--rw port-number                    uint16
> 
>     |     +--rw port-state?                    port-state-enumeration
> 
>     |     +--rw underlying-interface?          if:interface-ref
> 
>     |     +--rw log-min-delay-req-interval?    int8
> 
>     |     +--rw peer-mean-path-delay?          time-interval-type
> 
>     |     +--rw log-announce-interval?         int8
> 
>     |     +--rw announce-receipt-timeout?      uint8
> 
>     |     +--rw log-sync-interval?             int8
> 
>     |     +--rw delay-mechanism?               delay-mechanism-enumeration
> 
>     |     +--rw log-min-pdelay-req-interval?   int8
> 
>     |     +--rw version-number?                uint8
> 
>     +--rw transparent-clock-default-ds
> 
>     |  +--rw clock-identity?    clock-identity-type
> 
>     |  +--rw number-ports?      uint16
> 
>     |  +--rw delay-mechanism?   delay-mechanism-enumeration
> 
>     |  +--rw primary-domain?    uint8
> 
>     +--rw transparent-clock-port-ds-list* [port-number]
> 
>        +--rw clock-identity?                clock-identity-type
> 
>        +--rw port-number                    uint16
> 
>        +--rw log-min-pdelay-req-interval?   int8
> 
>        +--rw faulty-flag?                   boolean
> 
>        +--rw peer-mean-path-delay?          time-interval-type
> 
> 
> 
> In contrast to the original 1588 YANG tree diagram:
> 
>    module: ietf-ptp-dataset
> 
>        +--rw instance-list* [instance-number]
> 
>        |  +--rw instance-number      uint16
> 
>        |  +--rw default-ds
> 
>        |  |  +--rw two-step-flag?    boolean
> 
>        |  |  +--rw clock-identity?   clock-identity-type
> 
>        |  |  +--rw number-ports?     uint16
> 
>        |  |  +--rw clock-quality
> 
>        |  |  |  +--rw clock-class?                  uint8
> 
>        |  |  |  +--rw clock-accuracy?               uint8
> 
>        |  |  |  +--rw offset-scaled-log-variance?   uint16
> 
>        |  |  +--rw priority1?        uint8
> 
>        |  |  +--rw priority2?        uint8
> 
>        |  |  +--rw domain-number?    uint8
> 
>        |  |  +--rw slave-only?       boolean
> 
>        |  +--rw current-ds
> 
>        |  |  +--rw steps-removed?       uint16
> 
>        |  |  +--rw offset-from-master?  time-interval-type
> 
>        |  |  +--rw mean-path-delay?     time-interval-type
> 
>        |  +--rw parent-ds
> 
>        |  |  +--rw parent-port-identity
> 
>        |  |  |  +--rw clock-identity?   clock-identity-type
> 
>        |  |  |  +--rw port-number?      uint16
> 
>        |  |  +--rw parent-stats?        boolean
> 
>        |  |  +--rw observed-parent-offset-scaled-log-variance? uint16
> 
>        |  |  +--rw observed-parent-clock-phase-change-rate?    int32
> 
>        |  |  +--rw grandmaster-identity?                       binary
> 
>        |  |  +--rw grandmaster-clock-quality
> 
>        |  |  |  +--rw clock-class?                  uint8
> 
>        |  |  |  +--rw clock-accuracy?               uint8
> 
>        |  |  |  +--rw offset-scaled-log-variance?   uint16
> 
>        |  |  +--rw grandmaster-priority1?           uint8
> 
>        |  |  +--rw grandmaster-priority2?           uint8
> 
>        |  +--rw time-properties-ds
> 
>        |  |  +--rw current-utc-offset-valid?   boolean
> 
>        |  |  +--rw current-utc-offset?         int16
> 
>        |  |  +--rw leap59?                     boolean
> 
>        |  |  +--rw leap61?                     boolean
> 
>        |  |  +--rw time-traceable?             boolean
> 
>        |  |  +--rw frequency-traceable?        boolean
> 
>        |  |  +--rw ptp-timescale?              boolean
> 
>        |  |  +--rw time-source?                uint8
> 
>        |  +--rw port-ds-list* [port-number]
> 
>        |     +--rw port-number        -> ../port-identity/port-number
> 
>        |     +--rw port-identity
> 
>        |     |  +--rw clock-identity?   clock-identity-type
> 
>        |     |  +--rw port-number?      uint16
> 
>        |     +--rw port-state?          port-state-enumeration
> 
>        |     +--rw underlying-interface? if:interface-ref
> 
>        |     +--rw log-min-delay-req-interval?    int8
> 
>        |     +--rw peer-mean-path-delay?          time-interval-type
> 
>        |     +--rw log-announce-interval?         int8
> 
>        |     +--rw announce-receipt-timeout?      uint8
> 
>        |     +--rw log-sync-interval?             int8
> 
>        |     +--rw delay-mechanism?     delay-mechanism-enumeration
> 
>        |     +--rw log-min-pdelay-req-interval?   int8
> 
>        |     +--rw version-number?                uint8
> 
>        +--rw transparent-clock-default-ds
> 
>        |  +--rw clock-identity?    clock-identity-type
> 
>        |  +--rw number-ports?      uint16
> 
>        |  +--rw delay-mechanism?   delay-mechanism-enumeration
> 
>        |  +--rw primary-domain?    uint8
> 
>        +--rw transparent-clock-port-ds-list* [port-number]
> 
>           +--rw port-number           -> ../port-identity/port-number
> 
>           +--rw port-identity
> 
>           |  +--rw clock-identity?   clock-identity-type
> 
>           |  +--rw port-number?      uint16
> 
>           +--rw log-min-pdelay-req-interval?   int8
> 
>           +--rw faulty-flag?                   boolean
> 
>           +--rw peer-mean-path-delay?         time-interval-type
> 
> 
> 
> I agree, assignment and comparison can still be done on clock-identity 
> and port-number directly (without a portIdentity construct) . But 
> people who are familiar with 1588-2008 may question where portIdentity 
> is gone.
> 
> 
> 
> 3. I think leafref is a very general semantics thing in YANG language, 
> if any tools have problem with this feature, maybe we need to contact 
> with the tool’s developer to support it.
> 
> 
> 
> Finally, more inputs from the WG are welcome.
> 
> 
> 
> Thanks again,
> 
> Yuanlong
> 
> 
> 
> 
> 
> -----Original Message-----
> From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Rodney 
> Cummings
> Sent: Wednesday, September 27, 2017 1:24 AM
> To: tictoc@ietf.org<mailto:tictoc@ietf.org>
> Subject: Re: [TICTOC] draft-ietf-tictoc-1588v2-yang-05 - Concern over 
> port identifier
> 
> 
> 
> Thanks Sean,
> 
> 
> 
> Regarding your other comment on TLD... I agree.
> 
> 
> 
> Regarding the comment below on port-identity, I agree that we need to 
> do it for practical reasons.
> 
> 
> 
> In 1588-2008, there is a distinct dataset member for 
> portDS.portIdentity, which 5.3.5 specifies as using type PortIdentity:
> 
>   struct PortIdentity {
> 
>     ClockIdentity clockIdentity;
> 
>     UInteger portNumber;
> 
>   }
> 
> 
> 
> If we interpret the 1588-2008 datasets as an information model, and 
> apply that as directly as possible to a YANG data model, 
> portDS.portIdentity is a container, which is what we have so far. That 
> introduces a challenge, because we want to use 
> portDS.portIdentity.portNumber as the key to the list of portDS's. We 
> solved that challenge with a leafref, but I'd agree that is ugly.
> 
> 
> 
> Your proposal changes portDS.portIdentity from a container to a 
> grouping, so that it portDS.portIdentity.portNumber can be used as the 
> key without a leafref.
> 
> 
> 
> The downside is that if/when a YANG management client tries to "get"
> portDS.portIdentity, it doesn't work... there is no portIdentity to 
> get.
> 
> 
> 
> Personally, I think that downside is worth it. One can argue that your 
> proposal still conforms to the 1588-2008 information model for 
> management, in that portDS.portIdentity still "exists" in a manner 
> that makes sense for YANG.
> 
> 
> 
> Rodney
> 
> 
> 
> 
> 
> 
> 
> From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Sean Condon
> 
> Sent: Tuesday, September 26, 2017 10:38 AM
> 
> To: tictoc@ietf.org<mailto:tictoc@ietf.org>
> 
> Subject: [TICTOC] draft-ietf-tictoc-1588v2-yang-05 - Concern over port 
> identifier
> 
> 
> 
> With reference to "YANG Data Model for IEEE 1588v2"
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht
> ml_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D05&d=DwMFAw&c=I_0YwoKy7z5LM
> TVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnb
> oKbZ8k&m=jKHczVNLN-KuV2HRZkbEZY1SzlCD_AztkaWSccrqBI8&s=msh7A7_OgHZ1l65
> Dn6_LhiDIXkXpFeiLGmKbKxsqXWw&e=
> 
> 
> 
> I have a concern about the structure of the YANG, and how the lists 
> port-ds-list and transparent-clock-port-ds-list are indexed with a 
> leaf which is a leafref.
> 
> 
> 
> The structure seems unnecessarily complex - port-number is represented 
> as a leaf directly beneath the list (to be used as key) and again 
> under the port-identity container. It is structured in a way that I 
> believe would make it difficult to work with some YANG tools in the 
> market.
> 
> 
> 
> The purpose of port-identity container is not clear from the document
> - it would achieve the same purpose if it was left out of 
> port-ds-entry and transparent-clock-port-ds-entry and instead the 
> grouping port-identity-grouping included directly.
> 
> 
> 
> See the attached files as original, a modified version and as a patch 
> file.
> 
> 
> 
> Sean Condon
> 
> =======================
> 
> Sean Condon
> 
> System & Software Architect
> 
> Frequency & Timing Division
> 
> Microsemi Inc.
> 
> mailto:sean.condon@microsemi.com
> 
> 
> 
> _______________________________________________
> 
> TICTOC mailing list
> 
> TICTOC@ietf.org<mailto:TICTOC@ietf.org>
> 
> https://www.ietf.org/mailman/listinfo/tictoc