[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: The saga on "manage identification"
I agree completely. The standard only states "...provide unambiguous identification..." without stating how this unambiguity (sic) should be achieved. The capability, on the other hand, does specify that the triplet [id,class,org] must be unique, which is where such a restriction belongs. In the future a new id capability could conceivably be defined with some alternate way of achieveing uniqueness. If I do not read this wrong it confirms my earlier longwinded argument, i.e. do not restrict PLCS, put the restrictions in DEX/capabilities. Regards, Per-Åke Gordon Robb wrote: > > Gentlefolk > Isn't it time to remind ourselves of what the PLCS AP 239 definition of > "manage identification" states > > "Manage identification > action to provide unambiguous identification of all elements, and > versions, of the product or support system to which reference needs to > be made, identification of interfaces between elements, the necessary > assembly, and other breakdowns structures, required to manage the > product through life and definition of the information to be held for > each type of product and support system element > > NOTE This activity occurs throughout the product life cycle and is > the basis of management of configuration change and configuration status > accounting of a product and all constituent configuration items. The > purposes and benefits of this activity include: > > · determining the structure (hierarchy) of a product and the > organization and relationships of configuration documentation and other > product information; > > · documentation of the performance, interface and other attributes > of a product; > · determination of the appropriate level of identification marking > of product and documentation; > · unique identification of a product or component part of a product; > · unique identification of the technical documents describing the > product; > · modification of identification of product and documents to > reflect incorporation of change; > · distinction between product versions; > · correlation of document revision level to product version; > · correlation of a PIF to related user or maintenance instructions > at the configuration item level." > > That definition is catered for by Capability (C001):- > assigning_identifiers which states in its introduction > "The purpose of this capability is to assign identifiers to entities > within the model that may be the subject of identification. There are > three components to identification; > > the identifier and its assignment > the organization that owns the identifier > the meaning of the identifier (e.g. serial number) as provided > by the classification > The approach adopted here is compatible with that provided in the DOD > Memorandum "The Department of Defence Guide to Uniquely Identifying > Items, Version 1.3" dated November 25th, 2003. See > (http://www.acq.osd.mil/uid) for the source. This memorandum applies to > high value tangible assets (such as an aircraft). However, the approach > here is much broader than the DoD approach and covers none tangible > assets (such as a maintenance task). > > NOTE The identifier shall be unique within the organization that owns > it. > > EXAMPLE A DUNS code or a CAGE Code is an example of an identification > that can be assigned to an organization. > > EXAMPLE A Part Number is an example of an identification that can be > assigned to the design of a Part. > > EXAMPLE A Serial Number is an example of an identification that can > be assigned to a physical instance of a Part (a Product_as_individual) > > The methodology of 'References to Identification_Assignment' is > depicted in the attachment. > > Whilst the modellers may wish to battle out their preferences I would > like to state that the way DEX 1 and DEX 8 are compiled (noting there > will be fine tuning to take place post the revision to module 1164 PAI > and possible 1251 Interface) meet the business requirements for managing > the id. > > The bottom line is that a serial number allocated by the 'OEM' is a > through life serial number that provides unambiguous identification and > traceability of the asset if required. Through configuration changes in > its life the PIF part number//section/reference number//National or NATO > stock number will change BUT the serial number remains the same. > > regards > > Gordon > > > > > > > > > > > > > -----Original Message----- > From: Per-Åke Ling [mailto:per-ake.ling@eurostep.com] > Sent: 26 October 2004 18:55 > To: Tim Turner > Cc: Rob Bodington; john.dunford@eurostep.com; 'Tim King'; > torirgen@eunet.no; trine.hansen@dnv.com; plcs@lists.oasis-open.org; > leif.tonning@dnv.com; 'Leif Gyllström' > Subject: Re: [plcs] Workshop #2 - Synchronise work on DEXs and reference > data between PLCS pilots and OASIS/PLCS > > > Hmmm, yes. But, it would be a headache to ensure uniqueness in the model > iteself, as you pointed out it should be a business issue. If specified > at all it should be in a DEX, not in the model. The reason for this > being that it is very difficult to define what constitutes uniqueness, > consider the following cases: > > 1. same id, different organisations > 2. same id, different effectivity > 3. same id, different classification > 4. same id, different context > ... > > So, given that identification is multidimensional, what constraints can > the model enforce that would sit comfortably with every implementation ? > > On the other hand, considering the DEX as a well defined subset and > restriction, it could well be that for a specific area of applicability > of PLCS (i.e. the DEX) a specific rule could be specified enforcing some > rule of uniqueness. > > To summarize, I believe that PLCS (the model) is fine as it is with all > its flexibility (and warts), the restrictions should instead be > specified in the DEX. Since probably nobody would claim conformance with > PLCS as a whole (a somewhat nebulous claim) this is not a problem, I > rather see an application claiming conformance with e.g. DEX #1, #7 and > #13 (or whatever). This will achieve the constraints without restricting > the model itelf, and thereby keeping it more futureroof. > > Regards, > Per-Åke > > Tim Turner wrote: > > Per, > > > > I can see your point. The contents of the identifier is a business > issue, > > not a modelling one. > > > > However, if (are?) we responsible for enforcing > consistency/uniqueness in > > the model, then we probably need some rules. Any global rules would > need to > > be established at the capability/dex level - not the PLCS schema level. > > > > I think the implementors will be cursing us if we give them > conflicting or > > ambiguous requirements that can be interpreted differently resulting in > > different populations of the data - so we need to strike the right > balance. > > > > I think we need to ensure at least consistency in the data. The real > > question then is how restrictive do the rules need to be for this. I was > > agreeing with Rob, in suggesting that we need to ensure that there is an > > identification of the P.A.R, and (going further) that there should > alsways > > be at least one identifier that is classified as a 'serial > identification > > code' (and owned by an Org'n). > > > > Whether we go further & ensure that the content of that identifier is > unique > > at all (I presume within the Dex), across all P.A.R's, P.A.P's and/or > all > > Parts is the issue. > > > > So the next question, I hinted at earlier, is whether we as > developers of > > the model are responsible for *ensuring* uniqueness of the data, or > do we > > pass on that problem to the implementors? > > > > kind regards, > > Tim > > > > NB. I am not certain that this is an issue from both the integration and > > data exchange uses of plcs (but certainly from the latter). > > > > > > > > ----- Original Message ----- > > From: "Per-Åke Ling" <Per-Ake.Ling@eurostep.com> > > To: "Rob Bodington" <rob.bodington@eurostep.com> > > Cc: "'Tim Turner'" <timturner11@bellsouth.net>; > <john.dunford@eurostep.com>; > > "'Tim King'" <tmk@lsc.co.uk>; <torirgen@eunet.no>; > <trine.hansen@dnv.com>; > > <plcs@lists.oasis-open.org>; <leif.tonning@dnv.com>; "'Leif Gyllström'" > > <leif.gyllstrom@aerotechtelub.se> > > Sent: Tuesday, October 26, 2004 12:24 PM > > Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs and reference > > data between PLCS pilots and OASIS/PLCS > > > > > > > >>I fail to see this as a PLCS problem. PLCS provides a > >>mechanism for identification, to be meaningful this should at least > >>be qualified by classification and an organisation claiming > >>ownership, i.e. the PLCS is flexible and rich enough to handle > >>any identification scheme. > >> > >>Whether or not NSN numbers are unique is surely a problem irrespective > >>of PLCS, i.e. the organisation assigning the numbers will have > >>problems regardless. > >> > >>On the other hand, I am not sure global rules are a good idea unless > >>one can ascertain that it will always be true for any conceivable use > >>of PLCS that an identification always will have an organisation (and > >>likewise for other rules). I am not happy about restricting the PLCS > >>schema this way, but a DEX (or capability) could certainly impose > >>such a restriction. > >> > >>Regards, > >>Per-Åke > >> > >> > >>Quoting Rob Bodington <rob.bodington@eurostep.com>: > >> > >> > >>>We can't stop someone using an NSN as a serial number . but > >>> > >>>If an identifier is a Serial number, then the identification_assignment > >>>should > >>>be classified as such. > >>> > >>>If the identifier is an NSN the identification_assignment should be > >>>classified > >>>as an NSN - not a serial number. > >>> > >>> > >>> > >>> > >>> > >>>Regards > >>>Rob > >>> > >>>------------------------------------------- > >>>Rob Bodington > >>>Eurostep Limited > >>>Web Page: <http://www.eurostep.com> http://www.eurostep.com > >>><http://www.share-a-space.com> http://www.share-a-space.com > >>>Email: Rob.Bodington@eurostep.com > >>>Phone: +44 (0)1454 270030 > >>>Mobile: +44 (0)7796 176 401 > >>> > >>>-----Original Message----- > >>>From: Tim Turner [mailto:timturner11@bellsouth.net] > >>>Sent: 26 October 2004 16:14 > >>>To: Rob Bodington; john.dunford@eurostep.com; 'Tim King'; > >>>torirgen@eunet.no > >>>Cc: trine.hansen@dnv.com; plcs@lists.oasis-open.org; > >>>leif.tonning@dnv.com; 'Leif > >>>Gyllström' > >>>Subject: Re: [plcs] Workshop #2 - Synchronise work on DEXs and > reference > >>>data > >>>between PLCS pilots and OASIS/PLCS > >>> > >>> > >>> > >>>Y'all, > >>> > >>> > >>> > >>>I tend to agree with Rob (the heretic!) - since I also recommended the > >>>use of > >>>global rules to help with consistency and to enforce what is being > >>>described by > >>>the Dexs. What is the point of not doing what we preach? > >>> > >>> > >>> > >>>The validation of a serial number is not something that the model > >>>should > >>>enforce. However, the Dexs state what type of reference data should be > >>>associated with an identifier of a Product_as_realized. > >>> > >>> > >>> > >>>What worries me is the subsequent issue; that if a NSN is used in place > >>>of a > >>>serial number (but classified as a serial number) - is the issue of > >>>uniqueness. > >>> > >>> > >>> > >>> > >>>If this situation can occur once, then the same NSN may be used > >>>elsewhere - also > >>>as a serial number. Hence we may have two (or more) identical > >>>identifiers (NSN) > >>>both classified as serial numbers. Will this not present a bigger > >>>problem? > >>> > >>> > >>> > >>>regards, > >>> > >>>Tim > >>> > >>>----- Original Message ----- > >>> > >>>From: Rob <mailto:rob.bodington@eurostep.com> Bodington > >>> > >>>To: john.dunford@eurostep.com ; 'Tim King' <mailto:tmk@lsc.co.uk> ; > >>>torirgen@eunet.no > >>> > >>>Cc: trine.hansen@dnv.com ; plcs@lists.oasis-open.org ; > >>>leif.tonning@dnv.com ; > >>>'Leif Gyllström' <mailto:leif.gyllstrom@aerotechtelub.se> > >>> > >>>Sent: Tuesday, October 26, 2004 10:21 AM > >>> > >>>Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs and > reference > >>>data > >>>between PLCS pilots and OASIS/PLCS > >>> > >>> > >>> > >>>John > >>> > >>>I disagree. > >>> > >>>The rule will say that there must be at least one identification > >>>assigned to > >>>product_as_realized. > >>> > >>> > >>> > >>>I do not see how you can represent a product_as_realized without > >>>identifying it. > >>>The id attribute are legacy step which we would like to get rid of. > >>> > >>> > >>> > >>>I am not saying that the identification must be a serial number. Just > >>>that you > >>>must identify the product_as_realized. Reference data will tell you > what > >>>type > >>>of identifier it is. > >>> > >>> > >>> > >>>I was thinking of doing the same to Part as well. > >>> > >>> > >>> > >>>Regards > >>>Rob > >>> > >>>------------------------------------------- > >>>Rob Bodington > >>>Eurostep Limited > >>>Web Page: <http://www.eurostep.com> http://www.eurostep.com > >>><http://www.share-a-space.com> http://www.share-a-space.com > >>>Email: Rob.Bodington@eurostep.com > >>>Phone: +44 (0)1454 270030 > >>>Mobile: +44 (0)7796 176 401 > >>> > >>>-----Original Message----- > >>>From: John Dunford [mailto:esukpc15@gotadsl.co.uk] > >>>Sent: 25 October 2004 15:05 > >>>To: 'Rob Bodington'; 'Tim King'; john.dunford@eurostep.com; > >>>torirgen@eunet.no > >>>Cc: trine.hansen@dnv.com; plcs@lists.oasis-open.org; > >>>leif.tonning@dnv.com; 'Leif > >>>Gyllström' > >>>Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs and > reference > >>>data > >>>between PLCS pilots and OASIS/PLCS > >>> > >>> > >>> > >>>Rob, please don't apply a rule to serial id. I like Tim's explanation > >>>of how > >>>things will work for the situation when reference is made to realized > >>>parts by > >>>"improper" means! PLCS must recognise that in many current > >>>applications, > >>>references need to be made to realized parts without serial ids. This > >>>is done > >>>in various ways including using NSNs, or Slot, or Part > >>>numbers/descriptions > >>>(e.g. when reporting a Fault, or hours run, on the Starboard Outer Feed > >>>Pump). > >>> > >>> > >>> > >>>I have a little more sympathy with a global rule on organization > >>>assignment, > >>>although this again may require such data to be generated by a > >>>translator, if > >>>the organization id is implicit within a given legacy system. > >>> > >>> > >>> > >>> > >>> > >>>John Dunford, > >>> > >>>Eurostep Limited, > >>> > >>>25, Chaucer Road, BATH BA2 4QX, UK > >>> > >>>Tel: +44 1225 789347 > >>> > >>>Mobile: +44 0797 491 8202 > >>> > >>>www.eurostep.com <http://www.eurostep.com/> > >>> > >>>www.share-a-space.com <http://www.share-a-space.com/> > >>> > >>> > >>> > >>>-----Original Message----- > >>>From: Rob Bodington [mailto:rob.bodington@eurostep.com] > >>>Sent: 26 October 2004 12:24 > >>>To: 'Tim King'; john.dunford@eurostep.com; torirgen@eunet.no > >>>Cc: trine.hansen@dnv.com; plcs@lists.oasis-open.org; > >>>leif.tonning@dnv.com; 'Leif > >>>Gyllström' > >>>Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs and > reference > >>>data > >>>between PLCS pilots and OASIS/PLCS > >>> > >>>I sort of agree with you Tim. However, I am considering writing a > global > >>>rule (a > >>>heretic statement I know) that forces a product_as_realised to have an > >>>identification_assignment to carry the serial number. I was also > >>>considering a > >>>rule to force the assignment of an organiztion assignment to to the > >>>identification assignment. > >>> > >>> > >>> > >>>Regards > >>>Rob > >>> > >>>------------------------------------------- > >>>Rob Bodington > >>>Eurostep Limited > >>>Web Page: <http://www.eurostep.com> http://www.eurostep.com > >>><http://www.share-a-space.com> http://www.share-a-space.com > >>>Email: Rob.Bodington@eurostep.com > >>>Phone: +44 (0)1454 270030 > >>>Mobile: +44 (0)7796 176 401 > >>> > >>>-----Original Message----- > >>>From: Tim King [mailto:tmk@lsc.co.uk] > >>>Sent: 26 October 2004 11:11 > >>>To: 'john.dunford@eurostep.com'; torirgen@eunet.no > >>>Cc: trine.hansen@dnv.com; plcs@lists.oasis-open.org; > >>>leif.tonning@dnv.com; 'Leif > >>>Gyllström'; 'Rob Bodington' > >>>Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs and > reference > >>>data > >>>between PLCS pilots and OASIS/PLCS > >>> > >>> > >>> > >>>Dear John, > >>> > >>>This business practice is not an issue for the PLCS model because we > >>>just map > >>>things where they should go (i.e. the NSN is mapped to the > >>>Identification_assignment for the Resource_item). We do not need to > >>>autogenerate anything. The Product_as_realized instance stands in its > >>>own right > >>>and needs no Identification_assignment (i.e. there is no serial number > >>>to > >>>distinguish). If the legacy systems requires the "identifier" then one > >>>can > >>>trace back through to the Resource_item that applies and find the NSN > >>>there. > >>>This means "we do not have a serial number for this part of the > realised > >>>ship > >>>but we know it is on there (never needing tracking) and we are using > the > >>>NSN as > >>>a proxy identifier". (Of course, I am not sure if the system has a > flag > >>>to > >>>indicate which serial numbers are real and which are NSNs - but that > >>>could be > >>>determined by intelligent inspection.) > >>> > >>>Cheers, > >>>Tim. > >>> > >>> > >>> > >>>-----Original Message----- > >>>From: John Dunford [mailto:esukpc15@gotadsl.co.uk] > >>>Sent: 25 October 2004 10:49 > >>>To: 'Tim King'; torirgen@eunet.no > >>>Cc: trine.hansen@dnv.com; plcs@lists.oasis-open.org; > >>>leif.tonning@dnv.com; 'Leif > >>>Gyllström'; 'Rob Bodington' > >>>Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs and > reference > >>>data > >>>between PLCS pilots and OASIS/PLCS > >>> > >>> > >>> > >>>Tim, the problem that Tor refers to is the opposite of the one you > cite. > >>> He is > >>>not facing an application which uses its own, special, identifiers > for a > >>>part. > >>>He is facing one where the NSN has been mis-used for this purpose. > This > >>>is OK > >>>if everyone know this is what has been done (as the host system users > >>>probably > >>>do), but it could cause significant problems, in a wider context, if > >>>the > >>>practice is spread (by a PLCS DEX) to a broader community. > >>> > >>>I suspect we will encounter many such examples of "id confusion" in > >>>current > >>>systems (not least in SSDD and UMMS, where I suspect the famous ACCREF > >>>Number > >>>means different things to different people). > >>> > >>>So, how should PLCS handle this? If we are all agreed that NSN's > >>>should be > >>>recorded by PLCS as identifiers of classes of resource_items (and it > >>>seems we > >>>are), how should we deal with the mapping when a particular application > >>>uses an > >>>NSN to identify a product_as_realized? Should the DEX translator auto > >>>generate > >>>a new unique id for the p_a_r, and relate the NSN to the p_a_r, as the > >>>id of the > >>>associated resource_item; or is there another way of handling this? > >>> > >>>Forgive me if I'm am treading ground already resolved, but I suspect > >>>"id > >>>confusion" may well be the biggest problem that PLCS implementers will > >>>face, and > >>>a consistent, well document approach will be needed. > >>> > >>>John Dunford, > >>>Eurostep Limited, > >>>25, Chaucer Road, BATH BA2 4QX, UK > >>>Tel: +44 1225 789347 > >>>Mobile: +44 0797 491 8202 > >>>www.eurostep.com > >>>www.share-a-space.com > >>> > >>>-----Original Message----- > >>>From: Tim King [mailto:tmk@lsc.co.uk] > >>>Sent: 20 October 2004 10:09 > >>>To: 'torirgen@eunet.no' > >>>Cc: 'john.dunford@eurostep.com'; trine.hansen@dnv.com; > >>>plcs@lists.oasis-open.org; leif.tonning@dnv.com; Leif Gyllström > >>>Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs and > reference > >>>data > >>>between PLCS pilots and OASIS/PLCS > >>> > >>> > >>> > >>>Yes. But the example you give just means that for the initial > >>>allocation of the > >>>NSN there is a one-to-one correspondence. If someone else finds a new > >>>use for > >>>the form, fit and function that the part_version embodies then the NSN > >>>is the > >>>common link across those different applications and potentially > >>>eventual > >>>different manufacturings. In principle, the NSN only enables supply > >>>rationalisation but can not really force people not to find a way to > >>>distinguish > >>>their own designs from others. > >>> > >>>Cheers, > >>>Tim. > >>>-----Original Message----- > >>>From: torirgen@eunet.no [mailto:torirgen@eunet.no] > >>>Sent: 19 October 2004 09:44 > >>>To: Tim King > >>>Cc: 'john.dunford@eurostep.com'; trine.hansen@dnv.com; > >>>plcs@lists.oasis-open.org; leif.tonning@dnv.com; Leif Gyllström > >>>Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs and > reference > >>> > >>>data between PLCS pilots and OASIS/PLCS > >>> > >>> > >>> > >>>John, > >>>Well in the case of the Norwegian Frigates the NSN applies sometimes to > >>> > >>>part_version, and even worse the part_version only apply to ONE ship... > >>> > >>>but in principle I tend to agree with you. > >>>Best regards, > >>>Tor Arne > >>> > >>> > >>> > >>> > >>>>I completely support John's comments. We reviewed this at Seattle and > >>> > >>>>when > >>>>I have time, I should be writing this up ... ideally as a capability. > >>> > >>>>Cheers, > >>>>Tim. > >>>> > >>>>-----Original Message----- > >>>>From: John Dunford [mailto:esukpc15@gotadsl.co.uk] > >>>>Sent: 18 October 2004 12:02 > >>>>To: Trine.Hansen@dnv.com; plcs@lists.oasis-open.org > >>>>Cc: Leif.Tonning@dnv.com; Leif Gyllström > >>>>Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs and > >>> > >>>reference > >>> > >>>>data between PLCS pilots and OASIS/PLCS > >>>> > >>>> > >>>>Trine, in briefly reviewing you PowerPoint and spreadsheet I was > >>> > >>>surprised > >>> > >>>>to see no mention of the entity Resource_item. Apart from anything > >>> > >>>else > >>> > >>>>this is the key to modelling NATO STOCK NUMBERS, which are identifiers > >>> > >>>of > >>> > >>>>resource_items. The whole Class, Group, Item structure is one set of > >>> > >>>>ready > >>>>made Reference Data, applicable to this entity. The NATO RD should > >>> > >>>not be > >>> > >>>>applied to part_version, because an NSN may be satisfied by any number > >>> > >>>of > >>> > >>>>part_versions from different suppliers. > >>>> > >>>>Indeed the resource_item/managed_resource area probably deserve more > >>>>attention from the DEX community than it has so far received. These > >>>>concepts were specifically designed to provide somewhere to hold the > >>> > >>>large > >>> > >>>>set of information which applies to items within an Inventory/Stock > >>>>management environment, and not to a specific part_version, and I am > >>> > >>>sure > >>> > >>>>you'll find plenty of this across the NDLO! > >>>> > >>>>John Dunford, > >>>>Eurostep Limited, > >>>>25, Chaucer Road, BATH BA2 4QX, UK > >>>>Tel: +44 1225 789347 > >>>>Mobile: +44 0797 491 8202 > >>>>www.eurostep.com > >>>>www.share-a-space.com > >>>> > >>>>-----Original Message----- > >>>>From: Trine.Hansen@dnv.com [mailto:Trine.Hansen@dnv.com] > >>>>Sent: 15 October 2004 18:03 > >>>>To: plcs@lists.oasis-open.org > >>>>Cc: Leif.Tonning@dnv.com > >>>>Subject: [plcs] Workshop #2 - Synchronise work on DEXs and reference > >>> > >>>data > >>> > >>>>between PLCS pilots and OASIS/PLCS > >>>> > >>>> > >>>>All. > >>>>Please find attached > >>>>(1) An updated figure of the proposed example "business concept" that > >>> > >>>will > >>> > >>>>be used in the planned workshops and > >>>>(2) Spreadsheet with draft input to the reference data discussions. > >>>>The attached spreadsheet is a draft input to the reference data > >>>>discussions. > >>>>Column A, E, F and H refer to instantiation diagrams and capabilities > >>> > >>>>produced in the Norwegian pilot and should only be viewed as > >>> > >>>references > >>> > >>>>only. > >>>> > >>>> > >>>><<Business concept v2.ppt>> <<equipment&part_values.xls>> > >>>>Regards > >>>>Trine Hansen > >>>>UCTNO940, Information Quality Management > >>>>Det Norske Veritas AS > >>>>( + 47 67 57 96 38 (office) > >>>>( + 47 90 83 44 24 (mobile) > >>>>* trine.hansen@dnv.com > >>>>http://www.dnv.com > >>>> > >>>> > >>>>************************************************************** > >>>>Neither the confidentiality nor the integrity of this message can be > >>>>guaranteed following transmission on the Internet. > >>>>All messages sent to a DNV email addressee are swept by Sybari Antigen > >>> > >>>for > >>> > >>>>the presence of computer viruses. > >>>>DNV acknowledges that SPAM email represents a potential security risk, > >>> > >>>and > >>> > >>>>DNVs filters to block unwanted emails are therefore continuously > >>> > >>>adjusted. > >>> > >>>>DNV has disabled "out of office" replies to the Internet > >>>>************************************************************** > >>>> > >>>> > >>>>DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The > >>>>information > >>>>in this message is confidential and may be legally privileged. It is > >>>>intended solely for the addressee. Access to this message by anyone > >>> > >>>else > >>> > >>>>is > >>>>unauthorised. If you are not the intended recipient, any disclosure, > >>> > >>>>copying, or distribution of the message, or any action or omission > >>> > >>>taken > >>> > >>>>by > >>>>you in reliance on it, is prohibited and may be unlawful. Please > >>>>immediately contact the sender if you have received this message in > >>> > >>>error. > >>> > >>>>This e-mail originates from LSC Group. Registered in England & Wales > >>> > >>>No > >>> > >>>>2275471 Registered Office: Devonport Royal Dockyard, Devonport, > >>> > >>>Plymouth, > >>> > >>>>PL1 4SG > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>>DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The > >>>information in > >>>this message is confidential and may be legally privileged. It is > >>>intended > >>>solely for the addressee. Access to this message by anyone else is > >>>unauthorised. If you are not the intended recipient, any disclosure, > >>>copying, > >>>or distribution of the message, or any action or omission taken by you > >>>in > >>>reliance on it, is prohibited and may be unlawful. Please immediately > >>>contact > >>>the sender if you have received this message in error. This e-mail > >>>originates > >>>from LSC Group. Registered in England & Wales No 2275471 Registered > >>>Office: > >>>Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG > >>> > >>> > >>> > >>>DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The > >>>information in > >>>this message is confidential and may be legally privileged. It is > >>>intended > >>>solely for the addressee. Access to this message by anyone else is > >>>unauthorised. If you are not the intended recipient, any disclosure, > >>>copying, > >>>or distribution of the message, or any action or omission taken by you > >>>in > >>>reliance on it, is prohibited and may be unlawful. Please immediately > >>>contact > >>>the sender if you have received this message in error. This e-mail > >>>originates > >>>from LSC Group. Registered in England & Wales No 2275471 Registered > >>>Office: > >>>Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG > >>> > >>> > >>> > >>> > >> > >> > >> > >>-- > >>======================================================== > >>Per-Åke Ling email: per-ake.ling@eurostep.com > >>Eurostep AB mobile: +46 709 566 490 > >>Vasagatan 38 http://www.eurostep.com > >>SE-111 20 Stockholm > > > > > > -- > ======================================================== > Per-Åke Ling email: per-ake.ling_AT_eurostep.com > Eurostep AB mobile: +46 709 566 490 > Vasagatan 38 http://www.eurostep.com > SE-111 20 Stockholm > > > *DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The > information in this message is confidential and may be legally > privileged. It is intended solely for the addressee. Access to this > message by anyone else is unauthorised. If you are not the intended > recipient, any disclosure, copying, or distribution of the message, or > any action or omission taken by you in reliance on it, is prohibited and > may be unlawful. Please immediately contact the sender if you have > received this message in error. This e-mail originates from LSC Group. > Registered in England & Wales No 2275471 Registered Office: Devonport > Royal Dockyard, Devonport, Plymouth, PL1 4SG * > > > > > > > ------------------------------------------------------------------------ > -- ======================================================== Per-Åke Ling email: per-ake.ling_AT_eurostep.com Eurostep AB mobile: +46 709 566 490 Vasagatan 38 http://www.eurostep.com SE-111 20 Stockholm
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]