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 protected]> wrote: > > 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 protected]] > 发送时间: 2017年11月22日 1:56 > 收件人: Jiangyuanlong; [email protected]; Alex Campbell; Karen O'Donoghue > 抄送: Xian Liu; Xujinchun; [email protected] > 主题: RE: Using instance-number or instance-name issue - RE: WG Last Call > resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06 > > 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 protected]] > Sent: Monday, November 20, 2017 7:34 AM > To: [email protected]; Alex Campbell ; Rodney Cummings ; Karen O'Donoghue > Cc: Xian Liu ; Xujinchun ; [email protected] > Subject: Using instance-number or instance-name issue - RE: WG Last Call > resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06 > > 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 protected]> > To: "Alex Campbell" <[email protected]>; <[email protected]> > Cc: "Xian Liu" <[email protected]>; "Xujinchun" > <[email protected]>; <[email protected]> > 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 protected]] >> Sent: Monday, October 30, 2017 10:15 AM >> To: Jiangyuanlong; [email protected] >> Cc: Xian Liu; Xujinchun; [email protected] >> 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 protected]> on behalf of Jiangyuanlong > <[email protected]> >> Sent: Friday, 27 October 2017 3:21 p.m. >> To: [email protected] >> Cc: Xian Liu; Xujinchun; [email protected] >> 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 protected] [mailto:[email protected]] >> Sent: Friday, October 27, 2017 9:48 AM >> To: Xian Liu; Rodney Cummings; [email protected]; 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://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= >> >> 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 protected] >> 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= >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> 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= > > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
