Conference azur::mcc

    From my experience, I would suggest you change to underscore to a dash.
    The SNMP access module does not like _.  I tried TP350_1 and had to use
    TP350-1.
    
    Steve Woestemeyer
    csc/cs - nsu

    Well, this seems like a good place to put this...
    
    Last week I installed the SNMP module at a field test site.
    We discovered the hard way (by putting dozens of entries in UCX and
    then changing them and changing them and...) that DECmcc SNMP will
    NOT accept "_" (underscore) in an entity name. Chipcom HUBs do not
    permit "-" (dash) in hub names and UCX permits both.
    
    If UCX permits it, why does the SNMP AM reject it? Underscores (and
    dashes) are permitted in entitiy names elsewhere in DECmcc. A bug?
    
    s/rob
    

	It's not the SNMP AM that's rejecting the underscore in the internet
host name, it's the FCL and Iconic Map PMs.  The reason it's rejected is because the
the definition of the internetname datatype does not allow anything but 
alphanumeric characters or a dash.

	One could argue that this definition is a bit too restrictive.

Dan

I agree with Rob (.3). DECmcc should not impose additional 
restrictions on anything it names. Let the entity restrict 
the naming syntax thus allowing DECmcc the flexibility to 
pickup any added value the entity might incorporate.     

/Claudia

    OKAY, OKAY, OKAY....
    
    I hear you. I will qar the definition of internet name in the SRM
    and in the implementation (FCL, since it supplies all of the datatype
    conversion routines for both PMs).
    
    Geez where are you guys when we design these things :)
    
    If you think that this is real critical Rob, drop me a mail note
    so that I can set it's priority. But right now FCL is scheduled
    for final v1.2 EFT code freeze on this coming friday, and I have
    plenty on the plate already (want to fix the code for me?)!
    
    jill
    

    Thanks Jill.
    
    I would love to fix the code for you but I am off to a customer today
    to help them with SNMP on Chipcom, Sun and Cisco :-)
    
    s/rob

	The BNF for the internet name datatype, as prescribed for the
	V1.0 SNMP AM and DECmcc system, is based on the definition of a
	valid Internet host name according to the RFC (whose number escapes
	me currently).

	Fyi,
	Mike

>	The BNF for the internet name datatype, as prescribed for the
>	V1.0 SNMP AM and DECmcc system, is based on the definition of a
>	valid Internet host name according to the RFC (whose number escapes
>	me currently).

Mike,

Could you post the actual number?  ULTRIX says it has the following restrictions
on hostnames:
   Restrictions
     Host names are limited to 31 characters and may contain only lower case
     ASCII characters a to z, numbers 0 to 9, dashes (-), underscores (_),
     and periods (.).

If you're following a valid RFC, seems like lots of implementors aren't. 

_Mek

	Sorry, I meant "domain name", not "host name".  I has always thought
	a host name had to be a valid domain name label, but I'm not sure.
	At any rate, we had to make DEcmcc handle internet domain names.
	What follows is an excerpt from RFC883, DOMAIN NAMES - IMPLEMENTATION 
	and SPECIFICATION:

	Mike

Appendix 1 - Domain Name Syntax Specification

   The preferred syntax of domain names is given by the following BNF
   rules.  Adherence to this syntax will result in fewer problems with
   many applications that use domain names (e.g., mail, TELNET).  Note
   that some applications described in [14] use domain names containing
   binary information and hence do not follow this syntax.

      <domain> ::=  <subdomain> | " "

      <subdomain> ::=  <label> | <subdomain> "." <label>

      <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

      <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

      <let-dig-hyp> ::= <let-dig> | "-"

      <let-dig> ::= <letter> | <digit>

      <letter> ::= any one of the 52 alphabetic characters A through Z
      in upper case and a through z in lower case

      <digit> ::= any one of the ten digits 0 through 9

   Note that while upper and lower case letters are allowed in domain
   names no significance is attached to the case.  That is, two names
   with the same spelling but different case are to be treated as if
   identical.

   The labels must follow the rules for ARPANET host names.  They must
   start with a letter, end with a letter or digit, and have as interior
   characters only letters, digits, and hyphen.  There are also some
   restrictions on the length.  Labels must be 63 characters or less.

   For example, the following strings identify hosts in the ARPA
   Internet:

      F.ISI.ARPA     LINKABIT-DCN5.ARPA     UCL-TAC.ARPA

    So, does that mean we can let DECmcc relax what it permits as SNMP
    names so it can use what UCX and ULTRIX permit?
    
    At least then we don't have to explain to customers that we can't do
    something that another vendor can (even if we are "right" and they arn't)
    and be percieved as the limiting factor.
    
    Besides, we use underscores so often in names of other class' entities
    it would seem to be consistant to permit them here. After all, arn't
    the AMs supposed to "hide unusual characteristics" of the managed
    entity from the management system and especially the user of same?
    
    s/rob
    
    quote taken from DECmcc V1.0 CSC Training

>
>    it would seem to be consistant to permit them here. After all, arn't
>    the AMs supposed to "hide unusual characteristics" of the managed
>    entity from the management system and especially the user of same?
>
>    s/rob
>    
>    quote taken from DECmcc V1.0 CSC Training


    Rob, 

    *Pragmatically* you may be correct on your basic point.  Although I
    cannot let you get away with quoting out of context like that...  

    Those words appear on a slide from a presentation with an *entirely*
    different focus.   So please don't throw a quote regarding _Entity
    Model_ compliance at an issue that is centered around _RFC_ compliance.  

    The "unusual characteristics" that the quote you used means those those
    characteristics of an entity that are 'unusual' to an EMA Director's
    view of the world.  I.e. any entity that doesn't behave in a manner
    consistent with the Entity Model is an "unusual characteristic that its
    associated AM must rectify.

    We now return you to your regularly schedule argument already in
    progress...

    /doug

    Actually I don't agree.
    
    I consider that the RFC (actually the one mentioned earlier was for
    DOMAIN names not HOST name but...) restriction on the underscore
    actually IS unusual to an EMA Directors view of the world and besides,
    there are many implimentations that permit underscores thus creating
    the defacto standard which I believe we will benifit (in $$) more in
    following.
    
    Conversly, what is the benifit, financial or otherwise, to Digital or
    to our customers, to restricting in DECmcc the use of the underscore
    for (so far) only one global entity instance name?
    
    Standards are good. However, they shouldn't prevent products from
    working or solving customers problems.
    
    s/rob

... and then shut up. ;^)

>    I consider that the RFC (actually the one mentioned earlier was for
>    DOMAIN names not HOST name but...) restriction on the underscore
>    actually IS unusual to an EMA Directors view of the world and besides,

That you consider it does not make it so, Rob....  An EMA director could give a
fart fig whether or not an identifier contained underscores or dashes.   There
is nothing in the Entity Model (EK-DCEMA-EM) that says ANYTHING about it.  
That particular *unusualness* has nothing to do with the Entity Model. Ergo, an
EMA director would find nothing UNUSUAL about a dash vs. an Underscore as part
of an instance identifier.   On the other hand, a *user* might find it unusual,
if he/she were expecting the identifier used by the EMA management system to
agree with what he/she was _accustomed_ to using (even if it was a violation of
some RFC).    

I personnally agree that we should permit the "_" to be a legit part of an
identifier for the class SNMP.   If everyone else allows it (RFC or not) we
definitely will be perceived as not interoperating very nicely.  It's not like
we're delivering a compiler and someone wants us to relax checking for ints
used as floats or something.... :)

Summary: I agree that we should support "_" as part of an SNMP identifier.   I
merely disagree with one of your supporting arguments.  I kind of feel
embarrassed having written this much so will leave it at that.

/doug

It's clear that we need to add underscore as a recognized part of
Internet Name data type.

Odds are good that we'll have this support in DECmcc V1.2.

						Chris

	Uh, there might be a small problem there.  I seem to recall dimly
	that internet name "." is carried internally as "_", due to mcc_dns
	intricasies.  And if you now allow "_" in the name, when it's time
	to convert back before calling the AM...

In MCC V1.1, IP name is used to build the SNMP object name in DECdns.
When the IP name contains dots ("."), the dots are converted to the
underscores ("_") before accessing DECdns (MCC SRM does not allow the use of
underscores in the IP name, and the conversion is a one-to-one relation).  
For example, when a user tries to register an SNMP object by typing the 
following command:
    MCC> register snmp zolton.lkg.dec.com

An SNMP object called .mcc_ip.zolton_lkg_dec_com is created in DECdns.
There is a mapping from a IP name to a DECdns fullname.
I guess that this was not the best way of handling IP names in DECdns.
The problem here was that the IP name was used as the DECdns object name
(a pseudo fullname), not as an alternate identifier name (backtralation name).
Since the the converted IP name is used as the DECdns object name, it was 
necessary to convert back to the original IP name. 


In MCC V1.2, an MCC fullname is used to store the SNMP object in DECdns, and 
the IP name is used as an alternate identifier (a backtraslation link).  
When the IP name is used in the backtranslation link name, the IP name is 
preserved by encapsulating the IP name double quotes, and used as a 
'quoted DECdns simple name' in building the DECdns link.

For example, the following command creates a DECdns object called .ipnodes.foo
(a fullname), a DECdns link .mcc_snmp_backtranslation."zolton.lkg.dec.com"
(IP name - alternate identifier), and a DECdns link 
.mcc_snmp_backtranslation.10149038 (IP address - alternate identifier):
    MCC> register snmp .ipnodes.foo syn zolton.lkg.dec.com

In summary, MCC V1.2 preserves the IP name and does not translate dots or
underscores.

	In  reading    the  past  replies,  it  seems  like  most  have
	"violently" agreed that  we  needed  to  support the underscore
	character as a possible  valid  character in the internet name,
	the problem is we never got around to it.

	This has come back to  bite  us  in the Auto Topology routines.
	The code is finding objects with  underscores  and they weren't
	registerable  in  DECmcc because of the implementation  of  the
	internet  datatype.   Well, you'll be happy to  know  the  next
	baselevel will allow underscores even though the RFC says  they
	are no-no's.

	JCE