Re: ADMD
2007-03-14 11:05:13
David MacQuigg wrote:
The Border is a special ADMD boundary, one in which there is no prior
relationship.
That strikes me as an extremely helpful definition. Concise, clear and
meaningful.
I think, however, I might disagree with it, although I'd be inclined to put
this in terms of a change, rather than being basic.
I believe that a Border MTA role is important, even when there is a special
arrangement between the neighboring ADMDs. (It doesn't matter whether the IP
linkage between the ADMDs is through a private network or over the public
Internet. There are all sorts of special trust arrangements possible.
1. Do folks prefer "Border" or "Boundary"? I think "Boundary" gets used
more, but I don't really care which is chosen, as long as there is good
agreement to yse the term?
So I'd be inclined towards a definition along the lines of:
2. "A Bo* module is portal to an ADMD. It may be provide any of the
underlying functional roles within the architecture. Its additional role at
the Bo* is to enforce exit and/or entry policies for the ADMD, when
interacting with Bo* modules in other ADMDs."
Thoughts?
You define the term "Edge" on page 12 to mean something
similar, but Fig. 4 shows an Edge between two related ADMDs.
Mumble. The document uses the term "Edge" to refer to an entire ADMD rather
than to a module within it. An Edge ADMD is an originator or final recipient
administrative environment.
A Bo* module will exist at the outer limits of *any* ADMD, edge, transit, or
whatever.
No they are not. They are part of an integrated service in which you
participate. The relationship between you and the other provider is
important, but it does not make them part of your network, except
perhaps for a non-technical use of the word network.
I would think the term "network" should include a collection of agents
connected by contractual relationships.
Although that is a perfectly reasonable definition, it is not the way the term
is used in the computer science and IT profession of "networking". I think we
should be very careful *not* to assign unusual meanings to terms of art within
the profession.
Anyway to facilitate our
discussion I will call what I have an NoA (Network of ADMDs). My NoA is
what outsiders have to deal with when they exchange email with me.
Well, I certainly see some benefit in having a term that refers to an
aggregation of ADMDs that interact, or have some relationships, or otherwise
are worthy of being considered together.
What do other folk think about this?
I'm not saying that ADMDs aren't important, just that there is a higher
level of organization, a Network of ADMDs that should not be ignored.
When I first read this document two years ago, I came to the conclusion
that IP-based authentication was futile, because a chain-of-trust
through all these ADMDs was too difficult to establish. Now I see that
there is a simpler way of looking at this architecture, one that
facilitates IP-based authentication at a single, well-defined Border.
The document is misleading because it implies that such a Border does
not exist.
1. It isn't meant to have that implication.
2. I certainly agree that IP-based authentication has utility between
directly-interacting sites. But then, I am an author of CSV... And in any
vent, discussing this in detail is off-topic, although using as an exemplar
seemed quite useful.
Can we at least agree that there is one special boundary between ADMDs,
and that is the Border between sending and receiving NoAs?
I think it is between any two ADMDs. Not sure I understand the special role
between "NoA"s. Please clarify.
Can we agree
that this Border is important enough to be included in Figs 3, 4 and 5?
Do you see that this Border is unique in that
Maybe.
As you already know, there is a serious challenge to keep the figures
understandable.
d./
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: ADMD (was: Re: I-D ACTION:draft-crocker-email-arch-06.txt), (continued)
- Re: ADMD, Frank Ellermann
- Re: ADMD, Hector Santos
- Re: ADMD, Frank Ellermann
- Re: ADMD (was: Re: I-D ACTION:draft-crocker-email-arch-06.txt), Valdis . Kletnieks
- Re: ADMD, Dave Crocker
- Re: ADMD, David MacQuigg
- Re: ADMD,
Dave Crocker <=
- Re: ADMD, David MacQuigg
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Dave Crocker
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Hector Santos
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Hector Santos
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Frank Ellermann
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], ned+ietf-smtp
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Valdis . Kletnieks
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Hector Santos
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Frank Ellermann
Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Hector Santos
|
|
|