Subject: [Megaco] RE: Comments draft-ietf-megaco-naspkg-04.txt

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 7 May 2002 14:39:38 -0400

Thanks for your comments.

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Monday, May 06, 2002 2:29 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: Megaco
Subject: Comments draft-ietf-megaco-naspkg-04.txt

G'Day Tom,

I have several comments on the NAS packages.

o General - "Term" can you expand it to "Termination" where ever it occurs.
Can
be confusing to the reader.

[PTT] ??? The only occurrence of the word "term" is in section 9.1.1, where
I could use "component" as an alternative.

o Sect 6.5 talks about the bearer capabilities in the TDM SDP draft and
H.248
Annex C. I think in the interests in keeping things consistent and help
interoperability that the same values should be used for both ie. USI, TMR.
So
you could specify exactly what values should be used from Annex C and the
relevant SDP attributes.

[PTT] I'm not sure how to respond to this.  This document isn't really meant
to be a NAS designer's guide: I'm trying to define something to meet their
requirements, not tell them what parameters to use.  It might be more
legitimate for me to create such a cross-reference in my SDP-for-TDM
document. 

o Sect 7.1.1 Dialout Number > Default if unspecified is "absent". The reads
as
if the value should be set "absent". Perhaps a better formulation is
"Dialled
number is absent if unspecified"

[PTT] OK

o Sect 8.2.1 allows the MG to indicate to the MGC that an outgoing call
should
be initiated. It provides the appropriate destination (dialnum) but I can't
find
anywhere that describes the type of call to be placed. I would have thought
that
the MG should also provide some sort of bearer capabilities to be used in
the
call. Perhaps the appropriate values (eg. USI/TMR) could be provided as an
additional 2 optional parameters to the CallReq event.

[PTT]  Good point: I'll have to think about this.  The whole area of
network-initiated outgoing calls seems to be a bit beyond present practice.

o Sect 9.1.1 Naming Patterns - I'm not sure what this is meant to achieve.
The
procedures don't cover this. Do you audit value/ audit capability? What
should
be returned? TID=NAS/*??

[PTT] The naming pattern is a terminationState property on ROOT.  Whatever
procedures apply to such properties apply to it.  In text encoding, the
returned item would be
   terminationState={ ..., nasroot/nampat="nas/*", ...}

Regards, Christian

> 
> [email-masked] wrote:
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Media Gateway Control Working Group of
the
> > IETF.
> >
> >         Title           : Megaco/H.248 NAS Package
> >         Author(s)       : J. Mitchell, t. Taylor, A. Whitton, R.
Subramaniam
> >
> >         Filename        : draft-ietf-megaco-naspkg-04.txt
> >         Pages           : 18
> >         Date            : 09-Apr-02
> >
> > This document is intended to satisfy the requirements in section
> > 11.2.5 of the Megaco/H.248 requirements document.  It defines five
> > packages:
> > - the base NAS package contains properties and events supported by
> > all NAS terminations;
> > - the NAS Incoming package contains properties and events
> > supported by NAS terminations involved in calls initiated by the
> > circuit network;
> > - the NAS Outgoing package contains properties supported by NAS
> > terminations involved in calls outgoing to the circuit network;
> > - the NAS Control package contains an event supported by a NAS
> > Control termination, which allows the MG to indicate a request to
> > initiate a data connection to a terminal served by the switched
> > circuit network;
> > - the NAS ROOT package contains properties supported by an MG which
> > is also capable of supporting at least the NAS and NAS Incoming
> > packages.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-megaco-naspkg-04.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of the
message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
username
> >
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> >         "get draft-ietf-megaco-naspkg-04.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >         [email-masked].
> > In the body type:
> >         "FILE /internet-drafts/draft-ietf-megaco-naspkg-04.txt".
> >
> > NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before the "FILE"
> >         command.  To decode the response(s), you will need "munpack" or
> >         a MIME-compliant mail reader.  Different MIME-compliant mail
readers
> >
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which have been split
> >         up into multiple messages), so check your local documentation on
> >         how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> >
------------------------------------------------------------------------
> > Content-Type: text/plain
> > Content-ID:     <[email-masked]>
> 
> --
> Fernando Vallejo Lazaro
> Phone:  +34 91 330 8279
> SW  Wireline ASD-Madrid
>        ALCATEL
> 
>

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 08 May 2002 10:34:08 +1000

G'Day Tom,

Please see my replies below.

Regards, Christian

Tom-PT Taylor wrote:
> [PTT] ??? The only occurrence of the word "term" is in section 9.1.1, where I
> could use "component" as an alternative.

[CHG] Component is OK for me.

> 
> o Sect 6.5 talks about the bearer capabilities in the TDM SDP draft and H.248
> interoperability that the same values should be used for both ie. USI, TMR. So
> 
> legitimate for me to create such a cross-reference in my SDP-for-TDM document.

[CHG] OK point taken but your text does appear in the normative part of the
draft (procedures text) and effectively by having those references you are
advice to NAS designers to do different things for the text and binary. Updating
the sentence to read "It will typically add the bearer capability properties  to
Local and Remote for the circuit termination based on call signalling." will
solve my concern. Alternatively you could list the current references and the
mention that for common binary/text people should use native USI/TMR values (SDP
a=isup_usi:<>) or H.248 Annex C USI (0x9023).  

> 
> o Sect 7.1.1 Dialout Number > Default if unspecified is "absent". The reads as
> 
> if the value should be set "absent". Perhaps a better formulation is "Dialled
> o Sect 8.2.1 allows the MG to indicate to the MGC that an outgoing call should
> 
> the MG should also provide some sort of bearer capabilities to be used in the

[CHG] If the capability remains in the packages to be able to make Network
initiated outgoing calls then we probably need it.

> 
> o Sect 9.1.1 Naming Patterns - I'm not sure what this is meant to achieve. The
> 
> procedures don't cover this. Do you audit value/ audit capability? What should
> 
> be returned? TID=NAS/*??
> 

[CHG] I understand how properties on root work. However from the property text I
didn't see what exactly the property was required to do. I checked on the
NamingPatternPackage and it seemed alot more complicated than what you had
presented in the NAS package but I guess the aim is different. Perhaps an
example showing multiple naming patterns is required just to make the use clear.

---

From: Christian Groves <[email-masked]>
Date: Wed, 08 May 2002 10:34:08 +1000

G'Day Tom,

Regards, Christian