Subject: RE: [RAM] Discovery

From: "Bound, Jim" <[email-masked]>
Date: Tue, 9 Jan 2007 15:54:26 -0500

JFC,
 
Going to go offline with you as I think we may be going a bit astray off
topic (and we are going to get yelled at soon :--)) (rightly so)..
Maybe when we get done we can apply some input to IETF RAM work
succintly.  My sole point was to identify discovery not in terms we
think today but from a broader view just suggesting when we get a model
built then is DNS the answer to discover identifiers.  The principles of
net centricity were my one way of justifying that we do need to work on
discovery to Roland within a network.  As I just said in an email I
think we need to answer as work item Brian's last mail at least that is
my input to the mail list. There is not much point in discovery if we
don't have what is to be discoverd nailed down in RAM :--).

Look forward to further analysis on xxx-net-centricity, and quite a task
you have taken on for your paper be glad to share my view with you. I
think your result will be quite informative to a few technology players
working this space I can think of for sure.
 
NB: If others find this topic interesting send mail to JFC and I to
participate in the offline discussion.
 
Thanks,
/jim

________________________________

	From: JFCM [mailto:[email-masked]] 
	Sent: Tuesday, January 09, 2007 10:34 AM
	To: Bound, Jim; Roland Dobbins; [email-masked]
	Subject: RE: [RAM] Discovery 

	At 04:35 09/01/2007, Bound, Jim wrote:
	
	>JFC,
	> > Jim,
	> > Very interesting remark as permits to ask simply the very
basic
	> > question: in your mind should we bound to a single net
	> > centricity technology and implementation?
	> > Thanks.
	> > jfc
	>
	>Net Centricity principles do not require that tight of a
bounding. What
	>it does require is that all the principles can co-exist and
operate (per
	>the list below and some add others to the list).  Thus it is
fair to
	>have multiple boundaries of technology solutions, but the core
	>principles should be checked.  It can be useful to the
development
	>models, architectures, paradigms, and implemented solutions is
my view.
	>
	>Does that answer your question enough for now?
	
	Dear Jim,
	thank you for your answer. I try to understand applied net
centricity 
	through practical standardisation examples: JTC1/SG32/WG2 and
other 
	works on ontologies and metadata propositions. As usual I
observe the 
	same "confusion" (or documented lack of/planned work) between
the 
	common Internet layer and my interest in the relational spaces
layer 
	(the networks of the network of networks).
	
	I feel that net centricity is the correct area where to address
this 
	confusion which opposes me to most of the IETF. But I feel that
we 
	still miss the necessary thinking to fully do that. This is
because I 
	think it calls for "multicentricity" aspects which have not been

	investigated yet (but I may be wrong). Questions are :
	(1) is there a single net centricity "technology" (may be not
the 
	best term to be used but it seems accurate - not in terms
equipment 
	and hardware, but in term of metatechnology to document
technologies)
	(2) or the need of a multicentricity open technology permitting
a 
	wide variety of interoperable implementations of the net
centricity concept.
	
	To try to understand that I consider net centricty as the
_degree_ of 
	pertinent usefulness in describing a network system (permitting 
	discovery, QoS, interconnectivity, etc.). It therefore permits
to 
	measure the tightness of the bounding between a network 
	implementation and its description.
	
	- the more the description is usuefull the easier the discovery,

	interconnectivity, etc.
	- two networks may have the same lose description and their 
	interconnection not to scale because their more precise
descriptions differ.
	
	I also observe that the current descriptive "technology" is
hierarchy 
	oriented. This means that the documented models have a root or
can be 
	associated in bouquet. But forests are not easy to document.
Lateral 
	relations are not really considered as such (but I may have not
read 
	the proper documents). I feel that these lateral relations are 
	precisely where "addresses" have a great role to play and call
for 
	multi orthogonal numbering plans of addresses. This can be true
at 
	every level (machine interconnectivty, software binary and
semantic 
	interoperability, people interintelligibility).
	
	The opposition I met about Multilingualism is a good example of
that 
	misunderstanding: a language (as everything) is first an address
- 
	where its concepts are documented, or a conditional interlink
chains 
	a documentation. Internet net centricity is documented in values
and 
	in texts. There is no problem with values, but there is one with

	texts as they are documented in one given language. However,
even if 
	it was documented in every language, I am not sure that a net 
	centricity based upon the sole current internet experience can 
	document every relational space. What if the description of a
network 
	systems calls on concepts ignored by the Internet technology.
	
	This is a complex issue. I am working on a paper reviewing the 
	practical axis of effort (fixity, virtuality, mobility,
intinerary, 
	multicentricty) approached by this mailing list. This is why I
am 
	interested by inputs.
	
	Thank you.
	jfc

	
	
	>Thanks
	>/jim
	>
	> >
	> >
	> > At 05:42 03/01/2007, Bound, Jim wrote:
	> >
	> > >Just for thinking there is a set of principles used by U.S.
DOD and
	> > >NATO and others called net centricity.  My reference to
this work is
	> > >the computer science term and not applied with terms like
	> > net centric
	> > >warfare or net centric ops, but rather a set of
pre-conditions to
	> > >achieve net centricity from models to implementations.  But
it is
	> > >beginning to permeate out of the classic military
	> > environment and the
	> > >core principles I extrapolate and test I use for any
	> > architecture and
	> > >for implementation are does the networking result provide:
	> > >connectivity, interoperability, security, discovery, QoS,
and
	> > >end-to-end (meaning two peers can communicate without
middle
	> > boxes and
	> > >packets could be encrypted so only the current IP header is
in the
	> > >clear).  The point of discovery is quite important as that
	> > is how the
	> > >network learns of parameters and information required.  And
	> > does need
	> > >some thought while developing an architecture. If any of
these
	> > >pre-conditions are missing above (and some add others as a
note) net
	> > >centricity can be negatively impacted, including discovery.
	> > What the
	> > >answer is for our work here for discovery is entirely
premature to
	> > >discuss (e.g. DNS, LDAP, UDDI,
	> > >LDAP+UDDI, SLP, SOAP, etc).
	> > >
	> > >Ref John Garstka :
http://en.wikipedia.org/wiki/John_J._Garstka
	> > >
	> > >Best,
	> > >/jim
	> > >
	> > >
	> > > > -----Original Message-----
	> > > > From: Roland Dobbins [mailto:[email-masked]]
	> > > > Sent: Tuesday, January 02, 2007 11:21 PM
	> > > > To: [email-masked]
	> > > > Subject: Re: [RAM] Destination Locator selection
	> > > >
	> > > >
	> > > > On Jan 2, 2007, at 8:17 PM, Bound, Jim wrote:
	> > > >
	> > > > > Putting the architecture discussion hat on only I
would not
	> > > > entirely
	> > > > > agree given how we have been using the term
'namespace',
	> > > > but I do see
	> > > > > the concern and point.  To find compromise I would
suggest
	> > > > we do need
	> > > > > to be concerned about the principle of "discovery"
	> > within the new
	> > > > > architecture model.
	> > > >
	> > > > Thanks for the clarification; in this particular case it
was a
	> > > > semantic issue, but one to which attention must be paid,
lest
	> > > > (further) confusion ensue.
	> > > >
	> > > >
	> > > >
--------------------------------------------------------------
	> > > > ---------
	> > > > Roland Dobbins <[email-masked]> // 408.527.6376
voice
	> > > >
	> > > >               All battles are perpetual.
	> > > >
	> > > >                  -- Milton Friedman
	> > > >
	> > > >
	> > > >
	> > > >
	> > > > _______________________________________________
	> > > > RAM mailing list
	> > > > [email-masked]
	> > > > https://www1.ietf.org/mailman/listinfo/ram
	> > > >
	> > >
	> > >_______________________________________________
	> > >RAM mailing list
	> > >[email-masked]
	> > >https://www1.ietf.org/mailman/listinfo/ram
	> >
	> >
<http://i.msgtag.com/anl/ogdEEgutbu/eetv/foty/Ch/pybmCsasq.gif>;
	
	  <http://i.msgtag.com/anmt/nasfoqtbybytDFpABhiea/Dxpp/exz.gif> 

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram