Subject: Re: draft-ietf-megaco-merged-01.txt

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 18 Aug 2000 09:05:00 -0500

I left off responding to this until I saw other reactions.  Would anyone
else care to comment on the proposition that the primary function of mId in
the message header is to serve as a logical handle to the control session,
rather than as an actual address to which responses must be sent?  I see
Naren's question (b) as one way to achieve differentiation of virtual MGs
but not necessarily the only one, so question (a) is the key one.

One other response below.

> -----Original Message-----
> From: Naren Tulpule [mailto:[email-masked]]
> Sent: Wednesday, August 16, 2000 2:06 PM
> To: [email-masked]
> Subject: Re: draft-ietf-megaco-merged-01.txt
>
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> >
> > 1. I think that there is an error in Appendix A, step 15. The
> > mId should be
> > [125.125.125.111].
> >
> [PTT]
> Certainly that would be consistent with the mId shown in step 17.
>
> [[ NAREN ]] Is it the consensus now that
> a) MID _MUST_ be unique for an MG or MGC, and treated as a
> logical handle
> irrespective of any changes in ports etc; and
> b) Virtual MGs _MUST_ distinguish themselves by a mandatory
> port part in the
> MID; and this "IP-address/name + port" MID _MUST_ not change
> (as in (a)).
> I am surprized the protocol designers did not fix even basic
> things like how
> an MG or MGC identifies a peer from MID received in a
> message. (But perhaps
> that's an "implementation detail", best left out of protocol specs :-)
>
> [PTT]
> The ABNF is more general and includes the ASN.1 as a
> possibility.  Basically
> the ABNF allows you to use either SDP or Annex C, whereas the
> ASN.1 assumes
> Annex C plus whatever packages come along to augment or replace it.
>
> [[ NAREN ]] Can you please clarify how ABNF allows us to use
> annex C? I
> thought annex C was strictly for binary encoding; and SDP for
> text encoding;
> and that ABNF only specified text encoding. Are you allowed
> to embed binary
> info in text? (Certainly if annex A is to be believed, we
> have to embed text
> strings like digit maps inside the binary but now it's the
> other way too?)
> Or do you mean some unspecified equivalent of binary ID-value
> pairs in text
> encoding?
>
[PTT] I plead guilty.  I raised a possibly which is not allowed in the main
body of the protocol document.  Back a year ago, before we made the
restriction, there was a suggestion that binary data would be Base-64
encoded.

> -- Naren.
> Narendra C. Tulpule    SMTS, Trillium Digital Systems
> Ph: +1-310-442-9222              Fax: +1-310-442-1162
> 12100 Wilshire Bl #1800         Los Angeles, CA 90025
>

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 18 Aug 2000 11:01:40 -0400

Tom-PT Taylor wrote:

>
>
> I left off responding to this until I saw other reactions.  Would
> anyone else care to comment on the proposition that the primary
> function of mId in the message header is to serve as a logical handle
> to the control session, rather than as an actual address to which
> responses must be sent?

I would agree with that. Requiring responses to be sent from the same
port as commands are received on is a rather undesirable limitation IMO.

-- Flemming

> I see Naren's question (b) as one way to achieve differentiation of
> virtual MGs but not necessarily the only one, so question (a) is the
> key one.
>
> [PTT] I plead guilty.  I raised a possibly which is not allowed in the
> main body of the protocol document.  Back a year ago, before we made
> the restriction, there was a suggestion that binary data would be
> Base-64 encoded.
>
> > -- Naren.

--
Flemming Andreasen
Cisco Systems