http://blog.gmane.org/gmane.ietf.nat.behave hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.nat.behave/10473 <pre>This draft defines a websocket extension to TURN to make TURN data have the ability to transport over the websocket connection. This method could be a option to solve the Http-fallback requirement in RTCWEB. F37 The browser MUST be able to send streams and data to a peer in the presence of FWs that only allows http(s) traffic. Besides, Turn server with websokcet extension could be a general relay server for some over websocket protocol, such as BFCP over websocket or MSRP over websocket. This could satisfy some Peer to Peer scene when using these protocol in the web environment , without a specific center server. Comments and suggestions are welcome. Best Regards, Xin -----Original Message----- From: internet-drafts&lt; at &gt;ietf.org [mailto:internet-drafts&lt; at &gt;ietf.org] Sent: Tuesday, May 14, 2013 9:15 AM To: Chenxin (Xin); Chenxin (Xin) Subject: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt A new version of I-D, draft-chenxin-behave-turn-websocket-00.txt has been successfully submitted by Xin Chen and posted to the IETF repository. Filename: draft-chenxin-behave-turn-websocket Revision: 00 Title: Traversal Using Relays around NAT (TURN) Extensions for Websocket Allocations Creation date: 2013-05-13 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-chenxin-behave-turn-websocket-00.txt Status: http://datatracker.ietf.org/doc/draft-chenxin-behave-turn-websocket Htmlized: http://tools.ietf.org/html/draft-chenxin-behave-turn-websocket-00 Abstract: This document defines an extension to TURN that allows it to run over a Websocket [RFC6455] channel. This will allow a client in a restrictive network to exchange and relay media or data over the websocket. The IETF Secretariat </pre> Chenxin (Xin 2013-05-15T01:40:05 http://comments.gmane.org/gmane.ietf.nat.behave/10457 <pre>The authors of draft-penno-behave-rfc4787-5382-5508-bis have asked that it become a working group document. Please send review nits, spelling corrections, and suchlike to the authors. Please send feedback about this becoming a working group document to the chairs, authors, or list, as you feel appropriate; clear indications of 'support' or 'do not support' are appreciated. http://tools.ietf.org/html/draft-penno-behave-rfc4787-5382-5508-bis-04 -d </pre> Dan Wing 2013-05-03T22:43:23 http://comments.gmane.org/gmane.ietf.nat.behave/10451 <pre>In organizing the encoding for the SYSLOG approach, I need to decide how to define the structured data elements. Each such element is identified by an SD-ID and contains a specified set of parameters. I have eight events in all (including "invalid port detected"), and twenty different parameters. The accounting is a little different from IPFIX because some IPFIX parameters end up in the SYSLOG headers instead. One parameter is common to all of the events, a few are common to at least four of them, and the rest are more scattered. There may be some reconciliation required when I submit the SYSLOG update. The question is how to define the structured data elements. Here are the possibilities: (a) define only one structured data element, within which all parameters are optional from the point of view of SYSLOG, but individual parameters may be mandatory from the application point of view depending on the event type. Every event would use the same structured data element. (b) define one structured data element per event, with mandatory and optional parameters as required. The same parameter would then be registered formally with IANA once for each event using it. (c) variation on (a): partition the parameters amongst multiple structured data elements, more than one of which may be needed to make up a complete event report. One possible use is to group parameters relating to a given NAT type. The disadvantage is a bit longer log lengths because of the additional structured data headers. Are there any opinions on all this? SYSLOG is defined in RFC 5424. Tom Taylor </pre> Tom Taylor 2013-05-03T01:07:03 http://comments.gmane.org/gmane.ietf.nat.behave/10450 <pre>Hi, I would like to suggest a change. If I understand correctly, this document deprecates the entire RFC4008 NAT-MIB, and proposes a completely new MIB under the same name. I think this is sub-optimal. In NMS applications that support multiple devices, some of which support RFC4008 and some of which support this new MIB module, it will be potentially confusing to call them by the same name. You really have two completely different MIB modules that you are trying to sell under the same name. I think that is not a good idea. I recommend writing an RFC4008bis document to deprecate the RFC4008 NAT-MIB. Then put your proposed new MIB objects into a separate MIB module, using a different name for the newly designed MIB for managing NATs (maybe NEW-NAT-MIB, but I'd hope for something that more accurately describes the modified purpose of the MIB, maybe NAT-MONITORING-MIB) Put this in a separate RFC. I think that would be a much cleaner solution, and much more obvious what you are doing here. David Harrington ietfdbh&lt; at &gt;comcast.net +1-603-828-1401 -----Original Message----- From: behave-bounces&lt; at &gt;ietf.org [mailto:behave-bounces&lt; at &gt;ietf.org] On Behalf Of Simon Perreault Sent: Wednesday, May 01, 2013 4:31 AM To: behave&lt; at &gt;ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-06.txt Group, This version fixes MIB syntax issues and updates the security considerations section according to the recommended boilerplate. As far as we know this is ready for WGLC. Simon Le 2013-05-01 10:28, internet-drafts&lt; at &gt;ietf.org a écrit : directories. Avoidance Working Group of the IETF. Translators (NAT) -- DTN made easy, lean, and smart --&gt; http://postellation.viagenie.ca NAT64/DNS64 open-source --&gt; http://ecdysis.viagenie.ca STUN/TURN server --&gt; http://numb.viagenie.ca _______________________________________________ Behave mailing list Behave&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/behave </pre> ietfdbh 2013-05-02T23:14:47 http://comments.gmane.org/gmane.ietf.nat.behave/10448 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Additional Managed Objects for Network Address Translators (NAT) Author(s) : Simon Perreault Tina Tsou Senthil Sivakumar Filename : draft-ietf-behave-nat-mib-06.txt Pages : 82 Date : 2013-05-01 Abstract: This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for monitoring of a device capable of NAT function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat-mib-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-nat-mib-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-05-01T08:28:07 http://comments.gmane.org/gmane.ietf.nat.behave/10445 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ Behave mailing list Behave&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/behave </pre> johnsonhammond2< at >hushmail.com 2013-04-27T17:14:39 http://comments.gmane.org/gmane.ietf.nat.behave/10436 <pre>The MAP-E and LW4over6 border routers are responsible for checking that the ports assigned by the CE are within the set allocated to that CE. I think we need a NAT logging event to report detection of an out-of-range port. Tom Taylor </pre> Tom Taylor 2013-04-25T11:35:15 http://comments.gmane.org/gmane.ietf.nat.behave/10434 <pre>This draft discusses some of the problems with current TURN authentication so that it can serve as the basis for stronger TURN authentication mechanisms. comments and suggestions are welcome. Best Regards, --Authors. -----Original Message----- From: internet-drafts&lt; at &gt;ietf.org [mailto:internet-drafts&lt; at &gt;ietf.org] Sent: Tuesday, April 23, 2013 6:04 PM To: Ram Mohan R (rmohanr); Tirumaleswar Reddy (tireddy); Muthu Arul Mozhi Perumal (mperumal); Alper Yegin; Ram Mohan R (rmohanr); Alper E. Yegin; Muthu Arul Mozhi Perumal (mperumal) Subject: New Version Notification for draft-reddy-behave-turn-auth-00.txt A new version of I-D, draft-reddy-behave-turn-auth-00.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Filename: draft-reddy-behave-turn-auth Revision: 00 Title: Problems with TURN Authentication Creation date: 2013-04-23 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-reddy-behave-turn-auth-00.txt Status: http://datatracker.ietf.org/doc/draft-reddy-behave-turn-auth Htmlized: http://tools.ietf.org/html/draft-reddy-behave-turn-auth-00 Abstract: This document discusses some of the issues with TURN authentication. The IETF Secretariat </pre> Tirumaleswar Reddy (tireddy 2013-04-24T03:22:20 http://comments.gmane.org/gmane.ietf.nat.behave/10432 <pre>I think we have to add a parameter to the session records for logging at the DS-Lite AFTR. Since the source IPv4 address may not be unique, the IPv6 tunnel address should also be logged. Is there enough deployment of GW-initiated DS-Lite that we should be considering other types of tunnel identifier too? Tom Taylor </pre> Tom Taylor 2013-04-19T20:03:34 http://comments.gmane.org/gmane.ietf.nat.behave/10412 <pre>I looked over the IETF86 minutes in preparation for updating the Syslog draft and noted that a bit was missing from the discussion at the end of the logging topic. We agreed, I believe, that it might be practical to do per-session logging using Syslog in specific situations where the number of events per second was limited. As a result, per-session logging would also be added to the Syslog draft along with an applicability statement. Tom Taylor </pre> Tom Taylor 2013-04-11T15:43:16 http://comments.gmane.org/gmane.ietf.nat.behave/10409 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis Author(s) : Teemu Savolainen Jouni Korhonen Dan Wing Filename : draft-ietf-behave-nat64-discovery-heuristic-17.txt Pages : 20 Date : 2013-04-04 Abstract: This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi- interface deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-nat64-discovery-heuristic-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-04-04T07:39:25 http://comments.gmane.org/gmane.ietf.nat.behave/10395 <pre>Hi, I notice that you have used a crafted security considerations section rather than using the boilerplate available at https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security# I haven't seen anything that makes me believe the policy has changed. You really should use the boilerplate, and fill it in in the manner described. It took significant negotiation between the various slates of OPS and SEC Ads to craft the boilerplate. Some of the text in your sec cons is not consistent with best current practices. David Harrington ietfdbh&lt; at &gt;comcast.net +1-603-828-1401 -----Original Message----- From: behave-bounces&lt; at &gt;ietf.org [mailto:behave-bounces&lt; at &gt;ietf.org] On Behalf Of David Harrington Sent: Friday, March 29, 2013 4:51 PM To: simon.perreault&lt; at &gt;viagenie.ca; tina.tsou.zouting&lt; at &gt;huawei.com; ssenthil&lt; at &gt;cisco.com Cc: behave&lt; at &gt;ietf.org Subject: [BEHAVE] nat-mib-05 Hi, I ran the nat-mib-05 through libsmi tools, and it reported errors. I'm having some issues with my use if libsmi on a new machine, so there might be some false positives in my results, But I manually checked a couple and they do appear to be errors. (REVISION versus LAST-Update; NatNotifications appears to be undefined; natPoolIndex should be not-accessible) Have you run the MIB through the libsmi tools? (http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/) Have you checked the MIB against the guidelines in RFC4181? David Harrington dbharrington&lt; at &gt;comcast.net +1-603-828-1401 _______________________________________________ Behave mailing list Behave&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/behave </pre> ietfdbh 2013-04-02T03:43:50 http://comments.gmane.org/gmane.ietf.nat.behave/10394 <pre>Hi, I ran the nat-mib-05 through libsmi tools, and it reported errors. I'm having some issues with my use if libsmi on a new machine, so there might be some false positives in my results, But I manually checked a couple and they do appear to be errors. (REVISION versus LAST-Update; NatNotifications appears to be undefined; natPoolIndex should be not-accessible) Have you run the MIB through the libsmi tools? (http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/) Have you checked the MIB against the guidelines in RFC4181? David Harrington dbharrington&lt; at &gt;comcast.net +1-603-828-1401 </pre> David Harrington 2013-03-29T20:50:35 http://comments.gmane.org/gmane.ietf.nat.behave/10393 <pre>Hi all, I am the author of rsyslog (the default syslogd on most Linuxes) and have been involved in the recent syslog RFC series. David Harrington has asked my to comment on syslog scalability. With rsyslog, I routinely do around 200,000 messages per second (mps) on low-end (notebook) hardware. I know that users do much larger traffic volumes in production systems. One user report can be found in [1], where 1 million mps were processed (with an older and slower version). The message sizes affect message rate. My testing was with 60 to 80 byte messages (the usual size for linux syslog entries). As another example, I know a customer who does heavy logging of call data records, size between 0.5 and 1.5k, with around 150,000 mps. They have deliberately chosen to stick to this number so that they have headroom in case of traffic spikes. Note that in that case, the output is automatically zipped, what obviously takes some toll on processing time. They also use an older and slower version. These scenarios, as far as I know, were taken via UDP and plain TCP syslog. If TLS is used, the numbers obviously are reduced due to the extra encryption requirement. Of course, this is not syslog specific but applies to all protocols utilizing TLS (and with hardware crypto boxes the performance hit is of course much lower). Regarding TLS, I need to mention that it is supported by at least rsyslog and syslog-ng, which together have 90+ percent "market share" on Linux and Unix. Adiscon also supports TLS on Windows in our WinSyslog, EventReporter and MonitorWare Agent products. I am not sure who else has implemented it, but I am sure there are many more implementations. Actual deployments currently favor legacy TCP syslog (As described in RFC6587). There are various reasons for this; one reason customers often mention is that they run their syslog traffic in an already-secured backend environment. Plain TCP syslog is very widely deployed and supported by almost all syslog tools that have at least some market share. I hope this comment is useful. Feel free to ask if information is missing. I did *not* read many mails on this mailing list here. So I may have missed some important points. I am currently subscribed to the list and will follow up. Best regards, Rainer Gerhards [1]http://kb.monitorware.com/000-000-character-messages-sec-with-rsyslog-t10740.html </pre> Rainer Gerhards 2013-04-01T16:20:20 http://comments.gmane.org/gmane.ietf.nat.behave/10387 <pre>Can someone share some history and research backed data behind this statement at the very bottom of section 4 in RFC 6145 (IP/ICMP Translation Algorithm). The translator SHOULD make sure that the packets belonging to the same flow leave the translator in the same order in which they arrived. I'm wondering why would be acceptable for a box to reorder packets of the same flow (SHOULD vs MUST)? While TCP can cope with reordering well (seq numbers plus TCP has MSS mechanism to avoid fragmentation all together if the nodes in the path also support MSS), I would think that (at least some) apps using UDP transport would not tolerate packet reordering. So I was hoping that someone can offer some references of real research backed data rather than opinions (I would like to her opinions as well but they often differ). Even if you have ECMP in the network and if all the nodes in the end-to-end path are performing per flow load balancing over ECMP links (which should be the norm), packet reordering should not happen. If nodes are performing per-packet load balancing over ECMP links then packet reordering can occur but I would consider this bad practice (I know that some old platforms would do per packet load balancing on ECMP links though). The reason I ask this is in the context of implementing fragmentation/reassembly for MAP-E/T (although the issue extends beyond MAP). For example in distributed platforms it would make sense to implement MAP translation function in-line (in the forwarding cards) but the reassembly function in the service cards since the reassembly function adds additional complexity and buffering requirements (I understand that the fragmented traffic is small percentage of all traffic, but still...). Let say that a v6 packet arrives to a BR (from the CPE). The BR will process this packet in-line and send it out as v4. Then another number of fragmented packets of the same flow arrive -&gt; the BR process those in service blades (not in-line). While service blade is processing the fragments (reassembling them), another non-fragmented packet of the same flow arrives on the BR. This packet is processed in-line and sent out before the previously received fragments are reassembled in service blade. Now the BR has caused packet re-ordering. Why is this, according to RFC 6145) acceptable? Any feedback appreciated. Kris </pre> Poscic, Kristian (Kristian 2013-03-31T12:21:56 http://comments.gmane.org/gmane.ietf.nat.behave/10383 <pre>The two NAT logging drafts were presented at the BEHAVE meeting at IETF86 (draft-sivakumar-behave-nat-logging-06 and draft-ietf-behave-syslog-nat-logging-00). They are both WG documents and based on the feedback at the meeting, we would like to see: * an update of the table presented at the meeting (slide 6 of http://tools.ietf.org/agenda/86/slides/slides-86-behave-2.pdf). * text added to the SYSLOG and IPFIX documents explaining their applicability. * discussion on the list to reach consensus that SYSLOG and IPFIX should, or should not, send different events because of their different applicability. -d </pre> Dan Wing 2013-03-13T18:11:05 http://comments.gmane.org/gmane.ietf.nat.behave/10382 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis Author(s) : Teemu Savolainen Jouni Korhonen Dan Wing Filename : draft-ietf-behave-nat64-discovery-heuristic-16.txt Pages : 20 Date : 2013-03-12 Abstract: This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi- interface deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-nat64-discovery-heuristic-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-03-12T15:21:39 http://comments.gmane.org/gmane.ietf.nat.behave/10381 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis Author(s) : Teemu Savolainen Jouni Korhonen Dan Wing Filename : draft-ietf-behave-nat64-discovery-heuristic-15.txt Pages : 20 Date : 2013-03-10 Abstract: This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi- interface deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-nat64-discovery-heuristic-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-03-11T06:55:26 http://comments.gmane.org/gmane.ietf.nat.behave/10378 <pre>Hi, I wonder why draft-ietf-tsvwg-natsupp is not normative in draft-ietf-behave-sctpnat? Especially when I read in draft-ietf-behave-sctpnat-08.txt, Section 6, page 7: "In this case the INIT SHOULD be dropped by the NAT and an ABORT SHOULD be sent back to the SCTP host with the M-Bit set and an appropriate error cause (see [I-D.ietf-tsvwg-natsupp] for the format)." Thanks, Martin </pre> Martin Stiemerling 2013-03-07T14:59:09 http://comments.gmane.org/gmane.ietf.nat.behave/10377 <pre> Dear Philip Matthews, Jonathan Rosenberg, Dan Wing, Rohan Mahy: An IPR disclosure that pertains to your RFC entitled "Session Traversal Utilities for NAT (STUN)" (RFC5389) was submitted to the IETF Secretariat on 2013-02-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1987/). The title of the IPR disclosure is "SSH Communications Security Corporation's Statement about IPR related to RFC 5389.""); The IETF Secretariat </pre> IETF Secretariat 2013-03-05T06:24:08 http://comments.gmane.org/gmane.ietf.nat.behave/10374 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Additional Managed Objects for Network Address Translators (NAT) Author(s) : Simon Perreault Tina Tsou Senthil Sivakumar Filename : draft-ietf-behave-nat-mib-05.txt Pages : 80 Date : 2013-02-25 Abstract: This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for monitoring of a device capable of NAT function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat-mib-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-nat-mib-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-02-25T18:51:52 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.nat.behave