Re: Action item from yesterday's meeting
Senthil Sivakumar <[email protected]> Wed, 01 Dec 2004 13:52:56 -0800
| Newsgroups | gmane.ietf.midcom |
|---|---|
| Message-ID | <[email protected]> |
At 09:49 PM 12/1/2004 +0100, Juergen Quittek wrote: >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. With twice NAT the mappings are not set up in advance. In the example that we were discussing w.r.t SIP, the invite causes the calling UA to request NAT to set up a mapping for its local address/port. In the same fashion, the called UA will request the NAT to set up a mapping for its local address/port before sending 200 OK and use that information in its 200 OK. Thanks Senthil >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 > > >