🚀 go-pugleaf

> If an end-system has multiple network-addresses, may that end-system restrict
> what application-entities are reachable through a specific network address. 

	I know of no Standard that precludes such a restriction.
	The only one I know of that even _seems_ that it _might_ preclude
	such a restriction is Naming and Addressing, 7498-3, which has
	no conformance clause.  Even if it did, though, the description
	of Presentation-address says (the last time I looked) that the
	tuple <P-sel,S-sel,T-sel,{set of Netwk-addrs}> included a {set...}
	where all Netwk-addrs in said {set...} referred to T-entities in
	the same open system.  It did not say that all Netwk-addrs that
	refer to any T-entity in that open system shall be included in any
	P-address promulgated in any directory -- or anything like that.

> Or must all application-entities be reachable on all network-addresses avail-
> able on that end-system.
> 
> Example of problem:
>     
>      End-system has 4 network-addresses (n1,n2,n3,n4)

	I assume by this that there are transport-entities in one _open_
	system, which T-entities can be reached through the network
	addresses n[1-4].  I don't understand "end-system" (although i
	haven't looked for a definition of this for over a year; perhaps
	by now they have one).

>      End-system has 2 applications entities (A,B)
> 
>      Is it valid to restrict access to A through network-addresses n1, n2 and
>      B through network-addresses n3, n4.
> 
> 
	Nothing would be invalid (that I know of) in a configuration
 	like this:

	A     A			B
	      |			|
	      | Psel=5		| Psel=5	Psel=presentation selector
	  ---(.)---------------(.)------   	(.) = service access point
	P  ___|___	     ___|___
	  |PE 'pa'|	    |PE 'pb'|		PE=presentation-entity
	  |_______|	    |_______|
	      |			|
	      | Ssel=3	        | Ssel=3	Ssel=session-selector
	  ---(.)---------------(.)------
	S  ___|___	     ___|___
	  |SE 'sa'|	    |SE 'sb'|		SE=session-entity
	  |_______|	    |_______|
	      |			|
	      | Tsel=3	        | Tsel=3	Tsel=transport-selector
	  ---(.)---------------(.)------
	T  ___|___	     ___|___
	  |TE 'ta'|	    |TE 'tb'|		TE=transport-entity
	  |_______|	    |_______|
	    |	|	      |   |
	 n1 |   | n2	   n3 |   | n4		<--- network addresses
	  -(.)-(.)-----------(.)-(.)----
	N __|___|_____________|___|__
	 |  network-entity 'nab'     |
	 |___________________________| 	... etc.

	So the presentation-address of application A is <5,3,3,{n1,n2}> and
	B's presentation-address is <5,3,3,{n3,n4}>.  The session-address
	of PE 'pa' is <3,3,{n1,n2}>; the transport-address of SE 'sa' is
	<3,{n1,n2}>; the network-addresses of TE 'ta' are {n1,n2}.  The 
	addresses of pb, sb, and tb follow similarly.

	Note that although this configuration is probably legal, it's
	almost certain to cause confusion unless there is some
	self-evident reason why A is reachable thru n1/n2 and B thru
	n3/n4 and that the selector combinations are assumed (by some
	static directory function?? -- better get out my heat-shields)
	to mean something associated with a particular subnetwork, e.g.

	It also seems to me that even if you had a configuration like
	the below, you could have a function of local system management
	that would know the called-P-address on a P-connect-indication,
	and automatically screen out those destined for A that came in
	if called-N-address was in {n3,n4} etc.  It's always legal to
	reject a connection-attempt if you feel like it.


	A     A			B
	      |			|
	      | Psel=5		| Psel=4	Psel=presentation selector
	  ---(.)---------------(.)------   	(.) = service access point
	P ____|_________________|____
	 | presentation-entity 'pab' |
	 |___________________________|
	      |	
	      | session-selector=3
	  ---(.)------------------------
	S ____|______________________
	 | session-entity 'sab'      |
	 |___________________________|
	      |	
	      | transport-selector=3
	  ---(.)------------------------
	T  ___|_____________________	 
	  |transport-entity 'tab'   |
	  |_________________________|	    
	    |	|	      |   |
	 n1 |   | n2	   n3 |   | n4		<--- network addresses
	  -(.)-(.)-----------(.)-(.)----
	N __|___|_____________|___|__
	 |  network-entity 'nab'     |
	 |___________________________| 	... etc.


> -- 

the opinions expressed above are my own and not necessarily my employer's