Subject: Implementors' Guide Update Editor's last Call

From: Christian Groves <[email-masked]>
Date: Wed, 09 May 2001 15:40:02 +1000

G'Day all,

The H.248 Series Implementors' Guide has been updated to revision 6.

It can be found at:
ftp://standard.pictel.com/avc-site/Incoming/
files:
TD-xxx_H248_Implementors_Additions_v6.doc
TD-xxx_H248_Implementors_Additions_v6.pdf

This revision contains the Approved Implementors' Guide and the
Implementors' Guide Additions v5 with some other changes. The changes
are detailed in the document.

This is an editors' last call. Please provide comments on this draft by
Monday the 13th as a revision 7 will be stored on the 14th and sent to
SG16 for approval at the Porto Seguro meeting. If you have a comment on
a correction please provide the detailed solution or exact changes that
you would like to see.

Cheers, Christian

---

From: Chuong Nguyen <[email-masked]>
Date: Wed, 09 May 2001 16:51:53 -0500

Christian

Section 11.2 ServiceChange Address and Ports
There is some confusion on  when to use either ServiceChange Address or
ServiceChange MGCID. The text below offers some advice on

[Begin Clarification]
1) The use of ServiceChangeAddress is not encouraged

<cnn>  Why is the use not encouraged?

2) MGCs must be able to cope with ServiceChangeAddress with either a full
address or just a port number in the case of TCP transport.

<cnn>  Do you mean UDP transport?
               And ServiceChangeAddress does not apply to TCP?

<cnn>  I don't see any text regarding the clarification of when one or the
other should be used.
The Standard text already has something like:

ServiceChangeAddress
   and ServiceChangeMgcId parameters must not both be present in the
   ServiceChangeDescriptor or the ServiceChangeResultDescriptor.  The
   ServiceChangeAddress provides an address to be used within the
   context of the association currently being negotiated, while the
   ServiceChangeMgcId provides an alternate address where the MG should
   seek to establish another association.

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: Chuong Nguyen <[email-masked]>
Date: Wed, 09 May 2001 17:19:41 -0500

Christian

6.58 TimeStamp in registration replies
· If the Timestamp is not sent by either the MG or the MGC, both sides
shall keep their original time base.

Does this now imply that TimeStamp is not required in ServiceChange
registration?

Megaco Text
The TimeStamp parameter shall be sent with a registration command and its
response.

----
Something else
ServiceChangeVersion in Megaco Text

   *  ServiceChangeVersion, if the responder wishes to negotiate the
      version of the protocol to be used for the association.

But ABNF
   ;at-most-once. Version is REQUIRED on first ServiceChange response
   servChgReplyParm     = (serviceChangeAddress / serviceChangeMgcId /
                          serviceChangeProfile / serviceChangeVersion )

Also it seems that if Version is REQUIRED for first ServiceChange
response,
wouldn't Version be required for first ServiceChange request?

Thanks
Chuong

---

From: Christian Groves <[email-masked]>
Date: Thu, 10 May 2001 12:20:05 +1000

G'Day Chuong, 

Please see my replies below.

Cheers, Christian

Chuong Nguyen wrote:
> There is some confusion on  when to use either ServiceChange Address
> or ServiceChange MGCID. The text below offers some advice on
> 
> [Begin Clarification]
[CHG] This was in the approved IG. The issue was that the
ServiceChangeMgcID and the ServiceChangeAddress carried essentially the
same information. So ServiceChangeMgcID was favoured.

> 
> 2) MGCs must be able to cope with ServiceChangeAddress with either a
> full address or just a port number in the case of TCP transport.
> 
[CHG] ServiceChangeAddress applies to all. The "or" relates TCP to the
port number. I guess you could remove the "in the case of TCP transport"
part.

> 
> 
> <cnn>  I don't see any text regarding the clarification of when one or
> the other should be used.
[CHG] That's why we put the note in favouring MGcID.

---

From: Christian Groves <[email-masked]>
Date: Thu, 10 May 2001 12:13:10 +1000

G'Day Chuong,

Please see my comments below.

Cheers, Christian

> Does this now imply that TimeStamp is not required in ServiceChange

[CHG] No I don't believe it does. The start of this paragraph has always
stated "The optional Timestamp...." so there is no change.

> 
> Megaco Text
> The TimeStamp parameter shall be sent with a registration command and
> its response.
> 
> ----
> Something else
[CHG] I would remove the comment about Version. Chapter 11.3 gives the
rules for when version is sent. There's no point in doubling up. Its not
a syntax issue its a procedural issue. Anybody have a problem with
removing the Version part of the comment?

---

From: Chuong Nguyen <[email-masked]>
Date: Thu, 10 May 2001 08:31:34 -0500

See comments below:

> > The TimeStamp parameter shall be sent with a registration command and

<cnn>  What about the above sentence quoted from Section 7.2.8 in the
paragraph where
               registration is described.  The use of the word "shall"
implies "required" to me.

              The paragraph where the word "optional" was used - to me it
meant that not
              all ServiceChange Method requires TimeStamp.  Then follow by
the "registration"
              paragraph which describes how registration is done which
states that TimeStamp
              is required for registration.

             But the change in the IG implies that TimeStamp is not
required in "registration"
             And that is all I am trying to point out.

Thanks
Chuong

---

From: "Paul Long" <[email-masked]>
Date: Thu, 10 May 2001 11:07:06 -0500

Christian,

We were just talking about timestamps on the reflector a week ago. I wished
I had seen this. Item 6.58 changes their semantics considerably. Previously,
service-change timestamps were merely, well, timestamps. This proposal now
makes a service-change timestamp sent by an MGC into a set-time feature on
the MG. I guess this is okay. Hmmm... The MGC won't really know _when_ the
possibly new time base takes effect in the MG, though. The MG may have
already sent messages (and RTP packets?) containing timestamps using its old
time base, so there will be an indefinite period after an MGC sends its
set-time timestamp that it will not know whether the timestamps being
reported by the MG are using the new time base or not. The timestamps will
therefore be ambiguous for an ambiguous amount of time. I guess the MGC will
just have to deal with this the best it can.

Maybe this should be rethought. Personally, I think the IG should just
repair the ASN.1 and ABNF syntax and leave the semantics alone in section
7.2.8.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Christian Groves
Sent: Wednesday, May 09, 2001 9:13 PM
To: Chuong Nguyen
Cc: [email-masked]
Subject: Re: Implementors' Guide Update Editor's last Call Section 6.58

G'Day Chuong,

Cheers, Christian

---

From: Al Varney <[email-masked]>
Date: Thu, 10 May 2001 12:28:09 -0500

>repair the ASN.1 and ABNF syntax and leave the semantics alone in section

    I agree that having the "current" MGC force a time-base change at the 
MG (as a requirement) should be rethought.  Do we really want to preclude 
an MC operating with multiple MGCs (with differing ideas about time)? -- I 
thought 3GPP was looking at just such a mechanism (at a somewhat higher 
level, but "based on" H.248.  BICC is supporting the idea of multiple nodes 
controlling a BIWF -- and that interface is "based on H.248".

    Should an MG give a (new) MGC that kind of control?  A trunking MG?  An 
announcement MG?

    I don't see any advantage in REQUIRING the MG to change/synchronize 
with the current MGC.  An MG without access to another time server, and 
with no recent contact with an MGC, might wish to re-set its 
time-base.  But why not allow the MG to decide.

    So far as I can tell, NOTHING BREAKS if the MG retains its own local 
time base forever --- regardless of how far off it might be from "world time".

Just my opinion,

Al Varney - Lucent Technologies  +1 630 224-7493    [email-masked]

---

From: "Paul Long" <[email-masked]>
Date: Thu, 10 May 2001 12:53:50 -0500

Christian,

My comments:

Item 6.16: Concatenation (e.g., A B) already takes precedence over the
alternative operator (e.g., A / B), so the proposed parentheses are
redundant. (See 3.10/RFC2234.) I guess it doesn't hurt to add them, but this
is technically a clarification and not a correction so it should go in
section 7.

Item 6.58: Inserting the text, "For UDP as a transport," precludes an MG
that uses TCP from also using ServiceChangeAddress. Not that _I_ want to do
such a thing, but is this a necessary constraint? Was this intended?

Item 11.6: I know this is only clarifying text, but you should probably
change "Parsers should accept whitespace..." to "Parsers shall accept
whitespace..."

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Christian Groves
Sent: Wednesday, May 09, 2001 12:40 AM
To: megaco ietf
Cc: Tom-PT Taylor; Glen Freundlich
Subject: Implementors' Guide Update Editor's last Call

G'Day all,

It can be found at:

Cheers, Christian

---

From: "Paul Long" <[email-masked]>
Date: Thu, 10 May 2001 13:00:44 -0500

Al,

I've mentioned this before, but remember that for an MG to change its time
base to, for example, the one implied by the MGC's timestamp, it must
unregister and then re-register in order to indicate the change to the MGC.
An MG could do this if it wanted to, of course, but sounds like a real waste
of bandwidth and delay.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Al Varney
Sent: Thursday, May 10, 2001 12:28 PM
To: [email-masked]
Subject: RE: Implementors' Guide Update Editor's last Call Section 6.58

    So far as I can tell, NOTHING BREAKS if the MG retains its own local
time base forever --- regardless of how far off it might be from "world
time".

Just my opinion,

---

From: Troy Cauble <[email-masked]>
Date: Thu, 10 May 2001 18:58:28 -0400

I strongly agree.  There is no need synchronize 
the MG and MGC's sense of time.

-troy

---

From: "Paul Long" <[email-masked]>
Date: Thu, 10 May 2001 19:00:42 -0500

Christian,

I've got a few more additions. Is it too late? These are mostly just a
summary of the things I've had resolved recently on the reflector. Here are
HTML and Word pages of the same content. (The HTML page doesn't render too
well using Netscape. I guess because it was generated by Word. :-)

http://www.packetizer.com/people/plong/IGContribs.htm
http://www.packetizer.com/people/plong/IGContribs.doc

Paul Long
ipDialog, Inc.

-----Original Message-----

G'Day all,

It can be found at:

Cheers, Christian

---

From: Christian Groves <[email-masked]>
Date: Fri, 11 May 2001 12:00:13 +1000

G'Day Paul,

These additions look OK to me with the following comments:
ALF not defined:
The note you propose should be in D.1 I've also modified the text:
"ALF is a set of techniques that allow an application, as opposed to a
stack, to affect how messages are sent to the other side. A typical ALF
technique is to allow an application to change the order of messages
sent when there is a queue AFTER it has queued them.  There is no formal
specification for ALF. The procedures in Annex D.1 define ALF behaviour
for the H.248 protocol."

Source Address:
Added a "For example" at the front of the changed line. Section 9 we've
tried to keep as transport independent as possible.

TimeStamp in registration request and reply:
I've added this to the existing 6.58 correction.

Error Descriptor location:
I've added this to the existing 6.33 correction.

Cheers, Christian

---

From: Christian Groves <[email-masked]>
Date: Fri, 11 May 2001 13:03:41 +1000

G'Day Chuong,

Your problem has been fixed with the removal of update to the 7.2.8
text.

Cheers, Christian

Chuong Nguyen wrote:
>               The paragraph where the word "optional" was used - to me
> it meant that not
>               all ServiceChange Method requires TimeStamp.  Then
> follow by the "registration"

---

From: Christian Groves <[email-masked]>
Date: Fri, 11 May 2001 12:42:39 +1000

G'Day Paul,

Please my comments below.

Cheers, Christian

> is technically a clarification and not a correction so it should go in

[CHG] Its not a clarification as it changes the syntax. As it was
already approved in the first IG I do not particular want to change it
was its not broken.

> such a thing, but is this a necessary constraint? Was this intended?

[CHG] Bharat asked this to be added so he can answer you on this. I'm
quite happy to remove the "UDP as a transport" because I don't like
trying H.248/Megaco procedures to transports.

> change "Parsers should accept whitespace..." to "Parsers shall accept
[CHG] Any complaints from ABNF gurus on this? Tom what's your call?

---

From: "Paul Long" <[email-masked]>
Date: Fri, 11 May 2001 09:47:08 -0500

Christian,

Here are my responses to your comments.

Item 6.16: It won't hurt to leave those parentheses in, but they do not
change the syntax. ABNF concatenation has higher precendence (are
"stickier") than alternation so these two constructs express exactly the
same thing:
	digitMapRange        = ("x" /  LWSP "[" LWSP digitLetter LWSP "]" LWSP )
	digitMapRange        = ("x" / (LWSP "[" LWSP digitLetter LWSP "]" LWSP))
A good analogy are the addition and multiplication operators in C. In the
same way that the above expressions are equivalent, so are the following
expressions equivalent:
	X = A +  B * C * D * E;
	X = A + (B * C * D * E);
Notice that in addition to digitMapRange, the hexpart, alternativeValue,
digitMap, and EOL constructs all exploit this ABNF precedence rule. If you
believe that digitMapRange needs to be fixed, then these other constructs
also need to be fixed.

Here is the relevant text from RFC2234:
3.10 Operator Precedence

   The various mechanisms described above have the following precedence,
   from highest (binding tightest) at the top, to lowest and loosest at
   the bottom:

        Strings, Names formation
        Comment
        Value range
        Repetition
        Grouping, Optional
        Concatenation
        Alternative
<<<<

Also, the outer parentheses around a rule definition may debatably improve
readability but are not required. Kinda bugs me that sometimes they are
used, sometimes they are not. Not a big deal but stylistically inconsistent.
This is the convention I'd personally like to see applied consistently
throughout the ABNF:
	digitMapRange        = "x" /  LWSP "[" LWSP digitLetter LWSP "]" LWSP

Item 6.58: Are we limiting the specification of a ServiceChangeAddress to
just UDP because it would be "too hard" to implement for TCP (a couple more
states in a state machine?) or because there is an inherent reason why it
only makes sense to use it with an unreliable channel? If the latter, let's
call it an "unreliable channel" and not "UDP," thus removing
transport-specific text from the spec; if the former, I'd recommend we
remove the limitation altogether and revert back to the original text.

Item 11.6: The problem I have with saying that "Parsers >>should<< accept
whitespace..." (emphasis mine) is that this appears to be backing off the
requirement in the ABNF that parsers _shall_ accept white space. See the
second LWSP, below? At best, this sounds funny; at worst, contradictory.
	localDescriptor      = LocalToken LBRKT octetString RBRKT
	LBRKT                = LWSP %x7B LWSP

(Re: "G'Day". Like, are you an Aussie or something? :-)

Paul Long
ipDialog, Inc.

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, May 10, 2001 9:43 PM
To: Paul Long
Cc: megaco ietf; [email-masked]
Subject: Re: Implementors' Guide Update Editor's last Call

G'Day Paul,

Cheers, Christian

---

From: Troy Cauble <[email-masked]>
Date: Fri, 11 May 2001 15:48:05 -0400

> a correction please provide the detailed solution or exact changes that

The header for section 7.2 is a copy of the header for 7.1.
7.2 addresses a different issue.

-troy

---

From: Christian Groves <[email-masked]>
Date: Mon, 14 May 2001 03:50:42 +1000

G'Day Paul,

For items 6.16 and 11.6 i'll let Tom make the call on what he wants
here. I'm more of a ASN1 supporter so I'd prefer somebody who did the
ABNF to make the calls on it in this case.
6.58 is being discussed in another thread.

Cheers, Christian

PS: Yes the G'Day is a give away, I'm an Aussie.