Subject: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: port-number

From: Opher Ronen <[email-masked]>
Date: Tue, 3 Oct 2017 17:56:41 +0000

Hi Rodney & all,

   I am somewhat belatedly posting a post to this thread following an offline correspondence with Rodney in context of this subject. I hope my feedback is not too late to be constructive, and will be posted correctly as this is my first post to this thread.

   I will also apologize in advance that I will be mostly offline till mid-October, so will likely be able to reply to responses only then.

   Rodney shared with me the consideration on this aspect, and I believe his recent post attempt to integrate my offline on this topic.

   I hope some more detailed feedback will hopefully assist this draft advance in a manner aligned with my perception on this aspect from my involvement in the P1588 WG in general and it's Management SC in specific.

   I will first comment that following my correspondence with Rodney that I believe (with reservation given my low involvement in direct implementation of management interfaces) that an interface that would enable performing a get to obtain an overall structure including the information comprimsing a PTP portIdentity appears nice to have. I would assume that this information will not be the most frequent aspect a management system would query, but easing obtaining it if overhead is reasonable may be worthwhile.

   A possibly more significant comment is to stress that the clockIdentity portion of the portIdentity attribute is equal in all port within a PTP Instance, and equal to the clockIdentity attribute with the clock data set. This is explicitly stressed by a new sentence added to the next revision draft, intended to clarify this to the reader: "The clockIdentity portion of a portIdentity is equal to the clockIdentity of the PTP Instance that the PTP Port is included in, and is therefore equal among all PTP Ports inside the PTP Instance."

  In my view regardless of the option followed for the data model for portIdentity, the ability to directly configure the clockIdentity portion of it should be prevented to avoid generating a configuration violating the above status (possible hampering the operation of the PTP protocol if later used as data for portIdentity on the wire).

   If I understood correct yang data model enable to provide a leafref pointer to the clockIdentity from the instance data set level, possibly best reflecting the actual limitations regarding the portIdentity structure.

Best Regards,

    Opher Ronen

Rodney Cummings <[email-masked]><mailto:[email-masked]&gt>; wrote:

> Hi folks,

> One of the last topics that we need to resolve for WG Last Call of

> draft-ietf-tictoc-1588v2-yang-05 is the representation of port-number,

> which serves as the key to the list of 1588 port data sets

> (i.e. port-list). I've had some offline discussion with IEEE 1588 WG

> members, and I'm copying NETMOD members for YANG expertise.

> I think we can narrow the possible options to two, so I'm starting a

> new thread to focus on those.

> IEEE Std 1588-2008 is the time sync standard that specifies the

> information model on which draft-ietf-tictoc-1588v2-yang-05 is

> based. In IEEE Std 1588-2008, subclause 5.3.5 specifies the following

> data type to identify each logical port in the 1588 product:

>    struct PortIdentity {

>       ClockIdentity clockIdentity;

>       Uinteger16 portNumber;

>    };

> IEEE Std 1588-2008 uses this data type as the "portIdentity" of the

> port in its on-the-wire protocol, state machines, and so on. In other

> words, in the 1588 standard itself, portIdentity is a "real thing"

> with real implementation.

> IEEE Std 1588-2008 also specifies a list of logical ports in each

> "clock", and portIdentity.portNumber is used as the key to that list

> of ports.

> In the YANG of draft-ietf-tictoc-1588v2-yang-05, we use YANG-style

> names (e.g. port-list, port-number), but otherwise we've tried to keep

> consistent to the IEEE Std 1588-2008 information model.

> We have a challenge with port-number. If YANG represents port-identity

> as a container within port-list, YANG does not allow a key to be a

> leaf within a container, so we cannot use port-identity/port-number as

> the key to port-list.

> It seems that we have two options:

> Option 1: Use a leafref

> ---

> YANG summary:

>         list port-ds-list {

>           key "port-number";

>           leaf port-number {

>             type uint16;

>           }

>           container port-identity {

>              leaf clock-identity {

>                 type clock-identity-type;

>                 config false;

>              }

>              leaf port-number {

>                 type leafref{

>                    path "../../port-number";

>                 }

>                 config false;

>              }

>           }

>         }

> This has disadvantages from the YANG perspective, in that port-number

> is duplicated. The "config false" is intended to mitigate YANG

> implementation challenges, such that only one value of port-number is

> provided for configuration.

> Option 2: Use a grouping

> ---

> YANG summary:

>      grouping port-identity-grouping {

>        leaf clock-identity {

>          type clock-identity-type;

>        }

>        leaf port-number {

>          type uint16;

>        }

>      }

>      list port-ds-list {

>        key "port-number";

>        uses port-identity-grouping;

>      }

> This has disadvantages from the 1588 perspective, in that it is not

> possible for a 1588-aware management client to "get" portIdentity. We

> are removing a 1588 "real thing" from the data model in order to

> accommodate a syntax limitation of YANG.

I think that in general when you go from an information model to a

concrete data model, you need to adapt to the data modelling language

you are using, and this will in most cases mean that there will be

some differences; in some cases the data model structure is different,

and in some cases the data model will result in a more detailed

model.  How keys are specified is one such example.  If you were to

use SMIv2, you'd have to change the names (so that they are unique),

and you'd have to map the structures to conceptual tables.

Clients need to understand the data model in use (not just the

information model behid it).

> Question for NETMOD experts

> ---

> My personal preference is Option 1 (leafref). Nevertheless, if the

> "config false" does not provide sufficient mitigation for today's YANG

> implementations, we can go with Option 2.

I don't think any implementation would have any problem supporting

option 1, but it does look a bit odd.  Also, it only "helps" if the

client is getting the data using <get>, but it will not help if it is

using <get-config>.

I think that the cleanest solution is to not try to completely mimic

the structure from the information model, but make sure that the

text in the description statements make it clear that the data model

looks different compared to the information model, in order to help

the readers.

/martin

> Feedback is very much appreciated.

> Thanks folks,

> Rodney Cummings

> Co-author draft-ietf-tictoc-1588v2-yang-05

> _______________________________________________

> netmod mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/netmod

References:

  *   [TICTOC] draft-ietf-tictoc-1588v2-yang-05: port-number<https://mailarchive.ietf.org/arch/msg/tictoc/lm1xq37jffkSMms2XJll3N-ydC0>
Rodney Cummings <[email-masked]>

---

From: Rodney Cummings <[email-masked]>
Date: Tue, 3 Oct 2017 18:27:45 +0000

As the kids say... "lol".

Our emails crossed paths.

The proposal I just sent reflects Opher's view (I hope), as well as others. 

Opher: My latest proposal removes the duplicate clockIdentity entirely. 

From: TICTOC [mailto:[email-masked]] On Behalf Of Opher Ronen
Sent: Tuesday, October 3, 2017 12:57 PM
To: [email-masked]
Subject: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: port-number

Hi Rodney & all,

Best Regards,
    Opher Ronen

/martin

> mailto:[email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwMFAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=Tvq4PvUNekeS1IF42ycx_7KyiF9Ag9bUucZE51SFvCw&s=BahOyOIDKpAWICQOgrlu0aga7dBde8X07-oq2ilONkw&e=
> 

References:
. https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tictoc_lm1xq37jffkSMms2XJll3N-2DydC0&d=DwMFAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=Tvq4PvUNekeS1IF42ycx_7KyiF9Ag9bUucZE51SFvCw&s=8SBqP6TRNUiieCBN4IZ6qzNQ5ZEW8pCBAm1kAULa-Mg&e=
Rodney Cummings <mailto:[email-masked]>

---

From: Opher Ronen <[email-masked]>
Date: Tue, 3 Oct 2017 18:39:46 +0000

Thanks Rodney,

 If I understand your latest suggestion correctly it appears a good choice for this initial yang model, taking a "less-is-more" approach.

Someone interested in knowing e.g. all portId's currently configured can append the port-number values from the port-ds-list to the clockID from the instance level.

I assume if more structured to "get" portID is deemed an important feature it can be added in a later version of the data-model.

Opher

-----Original Message-----
From: Rodney Cummings [mailto:[email-masked]] 
Sent: Tuesday, October 3, 2017 9:28 PM
To: Opher Ronen <[email-masked]>; [email-masked]
Subject: RE: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: port-number

Hi Rodney & all,

Best Regards,
    Opher Ronen
 
Rodney Cummings <mailto:[email-masked]&gt; wrote:
> which serves as the key to the list of 1588 port data sets (i.e. 
> port-list). I've had some offline discussion with IEEE 1588 WG 
>information model on which draft-ietf-tictoc-1588v2-yang-05 is  based. 
>In IEEE Std 1588-2008, subclause 5.3.5 specifies the following  data 
>type to identify each logical port in the 1588 product:
>    struct PortIdentity {

I think that in general when you go from an information model to a concrete data model, you need to adapt to the data modelling language you are using, and this will in most cases mean that there will be some differences; in some cases the data model structure is different, and in some cases the data model will result in a more detailed model.  How keys are specified is one such example.  If you were to use SMIv2, you'd have to change the names (so that they are unique), and you'd have to map the structures to conceptual tables.

Clients need to understand the data model in use (not just the information model behid it).

> implementations, we can go with Option 2.

I don't think any implementation would have any problem supporting option 1, but it does look a bit odd.  Also, it only "helps" if the client is getting the data using <get>, but it will not help if it is using <get-config>.

I think that the cleanest solution is to not try to completely mimic the structure from the information model, but make sure that the text in the description statements make it clear that the data model looks different compared to the information model, in order to help the readers.

/martin

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_netmod&d=DwMFAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcS
> jixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=Tvq4PvUNekeS1IF42
> ycx_7KyiF9Ag9bUucZE51SFvCw&s=BahOyOIDKpAWICQOgrlu0aga7dBde8X07-oq2ilON
> kw&e=
> 

References:

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 9 Oct 2017 11:47:15 +0000

Hi Opher and all,

Thanks much for all the comments. So the consensus seems to me is - we agreed to model both port-number and clock-identity in the port-ds-list.
This will reflected in our next revision of draft-ietf-tictoc-1588v2-yang.
Definitely, later versions can take another approach with version control capability of YANG.

Cheers,
Yuanlong

-----Original Message-----
From: TICTOC [mailto:[email-masked]] On Behalf Of Opher Ronen
Sent: Wednesday, October 04, 2017 2:40 AM
To: Rodney Cummings; [email-masked]
Subject: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: port-number

Thanks Rodney,

Opher

-----Original Message-----
From: Rodney Cummings [mailto:[email-masked]]
Sent: Tuesday, October 3, 2017 9:28 PM
To: Opher Ronen <[email-masked]>; [email-masked]
Subject: RE: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: port-number

Hi Rodney & all,

Best Regards,
    Opher Ronen

/martin

References:

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Rodney Cummings <[email-masked]>
Date: Mon, 9 Oct 2017 15:38:30 +0000

Hi Yuanlong,

To be clear my proposal is:
- Model port-number directly in port-list as the key.
- Do not model clock-identity in port-list.
- Do not model port-identity in port-list.
- In the description of port-number, mention that port-identity is not explicitly modeled in YANG, but implicitly through the use of port-list[]/port-number and instance-list[]/clock-identity. See my previous email for proposed text.

Rodney

> From: Jiangyuanlong [mailto:[email-masked]]
> Sent: Monday, October 9, 2017 6:47 AM
> To: Opher Ronen ; Rodney Cummings ; [email-masked]
> Cc: Zongning ; Liushucheng (Will Liu) ; Zhuhengjun
> Thanks much for all the comments. So the consensus seems to me is - we
> agreed to model both port-number and clock-identity in the port-ds-list.
>  If I understand your latest suggestion correctly it appears a good choice
> for this initial yang model, taking a "less-is-more" approach.
> 
> Someone interested in knowing e.g. all portId's currently configured can
> append the port-number values from the port-ds-list to the clockID from
> the instance level.
> 
> I assume if more structured to "get" portID is deemed an important feature
> it can be added in a later version of the data-model.
> 
> Opher
> 
>    I am somewhat belatedly posting a post to this thread following an
> offline correspondence with Rodney in context of this subject. I hope my
> feedback is not too late to be constructive, and will be posted correctly
> as this is my first post to this thread.
>    I will also apologize in advance that I will be mostly offline till
> mid-October, so will likely be able to reply to responses only then.
>    Rodney shared with me the consideration on this aspect, and I believe
> his recent post attempt to integrate my offline on this topic.
>    I hope some more detailed feedback will hopefully assist this draft
> advance in a manner aligned with my perception on this aspect from my
> involvement in the P1588 WG in general and it's Management SC in specific.
>    I will first comment that following my correspondence with Rodney that
> I believe (with reservation given my low involvement in direct
> implementation of management interfaces) that an interface that would
> enable performing a get to obtain an overall structure including the
> information comprimsing a PTP portIdentity appears nice to have. I would
> assume that this information will not be the most frequent aspect a
> management system would query, but easing obtaining it if overhead is
> reasonable may be worthwhile.
>    A possibly more significant comment is to stress that the clockIdentity
> portion of the portIdentity attribute is equal in all port within a PTP
> Instance, and equal to the clockIdentity attribute with the clock data
> set. This is explicitly stressed by a new sentence added to the next
> revision draft, intended to clarify this to the reader: "The clockIdentity
> portion of a portIdentity is equal to the clockIdentity of the PTP
> Instance that the PTP Port is included in, and is therefore equal among
> all PTP Ports inside the PTP Instance."
>   In my view regardless of the option followed for the data model for
> portIdentity, the ability to directly configure the clockIdentity portion
> of it should be prevented to avoid generating a configuration violating
> the above status (possible hampering the operation of the PTP protocol if
> later used as data for portIdentity on the wire).
>    If I understood correct yang data model enable to provide a leafref
> pointer to the clockIdentity from the instance data set level, possibly
> best reflecting the actual limitations regarding the portIdentity
> structure.
> 
> Best Regards,
>     Opher Ronen
> 
> concrete data model, you need to adapt to the data modelling language you
> are using, and this will in most cases mean that there will be some
> differences; in some cases the data model structure is different, and in
> some cases the data model will result in a more detailed model.  How keys
> are specified is one such example.  If you were to use SMIv2, you'd have
> to change the names (so that they are unique), and you'd have to map the
> structures to conceptual tables.
> 
> I don't think any implementation would have any problem supporting option
> 1, but it does look a bit odd.  Also, it only "helps" if the client is
> getting the data using <get>, but it will not help if it is using <get-
> config>.
> 
> 
> I think that the cleanest solution is to not try to completely mimic the
> structure from the information model, but make sure that the text in the
> description statements make it clear that the data model looks different
> compared to the information model, in order to help the readers.
> 
> 
> 
> /martin
> 
> 
> 
> >
> . https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__mailarchive.ietf.org_arch_msg_tictoc_lm1xq37jffkSMms2XJll3N-
> 2DydC0&d=DwMFAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7D
> w7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=Tvq4PvUNekeS1IF42ycx_7KyiF9Ag9bUucZE51
> SFvCw&s=8SBqP6TRNUiieCBN4IZ6qzNQ5ZEW8pCBAm1kAULa-Mg&e=
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_tictoc&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCi
> E2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=3vIq
> KhIleK3ifzu2gqWugIUX62HPLM5VReDafflfyVY&s=jy6sTQ1a-
> mKqq1ymmNMj7g1kzyAcFvPE9emfALot4FE&e=

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 10 Oct 2017 01:55:22 +0000

Dear Rodney,

Thank a lot for the clarification.
It is not clear to me how clock-identity is modeled indeed (I changed the message title to reflect it). 
Currently, clock-identity is a member attribute in quite a few containers, such as default-ds, parent-ds. parent-port-identity, port-ds-list[]. port-identity, transparent-clock-default-ds, and transparent-clock-port-ds-list[].port-identity, but instance-list[] does not have clock-identity as its member. Are you suggesting to move clock-identity from default-ds into instance-list[]?
How do we model clock-identity in the transparent-clock-port-ds-list[], remove it too? 

Regards,
Yuanlong

-----Original Message-----
From: Rodney Cummings [mailto:[email-masked]] 
Sent: Monday, October 09, 2017 11:39 PM
To: Jiangyuanlong; Opher Ronen; [email-masked]
Cc: Zongning; Liushucheng (Will Liu); Zhuhengjun
Subject: RE: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: port-number

Hi Yuanlong,

Rodney

> Subject: RE: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: 
> port- number
> 
> Hi Opher and all,
> 
>  If I understand your latest suggestion correctly it appears a good 
> choice for this initial yang model, taking a "less-is-more" approach.
> 
> Someone interested in knowing e.g. all portId's currently configured 
> can append the port-number values from the port-ds-list to the clockID 
> from the instance level.
> 
> I assume if more structured to "get" portID is deemed an important 
> feature it can be added in a later version of the data-model.
> 
> Opher
> 
> Subject: RE: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: 
> port- number
> 
> offline correspondence with Rodney in context of this subject. I hope 
> my feedback is not too late to be constructive, and will be posted 
> correctly as this is my first post to this thread.
>    Rodney shared with me the consideration on this aspect, and I 
> believe his recent post attempt to integrate my offline on this topic.
>    I will first comment that following my correspondence with Rodney 
> that I believe (with reservation given my low involvement in direct 
> information comprimsing a PTP portIdentity appears nice to have. I 
> would assume that this information will not be the most frequent 
> aspect a management system would query, but easing obtaining it if 
> overhead is reasonable may be worthwhile.
>    A possibly more significant comment is to stress that the 
> clockIdentity portion of the portIdentity attribute is equal in all 
> port within a PTP Instance, and equal to the clockIdentity attribute 
> with the clock data set. This is explicitly stressed by a new sentence 
> added to the next revision draft, intended to clarify this to the 
> reader: "The clockIdentity portion of a portIdentity is equal to the 
> clockIdentity of the PTP Instance that the PTP Port is included in, 
> and is therefore equal among all PTP Ports inside the PTP Instance."
> portIdentity, the ability to directly configure the clockIdentity 
> portion of it should be prevented to avoid generating a configuration 
> violating the above status (possible hampering the operation of the 
> PTP protocol if later used as data for portIdentity on the wire).
> pointer to the clockIdentity from the instance data set level, 
> possibly best reflecting the actual limitations regarding the 
> portIdentity structure.
> 
> Best Regards,
>     Opher Ronen
> 
> > draft-ietf-tictoc-1588v2-yang-05 is the representation of 
> > port-number, which serves as the key to the list of 1588 port data sets (i.e.
> > names (e.g. port-list, port-number), but otherwise we've tried to 
> > keep consistent to the IEEE Std 1588-2008 information model.
> >
> > We have a challenge with port-number. If YANG represents 
> > port-identity as a container within port-list, YANG does not allow a 
> > key to be a leaf within a container, so we cannot use 
> > port-identity/port-number as the key to port-list.
> >
> > This has disadvantages from the YANG perspective, in that 
> > port-number is duplicated. The "config false" is intended to 
> > mitigate YANG implementation challenges, such that only one value of 
> > port-number is provided for configuration.
> >
> > Option 2: Use a grouping
> > ---
> >
> > YANG summary:
> >
> > possible for a 1588-aware management client to "get" portIdentity. 
> > We are removing a 1588 "real thing" from the data model in order to 
> and in some cases the data model will result in a more detailed model.  
> How keys are specified is one such example.  If you were to use SMIv2, 
> you'd have to change the names (so that they are unique), and you'd 
> have to map the structures to conceptual tables.
> 
> > "config false" does not provide sufficient mitigation for today's 
> > YANG implementations, we can go with Option 2.
> 
> using <get-
> the structure from the information model, but make sure that the text 
> in the description statements make it clear that the data model looks 
> different compared to the information model, in order to help the readers.
> 
> 
> 
> /martin
> 
> 
> 
> >
> w7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=Tvq4PvUNekeS1IF42ycx_7KyiF9Ag9bUuc
> ZE51 SFvCw&s=8SBqP6TRNUiieCBN4IZ6qzNQ5ZEW8pCBAm1kAULa-Mg&e=

---

From: Rodney Cummings <[email-masked]>
Date: Tue, 10 Oct 2017 14:02:29 +0000

My apologies Yuanlong,

I meant to use instance-list[]/default-ds/clock-identity. According to the 1588 standards, the value there is the same as the value in 1588's "portDS.portIdentity.clockIdentity".

The value of clock-identity in other locations is different.

Rodney

> Sent: Monday, October 9, 2017 8:55 PM
> To: Rodney Cummings ; Opher Ronen ; [email-masked]
> Subject: draft-ietf-tictoc-1588v2-yang-05: clock-identity
> 
> Dear Rodney,
> 
> Currently, clock-identity is a member attribute in quite a few containers,
> such as default-ds, parent-ds. parent-port-identity, port-ds-list[]. port-
> identity, transparent-clock-default-ds, and transparent-clock-port-ds-
> list[].port-identity, but instance-list[] does not have clock-identity as
> its member. Are you suggesting to move clock-identity from default-ds into
> instance-list[]?
> - In the description of port-number, mention that port-identity is not
> explicitly modeled in YANG, but implicitly through the use of port-
> list[]/port-number and instance-list[]/clock-identity. See my previous
> email for proposed text.
> 
> Rodney
>

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 11 Oct 2017 08:44:02 +0000

Rodney,

Thanks much, I got it now;)

Cheers,
Yuanlong

-----Original Message-----
From: Rodney Cummings [mailto:[email-masked]] 
Sent: Tuesday, October 10, 2017 10:02 PM
To: Jiangyuanlong; Opher Ronen; [email-masked]
Cc: Zongning; Liushucheng (Will Liu); Zhuhengjun
Subject: RE: draft-ietf-tictoc-1588v2-yang-05: clock-identity

My apologies Yuanlong,

Rodney

> Currently, clock-identity is a member attribute in quite a few 
> containers, such as default-ds, parent-ds. parent-port-identity, 
> port-ds-list[]. port- identity, transparent-clock-default-ds, and 
> transparent-clock-port-ds- list[].port-identity, but instance-list[] 
> does not have clock-identity as its member. Are you suggesting to move 
> clock-identity from default-ds into instance-list[]?
> How do we model clock-identity in the 
> transparent-clock-port-ds-list[], remove it too?
> 
> Regards,
> Yuanlong
> 
> > Thanks much for all the comments. So the consensus seems to me is - 
> > we agreed to model both port-number and clock-identity in the port-ds-list.
> > This will reflected in our next revision of 
> > draft-ietf-tictoc-1588v2-
> yang.
> > Subject: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: 
> > port- number
> >
> > Thanks Rodney,
> >
> > can append the port-number values from the port-ds-list to the 
> > clockID from the instance level.
> >
> > Subject: Re: [TICTOC] [netmod] draft-ietf-tictoc-1588v2-yang-05: 
> > port- number
> >
> > Hi Rodney & all,
> >    I am somewhat belatedly posting a post to this thread following 
> > an offline correspondence with Rodney in context of this subject. I 
> > hope my feedback is not too late to be constructive, and will be 
> > posted correctly as this is my first post to this thread.
> >    I will also apologize in advance that I will be mostly offline 
> > till mid-October, so will likely be able to reply to responses only then.
> >    I hope some more detailed feedback will hopefully assist this 
> > draft advance in a manner aligned with my perception on this aspect 
> > from my involvement in the P1588 WG in general and it's Management 
> > SC in
> specific.
> > implementation of management interfaces) that an interface that 
> > would enable performing a get to obtain an overall structure 
> > including the information comprimsing a PTP portIdentity appears 
> > nice to have. I would assume that this information will not be the 
> > most frequent aspect a management system would query, but easing 
> > obtaining it if overhead is reasonable may be worthwhile.
> > with the clock data set. This is explicitly stressed by a new 
> > sentence added to the next revision draft, intended to clarify this 
> > to the
> >   In my view regardless of the option followed for the data model 
> > for portIdentity, the ability to directly configure the 
> > clockIdentity portion of it should be prevented to avoid generating 
> > a configuration violating the above status (possible hampering the 
> > operation of the PTP protocol if later used as data for portIdentity on the wire).
> >    If I understood correct yang data model enable to provide a 
> > leafref pointer to the clockIdentity from the instance data set 
> > level, possibly best reflecting the actual limitations regarding the 
> > portIdentity structure.
> >
> > Best Regards,
> >     Opher Ronen
> >
> > > I think we can narrow the possible options to two, so I'm starting 
> > > a new thread to focus on those.
> > >
> > >In IEEE Std 1588-2008, subclause 5.3.5 specifies the following  
> > > IEEE Std 1588-2008 uses this data type as the "portIdentity" of 
> > >the port in its on-the-wire protocol, state machines, and so on. In 
> > >other words, in the 1588 standard itself, portIdentity is a "real thing"
> > > "clock", and portIdentity.portNumber is used as the key to that 
> > > list of ports.
> > >
> > > port-identity as a container within port-list, YANG does not allow 
> > > a key to be a leaf within a container, so we cannot use 
> > > mitigate YANG implementation challenges, such that only one value 
> > > of port-number is provided for configuration.
> > >
> > > Option 2: Use a grouping
> > > ---
> > >
> > > YANG summary:
> > >
> > > This has disadvantages from the 1588 perspective, in that it is 
> > > not possible for a 1588-aware management client to "get" portIdentity.
> > > We are removing a 1588 "real thing" from the data model in order 
> > > to accommodate a syntax limitation of YANG.
> >
> > concrete data model, you need to adapt to the data modelling 
> > language you are using, and this will in most cases mean that there 
> > will be some differences; in some cases the data model structure is 
> > different, and in some cases the data model will result in a more detailed model.
> > How keys are specified is one such example.  If you were to use 
> > SMIv2, you'd have to change the names (so that they are unique), and 
> > you'd have to map the structures to conceptual tables.
> >
> > client is getting the data using <get>, but it will not help if it 
> > is using <get-
> > config>.
> >
> >
> > the
> readers.
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
> > > ma
> > > il
> > > man_listinfo_netmod&d=DwMFAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIP
> > > el
> > > cS
> > > jixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=Tvq4PvUNekeS1
> > > IF
> > > 42
> > > ycx_7KyiF9Ag9bUucZE51SFvCw&s=BahOyOIDKpAWICQOgrlu0aga7dBde8X07-oq2
> > > il
> > > ON
> > > kw&e=
> > >
> >
> > References:
> > 2DydC0&d=DwMFAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71
> > sf
> > 2o7D
> > 3A__www.ietf.org_mailman_listinfo_tictoc&d=DwIFgQ&c=I_0YwoKy7z5LMTVd
> > yO
> > 6YCi
> > E2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&
> > m=
> > 3vIq