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 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. > 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:tictoc-boun...@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, November 22, 2017 10:51 PM > To: Bob kb8tq > Cc: Xian Liu; Xujinchun; Karen O'Donoghue; netmod@ietf.org; tic...@ietf.org > 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 > > > > > On Nov 21, 2017, at 10:18 PM, Xujinchun <xujinc...@huawei.com> 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:rodney.cummi...@ni.com] > > > 发送时间: 2017年11月22日 1:56 > > > 收件人: Jiangyuanlong; tic...@ietf.org; Alex Campbell; Karen O'Donoghue > > > 抄送: Xian Liu; Xujinchun; netmod@ietf.org > > > 主题: 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:jiangyuanl...@huawei.com] > > > Sent: Monday, November 20, 2017 7:34 AM > > > To: tic...@ietf.org; Alex Campbell ; Rodney Cummings ; Karen > > > O'Donoghue > > > Cc: Xian Liu ; Xujinchun ; netmod@ietf.org > > > 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" <jiangyuanl...@huawei.com> > > > To: "Alex Campbell" <alex.campb...@aviatnet.com>; <tic...@ietf.org> > > > Cc: "Xian Liu" <lene.liux...@foxmail.com>; "Xujinchun" > > > <xujinc...@huawei.com>; <netmod@ietf.org> > > > 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:alex.campb...@aviatnet.com] > > >> Sent: Monday, October 30, 2017 10:15 AM > > >> To: Jiangyuanlong; tic...@ietf.org > > >> Cc: Xian Liu; Xujinchun; netmod@ietf.org > > >> 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 <netmod-boun...@ietf.org> on behalf of Jiangyuanlong > > > <jiangyuanl...@huawei.com> > > >> Sent: Friday, 27 October 2017 3:21 p.m. > > >> To: tic...@ietf.org > > >> Cc: Xian Liu; Xujinchun; netmod@ietf.org > > >> 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: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > > >> Sent: Friday, October 27, 2017 9:48 AM > > >> To: Xian Liu; Rodney Cummings; rodney.cummi...@ni.com; > > >> 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_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: > > >> 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 > > >> netmod@ietf.org > > >> 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= > > >> > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> 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= > > > > > > _______________________________________________ > > > TICTOC mailing list > > > tic...@ietf.org > > > https://www.ietf.org/mailman/listinfo/tictoc > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > 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/> > > _______________________________________________ > TICTOC mailing list > tic...@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc -- 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/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
