Conference azur::mcc

I definitely need LocalEntityName too on input for V1.1

    As of now, LocalEntityName support is not planned for V1.1.  As
    Richard pointed out, you can use FullEntityName for now, and include
    the Global Entity in the data.
    
    Christine
    

re .2

If LocallEntityName support can't be squeezed in for V1.1, what about it
for V1.2 ?  

Regards,
Phil

    I will put it on the list to be considered.
    

    Without support of LocalEntityName, how do you plan to support the 
    Phase V access module?  Many Phase V entities utilize this data type.

    As it stands right now Jim has modified the AM to return a full
    entity name instead of  just the local entity name. It is slightly
    different in output appearance but was not a difficult change (since
    both are passed around mcc as AES specs)
    

    Actually this makes a lot of sense, perhaps LocalEntityName should have
    been just a "short-hand" user-interface representation of a
    FullEntityName, and should  not be visible at the call interface.  
    This probably does make things easier in a system with multiple global
    entity  classes.
    

One thing to consider about using FullEntityName in place of LocalEntityName.
Sure, they are both AES internally, so the code doesn't care. But the values
you build up in your MIR will be different, and may come back to haunt you.

Using FullEntityName for all your relationship attributes, you will be
replicating the names of the global entity instance and all intervening
sub-class instances down to the entity you actually want to "point at".

If you ever rename the global instance, or any of those intervening instances,
all your relationship pointers become invalid.

LocalEntityName let's you point to an entity without explicitly naming its
ancestors, and avoids this problem. The full path to the referenced entity
is computed at "run-time" instead of stored as the attribute value.

    Richard,
    
    I wasn't sure if I was misunderstanding your previous reply, but could
    you clarify your understanding of LocalEntityName please?  It sounded
    like you defined LocalEntityName to be the full entity with one or more
    of its "ancestors" stripped off.  
    
    I had understood LocalEntityName to be the same as FullEntityName
    but with the global entity (one level only) stripped off, not multiple
    levels stripped off.
    
    Isn't LocalEntityName a Phase V datatype?  Could someone from Phase V
    clarify this?  Thanks.
    
    Christine
    

	Christine,

		Richard's explaination of the use of LocalEntityName makes
perfect sense. LocalEntityNames are used as 'pointers' to other subentities
within the same Global Entity instance. For example, in Phase V the entity
Node.Routing.Circuit has an attribute Data Link Entity Name. The value of
which would be something like "DDCMP LINK link-name STATION station-name".

		Now if that attribute values gets stored in the MIR as a
FullEntityName it would be "NODE node-name DDCMP LINK link-name 
STATION station-name". Then the NODE gets renamed sometime down the road,
and, as Richard pointed out, all of those values are now invalid. If they
get stored as LocalEntityNames they would still make sense.

	JimH

Christine has a good point. Both the Entity Model and the MCC SRM say that
the LocalEntityName contains the "local portion" of the full entity name.
That would seem to mean "evetything except the global entity". To whit:

FullEntityName: Granpa able Mama baker Kid charlie

I was thinking the local name could be any terminal sub-string of the
full name, like just Kid Charlie. The description seems to say that only
the global can be removed, so it can't be any less than Mama baker Kid charlie.

    Thanks Richard and Jim.  I too understood that "Mama baker Kid charlie"
    should be the LocalEntityName, not "Kid charlie".  
    
    I just wanted to set the same expectations for when we support the
    datatype.
    
    Christine
    

    Re .-3: you're right, hadn't thought of that.
    

My response to the temporary unavailability of LocalEntityName is to not
support the Rename directive. This will prevent the pointers from becoming
invalid.

In a future version, when LocalEntityName is available, I'll enable Rename, 
change the datatype of the pointer fields, and run an installation-time
utility to run through and strip the GE instances from the pointer values.

In the meantime, here is something somewhat more kinky: Only the PMs check
FullEntityName values for the GE instance on input. Many of the relationship
attributes I'm defining can be status attributes, set only by the entity
itself. So I can call them FullEntityName to keep the PMs happy, but not
put the GE instance in the value to avoid having to come back and fix them
later. I think.

RE .14
        I'm not sure what your last paragraph  means, could you explain.
    
    FYI PM's and some FM's care about the fullentityname, as for AMs
    I doubt that any do right now but who knows what the future might
    bring....
    

Jill, sorry about the last paragraph of .14, just thinking aloud, probably
a dumb idea.

Is LocalEntityName supported for V1.2?  If not, is it going to be supported
for Vnext?

MCC treats a local entity as a full entity, as MCC needs the top level entity
information.

The CMIP translation in DNA5 strips the top level entity going to "the wire"
and adds in the top level entity (which must be a phase V node) when it
converts from "the wire" to ILV for MCC.

Ruth K.

According to the kernel team supervisor:

Supported in V1.3.

Re: .18

While that  behaviour  is  better  than  not  supporting it at all, it isn't
"right".  Some problems:

1) This means the syntax and behaviour of those attributes is different from
that  described  throughout  the  documentation  for the node being managed.
This  is  a  case of gratuitously breaking other products' documentation for
your own convenience.

2) Local Entity Names are used to refer to entities on the same node but you
would  allow  a user to use the name of another node in there and not get an
error.   For  example,  the  Routing  Circuit points to the datalink using a
Local  Entity Name.  It clearly makes no sense to point to a datalink entity
on  another  node.   But  if  you  just strip the name then no error will be
reported  if  the user specifies a remote node name (expecting it to achieve
something).

3) What happens if the node doesn't have a name?

I think  this "solution" is entirely bogus: just a hack.  There is no reason
why  LEN  shouldn't just be handled as another datatype.  MCC does not "need
the top level entity information": LEN is *defined* as a name subordinate to
"Node 0".

If you  really can't be bothered to do this properly with a new type then at
least  use  "Node  0" (and require it on input) instead of just ignoring the
user's input.  That at least addresses items 2 and 3.

Graham

1) The global entity prepended to the local entity by the PhaseV AM *is* the
 *local* Node name.

2) I suppose that if the local node has no "name" some other node identifier is
used.   I will ask the Phase V developers.

3) Since this "hack" was a Phase V AM proposal, I will ask the Phase V 
developers to comment on your comments.