Subject: RE: Implementors' Guide Update Editor's last Call

From: "Kaul, Bharat" <[email-masked]>
Date: Fri, 11 May 2001 10:32:51 -0700

Hi Paul,

  For 6.58 in implementation guide the reason it is UDP only is that for an
MG using TCP as transport it is of no use to have ServiceChange Address
specified in it as MG does not have a TCP server where MGC will connect to.
This implies  for TCP as transport MGC should not look at ServiceChange
Address either. The standards didn't say any of this anywhere and there is a
whole series of emails on this indicating possibility of interop issues. And
in order to end this silence of the standards, the part was added in
implementors guide.  

- Bharat

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

G'Day Paul,

Please my comments below.

Cheers, Christian

Paul Long wrote:
> 
> 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.

[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.

> 
> 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?

[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.

> 
> Item 11.6: I know this is only clarifying text, but you should probably
> change "Parsers should accept whitespace..." to "Parsers shall accept
> whitespace..."
[CHG] Any complaints from ABNF gurus on this? Tom what's your call?

> 
> 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,
> 
> 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: "Paul Long" <[email-masked]>
Date: Fri, 11 May 2001 12:50:08 -0500

Bharat,

But if an MG specified a ServiceChangeAddress, that would imply that it
would indeed be able to listen on that port for a TCP connection to be
established. I just don't understand why we need to constrain something in
the standard that will naturally be controlled by the signaling entity.
Basically, if you can't do something, don't signal that you can. Maybe you
are saying that an MG cannot inherently ever be a "TCP server." Is that it?
If so, why can't it?

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kaul, Bharat
Sent: Friday, May 11, 2001 12:33 PM
To: 'Christian Groves'; Paul Long
Cc: megaco ietf
Subject: RE: Implementors' Guide Update Editor's last Call

Hi Paul,

- Bharat

---

From: "Paul Long" <[email-masked]>
Date: Fri, 11 May 2001 13:26:55 -0500

Bharat,

Someone just told me via private email that the problem isn't necessarily
with the MG but with the MGC. We don't want to require the MGC to ever have
to initiate a connection to the MG, and this would otherwise be the only
situation where it would have to. I don't have to understand why, I'll just
assume that there are real good reasons. :-)

How about changing the wording, then. I thought the original sentence was
kind of awkward, anyway. How about changing from this:

"For UDP as a transport, the MG may specify the transport
ServiceChangeAddress to be used by the MGC for sending messages in the
ServiceChangeAddress parameter in the input ServiceChangeDescriptor."

to this:

"In the ServiceChangeAddress parameter of the ServiceChangeDescriptor, the
MG may specify the transport address to be used by the MGC for sending
request messages.  So that the MGC does not have to initiate a new
connection, however, the MG shall not specify a ServiceChangeAddress if the
association is using a reliable, connection-oriented transport."

This explains the requirement somewhat and eliminates the reference to a
particular transport. I would have just said, "connection-oriented
protocol," since that would mean TCP in the case of IP, but that term is not
used elsewhere in the spec, so I also said "reliable." From a quick online
search, it appears that "reliable" and "connection-oriented" are synonymous,
but we can state both just to be absolutely clear. What do you think about
this new wording?

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Paul Long
Sent: Friday, May 11, 2001 12:50 PM
To: megaco ietf
Subject: RE: Implementors' Guide Update Editor's last Call

Bharat,

Paul Long
ipDialog, Inc.

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

Hi Paul,

- Bharat