Subject: Re: [TICTOC] +AFs-netmod+AF0- WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

From: "t.petch" <[email-masked]>
Date: Thu, 9 Nov 2017 17:47:55 -0000

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
Sent: Thursday, November 09, 2017 1:58 AM

Tom,

Good to know all your viewpoints. We will add a sentence in Section 2
explaining the logic of YANG style names in this document, maybe put it
as a note in the 2nd paragraph (as these names are used in the 3rd
paragraph) .

<tp>

Yuanlong,

Another belated thought.

It is common practice, and I think a good one, to include a sentence
just before the YANG module giving Normative references to other RFC
andsuch like that are referenced, implicitly or explicitly, in the
module itself (which, of course, cannot contain the references in the
same way that the rest of the RFC can).  The sentence does not become
part of the YANG module but anyone harking back to the RFC will quickly
find where to go for more information.

draft-ietf-netmod-rfc7277bis-00 gives a good example of this.  For this
I-D, I would suggest references to IEEE Std 1588-2008 and the RFC from
which ietf-interfaces is imported.

Tom Petch

Thanks,
Yuanlong

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Wednesday, November 08, 2017 9:12 PM
To: Jiangyuanlong; Alex Campbell; [email-masked]
Cc: Xian Liu; Xujinchun; [email-masked]
Subject: Re: [netmod] WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06

Yuanglong

I think that your Introduction is fine, and would not shorten it at all.
(I think that the Introduction to most I-Ds that describe YANG modules
is woefully weak).

I think too that you are spot on with your terminology; where IEEE
1588-2008 has an accepted way of working, then that is the right way for
this I-D.

One fresh comment arising from that.  You commented earlier that you had
departed from IEEE 1588-2008 in changing camel case to the YANG style
names, with hyphens, and I think that that is a logical choice.  But I
would go further and explain that choice so that those coming from IEEE
1588-2008 understand what has happened and why.  Not sure where to put
that; probably Section 2, perhaps immediately before the tree diagram,
since that is when readers will be exposed to the issue.

If you have done more than just change the style of name, then it would
be worth having a concordance of IEEE 1588-2008 names and YANG names;
this was common practice with MIB Modules.

Tom Petch

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
To: "Alex Campbell" <[email-masked]>; <[email-masked]>
Cc: "Xian Liu" <[email-masked]>; "Xujinchun"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, November 07, 2017 7:53 AM
Subject: Re: [netmod] WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06

> 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:[email-masked]]
> Sent: Monday, October 30, 2017 10:15 AM
> To: Jiangyuanlong; [email-masked]
> Cc: Xian Liu; Xujinchun; [email-masked]
> 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 <[email-masked]> on behalf of Jiangyuanlong
<[email-masked]>
> Sent: Friday, 27 October 2017 3:21 p.m.
> To: [email-masked]
> Cc: Xian Liu; Xujinchun; [email-masked]
> 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: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 27, 2017 9:48 AM
> To: Xian Liu; Rodney Cummings; [email-masked]; 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.tx
t
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 10 Nov 2017 01:27:03 +0000

Dear Tom,

Good suggestion, we will adding this note of references at the beginning of Section 3.

Cheers,
Yuanlong

-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: Friday, November 10, 2017 1:48 AM
To: Jiangyuanlong; Alex Campbell; [email-masked]
Cc: Xian Liu; Xujinchun; [email-masked]
Subject: Re: +AFs-netmod+AF0- WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
Sent: Thursday, November 09, 2017 1:58 AM

Tom,

Good to know all your viewpoints. We will add a sentence in Section 2 explaining the logic of YANG style names in this document, maybe put it as a note in the 2nd paragraph (as these names are used in the 3rd
paragraph) .

<tp>

Yuanlong,

Another belated thought.

It is common practice, and I think a good one, to include a sentence just before the YANG module giving Normative references to other RFC andsuch like that are referenced, implicitly or explicitly, in the module itself (which, of course, cannot contain the references in the same way that the rest of the RFC can).  The sentence does not become part of the YANG module but anyone harking back to the RFC will quickly find where to go for more information.

draft-ietf-netmod-rfc7277bis-00 gives a good example of this.  For this I-D, I would suggest references to IEEE Std 1588-2008 and the RFC from which ietf-interfaces is imported.

Tom Petch

Thanks,
Yuanlong

-----Original Message-----
From: t.petch [mailto:[email-masked]]
Sent: Wednesday, November 08, 2017 9:12 PM
To: Jiangyuanlong; Alex Campbell; [email-masked]
Cc: Xian Liu; Xujinchun; [email-masked]
Subject: Re: [netmod] WG Last Call resolutions incorporated in

Yuanglong

I think that your Introduction is fine, and would not shorten it at all.
(I think that the Introduction to most I-Ds that describe YANG modules is woefully weak).

I think too that you are spot on with your terminology; where IEEE
1588-2008 has an accepted way of working, then that is the right way for this I-D.

One fresh comment arising from that.  You commented earlier that you had departed from IEEE 1588-2008 in changing camel case to the YANG style names, with hyphens, and I think that that is a logical choice.  But I would go further and explain that choice so that those coming from IEEE
1588-2008 understand what has happened and why.  Not sure where to put that; probably Section 2, perhaps immediately before the tree diagram, since that is when readers will be exposed to the issue.

If you have done more than just change the style of name, then it would be worth having a concordance of IEEE 1588-2008 names and YANG names; this was common practice with MIB Modules.

Tom Petch

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
To: "Alex Campbell" <[email-masked]>; <[email-masked]>
Cc: "Xian Liu" <[email-masked]>; "Xujinchun"

trip.
> 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.
> [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.
normative
been
using
configuration
NETCONF
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.
message
> [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.
concerns?
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.
module?
Xujinchun
IETF repository.
> 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.

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 20 Nov 2017 13:34:23 +0000

Hi all,

Item #5 below is the last open issue we discussed both in emails and in IEEE 1588 mailing list on draft-ietf-tictoc-1588v2-yang.  
In a summary: in draft-ietf-tictoc-1588v2-yang, list instance-list has a key of "instance-number", but there were discussions whether to use instance-name (a string) instead.

Currently, "instance-number" in draft-ietf-tictoc-1588v2-yang-06 aligns well with the texts in the new revision of IEEE 1588 (D1.2/2017): 
   "The instanceList is indexed using a number that is unique per PTP Instance within the PTP Node, applicable to the 
   management context only (i.e. not used in PTP messages). The domainNumber of the PTP Instance must not be used as the index 
   to instanceList, since it is possible for a PTP Node to contain multiple PTP Instances using the same domainNumber."

The main requirement of instanceList in IEEE 1588 is the uniqueness of its index, and the "key" statement of YANG serves this purpose very well.

That is, when instance-number is used as a key, a PTP Node with multiple PTP Instances cannot use the same instance-number value for these PTP Instances (just according to YANG semantics).

Using instance-name (string) can also guarantee the uniqueness of the index of a list, but compared with an integer, a string is usually more complex to process and store. If instance-name is modeled as an arbitrary length of string, there is even a risk of buffer-overflow attack.

Furthermore, it should be noted that draft-ietf-tictoc-1588v2-yang is targeted at IEEE 1588-2008, for which most products today only have a single PTP instance, and not have a name for this instance, it seems quite weird to introduce a name for this instance.

Therefore, I would suggest we keep on using instance-number as a key. But as 65536 limit is a concern, I further suggest to change its type to uint32.

Any comments or concerns on this suggestion to move forward?

Thanks,
Yuanlong

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
To: "Alex Campbell" <[email-masked]>; <[email-masked]>
Cc: "Xian Liu" <[email-masked]>; "Xujinchun"

trip.
normative
been
using
configuration
NETCONF
1588(-2008)?
message
concerns?
module?
Xujinchun
IETF repository.

---

From: Rodney Cummings <[email-masked]>
Date: Tue, 21 Nov 2017 17:55:38 +0000

Hi Yuanlong,

I have no concerns with instance-number, as that is what the upcoming 1588 revision outlines for management.

I also have no strong objections against changing instance-number to instance-name. If we do that, I think it would be best to make the same change in the upcoming 1588 revision. I asked the 1588 working group for opinion, but I haven't heard back on that.

All things being equal, my preference is to go with instance-number.

Rodney

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Monday, November 20, 2017 7:34 AM
To: [email-masked]; Alex Campbell ; Rodney Cummings ; Karen O'Donoghue 
Cc: Xian Liu ; Xujinchun ; [email-masked]
Subject: Using instance-number or instance-name issue - RE: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

Hi all,

Thanks,
Yuanlong

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
To: "Alex Campbell" <[email-masked]>; <[email-masked]>
Cc: "Xian Liu" <[email-masked]>; "Xujinchun"

trip.
normative
been
using
configuration
NETCONF
1588(-2008)?
message
concerns?
module?
Xujinchun
IETF repository.
> Document date:  2017-10-26
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06.tx&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=N0N5kBPcGMivXWwspHEOc-bP0mbYpkKu2IvM2Asyf_8&e=
t
> Status:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang_&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=aYlovx_kTQtAiJAUMTJn8NCRZQIi_jEVNa-tC_5HFlk&e=
> Htmlized:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=j1aDjiU7AeuEV-p20PNwNpvZPrGSbBiHLHta7q05pak&e=
> Htmlized:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=7tYOv1M_EYHCPG1MiOq3BVl7vpB0w-LSiDYcQHM4ayM&e=
> Diff:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=Z12Xm_2k7cEAlV7lFQb_zw7A-D-HL77C-Kuy2BgyCHA&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=cUl0d0wDX9fIwjIEHlhcrfg17x7phpI9QiF5PuXsYd4&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=cUl0d0wDX9fIwjIEHlhcrfg17x7phpI9QiF5PuXsYd4&e=

---

From: Xujinchun <[email-masked]>
Date: Wed, 22 Nov 2017 03:18:16 +0000

Hi Rodney,

In my opinion, instance-name or instance-number does not matter if the number of instances are small. But if the instances may grow into hundreds or more in scale, then string should not be a choice.

We know how awkward it is to store and sort out a key of string compared with an integer.

Thanks

Jinchun XU

-----邮件原件-----
发件人: Rodney Cummings [mailto:[email-masked]] 
发送时间: 2017年11月22日 1:56
收件人: Jiangyuanlong; [email-masked]; Alex Campbell; Karen O'Donoghue
抄送: Xian Liu; Xujinchun; [email-masked]
主题: RE: Using instance-number or instance-name issue - RE: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

Hi Yuanlong,

Rodney

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Monday, November 20, 2017 7:34 AM
To: [email-masked]; Alex Campbell ; Rodney Cummings ; Karen O'Donoghue 
Cc: Xian Liu ; Xujinchun ; [email-masked]
Subject: Using instance-number or instance-name issue - RE: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

Hi all,

Thanks,
Yuanlong

----- Original Message -----
From: "Jiangyuanlong" <[email-masked]>
To: "Alex Campbell" <[email-masked]>; <[email-masked]>
Cc: "Xian Liu" <[email-masked]>; "Xujinchun"

trip.
normative
been
using
configuration
NETCONF
1588(-2008)?
message
concerns?
module?
Xujinchun
IETF repository.

---

From: Bob kb8tq <[email-masked]>
Date: Wed, 22 Nov 2017 08:16:22 -0500

Hi

If you change to “instance name” be very clear on the character set(s) allowed. I have seen some really bad side 
effects when unexpected character sets show up in ID fields. Software tries to parse it for presentation on a screen
or into a log. The result is a crash or lockup. 

Bob 

> On Nov 21, 2017, at 10:18 PM, Xujinchun <[email-masked]> wrote:
> 
> Hi Rodney,
> 
> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Nov 2017 15:51:12 +0100

According to RFC 7950, section 9.4, YANG strings are Unicode and
ISO/IEC 10646 characters, including tab, carriage return, and line
feed but excluding the other C0 control characters, the surrogate
blocks, and the noncharacters. Of course, handling Unicode correctly
can still be a lot of fun and systems that do not get this right might
still crash or lockup.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 23 Nov 2017 02:17:33 +0000

Juergen & Bob, 

Can I assume you are in support of using instance-number in this case? ^&^
But seriously, maybe it makes sense to restrict the valid characters of a string, especially when it is used as a key.
Otherwise, we need to note this risk in "Security considerations" of a RFC (actually it can become a kind of DoS attack). 

Thanks,
Yuanlong

-----Original Message-----
From: TICTOC [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, November 22, 2017 10:51 PM
To: Bob kb8tq
Cc: Xian Liu; Xujinchun; Karen O'Donoghue; [email-masked]; [email-masked]
Subject: Re: [TICTOC] [netmod] Using instance-number or instance-name issue - RE: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

According to RFC 7950, section 9.4, YANG strings are Unicode and ISO/IEC 10646 characters, including tab, carriage return, and line feed but excluding the other C0 control characters, the surrogate blocks, and the noncharacters. Of course, handling Unicode correctly can still be a lot of fun and systems that do not get this right might still crash or lockup.

/js

On Wed, Nov 22, 2017 at 08:16:22AM -0500, Bob kb8tq wrote:
> Hi
> 
> If you change to “instance name” be very clear on the character set(s) 
> allowed. I have seen some really bad side effects when unexpected 
> character sets show up in ID fields. Software tries to parse it for presentation on a screen or into a log. The result is a crash or lockup.
> 
> Bob
> 
> > 主题: RE: Using instance-number or instance-name issue - RE: WG Last 
> > Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
> > 
> > Hi Yuanlong,
> > 
> > Subject: Using instance-number or instance-name issue - RE: WG Last 
> > Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
> > 
> > Hi all,
> > 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_in
> > ternet-2Ddrafts_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06.tx&d=DwIF
> > gQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhF
> > t24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMI
> > qStw&s=N0N5kBPcGMivXWwspHEOc-bP0mbYpkKu2IvM2Asyf_8&e=
> > t
> >> Status:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet
> > f.org_doc_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang_&d=DwIFgQ&c=I_0YwoKy
> > 7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuup
> > swWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=aYlovx
> > _kTQtAiJAUMTJn8NCRZQIi_jEVNa-tC_5HFlk&e=
> >> Htmlized:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_
> > html_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=DwIFgQ&c=I_0YwoKy7
> > z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuups
> > wWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=j1aDjiU
> > 7AeuEV-p20PNwNpvZPrGSbBiHLHta7q05pak&e=
> >> Htmlized:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet
> > f.org_doc_html_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=DwIFgQ&c
> > =I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24D
> > Pjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw
> > &s=7tYOv1M_EYHCPG1MiOq3BVl7vpB0w-LSiDYcQHM4ayM&e=
> >> Diff:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rf
> > cdiff-3Furl2-3Ddraft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=DwIFgQ&c
> > =I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24D
> > Pjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw
> > &s=Z12Xm_2k7cEAlV7lFQb_zw7A-D-HL77C-Kuy2BgyCHA&e=
> >> 
> >> Abstract:
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_m
> >> ailman_listinfo_netmod&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZu
> >> IPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E
> >> _rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=cUl0d0wDX9fIwjIEHlhcrfg17x7ph
> >> pI9QiF5PuXsYd4&e=
> >> 
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_m
> >> ailman_listinfo_netmod&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZu
> >> IPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E
> >> _rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=cUl0d0wDX9fIwjIEHlhcrfg17x7ph
> >> pI9QiF5PuXsYd4&e=
> >

---

From: Bob kb8tq <[email-masked]>
Date: Wed, 22 Nov 2017 21:57:32 -0500

Hi

I’m fine with instance number. I would not rule out instance name. I’m simply concerned about
a wide open field. 

I would suggest a specific sub-set of characters be allowed if it goes to “instance name”. The
normal printable characters should be adequate. They generally are handled well by just about
anything you would ever use.

This is not something that is going to be an immediate crash sort of issue. It only will be a source of odd 
system to system weirdness. Tracking those sorts of issues down can be very painful. The last one
I ran into took about 4 months of poking at this and poking at that. Indeed a few lines of code would 
have prevented the problem altogether. Possibly I’ve just been uniquely un-lucky in this regard. 

Bob

> On Nov 22, 2017, at 9:17 PM, Jiangyuanlong <[email-masked]> wrote:
> 
> Juergen & Bob, 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 23 Nov 2017 08:12:29 +0100

I have no opinion in this specific context. That said, I generally
prefer names over numbers in configuration items.

I agree that using a plain YANG string can lead to surprises and
potential security issues if people do not expect that the identifier
can contain almost arbitrary characters. In LMAP, I started to use an
idententifier type but then at the end there was no clear opinion what
the appropriate restrictions would be and hence we ended up with a
hint to implementors in the security considerations:

   The data model uses a number of identifiers that are set by the
   Controller.  Implementors may find these identifiers useful for the
   identification of resources, e.g., to identify objects in a file
   system providing temporary storage.  Since the identifiers used by
   the YANG data model may allow characters that may be given special
   interpretation in a specific context, implementations must ensure
   that identifiers are properly mapped into safe identifiers.

I think it would be useful to have a data type (i.e.,
config-identifier) that is commonly used to name configuration
items. But it is unclear to me how to define such a type. The
yang-identifier defined in RFC 6991 is likely too restrictive if you
look at it from an internationalization point of view.

/js

---

From: Jiangyuanlong <[email-masked]>
Date: Sat, 25 Nov 2017 02:05:27 +0000

Good practice. I think it makes sense to consider YANG internationalization as a whole, perhaps in a open source project , or define a YANG module to support internationalization, then any YANG module can import this internationalization-support module if needed.

Back to the issue of instance-number or instance-name, I believe the original commenter's main concern (that is, uint16 may be too limited) has been resolved by using an instance-number of type uint32, so we will go with instance-number.

Cheers,
Yuanlong

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, November 23, 2017 3:12 PM
To: Jiangyuanlong
Cc: Bob kb8tq; Xian Liu; Xujinchun; Karen O'Donoghue; [email-masked]; [email-masked]
Subject: Re: [TICTOC] [netmod] Using instance-number or instance-name issue - RE: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

I have no opinion in this specific context. That said, I generally prefer names over numbers in configuration items.

I agree that using a plain YANG string can lead to surprises and potential security issues if people do not expect that the identifier can contain almost arbitrary characters. In LMAP, I started to use an idententifier type but then at the end there was no clear opinion what the appropriate restrictions would be and hence we ended up with a hint to implementors in the security considerations:

I think it would be useful to have a data type (i.e.,
config-identifier) that is commonly used to name configuration items. But it is unclear to me how to define such a type. The yang-identifier defined in RFC 6991 is likely too restrictive if you look at it from an internationalization point of view.

/js

On Thu, Nov 23, 2017 at 02:17:33AM +0000, Jiangyuanlong wrote:
> Juergen & Bob,
> 
> Can I assume you are in support of using instance-number in this case? 
> ^&^ But seriously, maybe it makes sense to restrict the valid characters of a string, especially when it is used as a key.
> Subject: Re: [TICTOC] [netmod] Using instance-number or instance-name 
> issue - RE: WG Last Call resolutions incorporated in 
> > If you change to “instance name” be very clear on the character 
> > set(s) allowed. I have seen some really bad side effects when 
> > unexpected character sets show up in ID fields. Software tries to parse it for presentation on a screen or into a log. The result is a crash or lockup.
> > 
> > Bob
> > 
> > > Subject: Using instance-number or instance-name issue - RE: WG 
> > > Last Call resolutions incorporated in 
> > > t24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZ
> > > MI qStw&s=N0N5kBPcGMivXWwspHEOc-bP0mbYpkKu2IvM2Asyf_8&e=
> > > t
> > >> Status:
> > > swWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=aYlo
> > > vx _kTQtAiJAUMTJn8NCRZQIi_jEVNa-tC_5HFlk&e=
> > >> Htmlized:
> > > wWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=j1aDj
> > > iU 7AeuEV-p20PNwNpvZPrGSbBiHLHta7q05pak&e=
> > >> Htmlized:
> > > Pjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqS
> > > tw &s=7tYOv1M_EYHCPG1MiOq3BVl7vpB0w-LSiDYcQHM4ayM&e=
> > >> Diff:
> > > Pjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqS
> > > tw &s=Z12Xm_2k7cEAlV7lFQb_zw7A-D-HL77C-Kuy2BgyCHA&e=
> > >> 
> > >> Abstract: