Re: Action item from yesterday's meeting
Juergen Quittek <[email protected]> Wed, 01 Dec 2004 21:49:15 +0100
| Newsgroups | gmane.ietf.midcom |
|---|---|
| Message-ID | <[email protected]> |
Suresh,
--On 01.12.2004 6:30 Uhr -0800 Pyda Srisuresh wrote:
> Juergen,
>
> Senthil makes several good points about the configuration and use of V4
> twice-NATs. The scenarios that Senthil points out are real customer scenarios.
> You propose a proxy solution, which doesnt require a NAT or an ALG. This is
> just like what you did with the FTP. Note, the objective is to externalize ALGs
> from firewall and NAT middleboxes using midcom. Your dislike for twice-NAT
> configurations shoudl not be a reason why midcom MIB will not support twice
> NAT.
This is a misunderstanding. I like twice-NATs and we are working with them
in our lab on a daily basis. What I do not like is restricting twice-NAT
usage to the case where all bindings are set up in advance. This would be a
very limited approach.
Thanks,
Juergen
--
Juergen Quittek [email protected] Tel: +49 6221 90511-15
NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de
> Please see my specific comments below inline.
>
> regards,
> suresh
>
> --- Juergen Quittek <[email protected]> wrote:
>
>> Hi Senthil,
>>
>> --On 30.11.2004 11:31 Uhr -0800 Senthil Sivakumar wrote:
>>
>> > Thanks for the reply.. Some comments inline..
>> >
>> >
>> >
>> >>>> In case of an INVITE message issues by the local terminal,
>> >>>> the SIP UA could operate as follows:
>> >>>>
>> >>>> 1. scan the SDP payload and extract the local terminal's address
>> >>>> parameters A0 (IP address, port number)
>> >>>> 2. request address translation of these local address parameters
>> >>>> at the NAT using the MIDCOM protocol.
>> >>>> Here both semantics under discussion are similar.
>> >>>> The only input you have is the local terminal address A0.
>> >>>> This is sent to the NAT as input parameter
>> >>>> The NAT returns the translated external parameters A2.
>> >>>> If you want to apply a more tight security policy, you use
>> >>>> the Policy Reserve Rule (PRR) transaction that does not yet
>> >>>> enable NAT service for the address and that may block early
>> >>>> media. Otherwise you would use the Policy Enable Rule (PER)
>> >>>> that immediately enables the NAT service.
>> >>>> 3. Then the original invite message needs to be patched replacing
>> >>>> the original address parameters A0 with the parameters A2 returned
>> >>>> by the NAT. The patched message if forwarded following SIP routing
>> >>>> rules.
>> >>>> 4. On receipt of an OK message, the UA scans the SDP payload and
>> >>>> extracts the other terminal's address parameters A3.
>> >>>
>> >>> How did the UA get A3 and not A1? The UA would only scan the invite
>> >>> messages and not other messages to replace its local address with
>> >>> the natted address?
>> >>
>> >> I am sorry for not explaining this issue sufficiently.
>> >>
>> >> Please note that SIP is quite flexible. The callee's UA may attach
>> >> the SDP payload specifying its address and codec parameters to the
>> >> 180 RINGING message as well as to the 200 OK message or other messages.
>> >> For this example, I assume that the SDP is carried by the 200 OK
>> >> message, but the example works analogously for other messages carrying
>> >> the callee's SDP payload.
>> >>
>> >>
>> >> The OK message is sent by the called external terminal. In the SDP
>> >> payload of the OK message the terminal states at which IP address
>> >> and port number it is expecting to receive data. This is the A3
>> >> information. A1 may not have been chosen at the NAT until this point
>> >> in time.
>> >
>> > OK, I think my question was, why would not this UA query the NAT
>> > to get the translated information for its local address/port. So when the
>> > initiated UA receives the OK, it is A1 and not A3.
>> >
> [Suresh] Yup, I agree. A midcom agent on the UA would want to do this to ensure
> the payload is consistent with NAT session translations.
>
>> > Secondly, the reason for twice NAT, most likely is because there is
>> > another A3 in A0's realm. How would the NAT distinguish between
>> > the two A3's? If the query was originated by A3 in the different realm
>> > then NAT can distinguish between these two requests because of the
>> > domains the requests are originating from.. (Is that a supported scenario
>> > where you have two A3s one in each realm?.).
>>
> [suresh] Right. Senthil brings up a good point. Traditional-NAT assumes
> overlapping realms - Private realm overlapping external realm. Twice-NAT
> address realms can be non-overlapping or partially overlapping. For simplicity
> I was taking the case of non-overlapping realms for twice-NAT in my examples.
> However, partially overlapping address realms is a supported twice-NAT
> scenario.
>
>> Well, these are very good questions concerning the discussed example
>> scenario. However, this is not the way anyone would build a network.
>
> [suresh] Juergen - this is not true. There are real customers with networks
> that use twice-NAT. Many vendors support twice-NAT.
>
>> If all UAs on both sides of the NAT can already exchange SIP messages
>> without any proxy in between, then there are already NAT bindings
>> established for every pair of one internal and one external terminal.
>
> [suresh] That is a large brush and not true. Twice-NAT translates both
> end-points. Just because one of the endpoints used static mapping doesnt mean
> that all endpoints are statically fixed outside their realm. There are also
> limitations on permitted session directions for these address mappings.
>
>> This is not a scalable solution.
>>
> [suresh] That depends on what the motivation for a solution is.
>
>> A real scenario would increase scalability by using SIP servers for
>> which all internal servers have established NAT sessions with a set of
>> external ones. In a more simple scenario you would have just one
>> SIP server (potentially co-located with the NAT) with addresses
>> in both realms.
>>
>> Then the SIP server(s) would know both realms and would have no
>> problem with identifying the realm to which an address belongs.
>>
>
> [suresh] Juergen - it sounds like, you are proposing a proxy solution in place
> of ALG. A proxy that understands both realms donot require a NAT. That is not
> the objective here. The objective of Midcom is to externalize ALGs from
> firewall and NAT middleboxes.
>
> regards,
> suresh
>> Thanks,
>>
>> Juergen
>>
>>
>> > Thanks
>> > Senthil
>> >
>> >
>> >> In step 5, A3 and A0 are inout parameters and A1 is returned by the
>> >> middlebox. Then the UA translates the SDP payload of the OK message
>> >> (replacing A3 with A1) and forwards the OK message to the application.
>> >>
>> >> Thanks,
>> >>
>> >> Juergen
>> >>
>> >>> Senthil
>> >>>> 5. Now a mapping for the reverse direction need to be established
>> >>>> using the MIDCOM protocol again. According to the current
>> >>>> semantics, the SIP UA sends A0 and A3, the terminal's address
>> >>>> parameters, with Suresh's semantics it would be A2 and A3.
>> >>>>
>> >>>> For the reverse direction (incoming call, the procedure is similar.
>> >>>>
>> >>>> This all works for RTP, RTSP, TCP, etc.
>> >>>>
>> >>>> Thanks,
>> >>>>
>> >>>> Juergen
>> >>>> --
>> >>>> Juergen Quittek [email protected] Tel: +49 6221
>> 90511-15
>> >>>> NEC Europe Ltd., Network Laboratories Fax: +49 6221
>> 90511-55
>> >>>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
>> http://www.netlab.nec.de
>> >>>>
>> >>>>>
>> >>>>> On 11/26/04 2:07 PM, "Pyda Srisuresh" <[email protected]> wrote:
>> >>>>>
>> >>>>>> Juergen,
>> >>>>>>
>> >>>>>> The solution you refer to is a transparent proxy solution (even though
>> >>>>>> Clavister.com refers to it as ALG). Check out the last parapgraph in
>> >>>>>> Clavister
>> >>>>>> web site which confirms that this is a proxy solution
>> >>>>>> (http://www.clavister.com/technology).
>> >>>>>>
>> >>>>>> The FTP-ALG that I am refering to is not a proxy. Unlike the proxy,
>> the
>> >>>>>> FTP-ALG
>> >>>>>> does not terminate FTP sessions with client and server and does not
>> inject
>> >>>>>> packets of its own. The ALG simply inspects FTP control packets and
>> >>>>>> modifies
>> >>>>>> payloads containing PORT/EPRT/PASV/EPSV commands as appropriate and
>> >>>>>> sets up
>> >>>>>> NAT-sessions on the NAT device. This is what NAT vendors typically do.
>> >>>>>>
>> >>>>>> I believe, what you & Martin are saying is that a) the transparent
>> proxy
>> >>>>>> solution exists for FTP, so vendors should use the proxy solution
>> >>>>>> instead of
>> >>>>>> the FTP ALG, and b) The FTP ALG example I gave cannot be used to
>> >>>>>> illustrate a
>> >>>>>> problem with the midcom semantics, because it is a solved problem
>> (proxy
>> >>>>>> solution). I disagree with this argument because what we are talking
>> >>>>>> about in
>> >>>>>> this WG is not replacing ALGs with proxies, but rather use Midcom to
>> >>>>>> externalize ALG intelligence. For that reason, the FTP ALG example is
>> >>>>>> a good
>> >>>>>> way to illustrate the problem with the sematics in the MIB draft. Let
>> >>>>>> me see
>> >>>>>> if
>> >>>>>> I can reword the problem description differenctly. Consider the
>> following
>> >>>>>> diagram.
>> >>>>>>
>> >>>>>> +----------+
>> +----------+
>> >>>>>> | internal |A0<-->A1 +-----------+ A2<-->A3|
>> external |
>> >>>>>> | endpoint +----- Internal -+ middlebox +- External -------+
>> endpoint |
>> >>>>>> | (A0) | realm +-----------+ realm | (A3)
>> |
>> >>>>>> +----------+
>> +----------+
>> >>>>>>
>> >>>>>> An application client, or an application server or a midcom agent
>> >>>>>> acting as
>> >>>>>> ALG
>> >>>>>> for a given application can know the session tuples in one realm or
>> the
>> >>>>>> other.
>> >>>>>> Only the NAT middlebox knows the combined session tuples (i.e.,
>> session
>> >>>>>> tuples
>> >>>>>> in either realm), as NAT sets up the translation sessions. Midcom
>> >>>>>> agent can
>> >>>>>> request NAT middlebox to set up NAT sessions and learn of the
>> translation
>> >>>>>> parameters, but it cannot know the translation parameters apriori.
>> >>>>>>
>> >>>>>> In a traditional NAT, A1 and A3 are the same. The current semantics
>> assume
>> >>>>>> that
>> >>>>>> midcom agent knows to provide A0 & A1 (as defined above) as input for
>> >>>>>> all the
>> >>>>>> PRR/PER queries. This is a reasnable assumption for traditional NAT.
>> >>>>>> But, the
>> >>>>>> problem is easy to see when A0 is different from A2 and A1 is
>> >>>>>> different from
>> >>>>>> A3. That is why I took the case of twice NAT and FTP-ALG for PORT
>> >>>>>> command to
>> >>>>>> illustrate the problem. But, the problem is neither specific to
>> >>>>>> twice-NAT nor
>> >>>>>> the FTP-ALG. You can conjure up several scenarios with a) applications
>> >>>>>> that
>> >>>>>> require an ALG and a) traversing bi-directional NAT or NAT-PT or a NAT
>> >>>>>> with a
>> >>>>>> combination of several types of address maps, and c) the midcom agent
>> only
>> >>>>>> knows the session tuples in external realm(i.e., A2 & A3). You will
>> >>>>>> quickly
>> >>>>>> note that assuming A0 & A1 alone as input will not be adequate for
>> these
>> >>>>>> apps.
>> >>>>>> There must be an option to select the input parameter realm. This is
>> >>>>>> exactly
>> >>>>>> what I proposed. Nothing more to it.
>> >>>>>>
>> >>>>>> Incidentally, this also the issue that I believe, Bob Penfield raised
>> >>>>>> in the
>> >>>>>> email dated 08/05 (You can refer the midcom archives fo rthis e-mail).
>> >>>>>> Here is
>> >>>>>> an excerpt from the e-mail.
>> >>>>>>
>> >>>>>>> 2) Step 3 of the PRR (section 6.4) states that the SNMP manager sets
>> the
>> >>>>>>> internal endpoint address components. This is correct if the
>> signaling
>> >>>>>>> (going thru the MIDCOM client) is outbound. If the signaling is
>> inbound,
>> >>>>>> it
>> >>>>>>> contains the external endpoint addresses.
>> >>>>>> What I am talking about here is the case where the signaling
>> >>>>>> protocol (e.g.
>> >>>>>> SIP) carries the endpoint media addresses for a media session (e.g.
>> in
>> >>>>>> SDP).
>> >>>>>> A SIP INVITE coming from the external network will hve SDP that
>> >>>>>> contains
>> >>>>>> the
>> >>>>>> address of the external endpoint. The internal endpoint media
>> >>>>>> addresses
>> >>>>>> won't be know until the 200 OK response comes from the internal
>> >>>>>> endpoint.
>> >>>>>>
>> >>>>>> Hope this helps explain the problem better.
>> >>>>>>
>> >>>>>> regards,
>> >>>>>> suresh
>> >>>>>>
>> >>>>>> --- Juergen Quittek <[email protected]> wrote:
>> >>>>>>
>> >>>>>>> Suresh,
>> >>>>>>>
>> >>>>>>> --On 24.11.2004 17:33 Uhr -0800 Pyda Srisuresh wrote:
>> >>>>>>>
>> >>>>>>>> Juergen,
>> >>>>>>>>
>> >>>>>>>> If you are saying that FTP-ALG is not required, that is simply not
>> true.
>> >>>>>>>
>> >>>>>>> I was just saying that I do not see a problem with the PORT command
>> >>>>>>> as long as PASV is available.
>> >>>>>>>
>> >>>>>>> Here is a quote from RFC 1579 written by Steve Bellovin in 1994:
>> >>>>>>>
>> >>>>>>> "Recommendation
>> >>>>>>>
>> >>>>>>> We recommend that vendors convert their FTP client programs
>> >>>>>>> (including FTP proxy agents such as Gopher [3] daemons) to use
>> >>>>>>> PASV
>> >>>>>>> instead of PORT. There is no reason not to use it even for
>> non-
>> >>>>>>> firewall transfers, and adopting it as standard behavior will
>> make
>> >>>>>>> the client more useful in a firewall environment."
>> >>>>>>>
>> >>>>>>> I do not say that ftp-ALGs are not required at all.
>> >>>>>>> What I say is that enabling the PORT command across a NAT is not a
>> >>>>>>> sufficient reason for installing a ftp-ALG.
>> >>>>>>>
>> >>>>>>> This does not exclude that ftp-ALGs may be very useful for solving
>> >>>>>>> other problems.
>> >>>>>>>
>> >>>>>>> - One of them is firewall control. In a highly secured/restricted
>> >>>>>>> environment even the PASV command might need a ftp-ALG in order
>> >>>>>>> to work across a firewall. Actually, Martin and I implemented
>> >>>>>>> such an ALG two years ago.
>> >>>>>>>
>> >>>>>>> - Considering the PASV command as more secure for the client and the
>> >>>>>>> PORT command as more secure for the server, the ideal ftp-ALG
>> >>>>>>> coverts a PASV command from the client into a PORT command to the
>> >>>>>>> server as for example described at
>> >>>>>>> <http://www.clavister.com/manuals/ver8.4x/manual/ftp_alg.htm>.
>> >>>>>>>
>> >>>>>>> - Another reason for an ftp-ALG may be policy control. The ALG
>> >>>>>>> could limit ftp access to a given set of servers and/or clients.
>> >>>>>>>
>> >>>>>>> - ... and probably there are more good reasons for using ftp-ALGs.
>> >>>>>>>
>> >>>>>>>> Users have the option to use PASV command. But, they dont have to.
>> >>>>>>>> PORT and
>> >>>>>>> EPRT
>> >>>>>>>> commands are still supported FTP commands. NAT vendors donot mandate
>> >>>>>>>> that
>> >>>>>>> users
>> >>>>>>>> use PASV command.
>> >>>>>>>>
>> >>>>>>>> PORT command simply illustrates the problem. Demonizing PORT commnd
>> does
>> >>>>>>> not
>> >>>>>>>> make the problem non-existant. Have a good weekend.
>> >>>>>>>
>> >>>>>>> I did not intend to demonize anything - at least no further than
>> >>>>>>> RFC 1579 did already ;-)
>> >>>>>>>
>> >>>>>>> Best regards,
>> >>>>>>>
>> >>>>>>> Juergen
>> >>>>>>> --
>> >>>>>>> Juergen Quittek [email protected] Tel: +49 6221
>> 90511-15
>> >>>>>>> NEC Europe Ltd., Network Laboratories Fax: +49 6221
>> 90511-55
>> >>>>>>> Kurfuersten-Anlage 36, 69115 Heidelberg,
>> >>>>>>> Germany http://www.netlab.nec.de
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>> regards,
>> >>>>>>>> suresh
>> >>>>>>>>
>> >>>>>>>> --- Juergen Quittek <[email protected]> wrote:
>> >>>>>>>>
>> >>>>>>>>> Suresh,
>> >>>>>>>>>
>> >>>>>>>>> --On 24.11.2004 8:37 Uhr -0800 Pyda Srisuresh wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Martin,
>> >>>>>>>>>>
>> >>>>>>>>>> Melinda suggested that I come up with an example to illustrate
>> >>>>>>>>>> that the
>> >>>>>>>>> current
>> >>>>>>>>>> sematics and MIB is problematic for certain types of NATs. I did
>> this
>> >>>>>>> with
>> >>>>>>>>> FTP
>> >>>>>>>>>> and PORT command in twice NAT scenario. You claim the FTP example
>> >>>>>>>>>> is not
>> >>>>>>>>> real.
>> >>>>>>>>>> That simply is not true. FTP is a common ALG used with NATs and is
>> >>>>>>>>>> very
>> >>>>>>>>> real.
>> >>>>>>>>>> That you dont like the FTP ALG would not make the problem go away.
>> >>>>>>>>>> There
>> >>>>>>> is
>> >>>>>>>>> a
>> >>>>>>>>>> real problem with the MIB, the way it is. And, there is a simple
>> >>>>>>>>>> fix to
>> >>>>>>> it.
>> >>>>>>>>>>
>> >>>>>>>>>> Hope you understand. Thanks.
>> >>>>>>>>>
>> >>>>>>>>> I do understand that you solve the problem of ftp using the PORT
>> >>>>>>>>> command.
>> >>>>>>>>> But you are solving a problem, that has been solved already a long
>> time
>> >>>>>>> ago.
>> >>>>>>>>> There is the ftp PASV command and every decent ftp client supports
>> >>>>>>>>> (if not
>> >>>>>>>>> prefers) it. Therefore, I still do not see a reason for changing
>> the
>> >>>>>>>>> semantics.
>> >>>>>>>>>
>> >>>>>>>>> Thanks,
>> >>>>>>>>>
>> >>>>>>>>> Juergen
>> >>>>>>>>> --
>> >>>>>>>>> Juergen Quittek [email protected] Tel: +49 6221
>> >>>>>>>>> 90511-15
>> >>>>>>>>> NEC Europe Ltd., Network Laboratories Fax: +49 6221
>> >>>>>>>>> 90511-55
>> >>>>>>>>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
>> >>>>>>> http://www.netlab.nec.de
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>> regards,
>> >>>>>>>>>> suresh
>> >>>>>>>>>>
>> >>>>>>>>>> --- Martin Stiemerling <[email protected]> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> Hi Cullen,
>> >>>>>>>>>>>
>> >>>>>>>>>>> --On Dienstag, 23. November 2004 17:31 Uhr -0800 Cullen Jennings
>> >>>>>>>>>>> <[email protected]> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>|
>> >>>>>>>>>>>| I have not been participating closely I the group so I may have
>> a
>> >>>>>>>>> complete
>> >>>>>>>>>>>| clueless opinion here but ... It seems that people are
>> >>>>>>>>>>> continuing to
>> >>>>>>>>>>>| deploy things like twice NAT, if we can make the protocol work
>> in
>> >>>>>>> these
>> >>>>>>>>>>>| cases without causing major complexity or big issues to the
>> >>>>>>>>>>> protocol,
>> >>>>>>>>> why
>> >>>>>>>>>>>| wouldn't we? It seemed to me that Srisuresh was proposing that
>> >>>>>>>>>>> a few
>> >>>>>>>>>>>
>> >>>>>>>>>>> Just to make it clear: The MIDCOM MIB already supports twice-NATs
>> and
>> >>>>>>> the
>> >>>>>>>>>>> semantics did so from the beginning. So in this sense there is
>> >>>>>>>>>>> anyway
>> >>>>>>> no
>> >>>>>>>>>>> change needed.
>> >>>>>>>>>>>
>> >>>>>>>>>>>| simple changes could make the protocol be about the same in the
>> >>>>>>>>>>> case
>> >>>>>>> we
>> >>>>>>>>>>>| currently have plus make it usable for a few more cases.
>> >>>>>>>>>>>
>> >>>>>>>>>>> The case presented do not represent a real case in my opinion.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Martin
>> >>>>>>>>>>>
>> >>>>>>>>>>>|
>> >>>>>>>>>>>|
>> >>>>>>>>>>>| On 11/16/04 10:19 AM, "Melinda Shore" <[email protected]> wrote:
>> >>>>>>>>>>>|
>> >>>>>>>>>>>|> I'm intending to get this issue closed in the next week (or
>> >>>>>>>>>>> sooner,
>> >>>>>>>>>>>|> if possible). Juergen and Suresh have presented their
>> >>>>>>>>>>> concerns, and
>> >>>>>>>>>>>|> if there are other people who have opinions or questions or
>> even
>> >>>>>>>>>>>|> just want to indicate how they're leaning, that would be a big
>> >>>>>>>>>>> help.
>> >>>>>>>>>>>|>
>> >>>>>>>>>>>|> Thanks,
>> >>>>>>>>>>>|>
>> >>>>>>>>>>>|> Melinda
>> >>>>>>>>>>>|>
>> >>>>>>>>>>>|>
>> >>>>>>>>>>>|> _______________________________________________
>> >>>>>>>>>>>|> midcom mailing list
>> >>>>>>>>>>>|> [email protected]
>> >>>>>>>>>>>|> https://www1.ietf.org/mailman/listinfo/midcom
>> >>>>>>>>>>>|
>> >>>>>>>>>>>|
>> >>>>>>>>>>>|
>> >>>>>>>>>>>| _______________________________________________
>> >>>>>>>>>>>| midcom mailing list
>> >>>>>>>>>>>| [email protected]
>> >>>>>>>>>>>| https://www1.ietf.org/mailman/listinfo/midcom
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>> midcom mailing list
>> >>>>>>>>>>> [email protected]
>> >>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/midcom
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> =====
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> _______________________________________________
>> >>>>>>>>>> midcom mailing list
>> >>>>>>>>>> [email protected]
>> >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/midcom
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> =====
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> _______________________________________________
>> >>>>>>>> midcom mailing list
>> >>>>>>>> [email protected]
>> >>>>>>>> https://www1.ietf.org/mailman/listinfo/midcom
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> =====
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> midcom mailing list
>> >>>>>> [email protected]
>> >>>>>> https://www1.ietf.org/mailman/listinfo/midcom
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> midcom mailing list
>> >>>> [email protected]
>> >>>> https://www1.ietf.org/mailman/listinfo/midcom
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>>
>>
>> _______________________________________________
>> midcom mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/midcom
>>
>
>
> =====
>
>
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom