Conference azur::mcc

Given The information below,in relation to my initial Note 1098.0,It LOOKS
like 38 is unsupported...Not because its 'Non-Decimal',but because it's
'unrecognised'........Sandie.

*****************************************************************************
SYS$COMMON:[MCC]MCC_DNS_SETUP_DIR.COM;

$       VALIDATE_IDP_OFFSET = F$LOCATE(",''VALIDATE_IDP_AFI',", MCC$AFI_LST) + 1
$       IF VALIDATE_IDP_OFFSET .GE. F$LENGTH(MCC$AFI_LST)

*****************************************************************************
SYS$COMMON:[MCC]MCC_DNS_SETUP_IDP.COM;

$       MCC$AFI_LST == ",49,37,53,39,41,55,43,57,45,59,47,"
$       AFI = F$ELEMENT(TMP, ",", MCC$AFI_LST)
$       DELETE/SYMBOL/GLOBAL MCC$AFI_LST

------------------------------------------------------------------------------
Extract from V.O.T.S management Guide B-5,B4-Constructing an NSAP address
       [	Table B-3-Authorities supported by VOTS:-  ]

AUTHORITY	AFI
---------	---
X.121		37 }
DCC		39 } ....All numbers being Odd values
local		49 }
	etc.....                   

I can't find the reference now, but in an early Phase V transition planning 
guide (I think that's where it was) I saw a discussion of the various AFIs and 
IDIs.

As I recall, there were also even-numbered versions of the AFIs e.g. X.121 
was 37 & 38 (or maybe 36 & 37) and the difference was that the even numbered 
AFI had a binary IDI.

_Mek

    Talk to Stan Goldfarb at took::goldfarb, he's the NSAP expert, he
    wrote the NSAP parse/display code used by DECnet-ULTRIX NCL.
    
    ben
    

    Since Ben mentioned my name, and Jill Callander was gracious enough to
    let me know, I suppose I might as well put in my two cents worth.
    
    DECnet/OSI (aka Phase V) requires that NSAPs contain DSPs that use
    binary syntax (i.e. each nibble, or 4 bit "digit" value in the DSP
    portion accepts the full range of digit values from "0" to "F").  
    
    As noted previously, the AFI values that we recognize are all odd.  The
    odd AFI values indicate an NSAP with a binary syntax DSP.  The even AFI
    values indicate the the NSAP's DSP is decimal syntax (i.e. each nibble
    in the DSP can contain only a BCD value from "0" to "9", and excludes
    "A" through "F").  For all practical purposes, since we can't use NSAPs
    defined via those AFIs, they are unrecognized.
    
    An AFI of "38" is the decimal syntax form (unsupported) for ISO DCC. 
    The AFI for the supported binary syntax form is "39".
    
    The second problem, which was also previously noted, is that the IDI
    format specified via the ISO DCC AFI (regardless of whether it is 38 or
    39) allows only 5 decimal digits to be specified for the IDI value. 
    The IDI value (8261100...) would not be acceptible.
    
    I'm not certain what AFI the customer really wants to use.  It depends
    on how the IDI value was obtained.  If it is an X.25 address, then an
    AFI of 37 would be appropriate.  Similarly, 41 should be used if the
    IDI is taken from a telex number, 43 if it is an international
    telephone number, and 45 if it is an ISDN number.
    
    Both DECnet/OSI for Ultrix and the DECnet-VAX Extensions will have a
    utility called DECNET_DNS_REGISTER.  This utility supports a function
    that will help the customer to change the network IDP stored in the
    DECdns namespace (though not in the individual nodes, themselves). 
    This should be used to help change the IDP for any Phase IV nodes in
    the network, since they can't do it themselves.
    
    Enjoy,
    Stan Goldfarb

    Just a little more explanation of the background to these notes.
    
    JANET is the Joint Academic Network which is run under the auspices of
    the Joint Network Team, a body set up by the UK Government to run the
    network originally for British Universities and Research Councils but
    now extended to other academic institutions in higher education.
    
    The JANET network is a private X.25 network, though it is supposed to 
    be compatible with British Telecom's PSS network. JNT assigned all
    Universities a range of addresses all starting 0000 rather than with
    a CCITT country and network code. 
    
    The range of addresses assigned to this particular customer is, if I
    remember correctly, 000041500000 to 000041504000, though in practice I
    believe the initial 415 is only allocated to this particular customer.
    
    (Perhaps I should confess at this point that before joining Digital I
    was responsible for this customers network!)
    
    Being a Government body JNT are now moving slowly from a range of open
    non-proprietory communications protocols, such as Blue Book File
    Transfer Protocol and Grey Book Mail protocol, to the use of OSI. To
    support this move JNT have issued all sites with a range of NSAPs.
    
    My current understanding is that these have been obtained from the
    British Standards Institute and then added to so that the addresses
    being allocated are partly IDPs but also intrude into the DSP part 
    of the address. This intrusion into the DSP could be considered to 
    be part of the pre-DSP which we recommend not using.
    
    The address allocated to this particular customer is 38 826 1100 00 415
    
    It would appear that the 38 826 1100 is allocated by BSI, the following
    00 is JNT assigned to mean `academic format' and the 415 is a site
    identifier (cf the X.25 address above.)
    
    I am also aware that the National Health Service have been allocated a
    range of addresses by a similar mechanism, this time using BSI as the
    initial source and then a body called the Information Management Centre
    (IMC) which is an NHS body based in Birmingham and run by Adrian Stokes
    who has been active in standards work in the UK for a long time.
    
    I am trying to get more information on the policy for NSAP allocation 
    and usage in both these areas. We have been asked to give a DECnet/OSI
    seminar to the IMC following a UK Central Region  Insight seminar which 
    we gave recently which was attended by a number of people from the
    Health Service.
    
    Both these bodies are fully committed to the use of OSI but have also
    been brought up to believe that OSI means X.25 and Connection Oriented
    Network Service.
    
    The particular part of the Health Service I have been dealing with
    recently has actually been influenced to believe that our approach
    could be better and it is important that we try to build up these
    relationships as soon as possible.
    
    This is as much background information as I have at the moment. I will
    report back here if I find out more. 
    
    Mike.

Re: .4

While NSAPs  with  decimal  format  DSP's  are  non-DNA they should still be
supported.  Autoconfiguration won't work and they can't be entered using DEC
format but they should still work.  We have always been careful (in Routing,
anyway)  to make sure that non-DEC format NSAPs will work as we cannot force
people  to  use the format we chose.  In particular /388261100415...  should
be a perfectly valid NSAP.

The next  problem  is  for  what  purpose does MCC want an IDP? Does it make
sense  to  accept a non-DEC format? What should happen if the customer isn't
using DEC-format NSAPs?

The general  principle  is  that  you  cannot assume that a customer will be
willing  to  use  DEC-format NSAPs.  If not, there may well be some features
which  won't  work  (e.g.  autoconfiguration) or which are more difficult to
use  but  the  rest of the product must function correctly.  It is a product
decision  to determine how much of the product will work with non-DEC NSAPs.

It is  not acceptable to try to force DEC-format down people's throats as it
will  start  to  tread  on  very  many toes (and the JNT have very sensitive
toes!).   However, pointing out what features they are missing out on by not
using DEC format is a very good idea.

Graham