Subject: RE: NAS Package commments

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 15 Mar 2001 17:13:42 -0500

Thanks a million for your comments.  Some points of debate.

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 11:39 PM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]
> Cc: Whitton, Alan [CAR:5Z00:EXCH]; megaco ietf
> Subject: NAS Package commments
> 
> 
> G'Day Tom,
> 
> I've just reviewed the NAS package and have a couple of minor 
> comments.
> 
> 7.1.1 and 7.1.2 use the term parameterID when propertyID is 
> the correct
> term. The should be changed to prevent confusion between 
> properties and
> event parameters.

[PTT]
OK
> 
> 7.1.2 and 8.2.1 may I suggest that HANDLE in the text case be OCTET
> STRING encoded in the HEX form. This allows the same cookie to be used
> in both text and binary. Otherwise text "value" limits what you can
> store.

[PTT]
OK
> 
> 9.1.1 & 9.1.2 - I don't know why you need these properties. Isn't the
> correct way to find out this information to do an audit on the MG and
> look for terminations that have the NAS packages allocated to 
> them. This
> is superflous.

[PTT]
9.1.2 names a single termination -- there will be at most one of them in an
MG.  I'd argue for this property on grounds of efficiency.

9.1.1 is, I agree, debatable.  The presence of this property is my
contribution to the discussion of how the MGC discovers ephemeral
terminations in advance of their creation.  The logical continuation of this
thought, of course, is that ROOT properties are defined for the naming
patterns of other ephemeral types.  

Playing devil's advocate: If it turns out that these naming patterns are not
disjoint, showing them as ROOT properties is a wasted effort.  That will
also mean that any audit would find terminationIDs capable of supporting a
variety of mutually exclusive packages.  AFAIK this is perfectly legitimate.
> 
> 9.1.2 Why isn't this returned in an audit? Its read only. If you can't
> set it or read it whats the point in having it?

[PTT]
I don't understand the problem.  It's read only -- that allows you to read
it in an audit of ROOT.
> Cheers, Christian

---

From: Christian Groves <[email-masked]>
Date: Fri, 16 Mar 2001 15:01:08 +1100

G'Day Tom,

Please see my comments below [CHG]

Christian

Tom-PT Taylor wrote:
> 9.1.2 names a single termination -- there will be at most one of them
> in an MG.  I'd argue for this property on grounds of efficiency.

[CHG] I must admit I don't understand what the control termination
actually is (its probably my ignorance of the finer workings of a NAS).
Is there typically only one interface on a NAS that does outgoing calls
as suggested by the package?

> terminations in advance of their creation.  The logical continuation
> of this thought, of course, is that ROOT properties are defined for
> the naming patterns of other ephemeral types.
> 
> Playing devil's advocate: If it turns out that these naming patterns
> are not disjoint, showing them as ROOT properties is a wasted effort.
> That will also mean that any audit would find terminationIDs capable
> of supporting a variety of mutually exclusive packages.  AFAIK this is
> perfectly legitimate.

[CHG] I don't really see the need or efficiency for this. How many MGs
will be configured to do NAS, VoIP, ISDN access, BICC, SIP, etc ? So the
most likely thing is that all the termination in a NAS MG (or virtual
MG) will be NAS ones anyway.

> I don't understand the problem.  It's read only -- that allows you to
> read it in an audit of ROOT.
[CHG] The following statement was confusing to me:
   Possible values: as provisioned in the MG.  The value MUST NOT 
   contain a wildcard.  If the MG does not support outgoing calls 
   originated from the data network, this property MUST NOT be set and 
   MUST NOT be reported in any audit of ROOT properties. 
   Defined in: TerminationState for ROOT. 
   Characteristics: read only. 

What should happen with regards to H.248? As its a property which
resides in a package if you put this package on root then will you have
"ctlnam" set. So should audit capability or audit value return it? I'm
concerned about the MUST NOT notes change normal H.248 behaviour.

Another thing I just picked up is that type should probably say "octet
string formatted as: ...."