Subject: ROOT termination

From: SRD Tian YaMin <[email-masked]>
Date: Thu, 12 Oct 2000 16:06:15 +0800

Hello, I need someone to verify my understandings:
When an unknown MG first registers to a MGC, in principle , it must register

each termination with a ServiceChange to make the MGC be aware of their
existence,
But to reduce the network traffic, wildcard TerminationId is necessary, and
the wildcards must be
carefully constructed to let the MGC know the exact termination set on the
MG, and it’s not  right to 
use Root termination in this case. 
Am I right? Thanks a lot if somebody can help me.

Best regards
Tian Yamin

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 12 Oct 2000 15:36:59 -0400

Actually, no.  You need not do a ServiceChange of every termination
(interesting idea however!) after Registration.  The ServiceChange
of service state is a CHANGE of service state, not the initial one.

Brian

> -----Original Message-----
> From: SRD Tian YaMin [mailto:[email-masked]]
> Sent: Thursday, October 12, 2000 4:06 AM
> To: [email-masked]
> Subject: ROOT termination
> 
>

---

From: SRD Tian YaMin <[email-masked]>
Date: Fri, 13 Oct 2000 09:26:39 +0800

So, how the MG do a registration?
How to set the default service state initially?

>> MG, and it is not  right to

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 13 Oct 2000 09:13:37 -0400

The issue is that many MGs have large numbers of terminations.
Ill-formed wildcard audits will generate huge numbers of responses,
or will generate responses that are ambiguous.

Ambiguous responses occur when the MG realizes different kinds of
terminations.  A simple example - suppose a gateway had 10,001
physical terminations.  10,000 of them implement package A,
1 of them implements package B.

An AuditValue=*{Audit{Package}} will return 10,000 versions of
AuditValue=termA/000{Package{A}}}
AuditValue=termA/001{Package{A}}}
...
and one case of
AuditValue=termB/000{Package{B}}}

W-AuditValue=*{Audit{Package}} would return
AuditValue=*{Package{A,B}}}

this is interesting, but not very helpful.  What you want to do is:
W-AuditValue=termA/*{Audit{Package}} and
W-AuditValue=termB/*{Audit{Package}} which would return
W-AuditValue=termA/*{Package{A}} and
W-AuditValue=termB/*{Package{B}}

the question is, how did you know that the gateway has two sets
of terminations termA/000 - termA/999 and termB/000?  There is no
way, with the current protocol and packages, to find that out.

Brian

> From: Thomas LEVY [mailto:[email-masked]]
> Sent: Friday, October 13, 2000 8:35 AM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: ROOT termination
> 
> 
> I don't quiet understand the problem.
> I guess you talk about permanent Termination.
> Why wouldn't be possible for the MGC to Audit with wildcard 
> in order to have
> all the TerminationID from the MG?
> Is it a too heavy procedure?
> 
> Thomas,
> 
> "Rosen, Brian" a écrit :
> 
> > The MG uses ServiceChange to register with an MGC
> > The MGC audits the MG.
> >
> > Note that if this is the initial registration for the MG 
> (the MG booted),
> > then there is no relevant state - the MGC programs the 
> state it wants.
> > The audits are to discover capability.
> >
> > If the registration is due to a failover, then the MGC does have to
> > audit state, but the audit commands are sufficient.
> >
> > There is a hole, which I'm supposed to have an I-D out on. The hole
> > is - how does the MGC know how to construct a finite number of
> > audit requests if it doesn't know the "naming pattern" of 
> the terminations
> > in the MG.  The current answer is - provisioning.
> >
> > The I-D I owe is a package that defines a property the MGC can read
> > which describes the naming pattern.
> >
> > Brian
> >
> > > Sent: Thursday, October 12, 2000 9:27 PM
> > > Subject: Re: ROOT termination
> > >
> > >